[14:52:57] NASSP Logging has been started by indy91 [14:53:00] hey [14:54:08] he [14:54:10] hey [14:54:23] Got 1 document so far [14:55:28] oh nice [14:55:45] https://www.dropbox.com/s/hg3s277ng3uwufr/APO%20B-072-53%20CHRON%20F6%20JUL-6-70%20JUL-7-70.pdf?dl=0 [14:56:09] it starts on page 34 of the pdf [14:56:46] this is a post-flight doc btw, talks about pre and post accident [14:57:29] yeah [14:57:43] it had a date of July 7th, so that was kind of expected [14:58:03] right [14:59:25] PDF page 64-65 has some stuff on MCC-2 targeting [15:00:20] yeah [15:00:23] brb [15:10:09] quite the good document [15:15:03] and it sounds like there will a lot in this in the Apollo 13 FIDO loop [15:22:21] good to hear [15:23:57] "Early in translunar coast, a change of philosophy was made." [15:24:29] doesn't sound like a good idea to me, haha [15:28:52] testing Apollo 8 midcourse calculations [15:29:36] not results that are as good as I hoped so far [15:30:38] using mode 3 I presume [15:31:24] mode 3 gave a bad result once, but I think it was because I had one of the numbers from the data table wrong [15:32:05] I tried my Apollo 16 MCC-2 scenario [15:32:12] mode 5 didn't return any result. I think I know why though, I had the time limits on the landing site lighting for Apollo 11 still in there [15:32:14] I built an SFP using the SCOT [15:32:52] I really need to add the page with the additional inputs [15:33:16] for Apollo 8, 10 and 11 it's fairly easy to build the prelaunch SFP [15:33:38] LOI and TLI pericynthion the same [15:34:52] and with free return trajectories the pericynthion longitude is never very far away from 180° [15:35:06] that longitude is only used in modes 1 and 4-5 anyway [15:35:27] free return and flyby assume 180° [15:35:38] as the initial guess [15:39:03] what about EMP latitude that we used to supply the old TLMCC targeting, is there an equivalent in the new TLMCC? Is it taken from the pericynthion/nodal coordinates in the SFP? [15:42:41] that's pericynthion [15:42:55] so we can use that number as the LOI pericynthion latitude [15:43:10] and for free return missions also as the TLI pericynthion latitude [15:43:24] and as a very rough estimate even for the node [15:46:05] what mission are you working on? [15:47:30] I only tried building an SFP for Apollo 16, then calculating MCCC-2 [15:47:36] MCC-2* [15:47:52] with option 5 and specific azimuth [15:48:40] but nothing happened when I clicked calculate, so maybe a wrong value on the SFP? [15:49:44] maybe one of the constants that are currently fixed for Apollo 11 [15:49:59] that caused me trouble with Apollo 8 just now as well [15:50:57] probably the constraint on the time at the landing site [15:51:48] so there is a min and max time for the time of landing site, shouldnt that be an input for opt. 4 and 5? [15:51:58] yes, it is [15:52:20] will be on additional page [15:53:05] ok [15:53:41] I think I'll just have the numbers from the main MED for the calculation on that main pagre [15:53:43] page* [15:54:02] vector time, column number, GET of TIG, configuration, SFP block number [15:54:27] there are a bunch of MEDs for additional inputs [15:56:22] I see [15:57:05] so in reality a MED was not a visual "button" that they would see [15:57:16] but just a bunch of codes they could enter [15:58:09] the Manual Entry Device was basically a computer console [15:58:33] IBM 2848 I believe [15:58:52] and the entry method were these MED codes [15:59:06] but there was only 1 physical MED, right, and all the different codes were entered at the same place? [15:59:26] maybe more than 1 MED [15:59:43] but it were 1 or more people in the RTCC doing the inputs [15:59:49] right [15:59:53] FIDO tells Dynamics what he wants [16:00:03] nearly in the same format already as the MED codes [16:00:16] and Dynamics will then have people working for him who actually do the inputs [16:00:39] Dynamics is the one who takes the inputs from the flight controllers [16:00:48] mainly FIDO, RETRO and GUIDO [16:01:31] the FIDO seems to have some cheat sheets so that he knows in what format the RTCC needs any request [16:01:47] I would hope so lol [16:02:04] still, Dynamics has to often ask again when FIDO was missing something [16:02:56] right [16:03:29] I'm trying to fix the issues with Apollo 8 mode 5, then I'll add the new page and will push the update [16:03:37] it calculates something now [16:03:41] but a 300 ft/s MCC [16:06:01] ouch [16:06:39] wouldnt you use mode 3 on Apollo 8? [16:06:55] well, 2 but I guess thats still broken [16:07:42] sure [16:07:46] but it should still work right [16:08:03] I was just testing all modes [16:08:09] right [16:08:12] not 2 and 4, pretty pointless for Apollo 8 [16:08:43] because of the LOI/DOI thing? [16:09:52] yeah [16:12:39] btw an update from UHCL on that 1st document. They are having trouble finding as it wasn't in the listed box. They are checking other boxes and will send me an update. [16:19:00] did we give them the wrong one? [16:19:31] 079-32 [16:20:35] no its the right one [16:20:47] [16:20:48] MPAD ( MISSION PLANNING AND ANALYSIS DIVISION ) INTERNAL NOTES FOR APOLLO 13 ( MISSION H-2 ) [16:21:20] Record Number: 40686, 01/01/1970 [16:22:12] ah you mean the location, yes that was it [16:25:29] yeah [16:25:33] finding a bunch of bugs [16:26:18] but mode 5 finds a good solution now [16:26:37] mode 3 as well, but somehow the TEI time is an hour late??? [16:26:54] I would understand 2 hours (one lunar orbit period) but 1? [16:51:02] interesting [16:51:13] it's the difference between a conic and a precision free return trajectory [16:51:21] time difference at node/pericynthion [17:00:59] much better [17:09:10] ah [17:09:22] it should be biased by that time difference [17:12:21] this could help my Apollo 16 test as well I guess [17:16:32] the main thing that will help you are the bug fixes and the ability to change some of the currently constant stuff, haha [17:20:55] on the bright side the flyby modes all work very well [17:21:00] and don't so many inputs [17:21:10] got a 3.6 ft/s flyby maneuver for Apollo 8 MCC-1 [17:21:15] fully optimized [17:22:00] I have such a muscle memory for starting that Apollo 11 MCC-2 scenario that I am starting that one half of the time instead of Apollo 8 MCC-1 [17:22:54] nice [17:27:43] doing more practicing with the MPT right now [17:28:54] the config/mass/trajectory update buttons, taht is only needed when 1st initializing the MPT, and then thats it? Or are there other situations where you would have to do it again? [17:32:46] mainly for initialization, yes [17:33:01] in reality there were people figuring out the actual current masses all the time [17:33:07] and occasionally there would be an update [17:33:19] e.g. in Earth orbit, updating some prelaunch estimates [17:33:25] mainly for the S-IVB I guess [17:33:44] config would be carried over with a maneuver [17:34:06] if you try and update the trajectory after you have already a bunch of maneuvers on the MPT, could that screw things up? [17:34:34] only if your trajectory has changed a bunch [17:34:43] but that was one of the main things in the last big MPT update [17:34:50] that you can update the trajectory [17:35:03] and it will integrate through coasting and maneuvers with that new initial state vector [17:35:09] the initial MPT version couldn't do that [17:36:01] hmm didnt the old MPT always use your actual position as starting point? [17:36:26] yeah, but the burn begin and end state vector never changed [17:36:30] for a maneuver [17:36:51] so if you had a maneuver in the MPT, but did some thrusting before that [17:37:06] the burn end state vector of that maneuver never changed [17:37:12] ah ok [17:37:30] it took the actual position for anything before the manuever though [17:38:15] so if if you burn (accidentally) before a string of maneuvers on the MPT, you can update the trajectory so that all your maneuvers will match up [17:39:24] yes [17:39:39] but the maneuvers in the MPT won't change their DV [17:39:53] so you will just get orbits that are not as you initially wanted [17:40:06] ok [17:40:32] so ideally if it were to happen (accidental thrusting) might as well just rebuild all your maneuvers [17:41:33] yeah [17:42:16] apparently the GPM and LOI had some special ability to account for that [17:42:33] they stored the desired orbital parameters after a burn [17:42:35] so you burn the maneuver that was on the MPT, then when your done does the MPT know your new trajectory? I guess you have to press the "trajectory update" after every burn [17:42:45] so it could then iterate on them to get the orbit still right [17:42:51] but not sure how much that was used [17:43:14] well, in reality they would confirm a maneuver [17:43:16] that doesn't work [17:43:25] confirming a maneuver is basically like replacing a maneuver [17:43:31] with the actually burned DV [17:43:42] and then later on new ground tracking leads to a new state vector update [17:43:57] but you might as well use the trajectory update button [17:44:02] right [17:44:05] simple [17:44:18] ground tracking could take a while [17:44:30] so in the mean time you wanted a new best trajectory estimate [17:45:14] trajectory update button is the equivalent of them incorporating ground tracking data? [17:45:20] yeah [17:45:26] it was a much more involved process of course [17:45:27] except us its intant [17:45:29] yeah [17:45:33] instant* [17:46:33] I mean in our case its already a simple way, I dont see why we'd need to simulate it more complex then that [17:47:26] true [17:47:37] only thing that would be interesting is the vector compare displays [17:47:52] you could check e.g. how accurate the SV in the AGC still is [17:48:13] but that would be interesting only, not super useful [17:49:10] well it could be useful when checking your P23 skills [17:52:16] for example, yeah [17:52:24] so say you want to build maneuvers on the MPT for the LM like DOI, but before you undock from the CSM, can you have the CSM MPT initialized as CSM+LM config, but the LM MPT initialized right away as LM only config? [17:52:38] I mean, I have implemented a bunch of MCC displays that are nice to have, so vector compare etc. will come eventually [17:52:51] yes [17:52:59] that's how I always did it [17:53:02] ok [17:53:08] auto update and use those for the CSM MPT [17:53:21] auto update, change config to LM alone, and that for the LM MPT [17:53:28] even if it was pre undocking [17:53:35] just the simplest way to do that [17:54:02] if I change the config then I need to also push config update [17:54:27] yeah [17:54:35] the display just has the MED quantities [17:54:47] pressing the button actually puts the value in the header of the MPT [17:55:02] ok [17:55:05] header, or block 1 [17:55:14] where all the intial values of the MPT are stored [17:55:19] blocks 2 and 16 are the maneuver data [17:55:23] 2 to 16* [17:55:24] so the initial value for which maneuvers start from [17:55:28] yep [17:56:39] config update will fail if you already have a maneuver in the table [17:56:47] as that could lead to inconsistencies [17:57:06] you have a DPS burn in there are you remove the LM from the initial config [17:57:09] no good idea :D [17:57:20] and you* [18:01:24] already a maneuver for the specific vehicle you mean? [18:01:46] like if I have CSM maneuvers that shouldnt matter I guess [18:02:03] it will always fail if you have any maneuver [18:02:14] ah ok [18:02:15] a CSM maneuver might still be docked [18:02:18] so a significant change [18:02:27] I see [18:02:32] just isn't allowed by the MPT logic [18:06:25] my LM maneuvers are not looking good on the MPT [18:06:40] hmm [18:06:47] DOI? [18:06:53] they get put right at the top with no TIG and 0 for everything else [18:07:25] yes and then to check I tried a simple maneuver with the GPM, but the same [18:08:08] maybe a bad initial config? [18:08:17] masses? [18:10:24] this is how I initialized the MPT, CSM: CSM: Columbia,AUTO, M55,M50,TUP LM: Eagle,AUTO,CFG:LM,M55,M50 (no TUP as I will do a P16) Then build all CSM maneuvers (MCC-2,LOI-1,LOI-2) then P16 and then try the LM maneuver [18:11:49] and the P16 with LOI-2? [18:12:59] try a checkout monitor, GET a bit after LOI-2 [18:13:06] well for the sake of my test I did not add LOI-2, just LOI-1 and then staright to the simple GPM maneuver with the LM after LOI-1 [18:13:14] so the P16 was done with LOI-1 (2) [18:14:34] did you have P16 working right before at all? [18:15:00] yes I had tested it last night [18:15:11] together with the space digitals [18:15:27] I compared CSM and LEM space digitals with and without the P16 [18:16:20] ok doing the checkout monitor [18:17:34] it does not calculate anything with the LEM [18:17:40] but with CSM it does [18:17:51] thats with a GET a bit after LOI-1 [18:23:09] I'll try it as well [18:23:17] I bet the P16 failed for some reason [18:25:44] unfortunately UHCL cannot locate the document [18:28:20] :( [18:28:34] and I also get no checkout monitor, so the P16 must have failed [18:30:27] I'll debug [18:34:47] oooh [18:35:19] I'm not sure what we are trying to do works [18:37:36] before it does a trajectory update it moves the state vector to present time [18:37:58] not sure quite yet what happens with the SV being so far in the future [18:41:21] so it doesnt like to do a P16 that far into the future [18:41:47] well it will move the SV to present time first [18:41:59] so still in lunar orbit but at 27h GET [18:42:04] hmm [18:42:15] and then it would generate an ephemeris for 48h [18:42:30] so the ephemeris ends at 75h GET [18:42:43] oh not good [18:42:59] so I guess thats just a general limitation of P16 [18:43:05] maybe [18:43:12] not quite sure about it yet [18:43:23] that's how I implemented it [18:43:28] but that doesn't mean it's right [18:45:16] I am going to try all this again but from a scenario close to LOI-1 [18:46:01] I guess you could add the maneuvers to the LM MPT as well [18:46:04] that will definitely work [18:46:10] right [18:46:24] but would that change the LM weight? [18:48:30] not if you do all maneuvers with the SPS [18:50:45] I wonder [18:51:09] the RTCC differentiates between a live and a static ephemeris [18:51:25] I wonder if what you are trying to do works for a static ephemeris [18:51:33] I never really understood the difference [18:51:37] but it could be for this [18:52:00] live as in, you want data about your current position etc. [18:52:02] maybe [18:53:47] well the good news about all this is I am starting to understand it more and more :D [18:54:57] I am testing near LOI and now it works [18:55:01] as expected [18:55:26] of course as you say I could of built the LM maneuvers in parallel as well [18:56:57] also, it's not handling things that happen beyond the ephemeris range correctly yet I think [18:57:50] LOI-1, is that LDPP? [18:58:03] single CSM maneuver 3.CIR,DOI [18:58:24] LOI-2 [18:58:25] yes [18:58:34] CIRularization maneuver and DOI [18:58:39] sorry, yes LOI-2 [18:59:22] thanks [18:59:39] "beyond the ephemeris range correctly" do you mean for things in general, not only P16 stuff? [19:00:38] in general [19:00:39] maybe [19:00:59] I think a recent change is that the last state vector in the ephemeris may be supplied to anything wanting it [19:01:16] so that should make a few things more work right [19:01:24] I see [19:01:41] like a maneuver calculation at a vector time beyond the ephemeris [19:01:47] so meaning the MPT is valid for 48 hours from present time as it stands [19:02:01] for low orbits [19:02:07] for high orbits it is 10 days [19:02:12] it depends on the initial state vector [19:02:19] its eccentricity and semi-major axis [19:03:22] right [19:03:24] no point in filling up the ephemeris with endless state vectors in LEO or LPO [19:03:38] and also, more than two days is quite important for TLC and TEC [19:03:47] I think that is the reason [19:06:57] ok, I think I have that time offset thing finally right with mode 3 [19:07:13] great [19:07:15] so all the expected modes work right for Apollo 8 [19:07:25] and I have DOI on the MPT [19:07:27] next is adding a page [19:07:29] looking good [19:07:30] nice [19:08:26] P17, whats taht for again? [19:08:50] just changes the numbering in the cape crossing table [19:09:10] the times when you cross either the cape or 180° in lunar orbit [19:09:22] there is a table that has those times associated to a rev number [19:10:03] you might want to change that number if you are already for a few revs in an orbit [19:10:07] then the current rev is not 1 [19:10:22] a lot of displays can take GET, maneuver or REV as an input [19:10:36] like, generate the sunrise/sunset table for revs 9 to 15 or so [19:11:05] only necessariy if it is off [19:11:20] I see [19:11:26] not relevant if you are in TLC [19:15:55] does REFSMMAT,HEAD-UP/DOWN in the DMT (MED U20) have any function yet? [19:16:14] is that to select which REFSMMAT that the display uses? [19:17:50] yes, the RTCC stores several REFSMMAT types at once, for both CSM and LM [19:17:54] not implemented yet [19:18:00] its own little side project [19:18:24] you can let the DMT calculate a DMT REFSMMAT; which is basically a P30/P40 REFSMMAT [19:18:27] preferred [19:18:44] otherwise I have hacked it so it uses the current REFSMMAT from the MFD [19:18:45] morning! [19:18:53] hey [19:19:35] hey Mike [19:19:51] what's up? [19:19:52] indy91, so if you dont specify anything, it will just use the current REFSMMAT? [19:20:06] not much just picking Niklas's brain :D [19:20:14] yeah, the same that the MFD always had [19:20:34] will be moved into the RTCC class at some point and the multiple types of it will be available [19:20:35] makes sense [19:20:54] and then you will have to do a bit of REFSMMAT management [19:21:05] move telemetry REFSMMAT to current for example [19:21:29] most of the REFSMMAT types we have are in there in some way [19:22:04] thewonderidiot, I'm still working on midcourse corrections [19:22:21] when Alex doesn't ask difficult questions that is [19:22:30] hehehe [20:08:47] indy91, I see TLI planning has its own page [20:09:02] is that for the TLI simulation? [20:09:14] no, that's the old TLI options on the TLMCC page [20:09:19] it's not done yet [20:09:31] if I overhaul it, it will use the new TLI simulation though [20:11:06] ah ok [21:26:18] good night! [17:18:47] Hey [17:22:18] hey Alex [17:22:29] I decided to fly Apollo 13, to test the TLMCC and the MPT [17:22:38] and to fly along while listening to the FIDO loop [17:24:07] back in a bit [17:26:06] Nice [17:26:26] I saw you pushed some TLMCC fixes [17:47:26] I’ll be back on in a few hours [20:59:42] evening [21:05:26] welcome back [21:05:57] I think I figured out the whole process to generate a TLI PAD and made the necessary fixes [21:06:39] nice [21:07:32] you have the TLI maneuver in the MPT [21:07:40] figure out the cutoff time with the DMT [21:07:52] add 15 minutes, which is when the S-IVB starts maneuvering to the sep attitude [21:08:06] add a 0 DV maneuver at that time [21:08:11] with specified LVLH attitude [21:08:31] specifying attitudes for direct input maneuvers was a bit broken, but fixed now [21:08:44] the LVLH attiude is the one the S-IVB maneuvers too [21:08:46] to [21:09:30] figure out cutoff time and inertial velocity with the checkout monitor rather [21:09:40] DMT has the EMS DV, burn time [21:09:53] it doesn't have the TB6 time, but that is just TIG minus 9:38 or so [21:10:31] oh and to complete the process you add another 0 DV maneuver for the LM ejection [21:10:53] same as sep attitude if you simply specify +X thrusters and not -X as it would really be [21:11:02] that sep maneuver changes config to CSM+LM [21:11:19] this is the process they used for Apollo 11 and 13 [21:11:28] TLI and two 0 DV maneuvers in the MPT [21:11:44] makes a happy RETRO for his Abort Maneuver PADs [21:13:04] I guess the Apollo 13 tapes and flying the mission helps to figure out the workflow [21:13:09] yeah [21:13:13] very similar to Apollo 11 [21:13:24] Apollo 11 had the extra CSM evasive maneuver [21:13:57] I am testing the fixes you added to the TLMCC branch [21:14:08] with my Apollo 16 scenario [21:14:12] I think if I prepare a worksheet, some sort of checklist this process isn't too bad [21:14:20] I added the page for additional inputs [21:14:29] great [21:14:35] thanks [21:14:45] should be enough to customize it for every mission [21:14:58] some constants are missing, but they would always be the same, for every mission [21:16:48] right [21:17:07] Ill play with it more later, Ill be back in a few hours [21:17:23] cya [21:17:24] ok [21:17:26] cya! [17:49:54] Hey [17:50:12] hey Alex [17:52:00] How’s Apollo 13 coming along? [17:53:53] very well [17:54:12] up to after LM ejection now and am finally implementing the one we were waiting for, TLMCC mode 4, haha [17:54:24] hehe [17:55:12] Interesting to hear how you can now make the PADs the way they did it [17:55:47] yeah, with the TLI PADs it's a few extra steps than just the DMT, but it does work [17:56:15] it's what they had to do as well [17:56:22] right [17:56:24] so mode 4 [17:56:35] and mode 4 really, both give me a 2.6 ft/s MCC-2 [17:56:48] if I leave the time at pericynthion unconstrained [17:57:04] Oh so you got it working [17:57:10] from a LOI/DOI geometry perspective it does give a very reasonable LOI1 perilune [17:57:18] yeah, pretty much copy and paste [17:57:24] mixing modes 2 and 5 :D [17:57:39] working through some bugs right now [17:58:06] Does constraining the time of you desire work as well? [17:58:56] well, I'm currently doing the necessary changes to the generalized iterator [17:59:05] that was the last missing feature of it [17:59:11] barrier checking [17:59:18] right [17:59:23] in this case the barrier is the time [17:59:49] I implemented many features from the recently acquired document about the generalized iterator [18:00:04] but I did not change the program flow to exactly what was in the document [18:00:11] which is causing problems now that I am adding a feature [18:00:22] so maybe I need to change the whole flow of it, I'll see [18:01:32] but it does seem to work with the change [18:01:43] So you said your LOI/DOI geometry is working better now as well? [18:01:54] well it comes up with a 58-59NM perilune [18:01:59] so that looks promising [18:02:09] interesting [18:02:20] didn't have a good LOI calculation with it yet [18:02:29] DVZ was pretty large [18:02:44] but I'll first fix all the bugs in mode 4 and try again then [18:03:28] so super optimized MCC-2 gives 2.6 ft/s, with the time constraint it becomes about 17 ft/s, which is closer to the planned value [18:03:57] I guess it needs to speed up by that amount to make it earlier to the moon than optimal [18:04:21] 2.6 FPS MCC-2, that’s quite small for a hybrid transfer burn, I guess Apollo 13 had a FR that wasn’t far off from the non FR one [18:04:35] 211NM planned [18:04:39] I'm a bit lower [18:04:57] normal variance I think [18:05:17] the 2.6 ft/s will be all perilune lowering to about 60NM I think [18:06:50] mode 2 gives 110 ft/s [18:06:59] but who cares about free return [18:07:12] How big is the range for the arrival time constraint? [18:07:27] Can you put min = max? [18:08:07] you can probably make it quite small [18:08:26] because it is getting optimized, it will probably always try moving in one direction [18:08:32] either earlier or later [18:09:11] so setting a max value the same as desired is sufficient in my case [18:09:43] it won't try moving to a smaller time, as that would more DV [18:12:24] right [18:12:58] the document you got from UHCL said the FIDO worked a whole new technique during early TLC [18:13:03] looking forward to that [18:13:10] right now he is still busy with tracking the S-IVB [18:13:17] maybe also calculating an APS burn for it [18:13:22] yeah I read a bit on that [18:13:37] the midcourse expert is already getting on his nerves [18:13:45] haha [18:14:04] let me chase the S-IVB for an hour the FIDO said in reply [18:14:25] the midcourse guy even already mentioned something about time constraints [18:15:09] Apollo 13 is the perfect mission I guess, as they do the CSM DOI for the first time [18:15:15] Those would be determined pre-mission I guess? [18:15:35] the time constraint [18:15:48] well, pre mission it might simply have the lighting constraints [18:16:01] LOI/DOI geometry is one thing, following the operational trajectory to the second is another [18:16:13] but it sounds like they will be trying to follow it closely [18:16:22] in the flight plan that only starts appearing with Apollo 14 [18:17:52] I guess the time constraint was more relaxed for 12 & 13 [18:17:53] the midcourse guy said that one solution gave a time 30 minutes off the OT [18:18:20] so probably the time constraint was still the lunar landing lighting [18:18:24] a few hours long [18:21:33] So they manually tweaked the min/max times I guess [18:22:01] yeah, that is probably the best way to try and manipulate the arrival time [18:22:25] the constraint variable is not consistent between different RTCC documents [18:22:42] Apollo 11 seems to have a constraint on the time of landing [18:22:57] but that is not exact, as that needs to use an estimate of the time between LOI and landing [18:23:07] the Apollo 14 RTCC Requirements uses GET at the node [18:23:13] and that's what I have implemented [18:26:10] For Apollo 11 could mode 2 even control time of arrival? I guess that’s limited by FR [18:26:31] the limit is only for modes 4 and 5 [18:27:11] you are right, the only way to control arrival time at the Moon with free return is the pericynthion altitude [18:27:13] right [18:27:40] Just that you said 11 had a constraint for the time of landing [18:28:26] yeah [18:28:34] they had modes 4 and 5 available for Apollo 11 [18:28:47] the RTCC Preflight Information has those numbers [18:29:05] ah so they had them in case they needed it [18:29:06] they had modes 1-7 ready for Apollo 8 [18:29:13] 8-9 came later [18:29:22] and of course there were changes over time [18:31:13] So mode 2-5 working very realistic looks promising now I guess [18:31:26] I hope, yes [18:31:43] what was available for Apollo 11 is already fully implemented, I think [18:31:58] I think initially they developed the non-free return modes for badly dispersed TLIs [18:32:11] and not for performance gains [18:32:54] there is an interesting Apollo Experience Report about the development of the major lunar mission calculation processors [18:33:03] MCC, RTE and LOI [18:35:06] yeah, it talks about bad TLIs as the reason for modes 4 and 5 to be initially implemented [18:36:28] oh, one hint about MEDs, in case you haven't figured it out yet [18:36:52] all MFD buttons that are for an MED code call the same function and just supply it with the input string [18:37:12] meaning, the only difference between the buttons is the displayed instructions on how to use it [18:37:26] you can enter e.g. F24 on the F23 button and vice-versa [18:37:45] Yes I had caught on to that [18:38:05] there is a central MED processing function [18:38:12] which calls different functions for each letter [18:38:23] a few function for F-code MEDs, one for K codes etc. [18:39:32] Very interesting [18:39:50] Gotta go, cya! [18:40:11] cya! [18:50:55] .tell AlexB_88 I got a 9 ft/s DVZ component of DOI for Apollo 13! [15:37:18] morning [15:37:56] that sounds about right :D [15:39:18] good to hear [15:39:23] hey [15:39:28] well [15:39:35] it still has a decently large LOI DVZ [15:40:03] Apollo 13 seems a bit special, in that it has a quite small plane change during LOI [15:40:28] meaning that the current incompatibility between LOI and TLMCC targeting is made even worse [15:40:36] as LOI targeting finds a different node [15:41:40] makes me want to implement the LOI targeting from that terrible handwritten document... [15:43:11] anyway, from my tests I am seeing that the new mode 4 is able to give a DOI ellipse with the desired 60NM apolune [15:43:23] what it does not do is get the DOI DVZ to 0 [15:43:33] and I don't think it even tries to do that [15:43:58] I was thginking there would be incompatibilities between the new TLMCC and old LOI [15:44:13] thinking* [15:44:16] yeah, it's mainly the backwards integration in the TLMCC processor [15:44:36] while the LOI targeting still assumes spherical gravity between LOI and landing [15:44:56] btw, let me know if you want more documents from UHCL, maybe another LOI one is available? [15:45:05] not from UHCL I believe [15:45:18] NARA has the one I would want [15:46:48] it's the one I should have requested all along, but I didn't see it until after Ron had scanned the one we got [15:47:50] I did fly a bit more Apollo 13 and listened to the FIDO loop [15:48:05] I have for the first time (I think?) tested the APS burn uplink through the PAMFD [15:48:08] works very well [15:48:26] now, for targeting it, that actually wasn't done by mission control [15:48:34] that was done at the MSFC [15:49:06] using [15:49:19] UNIVAC 1108 Lunar Targeting Program (LUNTAR) [15:49:45] interesting [15:49:47] which we don't have any information about, but an Apollo 13 document describes a little bit how it works [15:50:08] the FIDO was actually simulating that burn a bit, but just by trial and error [15:50:27] direct input maneuver with fixed DV, specified LVLH attitude and he changed pitch and yaw around [15:50:49] just to see where it will impact the Moon [15:52:30] and where I am at in the FIDO loop he just started to look at the MCCs [15:52:47] and the LOI TIG he got was quite similar to what I got with no time constraint [15:52:53] about 20 minutes later than planned [15:52:59] and thats where there was tension between him and the other guy trying to tell him MCC-2 stuff? [15:53:37] well FIDO still was working on the S-IVB, state vectors, simulating the burns it did, and the Midcourse expert was getting a bit impatient and wanted to get started, haha [15:54:43] hehehe [15:54:58] there just was a shift change, the new FIDO already mentioned that he is going to use his shift to get MCC-2 right [15:55:38] I'm really not quite sure how you can tweak mode 4 to get all the constraints right [15:55:48] you want LOI ellipse to be 170x60 [15:56:02] as only that will of course get the DOI DVZ to 0 [15:56:22] timing is not an issue, that can easily be done with the time constraint on the node [15:56:28] I pushed that update btw [15:56:49] yeah I saw, Ill give it a try [15:57:13] so all modes except 2 are basically done now? [15:57:21] mode 2 is also done [15:57:25] as much as mode 4 [15:57:29] so probably still some bugs [15:57:48] ok [15:57:59] I have a bit of time today, Ill do some testing [16:05:42] great [16:12:33] I ran out of buttons on the MCC transfer to MPT page [16:12:43] there should be an option to choose the column from the MCC display [16:14:19] I see [16:15:23] hmm, FIDO told Midcourse to come to him [16:15:33] either that means lots of good stuff to come [16:15:47] or it's not going to be on the loop, as they can talk directly [16:16:09] so I am testing my Apollo 16 scenario. 1st option 4 gives LOI DV of 12020 fps, lol. I think it must just be that I have some bad values in SFP [16:16:18] yeah, probably [16:16:34] all times are GMT, except TLI TIG [16:16:43] hmm [16:16:55] from midnight launch day [16:17:04] that must be it then [16:17:05] so you need to subtract the launch time [16:17:10] no [16:17:15] add the launch time to the GET [16:17:24] to get the GMT [16:18:01] one thing I have noticed is that a SFP block is really only valid for one of the BAP modes [16:18:24] some initial guess that is good for mode 4 was failing the mode 5 iteration for example [16:18:36] but "DELTA TIME OF LPO" and "DELTA TIME OF LLS" are just a specific time range right? [16:18:47] yeah [16:19:05] and "DELTA TIME OF TEI" [16:19:14] delta time of LPO would be impulsive LOI to impulsive TEI time, ideally [16:19:29] delta time of LLS would be LOI to CSM flying over the landing site on the landing rev [16:19:34] I mean if those times are off by a few minutes, should it matter? [16:19:40] and delta time of TEI is impulsive TEI to EI [16:19:48] no, minutes should be ok [16:19:53] ok [16:20:06] I've been getting good results when the updated values were up to 15 minutes [16:20:31] different [16:21:20] and I've been getting decent results with some simplifications like all heights at 60NM [16:21:31] the same EMP latitudes that we used before [16:21:41] longitude at 180° [16:21:49] should still work [16:23:04] and not all SFP values are even used by all the modes [16:23:21] oh and about longitudes [16:23:35] to help it converge, I've used the following assumption [16:23:55] every longitude should be a positive number, except for the LLS longitude, that should be -180° to 180° [16:25:29] ok so for the node longitude it wouldnt be -175 but rather 185? [16:25:42] yeah [16:25:59] that might also have been a cause for a failed iteration [16:26:37] so I just need to convert my node GET into GMT [16:26:42] yeah [16:26:55] April 16, 1972, 17:54:00 UTC [16:27:01] so add the 17:54:00 [16:27:05] to the GET [16:28:00] well, 17:54:00.37 to be precise [16:28:01] :D [16:28:15] not for table 1, that is preflight! [16:28:27] ah right [16:29:00] hmm, even if FIDO and Midcourse will be talking off the loop, they still need to send requests to Dynamics for any calculation, so I don't think I would miss too much [16:29:36] adding the MED to edit the SFP blocks right now [16:30:46] great [16:31:39] aha, they just ran a mode 4, with time constraint [16:31:45] 77:29:00 on both min and max [16:32:02] almost the same number I have tried [16:32:34] using the same number for both min and max would not work right now in the RTCC MFD [16:33:06] ah interesting, thats what I thought they would do [16:33:09] nevrermind [16:33:16] they can't do that, haha [16:33:24] lower limit to 77:20:00 [16:33:33] ah [16:33:53] I wonder if on 14 it was tighter [16:34:00] what they want is the 77:29:00 [16:34:19] although I think 77:28:30 might get the LOI TIG closer to nominal [16:34:24] I wonder if they will do that next :D [16:34:56] I think you just need to see if it wants to go to max or to the min value [16:35:06] and just change that number around [16:35:13] the other limit will not be so important [16:36:21] "GMT TIME FLAG" should that be set to something? [16:36:42] no [16:36:51] I think that is just the time at which the block was generated [16:36:56] whatever that is used for [16:37:06] nothing I could see in the TLMCC processor [16:37:18] maybe just to see, if the block is outdated or so [16:39:36] hmm so I am still seeing DV LOI of 12000 fps [16:40:11] with the correct time set for node (GMT) [16:40:26] hmm [16:40:31] have you tried a mode 1? [16:40:54] just to see if that at least works [16:41:17] just did now [16:41:34] it seems to work yes [16:41:43] mode 1 still uses the initial guess for the pericynthion [16:41:48] in addition to the nodal target [16:41:57] so that can't be too much off then [16:42:10] anything on the constraints page? [16:42:18] LOI DV 2757 [16:42:20] I FR and down is all 0's but I guess thats expected for mode v1 [16:42:25] mode 1* [16:42:32] yeah [16:42:51] constraints are all default except I put in a TMIN,TMAX [16:42:58] constraints page should default to fairly useful numbers [16:43:03] what did you put in? [16:43:30] 74:24:00 to 74:33:00 [16:43:35] ok [16:43:41] such a small range should be no problem [16:43:47] worked for me just now [16:44:19] what are the LOI pericynthion numbers you used? [16:44:59] and the LLS radius? [16:45:03] https://www.dropbox.com/s/jkyugqf5tmdpsy1/Screenshot%202020-01-24%2011.44.52.png?dl=0 [16:45:49] hmm [16:45:59] I think the node and LOI heights are not good [16:46:12] possibly [16:46:37] although, should be ok for mode 2 and 4 [16:47:14] if you give me the scenario I'll try and debug it [16:47:16] DV PC is also showing bad numbers [16:47:21] sure [16:47:46] every mission might have its unique set of bugs it brings to light :D [16:47:55] I btw this mission was my manual TLI [16:48:09] so MCC-2 should be over 100 fps [16:48:09] shouldn't be a problem [16:48:21] just so you're aware [16:48:27] right [16:48:55] https://www.dropbox.com/s/gjivdyj7pzmymun/Apollo%2016%20pre-MCC2.scn?dl=0 [16:49:56] thanks [16:54:02] remember that polynomial for optimum non-free return missions? [16:54:12] that wants to change your pericynthion time by 36 hours [16:55:23] maybe I should just not use it if I am not sure that it works right :D [16:55:51] can you try some TIG that is more than 20 hours after TLI? [16:56:30] sure [16:57:12] oh I had tried 30:00:00 [16:57:26] and LOI TIG was 48 hours or so lol [16:57:48] but I am trying again [16:57:57] hmm [16:58:05] I think I have a problem [16:58:16] I don't have your skeleton flight plan for Apollo 16 :D [16:58:24] oh haha [16:58:26] can you copy&paste that for me? [16:58:30] sure [16:59:37] https://www.dropbox.com/s/3959ktbxodfy4se/Apollo%2016%20SFP.txt?dl=0 [17:00:38] rtcc->PZSFPTAB.blocks[0].rad_lls = OrbMech::R_Moon - 0.1405; [17:00:48] that should be 0.1405 NM [17:00:51] so times 1852 [17:01:26] but that won't be anything significant [17:01:37] ah ok [17:01:52] Apollo 11 SFP has the *1852 missing as well [17:02:02] for LLS height [17:09:23] but that's meters [17:09:39] right [17:15:53] on the first step it tries to make the orbit prograde [17:16:18] it only was a 3 hour difference, but that polynomial might have messed up there as well [17:16:27] so I'll disable it for now [17:16:53] ok [17:17:05] whats the purpose of the polynomial? [17:17:37] for badly dispersed trajectories to find a reasonable time at pericynthion [17:17:52] close to optimum DV I guess [17:18:09] but if one coefficient is wrong it hurts more than it helps anyway [17:18:34] and so far lists of coefficients in RTCC documents don't have a good track record of being 100% correct... [17:20:44] hmm [17:20:48] also ends up prograde [17:23:18] weird [17:30:02] even mode 5 seems to try a prograde orbit [17:30:43] I think I found the bug [17:31:12] a bad patch, as in patched conics [17:31:24] patch time later than perilune time [17:31:28] can't be good [17:31:49] easy fix? [17:32:12] maybe [17:32:39] a wonder that anything ever worked with this, if it was consistently bad :D [17:33:08] haha [17:33:27] back in a bit [17:51:26] in the mean time I am trying the Apollo 13 MCC-2 [17:51:45] wow, opt. 4 gives an LOI TIG 1 second off from the SCOT [17:52:02] and TEI TIG about a minute off [17:52:46] I used the TLMIN,TLMAX that you quoted from the tapes [18:02:15] well, I used a TIG of 20 hours on that calculation, using the actual TIG (30:41) gives an LOI TIG about 30 seconds off [18:02:47] but the solution looks very close to the real Apollo 13 MCC-2 [18:27:28] yeah, I've had pretty good results for Apollo 13 so far [18:28:48] so in the first steps all modes converge a perilune state to the position at the midcourse [18:28:52] that works [18:29:22] but in the next step it goes from the midcourse to the perilune, and patching in that direction is what causes the issue [18:29:58] it's finding the time when it leaves the lunar SOI instead of when it enters it, or something like that [18:34:35] right [18:39:46] I noticed on Apollo 13 the SFP has 180 longitude for the node [18:40:07] I wonder if it has an easier time with that then a specific one like I used on 16 [18:40:48] ah, I think I have it [18:41:00] hmm, the right value is always better [18:41:07] I would think so too [18:41:09] but 180° seems to work as a good initial guess [18:41:22] I was too lazy too convert any value [18:41:26] haha [18:41:36] I think the solution is to make an atan into an atan2 [18:41:48] that probably fixes the bug [18:42:27] let's see what that does... [18:45:06] heres hoping [18:49:27] it fixed it [18:49:28] but [18:49:29] more issues [18:51:31] yay! and damn [19:00:11] hmm, well it likes to run into the 75° return inclination constraint [19:00:19] which causes some problems, but it does give a result now [19:00:49] I fixed those kind of constraints in the optimization mode, I think I still need to add some improvements for the normal converge mode [19:16:49] I see [19:19:48] 70 ft/s with no time constraints [19:21:16] 197 ft/s with time constraint :D [19:22:29] on Apollo 16? [19:23:13] yeah [19:23:27] about 200 when I tweak the LOI TIG to the exact right time [19:23:41] I guess that is about as expected [19:24:57] my MCC-1 was 196.1 VT when I flew it [19:25:13] with the more normal time at pericynthion it also doesn't run into the 75° return inclination [19:25:16] just looking back on my maneuver pads I had made [19:25:21] the 70 ft/s is very optimized then [19:27:22] hmm [19:27:43] it doesn't give me the 70 ft/s solution anymore [19:27:57] great consistent results... [19:29:54] did you remember to take a previous MCC back off the MPT? [19:30:28] didn't use the MPT [19:33:17] I have an idea what it could be [20:04:54] AlexB_88, pushed the latest round of fixes [20:05:01] and you can edit the SFP now [20:05:06] and delete MCC columns [20:06:33] and I think next I need to reorganize the generalized iterator [20:06:35] unfortunately [20:24:28] ok [20:25:03] good idea to be bale to edit the SFP [20:25:06] able* [20:27:16] ah great, you included the Apollo 16 SFP values [20:27:37] yeah [20:27:37] I dont have to keep copying it back in at each update :D [20:27:52] if we have them for all missions I can delete a bunch of MFD internal variables [20:27:59] right [20:28:00] as opposed to the SFP stuff which is in the RTCC class [20:28:15] I was going to ask, is stuff like TLCCFreeReturnEMPLat still needed? [20:29:01] I guess some stuff is still needed for the LOI targetting [20:29:13] yeah [20:29:35] the inputs are probably going to be a bit separate [20:29:40] for TLMCC and LOI [20:31:08] LOI processor doesn't have that many inputs anyway [20:35:46] does the real have LOI ellipse specification? [20:35:52] the real one* [20:36:25] you mean the solution 1 or 2 or the LOI and DOI apolune/perilune? [20:36:40] in both cases the answer is yes, since Apollo 14, possibly 13 [20:38:45] solution 1 and 2 [20:38:52] on the LOI page [20:39:37] the real LOI processor calculates multiple solutions at once [20:39:52] the two we have, then two at exactly perilune [20:39:54] and some others [20:40:24] https://i.imgur.com/THJBg90.png [20:40:51] oh nice [20:41:12] that's the display from an Apollo 14 sim [20:41:57] something well see in the RTCC MFD soon? [20:42:47] oh yeah [20:42:54] if I can figure out the RTCC Requirements document [20:43:15] if not, I'll have to ask Ron for the revision of the document and hope it's better [20:43:28] will the LOI solutions be much different then now? [20:43:55] usually not I think [20:44:06] what will improve is flying over the landing site at the right time [20:44:18] emphasis on over the landing site [20:44:38] some mission with larger approach azimuths are a few miles off [20:44:41] Apollo 12 for example [20:45:03] with the backwards integration from the landing site to LOI that is taken into account [20:45:22] the procedure before the new LOI Targeting (so at least up to Apollo 12) was to bias the landing site latitude [20:45:37] I guess with the MPT that can be done right now already [20:46:06] calculate a LOI, see how much off the latitude is when you fly over the landing site longitude on the right rev [20:46:08] and bias it [20:49:45] yeah I did that on my last couple of flights [20:49:59] I think on 16 I didnt need to though [20:50:05] but definetly 12 [20:50:16] and 14 I think [20:51:00] I think it's a function of inclination (larger means more nodal precession) and approach azimuth (if it's not 90° the nodal precession has a stronger effect on crossrange) [20:51:38] I just hope that the backwards integration is compatible with a circular orbit [20:51:41] for missions with LOI-2 [20:51:57] but if not I can probably change it up a bit so that it works with that as well [20:54:03] right [20:54:36] so just testing MCC-2 on Apollo 16 with the latest update [20:54:46] very similar result to yours, good stuff [20:55:10] my LOI DVz though is quite high, -1048.3 fps [21:00:29] I'm not really liking the results so far either [21:00:36] what do you get as the pericynthion height? [21:01:28] 58.451 [21:02:55] guess I still have some work to do [21:03:29] in dobut the whole damn LOI Targeting [21:04:42] ah wait [21:04:51] I think one of my constraints is wrong [21:04:59] REVS2 [21:05:08] should be 10 not 11 on Apollo 16 [21:05:26] oh [21:05:38] I was thinking about that, if 11 was right for most missions [21:05:59] SITEROT 345 [21:06:11] thats 15 degrees right? should be 16 [21:06:18] ah [21:06:27] TLMCC processor uses a different sign convention [21:06:41] and if you look at the LOI Targeting picture I posted, it's 345° there as well [21:06:48] so you probably want 344° [21:06:56] aka -16° [21:07:03] right [21:09:35] REVs before and after LOPC [21:09:59] is that LOPC 1 or 2 and where does it start, LOI? [21:10:38] LOPC1 [21:10:57] LOPC2 also needs to be modelled, which it currently isn't properly [21:11:14] all I know that the numbers are 3 and 8 for Apollo 11 [21:11:31] and they are: orbits from landing to LOPC and orbits from LOPC to flying over the LLS again [21:12:03] I think for mode 2 and 4 they are currently not that important [21:18:01] ok [21:18:53] I changed the constants, but LOI is still a bit off [21:18:58] high DVz [21:21:33] yeah, not sure what causes that [21:21:41] I doubt it's only the LOI targeting being off [21:25:16] oh wait [21:25:29] +197 DVz [21:25:37] I changed some of the SFP values [21:26:01] I basically did Lat 0 Long 180 Alt 60 for the node [21:27:31] ah [21:27:48] for the node only? [21:27:58] no all [21:28:01] ah [21:28:19] yeah, there is one variable it tries to converge that I am not 100% about [21:28:32] some height [21:28:48] it caused some issues if the pericynthion heights were far off 60NM [21:29:02] have to take a look at that again [21:46:59] LOI solutions for ellipse 1 and 2 are identical [21:47:36] they are if the node altitude is below the desired perilune [21:47:51] then there can be only one solution, which has the node altitude as perilune [21:48:43] which is lower than the specified perilune altitude on the LOI page [21:48:54] right [21:49:28] do the BAP modes update SFP 2 currently? or is it still to come [21:49:50] SFP 2 shows all 0's [21:50:23] after doing mode 4 [21:50:32] F30 button [21:51:05] hmm dont see F30 [21:51:46] ah found it [22:17:55] the generalized iterator reorganization is actually coming along nicely [22:18:02] should hopefully fix some border cases [22:18:13] although it probably won't do much for Apollo 16 [22:25:34] nice [22:26:03] it seems by playing with the node height it gives better solutions [22:26:30] so [22:26:38] there is a variable called dh bias [22:26:44] you can also see it on the LOI display [22:26:57] it's never properly explained how it was used [22:27:11] but it could be useful for tweaking heights like that [22:31:29] k [22:32:03] ok* [22:40:49] night! [14:25:32] morning [14:34:41] hey [14:38:33] fixing bugs and getting the reorganized generalized iterator to work [14:39:47] great [14:41:27] I had built an Apollo 14 SFP last night [14:42:04] but having issues with it too, not giving a good result with option 4 [14:44:11] I bet [15:12:58] I think I found something [15:13:15] it requires a bunch of changes [15:13:19] but it's probably worth trying [15:16:49] ok [15:19:04] the variables the iterator is trying to get right are weighted against each other [15:19:15] and it seems like it does matter what unit the variables are for that [15:19:43] so I need to change meters to Earth radii, m/s to Eart radii per hour. At least as the output to the iterator [15:20:08] fun stuff [15:20:25] hardly :D [15:20:37] hehe [15:21:01] the TLMCC has only three functions the iterator is calling. For two of them it's a simple change [15:24:02] mass is a different variable type, it only ever gets optimized [15:24:09] but I wonder if the unit matters there as well... [16:00:22] indy91, what do you think about committing the new ML/LUT meshes soon? [16:03:17] sure [16:03:26] I think Jordan is still making some improvements though [16:03:51] ah ok [16:19:28] well, I finally get back to my normal computer tonight, Ive been on my laptop since early December :D [16:33:16] haha, nice [16:38:43] gotta go, good luck with the TLMCC [16:40:14] cya! [16:01:39] hey [16:10:42] hey Alex [16:11:31] they did not have the updated LOI targeting for Apollo 13 [16:12:07] might mean they had to do more trial and error [16:12:17] oh interesting [16:12:31] the inputs they used are exactly the same as the Apollo 11 MED [16:12:38] 34NM "circular" orbit [16:12:56] average of an 60x8 orbit [16:13:31] and I switched everything over to the reorganized generalized iterator [16:13:39] together with some bug fixes things are looking more stable [16:14:11] LOI DVZ is stil large, but that is more the fault of the LOI targeting I believe [16:14:26] right [16:15:43] one thing I had gotten wrong is the barrier logic in the optimized mode [16:15:59] it actually recognizes that e.g. the optimum DV is at exactly the specificed max time [16:16:14] and then tries to force the solution to be at exactly that time [16:16:19] which is a good assumption [16:17:05] so feeling a bit barrier about those time constraints, at least when it optimizes [16:17:09] lol [16:17:11] a bit better* [16:17:56] right [16:19:04] looks like you're getting there slowly but surely [16:19:13] yeah, I think so [16:19:41] pushed the update [16:20:25] awesome [16:20:34] Ill test it [16:21:36] haven't tested it with Apollo 16 yet [16:22:55] it at least comes up with a reasonable mode 4 solution for 16 [16:23:33] and gives a small DVZ for LOI [16:25:10] ok [16:27:52] but a huge DOI DVZ [16:30:49] hmm [16:31:13] the dwell orbits have to be set to 2 10 [16:31:45] and 344 for the angle [16:31:50] right [16:36:00] not much better [16:37:18] on approach, the orbit should have 71NM perilune [16:37:38] I'm not sure it will ever do that with the current logic [16:37:41] except [16:37:56] when you change some SFP parameters [16:38:30] flight path angle at LOI [16:38:49] it uses that initial guess quite far into the mode 4 calculation [16:41:22] right now thats 0 [16:41:29] hmm, leads to bad solution if I change that to 2° or -2° [16:41:51] I actually heard on the FIDO loop that it should be +2° for Apollo 13 [16:42:49] uhh [16:43:00] oh right [16:43:06] I changed the TIG to MCC-4 :D [16:44:29] flight path angle at LOI ignition? [16:44:50] SCOT says -9.3 or so [16:45:07] and +2.5 at burnout [16:45:19] has to be impulsive point [16:45:34] but it doesn't really change the solution [16:59:18] is there a chance the issue could be on the LDPP side? [17:01:47] don't think so [17:01:56] hmm [17:02:34] if I am seeing that correctly I did something wrong for mode 4 [17:02:45] the flight path angle at LOI is never even iterated on??? [17:06:54] that might mean you could control the orbit with the flight path angle parameter [17:14:39] yeah, now the flight path angle has an influence [17:15:58] but it only makes the pericynthion height smaller [17:17:22] I have some ideas, have to think a bit, haha [17:25:42] helmet fire? :D [17:38:50] its the irritator's fault [18:15:10] well hopefully more of the Apollo 13 FIDO loop gives some clues [18:15:26] they did talk about the flight path angle already [18:15:39] FIDO thought the LOI processor also used the SFP value of it [18:15:42] but it doesn't [18:16:10] interesting [18:18:00] the FIDO isn't much smart than us [18:18:04] but he has some help [18:18:09] much smarter* [18:24:42] yeah, lots of help [18:28:06] well the geometry stuff isn't fully working out yet, but so far the updates have made the TLMCC processor more stable for me at least [18:31:32] one good test case might be an 40° inclination constraint [18:31:37] which would be a mission constant [18:31:49] in the RTCC Requirements documents it's actually 40° most of the time [18:31:53] but it should be adjustable [18:32:06] and I made it 75° so far [18:32:13] because I didn't want it to run into it [18:32:19] but now that might be good for testing [18:36:59] damn internet [18:37:17] it often duplicates you [18:37:45] if you missed something read the chatlog, lol [18:38:47] it doesn't enforce the 40° for free return [18:38:53] only the powered return, TEI [18:42:18] ah I see [18:42:43] dont think I missed anything [18:44:14] in the constraints you can define the LOI, LOI-2, DOI mission profile for mode 2 & 4? [18:44:37] for Apollo 12 and before [18:45:20] ie. by making HPLOI2 60 instead of 8 [18:58:26] I'd use modes 3 and 5 [18:58:39] with the desired azimuth set as the min and max [18:58:51] that's how they kept the old modes 2 and 4 around [18:59:19] and for modes 3 and 5 the LPO altitude is fixed [18:59:22] 60NM [19:02:09] for a mission with LOI-2 modes 2 and 4 would be worse [19:02:26] as it is trying get a specific LOI ellipse orientation [19:02:37] even if HPLOI2 is 60 [19:04:03] right [19:04:03] doing tests with Apollo 11 right now [19:04:17] building all maneuvers up to DOI [19:04:43] mode 2 did not even give a solution at all but mode 3 works [19:05:03] forced it to -91 azi [19:05:06] probably some SFP initial guess [19:05:26] LOI DV's are very close to real [19:07:00] what is weird though is my LOI-2 solution is not quite the same as compared to the flight plan and real LOI-2 pad [19:07:29] 20 minutes late and DVZ is quite off [19:09:06] DVZ quite off? There is a DVZ at all? :D [19:09:34] did the LOI-1 not make a 60NM perilune? [19:09:35] +75 fps is nominal [19:09:51] wait, which mission are we talking about [19:10:00] real LOI-2 was -104.8 (-31.9); y is zero; z, -74.3 (-22.6) [19:10:03] Apollo 11 [19:10:07] really [19:10:24] LOI-2 should have 0 DVZ [19:10:51] thats what I thought as well [19:11:11] oh [19:11:12] but even the flight plan shows an expected 75 fps DVz [19:11:16] it's the biased orbit [19:11:21] they didn't do 60 circular [19:11:42] ah [19:11:44] but different, so that the weird lunar gravity makes it closer to 60 circular later on [19:12:11] which I don't think we get [19:12:17] so we should aim for 60 circular [19:12:29] but it's something I will research in the Apollo 11 FIDO loo [19:12:30] p [19:20:47] haven't listened to that part yet [19:20:56] I checked on one LOI calculation [19:21:00] LOI-1 [19:21:08] but not really LOI-2 [19:21:28] I think it's a LDPP circularization maneuver and then some biased DV or so [19:37:59] oh they took the LDPP solution and modified it? [19:46:13] I think so [19:46:19] as the LDPP will give the 60NM circular [19:46:47] but I might misremember [19:47:14] the GPM would also potentially do the job [19:54:49] yeah [19:55:14] "delta azimuth of LOI" [19:55:52] I used the SCOT for this, plane change angle at LOI burnout [19:56:19] yeah, looking at the updated SFP block 2 that results from the calculation that is a good guess [19:56:50] but actually, it usually finds the solution if that is set to 0 [19:56:53] just not so fast [19:56:54] one thing I am confused is if it should be positive or negative [19:56:56] and maybe not as reliable [19:56:59] yeah same :D [19:57:26] I think I just tried it [19:57:36] and if the result indicated the sign was wrong I changed it [19:59:13] right [19:59:22] I am going to create an SFP for Apollo 12 [19:59:27] a mission I might fly soon [19:59:47] I have a few weeks off now, and with my actual PC :D [20:04:28] Apollo 12 should work well [20:06:08] mode 6 for MCC-1 and mode 3 for MMC-2 im thinking [20:06:18] MCC-2* [20:06:52] MCC-1 most likely not being needed, but mode 6 for the FR correction [20:07:32] sure [20:07:44] the SCOT has the free return perilune precisely defined [20:07:45] although modes 6 and 7 were mostly abandoned by Apollo 11 [20:08:04] might as well run a fully optimized mode 9 [20:08:20] ah right [20:09:03] mode 9A is with a specified inclination of 0° [20:09:18] only difference in terms of inputs to 9B [20:09:31] 9B will achieve the desired inclination [20:09:44] 9A and 9B are just different internally [20:09:55] two quite different and separate program flows [20:17:00] ok [20:17:14] LLS 1st pass, thats the TLAND? [20:17:39] dt_lls, LOI to TLAND? [20:19:08] yes [20:19:16] thanks [20:27:37] most commonly used word in the FIDO loop is [20:27:43] groovy [20:27:54] must have been the current trendy thing to say :D [20:27:59] really [20:28:11] thought it would be "babe" lol [20:28:35] oh that's quite common as well [20:31:25] trends change a bit I guess, "babe" would be a weird thing to say to another man today :D [20:31:57] yeah [20:32:20] ok I got the Apollo 12 SFP ready to test [20:36:31] your Apollo 16 scenario with the manual TLI [20:36:41] calculated a mode 9 [20:36:52] for once it took a second to come up with a solution [20:37:02] probably iterates slowly due to the high perilune [20:37:08] because the optimal flyby is at 2100NM [20:37:14] 25.2 ft/s [20:39:48] hmm [20:40:02] with a specfied inclination, the same of mode 9A, mode 9B does not find the same DV [20:40:12] probably some issue in mod e9B [20:40:14] mode 9B* [20:40:27] oh [20:40:35] it's just the initial guess for the flyby altitude [20:40:46] if I change that to 2000 it finds it [20:41:46] forgot to do mode 5 and not mode 4 on Apollo 12 [20:41:47] good test case, as the trajectory is a bit off nominal [20:41:58] so did a mode 4 and it looks quite good [20:42:12] even mode 4 looks good? [20:42:17] yeah [20:42:31] MCC 71.7 [20:42:33] interesting [20:43:59] want my SFP values? [20:45:02] sure [20:45:19] https://www.dropbox.com/s/2t6az21b6016j1w/Apollo%2012%20SFP.txt?dl=0 [20:45:26] thanks! [20:45:36] np [20:45:42] I have to run, cya later! [20:45:57] cya! [15:37:22] hey [16:09:00] hey [16:09:27] I actually did a bit work on the LOI targeting [16:09:40] I think I should be able to recover the unreadable passages [16:10:12] just by knowing what it is supposed to do [16:12:17] nice [16:12:28] although I still would like the revision [16:12:44] it suffers from some of the same things in terms of clarity what it is trying to do as the MCC documents [16:12:56] in the backwards integration [16:13:47] and I am beginning to question some things in the TLMCC processor [16:14:14] it uses orbital parameters of the DOI ellipse to determine the right height of the node between hyperbola and LOI ellipse??? [16:14:39] there is a revision 2 of that TLMCC document which we have. Just some updated pages. And it's a quite substantial change [16:15:04] not really sure which version I like more... [16:19:03] my main issue with the updated version is that you need to give it a specific true anomaly of LOI on the ellipse [16:19:10] so you need to know that value [16:19:21] or manually change it back and forth to get the right orbit rotation [16:22:24] hmm an extra SFP value? [16:23:02] it's a MED value for the TLMCC processor [16:23:05] even in the older version [16:23:27] but there it is just used to improve the estimate of the time at the LSS a bit [16:23:32] LLS* [16:27:38] oh and on the Apollo 13 FIDO loop [16:27:48] the FIDO wasn't happy with the pericynthion height [16:27:53] a familiar feeling [16:28:04] but he was able to specify that value in some way?? [16:30:19] does it show how they ensured proper LOI/DOI geometry without the capability yet in mode 4? [16:30:57] they are still working on it, so I think there will be more [16:31:59] also still possible that they changed the SFP value only [16:32:30] or they changed the HP of the first LPO [16:32:49] if they have the new version [16:33:00] I'm just searching if there was an intermediate version [16:33:14] the latest update to the nonfree modes was in February 1969 [16:33:23] no LOI/DOI geometry of course [16:33:41] yeah [16:33:46] there was an intermediate version [16:33:47] for H-2 [16:33:52] November 1969 [16:38:14] jarmonik released a Terrain ToolKit [16:38:16] https://www.orbiter-forum.com/showthread.php?t=41279 [16:38:38] Could be useful to make better imagery for the landing sites [16:39:11] ah nice [16:54:32] time to make some changes so that it all works how I think it should work [17:14:54] with the TLMCC revision doc you were speaking of? [17:16:45] all Apollo 14 [17:16:57] but it has two changes, some changed pages [17:17:03] up to late 1971 [17:17:13] so I guess it's fair to say this is the last version of this document [17:17:25] and the big differences are between the base Apollo 14 version and change 2 I believe [17:18:56] and I'm just going to change it all [17:19:08] so that it works how I like it :D [17:19:41] kind of an intermediate version between the two [17:25:59] cant say that would be inaccurate, as a lot of missions seemed to have been on some sort of "intermediate revision" anyway :D [17:27:32] and manually tweaking of maneuvers [17:28:21] btw I think the Terrain ToolKit only works on a recent D3D9 revision for the release version of Orbiter 2016 [17:28:33] so I am installing Orbiter 2016 [17:33:07] back to buggy accelerometers and docked vessels that don't want to rotate :D [17:33:43] yeah [17:34:06] well I'd just use it to create the terrain' [17:36:33] right [17:48:08] LAT OF TLI PEROCYN. -148.969 [17:48:29] doesnt sound right :D [17:50:39] rtcc->PZSFPTAB.blocks[0].lat_pc1 = -2.6; [17:50:44] someone forgot a RAD [17:51:34] ah [17:51:54] anyways I was wondering why I couldnt calculate a mode 9 under 700 fps [17:52:04] now its better, 12 fps [17:52:32] sounds better [17:53:11] so you manually enter the pericynthion height in mode 9? I used the SCOT vale [17:53:14] value* [17:54:05] on the page with the inputs it's an initial guess to help it find the solution [17:55:06] might be set to a different value than nominal flyby if you are on a trajectory that is quite off [17:55:15] otherwise it can be the same as the lat_pc1 [17:55:53] the only scenario where it didn't find the optimal solution was your Apollo 16 scenario [17:56:04] which has an optimum at 2100NM flyby [17:56:18] then 60NM as the initial guess didn't fully work :D [17:56:42] did they do a mode 9 for MCC-1 on Apollo 13? [17:57:09] I'm not quite there yet, but I heard something about some extra calculation for the MCC-1 time [17:57:16] the normal MCC-1 was already scrubbed [17:57:20] right [17:57:35] MCC-1 would have a smaller DV than MCC-2 [17:57:46] right just a FR correction [17:57:50] so if MCC-2 calculated with mode 4 would have become too much DV [17:58:02] they might have executed a MCC-1 hybrid transfer already [17:58:12] ah I see [17:58:32] for certain alternate missions you do a flyby maneuver as MCC-1 [17:58:40] any mission that doesn't allow a lunar mission [17:59:57] Apollo 17 CSM only mission is also interesting [18:00:09] they would have done a MCC-1 back to free-return, but a lunar mission [18:00:18] 617.6 ft/s MCC-1 [18:00:35] now that requires some SFP changes I think :D [18:00:46] well [18:00:47] maybe [18:01:04] and it would be a mode 3 [18:01:14] they would have done LOI-1, LOI-2 [18:12:11] LOI target is very close to SCOT [18:12:14] for Apollo 12 [18:12:56] nice [18:13:29] at least some modes are working right :D [18:17:13] LOI-2 and DOI DVz are a bit different, but I guess again because of the planned elliptical orbits vs. our 60x60 [18:18:45] did they try that again on 12? [18:18:52] Because it sure didn't pan out like they planned on 11 [18:19:01] the CSM orbit was quite elliptical for rendezvous [18:19:15] yeah [18:20:01] SCOT says post LOI-2: 66.0x54.2 [18:20:17] oh wow [18:25:49] I kind of tried how they might of did that [18:26:40] I calculated CIR,DOI with the LLDP 1st, then looked at the longitude of the CIR maneuver on the descent planning display [18:27:29] then used the GPM, Apogee and Perigee change, point Longitude and used the Longitude from the LLDP [18:27:47] seems to have worked [18:28:44] Im sure point time would have worked [18:29:01] anyways not something we really have to do in NASSP I guess [18:29:24] yeah, I don't think we have to [18:29:44] we only get the more simple Moon gravity and some Earth gravity which might be pulling spacecraft around [18:30:09] I haven't tried it, maybe there is enough disturbing forces anyway to deorbit spacecraft over time [18:30:25] and I will listen to the FIDO loop for Apollo 11 again to find the more detailed LOI-2 procedures [18:34:44] starting at AOS after LOI-1 should be good enough I guess [18:34:52] to find their LOI-2 method [19:15:35] "rerun the RET and compute LOI-2" [19:15:45] the only RET I know is the Rendezvous Evaluation Table [19:15:49] used by the DKI and SPQ [19:16:17] could also mean two separate things [19:16:28] rerun the RET, and also recompute LOI-2 [19:21:42] nah [19:21:47] already transferred to the MPT [19:21:59] so I probably have to go back further, for the initial inputs [19:58:37] oh wow [19:58:43] they computed LOI-2 as a CDH??? [19:59:52] wow [20:00:11] FIDO are you drunk? [20:00:31] in any case very creative [20:00:42] they probaby made it rendezvous with the desired orbit, somehow [20:01:43] and the main inputs for that will have been made earlier, so I have to go back before LOI-1 I think [20:04:08] maybe some manually inputted LM state vector that is 60x60 later on [21:12:49] 10 hour mark in the Apollo 13 FIDO loop [21:13:17] interesting talk between FIDO and Midcourse. So much so that the FIDO asked Midcourse (again) to come to the MOCR to him. Unfortunate for me [21:30:00] good night! [15:47:57] hey [15:48:53] hey Alex [15:55:12] they are just calculating DOI for the first time on Apollo 13 [15:55:28] inputs as expected [15:55:38] except for "use the integrator" [15:56:00] normally it uses the AEG, which is analytical and a bit less accurate, especially over multple dwell orbits [15:56:17] that's not a capability I know of from the documents about the LDPP I have [16:08:44] and I'm not really making progress with with mode 4. I like the post DOI apolune being close to 60 [16:08:48] DVZ is usually "ok" [16:08:52] DOI DVZ that is [16:08:56] LOI DVZ not so much [16:09:27] and I even tried implementing an intermediate solution in the LOI processor, to make it find the same node as the TLMCC [16:09:35] but that still only makes the DVZ a bit better [16:14:52] I see [16:18:40] can't get a good apolune for DOI in your Apollo 16 scenario though [16:22:21] haha [16:22:28] they just had a RTE computing [16:22:38] apparently broke the record for their longest computation [16:22:49] 5:02min [16:23:10] was blocking another TLMCC computation from FIDO [16:26:42] wow [16:27:05] some P37s that come close to the Moon will easily beat that I think [16:28:01] the IBM 360 is slightly faster though :D [16:36:36] I'm not really making progress. Should I make some changes to the whole thing that tries to make the DOI DVZ 0 all the time? [16:37:38] and just forget the RTCC Requirements document, at least in some parts... [16:37:43] hmm [16:38:00] good question [16:39:13] would it make it harder to revisit later though, making those changes? [16:39:24] in case we get more documents [16:40:08] I don't think there is any more TLMCC document to be had [16:40:16] I see [16:40:18] there is the LOI one which might help a bit [16:40:22] or even a lot [16:40:59] in the mean time is it possible to manually build proper LOI/DOI geometry with mode 5? [16:41:35] no, not really [16:41:45] ok [16:41:49] they just don't aim for any LOI ellipse rotation [16:41:56] that would even deviate more [16:42:52] the backwards integration happens mostly in a sub function [16:43:01] meaning that I could implement a new one and let it use that [16:43:13] and later on, maybe, let it use the one closer to as it should be [16:45:03] yeah [16:45:59] we're you still set on trying the LOI processor? [16:46:11] were* [16:47:06] I'm thinking about asking Ron to scan the revision 1 of that [16:47:17] but I think I can get at least some of the LOI modes working [16:47:38] it calculates 4 types of LOIs, 2 for each type, so 8 solutions [16:47:45] and I think I can at least 2 types of them working [16:47:51] the others are more problematic [16:48:47] one solution is trying to get the 170x60 right and does no plane change at all [16:48:53] that's the easiest [16:48:56] and least useful I guess [17:15:17] well I asked Ron about the LOI document [17:15:25] haven't heard from him this year yet [17:15:36] and he also hasn't been at NARA this year I think [17:17:47] the other LOI solution is 170x60 + proper LS approach azimuth? [17:18:45] actually not 100% sure how it works [17:18:59] https://archive.org/details/69FM327Images/page/n3/mode/2up [17:19:01] left side [17:19:07] has the descriptions [17:20:17] thanks [17:20:57] I can see what you mean later on in that doc, the handwritten equations [17:26:28] some unreadable parts are similar to the TLMCC backwards integration which I have now understood quite well [17:26:33] so that isn't a big problem [17:26:40] but later on there is more [17:26:46] more places you can't really read [17:27:07] and there are a bunch of mistakes and omissions, so I would hope the revision fixes those as well [17:28:58] and mainly it should have some of the same changes that the TLMCC document revisions did [17:29:05] which added more to my confusion than helped [17:44:20] trying out the whole sequence of creating the TLI pad [17:44:53] you described it once and I found it in the logs [17:47:08] hmm [17:47:18] TLI solution is all 0's on the MPT [17:47:33] which mission? [17:48:11] 1 [17:48:13] 11 [17:48:29] I already hit TB6, maybe thats why [17:48:46] yeah, could be [17:48:58] it does a check on current time [17:49:05] which probably screwed up something [17:49:07] Ill try an eariler scenario [17:49:51] yep it works [17:50:12] let me check my notes [17:50:36] you should then get a checkout monitor [17:50:38] type MVE [17:50:50] to get inertial velocity and the cutoff GET [17:51:02] then add 15 minutes to the cutoff GET [17:51:09] for the sep maneuver thing [17:51:40] and then the first 0 DV maneuver [17:51:48] for Apollo 11 the LVLH attitude is [17:52:03] 41.6 P, 120.8 Y, 131.9° R [17:52:17] and Apollo 13 had the same thing, just a minus on the roll [17:52:22] careful about the order btw [17:52:40] the 0 DV maneuver should be with the CSM RCS, just to make it a bit simpler for the calculation [17:52:44] and type inertial [17:53:03] and the way you switch the burn data is enter P1 [17:53:10] where you would otherwise enter the M40,P2 etc. [17:53:13] just P1 [17:53:24] and the attitude is on the top right button [17:53:29] LVLH= the attitude [17:55:48] hmm [17:55:59] that might be a -120.8° [17:58:49] is the cutoff GET the 1st GET listed on the top left of the checkout monitor? [17:59:32] I think so [18:00:53] ok [18:00:54] 3:05:01 [18:01:22] I accidentally put maneuver 0 for the checkout monitor and it gave a CTD [18:01:23] is what they had [18:01:28] oh [18:01:33] that should be checked [18:01:35] my bad [18:03:27] in fact I'll probably change it to use the MED input method as well [18:03:35] which then has the right checking logic and default values [18:04:18] and at some point give the right error message on the online monitor [18:05:19] ok [18:05:26] it does some check already [18:05:29] but not on 0 [18:05:45] manually adding TLI TIG + burn time comes up to 2:49:56 [18:05:56] checkout monitor shows 2:50:01 [18:06:03] temporary fix is in [18:06:29] hmm [18:10:09] the IBM document gives the exact definition [18:10:36] for burntime [18:11:56] the checkout monitor time is after thrust tailoff [18:12:04] so that is 1.8 seconds difference [18:12:21] and the current logic has TIG at the beginning of thrust buildup [18:12:27] another 2.5 seconds difference [18:15:19] one thing that definitely doesn't make sense is the DMT TIG and burntime combination [18:15:31] becomes that leaves out the 2.5 seconds buildup time [18:16:03] because* [18:16:11] my ISP is starting to get on my nerves [18:16:46] anyway I missed a bit but I see it in the logs [18:17:39] how do you even define TLI TIG, haha [18:17:58] I guess TB6 + 9:38 is the best [18:18:05] that's what the event timer is set to [18:18:40] right [18:18:56] so for the 0 DV maneuver [18:19:07] thats direct input page? [18:19:48] yep [18:21:45] M40,P1; [18:21:59] just P1 [18:22:04] that's not a MED input [18:22:14] just the way I had to use to switch between the differen burn options [18:22:29] M40,P1; gave a CTD [18:22:35] ... [18:22:36] sorry [18:22:42] haha no worries [18:22:44] and then you could enter something with M40,P1,etc. but you want to keep it all 0 [18:22:54] but just P1 displays the P1 stuff [18:23:32] still a bit confused of what and where to input, do I have to actually enter the attitude (41.6 P, 120.8 Y, 131.9° R) [18:24:03] yes [18:24:18] that only gets displayed when it's in inertial and P1 mode I think [18:24:29] so instead of External DV you want inertial [18:24:38] and then input P1 where you would normally do M40 [18:24:45] then it should display the attitude [18:25:14] ah ok [18:25:48] is the sep attitude taken from the flight plan? [18:26:52] kind of [18:27:14] it's the LVLH attitude in the LVDC, but with a different Euler angle convention [18:27:17] it's 120° pitched up [18:27:26] and then 40° yaw to right or left, depending on the mission [18:27:42] so i think it is 41.6 P, -120.8 Y, 131.9° R [18:27:50] and 41.6 P, -120.8 Y, -131.9° R [18:27:57] for all missions [18:28:04] except Apollo 8, which had no yaw [18:28:11] still have to calculate the attitude for that [18:28:39] how would they calculate the attitude for late launches? [18:30:00] it's the same [18:30:03] in LVLH [18:30:15] LVDC does the same maneuver [18:30:23] the attitude is in the LVDC presettings [18:30:50] ah right [18:31:23] ok maneuvers on the MPT [18:31:34] DMT to check the attiudes I guess [18:31:40] yeah [18:32:04] you want to see [18:32:05] 357°, 107°, 41° [18:32:07] or close [18:32:54] hmm [18:32:59] thats a negative :D [18:33:12] probably got the order wrong [18:33:21] it's entered differently than I wrote it out [18:33:29] I wrote it like FIDO gave it to Dynamics [18:36:03] trying to replicate it [18:36:09] while fixing the TLI time displays [18:38:15] oooh [18:38:29] DMT display subtracts the tailoff time [18:38:36] I did that twice then [18:39:46] ok [18:39:48] CSM [18:39:50] no replace [18:39:53] 3:05:01 [18:40:00] CSM RCS +X [18:40:08] 4 quads, but doesn't matter [18:40:15] has to be + of course [18:40:26] Inertial [18:40:38] P1, 0 ft/s, 0 sec [18:43:16] well [18:44:05] ok [18:44:09] got the signs wrong [18:44:14] it is no minuses [18:44:26] for Apollo 13 it is minus on both 120 and 131 [18:44:33] but for Apollo 11 it is all + [18:44:53] so I did write it down right after all [18:45:11] LVLH 41.60° P 120.80° Y 131.90° R [18:45:35] yep that works [18:46:00] great, haha [18:46:06] that's the sep attitude [18:46:20] extraction attitude is probably calculated manually, like the crew would do it [18:46:38] then they added an extraction maneuver [18:48:14] so FDAI=? [18:49:28] oh they dont add the extraction attitude at all [18:49:40] just manually calculate it [18:50:41] so just for practice I want to invert and attitude for a certain maneuver [18:50:50] M58,CSM,2,U; [18:51:05] is that correct or should it be M58,CSM,2,U,,; [18:51:12] that only works for P30 maneuvers [18:51:16] ah ok [18:51:23] as for inertial you have given it directlx an attitude [18:51:34] right [18:51:48] they just made the extraction maneuver with +X RCS [18:51:50] in the MPT [18:52:01] which is then the same direction as the actual extraction [18:52:11] here are my inputs [18:52:17] 4:10:1 [18:52:19] 4:10:01 [18:52:25] CSM RCS +X [18:52:30] Inertial [18:52:37] 3 second maneuver [18:52:41] which you enter with [18:52:49] M40,P1,,,3; [18:53:00] that puts a -1 as the DV [18:53:08] which looks weird, but internally it would be correct [18:53:19] has to be minus so that it uses the burn time [18:53:24] then [18:53:26] IMU attitude [18:53:31] same as you calculated on the DMT [18:54:12] gives me a 0.4 ft/s maneuver [18:54:29] wouldnt it be -X? [18:54:47] yes, but you use the sep attitude [18:54:53] oh right [18:55:08] extraction attitude probably calculated the person who writes the TLI PAD [18:55:11] not FIDO himself [18:55:28] just a little trick so that he doesn't need the extraction attitude [18:55:37] is there a place with all the P1-P7 and M40 input descriptions? [18:56:30] pretty sure I gave you the document [18:56:38] HSI-209462 [18:56:44] PDF page 424 [18:56:54] ah yes [18:56:56] I have it [18:57:01] thanks [18:57:03] and it's an undocking maneuver [18:57:09] right [18:57:10] config after is CSM+LM [18:57:33] and lastly they put the evasive maneuver on there [18:57:43] I guess in our case we can cheat, not put in that maneuver and just update the MPT initialization after sep? [18:57:44] 4:40:01 [18:58:14] we could [18:58:30] since we dont have to wait hours for new tracking data :D [18:58:44] well, this is the config it was in before the EPO PADs were done [18:58:57] so RETRO needed all of this to calculate his RTE abort maneuvers [18:59:24] when FIDO had added the evasive maneuver he then told RETRO "you can start" [19:00:10] hmm [19:00:14] something is buggy [19:00:21] I added the evasive maneuver but the DV is wrong [19:02:33] should TLI pad generation work on Apollo 12? [19:02:50] I think so, yes [19:02:53] ok [19:07:04] when I add the evasive maneuver directly after TLI then it calculates right [19:07:17] probably a bug related to the 0 DV maneuver [19:07:34] back in a bit [19:23:10] hmm, I tried M58 with my MCC-2 solution and it seems to flip YB (yaw?) [19:24:31] YB is LVLH attitude I think [19:24:50] and it uses a weird LVLH convention [19:25:08] hence the need to input the weird angles for sep [19:25:39] ok [19:26:49] so I should look at OR, IP, MY for a normal P30 attitude? [19:27:07] that's IMU attitude yeah [19:27:16] ok [19:27:25] I think those labels should actually be different for the LEM [19:29:09] oh the P30 option in REFSMMAT no longer gets a DV vector [19:30:00] hmm, right [19:30:09] not from the MPT at least [19:30:11] and if I manually input one on the external DV uplinks page, then go back to the P30 REFSMMAT page it shows a TIG and DV vector [19:30:30] but calculating displays all nans [19:30:46] with the input TIG and DV? [19:30:53] yeah [19:31:03] bugs are all around [19:31:09] haha [19:32:54] to be fair I dont think you've touched REFSMMATs in a while [19:33:11] I've only touched it a little bit with the MPT changes [19:33:18] but no testing [19:33:31] some REFSMMAT options need a SV from the MPT [19:34:21] Im launching Apollo 12 tonight I think [19:34:33] from the ephemeris rather [19:35:13] Im sure I can fly it even with those bugs, the only time I need to do a P30 REFSMMAT is LOPC's I think [19:36:01] and if there are more bugs, well I guess the best way to find them is to fly a mission :D [19:37:06] btw did we ever get around to finding an Apollo 12 LM timeline book with the missing page 3 & 4? [19:37:07] good way to distract me from the fact that I don't got mode 4 working properly yet [19:37:36] true [19:37:36] I don't think so [19:47:27] ok found the bug with the evasive [19:47:36] as I thought an MFD issue [19:47:55] the coordinate system indicator (IMU, LVLH, FDAI) is normally set to -1 [19:48:09] when no attitude is given [19:48:32] I entered two maneuvers with inputs between TLI and evasive [19:48:36] and it wasn't -1 anymore [19:48:50] and then with the evasive maneuver it thought I had input an attitude [19:49:08] now I reset it to -1 whenever the burn data is not P1 [19:49:36] and the DMT with a 0 DV maneuver just never had the burntime initialized to 0 [19:49:44] that is now done and the BT will show 0 [19:50:14] I'll check if it all works and look at the P30 REFSMMAT then [19:53:17] sounds good [19:54:45] looks all good [19:55:18] I guess the REFSMMAT calculation just had an issue in MPT mode [19:55:54] did you try the calculation when you had a maneuver or more in the MPT? [19:56:17] yeah [19:56:33] but I tried also a different scenario without even activating the MPT [19:56:45] oh [19:57:19] tell me what you did so I can replicate [19:57:24] which scenario [19:57:46] my Apollo 16 PDI scenario [19:58:10] and what did you calculate? [19:58:34] ok so in the case of no MPT, it works if you enter the DV TIG and vector in the uplinks page and then go back to the P30 REFSMMAT page and calculate [19:58:50] a simple GPM maneuver [19:58:51] well, or calculate any maneuver [19:59:03] yes but thats the thing [19:59:14] it doesnt transfer to the P30 REFSMMAT page [19:59:21] what doesn't? [19:59:26] in non MPT mode? [20:00:06] If I calculate a maneuver, it used to automatically populate the P30 REFSMMAT page, but not anymore. This is in both MPT and non-MPT [20:00:18] huh [20:00:35] pretty sure that should still work in non-MPT mode for most things [20:00:40] maybe I broke one or two [20:00:47] what did you try? [20:00:56] I tried TLMCC and GPM so far and it doesnt [20:01:06] ok [20:01:15] well TLMCC was with the MPT [20:01:22] oh [20:01:23] but GPM noty [20:01:25] I see [20:01:27] not* [20:01:40] you need to use the transfer to MPT page [20:01:52] it just only makes it from impulsive to finite maneuver [20:02:00] doesn't transfer it to MPT [20:02:12] oh I did that [20:02:15] oh [20:04:18] works for me [20:04:21] tried the GPM [20:04:34] it even shows the same TIG and DV on the transfer to MPT page [20:04:54] hmm [20:05:54] you calculate on GPM page then calculate finite burn [20:06:04] and that's the TIG and DV that is used MFD wide [20:09:15] hmm [20:09:48] so the MPT does have to be active? [20:10:05] it has to be not active [20:10:51] ah ok I see [20:11:12] it doesn't work if it is active [20:11:19] I thought that if it was not active you would never go throught the MPT step on any given maneuver page [20:11:24] through* [20:11:52] right, I should probably change the diplays in non-MPT mode [20:12:03] so that it just says that it is calculating a finite burn [20:12:18] the reason is of course that you have the same thruster selection option as in MPT mode [20:14:08] I guess the TAB and REP buttons dont do anything in non-MPT mode? [20:14:39] yeah [20:14:43] should probably be blanked [20:14:46] in non-MPT mode [20:14:50] yeah [20:16:26] most other inputs also don't work [20:16:35] really only the selected thruster [20:19:08] I'm blanking all the things [20:20:42] all these new features like the midcourse tradeoff display will all fully work without MPT [20:21:02] and only on the transfer to the MPT or to an finite burn should there be a difference [20:21:05] that is the idea [20:21:18] most real MCC display will need the MPT though [20:55:56] Sounds like Ron is going to scan the (probably) final LOI targeting document some time in the next few weeks [20:57:11] nice! [20:58:49] He had some scanning trouble [20:58:56] today is his first day back at NARA this year [20:59:34] he has finished scanning the MIT schematics last year and is doing LM schematics from Grumman [20:59:49] "Almost everything so far relates to the mechanical structure ... struts, beams, heat shielding, engine mounts, and so forth." [21:00:07] maybe useful to update our LM 3D model, but not any simulation yet [21:07:32] great [21:16:40] do you think you could get column 2 of the space digitals display working without too much difficulty? [21:17:57] I can do the entering the SOI and the closest approach easily [21:18:55] the node is a bit more tricky [21:40:37] I'll have the bunch of fixes and additions ready tomorrow [21:40:40] good night! [15:27:17] morning [15:32:37] hey Alex [15:41:32] just about to launch Apollo 12 [15:41:48] got your latest update [15:45:24] great [15:45:39] added the closest approach for space digitals column 2 [15:45:57] and I am now changing the Checkout Monitor to the MED format and am adding the 3 missing options [15:46:06] radius, altitude, flight path angle [15:46:27] I tired it, but have trouble getting it to display anything [15:46:29] so you can get the closest approach with the checkout monitor as well [15:46:34] hmm [15:46:49] oh right [15:46:53] it's quite annoying [15:47:10] for column 2 you need to enter inclination and ascending node for the node calculation [15:47:13] every time [15:47:20] just add 0s for that for now [15:47:34] so in the MED code two additional 0s at the end [15:47:57] ah ok [15:48:01] other MEDs have a remember function so that you don't need to enter those values every time. But the space digitals one apparently hasn't [15:48:33] MANDATORY FOR COL. 2, NOT ALLOWED FOR.COL. 1 AND 3 [15:48:44] great [15:48:52] works [15:49:04] thanks for that qick addition [15:49:07] quick* [15:49:11] sure [15:49:32] inspired me to add a better function for finding e.g. flight path angle = 0 [15:51:25] it's the same function as used to build the ephemeris [15:51:53] by default the ephemeris would stop being built at 400k feet for Earth or 0 altitude for Moon [15:52:07] it kind of does that already, although not exactly at those altitudes [15:52:56] the checkout monitor with find the option to find 0 altitude was used a lot by the FIDO to check the current status of S-IVB impact coordinates [15:54:20] sounds like quite a useful option [15:55:54] and if I remember correctly they also used it to find apolune times on Apollo 11 lunar ascent [15:56:48] cant the orbit digitals do thatÉ [15:56:54] ?* [15:57:51] I think the FDO Orbit Digitals would actually not work in TLC [15:58:03] it kind of switches between FDO Orbit Digitals and Space Digitals [15:58:09] only one of those works at a time [15:58:13] and in lunar orbit... [15:58:15] hmm [15:58:49] I think the checkout monitor finds a more precise time, but not sure [15:59:08] ok [16:01:08] I guess they always have multiple options available [16:02:32] and I am implementing the error messages for the checkout monitor [16:02:43] shows an "Error X" on the checkout monitor page [16:02:50] was useful for me already [16:02:56] I wanted to see when the S-IVB reaches altitude 0 [16:03:00] but it never does [16:03:07] it flies past the Moon at 1400NM [16:04:02] and if want no more complicated option the MED input method is actually quite simple [16:04:11] U02,CSM,GET,27:0:0; [16:04:21] or U02,CSM,MVE,1; [16:04:34] that defaults to ECI reference though [16:04:46] U02,CSM,GET,27:0:0,ECT,FT; [16:05:00] would get you Earth centered true, with feet and feet/second display [16:05:08] no [16:05:11] haha [16:05:18] U02,CSM,GET,27:0:0,,ECT,FT; [16:05:25] needs to skip the threshold time input [16:05:36] and as always you can use the one RTCC document as reference [16:10:02] and for MED input errors [16:10:16] there would be something on the online monitor [16:10:27] like "something is wrong with the 5th input" [16:12:38] nice [16:13:54] that will come soon, with the MED errors [16:14:06] right now there isn't really any clue what you did wrong [16:15:17] yeah that will definitely help haha [16:15:52] also would there be any way to make the MFD screens not revert back to the main menu when you change panels and back? [16:18:20] it doesn't [16:18:29] but if you have multiple MFDs open [16:18:38] it will have the screen of one of them open [16:18:42] on all of them [16:18:58] but that should also be fixable I think [16:20:08] it's also rather buggy when you save and reload a scenario with two or more RTCC MFDs open... [16:20:53] or is there a separate bug I am not aware of? [16:21:14] If I have one RTCC MFD open and then change back and forth between panels it still has the original page open [16:25:43] I think I notice in in the lower LEB display, with 4 MFDs open at the same time [16:26:06] I switch panels and back and they are all on the MPT I think [16:26:47] yeah, they will all have the same page [16:26:52] one of the ones that was open [16:27:00] that should be fixable [16:28:16] not super urgent of course [16:54:19] yeah it's a bit difficult [17:09:55] I still need to add the page to compute nodal targets in EMP coordinates [17:10:24] ah right, that is what we used the commented code in the MFD code for [17:11:34] and I need to fix the TLI page [17:17:15] alright, good Apollo 12 launch + insertion [17:17:38] had the FDO launch analog up too [17:19:03] here's the display post-insertion: [17:19:05] https://www.dropbox.com/s/pybbsfyuhduvkq8/Screenshot%202020-01-29%2010.17.58.png?dl=0 [17:21:59] the gaps are when you were looking on another panel or when you were outside? [17:22:10] I think it's only writing the data when the MFD is active [17:23:11] what's also fun is to have the space or orbit digitals on during TLI [17:23:31] when the TLI is in the MPT you can then see the trajectory that it predicts you to have [17:24:36] from the TLI sim [17:27:48] nice [17:28:03] yeah I was switching back and forth between views [17:29:07] I am still hesitant to implement a real RTCC timestep [17:29:19] so that it does something on every timestep [17:29:22] and not just on request [17:39:51] this may be a stretch but I was thinking of something last night. Eventually, could we have the entire RTCC in an outside application, independent of Orbiter and just have the 2 communicate? [17:40:54] that way you could not have the limitations of an MFD and I guessw would solve the issue you described above [17:41:02] guess* [17:44:20] eventually that should be possible, yeah [17:44:40] one thing I still need to improve more is the dependency of the MFD on the Orbiter API [17:45:05] that makes it more difficult to port to an outside application [17:46:39] So how would people use this new nodal state utility [17:47:00] they find latitude and longitude at e.g. LOI in a mission report [17:47:06] put that in [17:47:15] it gets converted to EMP coordinates [17:47:29] should I add another button that directly transfers the new numbers to the SFP block 1? [17:48:41] and then with the new TLMCC processor you can run a mode 1 to that target [17:51:35] sure [17:51:49] also would convert GET to GMT [17:52:52] for completion I'll also add an height input to that page [17:53:02] then you have the whole nodal state [17:53:15] also nicer than having to manually edit the SFP through the MED [17:54:16] yeah [17:54:32] TLI successfully added to the MPT [17:54:38] Apollo 12 [17:55:11] great [17:55:20] seems to work fairly reliably after I had found that one bug [17:55:30] other than trying to calculate it after TB6 :D [17:59:17] there is still a 2 second difference for the TIG + BT and cutoff GET in the checkout monitor, but that is just because of tailoff thrust I guess? [17:59:49] yeah [18:01:24] TB7 begins before tailoff [18:01:45] so the very accurate TB7+900 time would be not be the one on the checkout monitor [18:06:13] right [18:06:28] ok for sep is 41.6 P, 120.8 Y, 131.9° R all missions except 8? [18:07:06] yes, except for the sign [18:07:17] some missions were to the left 40°, others to the right [18:07:27] if those numbers don't work make it minus on yaw and roll [18:07:33] that would definitely work [18:07:40] right [18:07:42] I can check [18:08:03] Apollo 11: [18:08:03] LVDC_XLunarAttitude 3.141589512 2.094395207 0.6981317008 [18:08:22] LVDC_XLunarAttitude 3.141589512 2.094395207 -0.5235987756 [18:08:24] huh [18:08:30] 30°?? [18:08:38] guess I was wrong [18:08:48] good that I made a conversion tool [18:08:53] I give you the right numbers [18:09:51] you need [18:10:45] 48.59° P -130.89° Y -139.11° R [18:11:04] for Apollo 12 [18:11:22] yep [18:11:37] 120° pitch, -30° yaw in the normal and the LVDC convention [18:12:06] but not the convetion that the RTCC likes... [18:12:14] convention* [18:12:49] well and 180° roll [18:12:50] hmm pitch and yaw are good but roll is 274 [18:13:18] and you had two minus? [18:13:23] oh stupid me [18:13:29] forgot the last - [18:13:46] for Apollo 12 we actually have a document with these numbers I think [18:13:53] with both conventions [18:14:43] there we go [18:14:56] https://i.imgur.com/FqChCLT.png [18:15:23] looks like I calculated it right [18:15:46] that's from the separation procedures [18:15:48] MSC memo [18:16:33] I think one is body relative to LVLH, and the other LVLH relative to the body. Or something like that... [18:20:44] as you can see I am not just making up angles to make it more difficult :D [18:22:41] haha I didnt think so [18:22:48] so SV update time [18:23:04] I still have my MPT active with maneuvers on them [18:23:11] will that mess with my SV update? [18:25:32] it will take a SV from the ephemeris [18:25:44] the first state vector before the time you give it [18:26:03] ok [18:26:14] so I just have to give it a time before the 1st maneuver [18:27:16] can I push TUP on the MPT even though I already have maneuvers on there? [18:27:39] give it the time at which you want the SV to be accurate [18:27:53] can be close to now I guess [18:28:00] yeah [18:28:05] yes you can [18:28:39] I mean heck, I can just delete those now anyways [18:28:39] it will integrate through coasting and maneuvers with the new initial state vector [18:28:50] right [18:29:18] its just the config button you were saying not to press wwhen maneuvers are already on it [18:29:22] the only thing it doesn't do right now is recompute the TLI TB6 time [18:29:39] you can press the config button and it should reject your update [18:29:58] you can update the masses [18:30:18] you might even want to do that. Our S-IVB looses mass from venting, although it simulates no acceleration from venting yet [18:30:39] the old TLI PAD calculation took the mass loss into account a bit [18:30:43] the new one not yet [18:30:54] but I doubt it's more than a second difference in burntime [18:31:10] if you do another mass update e.g. shortly before TLI again [18:32:18] ok [18:33:19] on Apollo 13 they messed up a bit with the venting [18:33:41] somehow they messed up the MPT so that the S-IVB kept using venting acceleration [18:33:52] which didn't help their tracking of the S-IVB [18:33:57] took them a while to figure out [18:34:47] that will be its own project some day, implement S-IVB venting acceleration realistically and at the same time implement it for the RTCC [18:35:49] is there a way to delete all maneuvers in the MPT in one command? [18:36:16] delete the first maneuver [18:36:20] deletes all of them [18:36:51] I do that by accident so many times... [18:37:01] when I just wanted to delete the 2nd or 3rd maneuver [18:38:54] hmm [18:39:23] I think LM NAV UPDATE TO CMC may still update the CSM slot [18:40:10] both uplink to 00021,01501,00001 [18:40:14] is that correct? [18:43:17] oh [18:43:20] let me check [18:44:27] hmm [18:44:35] did you press CLC again? [18:44:42] yeah' [18:44:49] if (SVSlot) [18:44:49] { [18:44:50] SVOctals[2] = 1; [18:44:50] } [18:44:51] else [18:44:51] { [18:44:52] SVOctals[2] = 77776; // Octal coded decimal [18:44:53] } [18:44:56] there is the 1 [18:45:08] and the exact same logic is used for the display [18:45:59] hmm [18:46:14] did you have an active LM MPT? [18:47:25] maybe it didn't actually update the SV in the MFD [18:47:35] and then it uplinked the same thing [18:48:42] hmm [18:48:53] that probably needs some work [18:49:03] you can also choose to use the CSM MPT for the LM SV [18:49:28] hmm [18:49:29] or can you [18:49:33] no active LM MPT [18:49:49] yeah, then it didn't actually update the uplink string [18:49:53] and kept the 1 [18:50:21] ah [18:50:32] so I just need to have an active LM MPT [18:50:52] I think so [18:51:27] they had the LM MPT active to prepare for TLI 2nd opp [18:51:34] that will be possible soon [18:51:46] there should be some error message [18:51:59] so what do I tie the LM to, yankee-clipper also? [18:52:28] since the LM doesnt exist yet [18:52:35] yes [18:52:42] they had the same initial SV for both [18:52:46] and the same config [18:52:59] TLI 1st opp in the CSM MPT and ephemeris, 2nd opp in the LM [18:53:23] yes [18:53:32] it works with the LM MPT [18:53:38] VID 77776 [18:54:44] yeah [18:54:59] something on that page should tell you about this issue [18:55:06] maybe display the vehicle name? [18:55:18] in MPT mode the one associated with the ephemeris [18:59:08] and otherwise it will say [18:59:10] "None!" [18:59:44] yeah [19:00:32] or [19:00:35] No Vessel [19:02:15] about the TLI on the MPT, and monitoring it with space digitals during TLI [19:02:49] I can just use the space digitals and UPD U20,CSM;? [19:08:38] seems to work [19:14:31] TB6 was a few seconds off, but I guess due to the slight mass difference [19:19:49] I think anything below 8 seconds off is normal as the LVDC only updates the SV that often [19:20:52] what is U20,CSM; supposed to do? [19:28:52] just initialize the space digitals [19:29:13] TLI went well, I monitored it with space digitals, quite cool [19:29:25] DVC at cutoff went to -10 fps [19:29:28] not to bad [19:30:38] Apollo 12 has a weird trajectory lol, IU seemed to be really maneuvering a lot during TLI [19:31:07] and the moon-rise is way off to the right of my flight path haha [19:33:16] I had 2.6 ft/s on 13 and 3.6 ft/s on 11 [19:33:22] DVC [19:33:48] could be that the presettings still need a bit of tuning for Apollo 12 [19:33:52] could lead to the maneuvering [19:34:28] and space digitals init is U00 [19:34:32] U20 is the DMT [19:37:11] sorry I meant U00 [19:39:33] hmm, I somehow cant delete TLI [19:39:36] from the MPT [19:44:08] oh right [19:44:17] you can't delete past maneuvers [19:44:22] it's a different process [19:44:24] history delete [19:44:30] but you don't actually have to do that [19:44:39] in theory [19:44:48] you can leave it in and do a TUP [19:45:27] it should basically ignore past maneuvers, although that isn't tested very well [19:45:50] history delete is not 100% implemented yet I think [19:46:37] not sure if past maneuvers should even appear on the MPT [19:46:41] the display [19:47:10] if it's too buggy you might have to reload, haha [19:49:01] history delete is complicated as it needs to move a lot of things from the MPT maneuver block to the init block [19:49:53] ok [19:50:16] does the SFP 2 get saved in the scenario? [19:50:38] not yet [19:51:05] I guess I can go on a deletion spree [19:51:15] hmm [19:51:17] not quite yet [19:51:25] still need to build the SFP for some missions [19:51:40] and then I'll delete all the old TLMCC variables [19:51:45] and add saving/loading for the new ones [19:52:18] I'll do all those things next [19:52:20] ok [20:22:01] indy91, so for the SIVB, restart maneuver enable, then TB8 enable? [20:22:20] restart maneuver is Apollo 9 only I think [20:22:23] you want evasive [20:22:41] ok [20:22:58] but I remember a specific order needed, evasive before TB8? [20:22:59] 12 still does the slingshot [20:23:03] yeah [20:23:09] evasive is the yaw maneuver [20:23:18] a few minutes after LM ejection [20:24:37] it changed from mission to mission until Apollo 13 [20:24:47] so I always have to look up which missions does what in which order [20:27:56] when to send the TB8 enable though... [20:28:53] when you send that it will start firing the APS immediately [20:29:15] so you should send the evasive maneuver signal shortly after LM ejection [20:29:28] and the TB8 enable right when the flight plan says it does the maneuver [20:29:42] the S-IVB APS Evasive [20:30:39] right, thats what I thought [20:31:36] there she goes [20:32:18] it was different on 10 and 11 [20:34:03] and then different on 13 and later as they crash into the Moon [20:34:38] right [20:35:04] did they use the RTCC for the slingshot maneuver? [20:37:38] hmm [20:37:51] there was a ground commanded APS burn later on on 12 [20:38:08] but it's mostly the preprogrammed APS burn and LOX dump [20:38:14] 10 and 11 did it that way [20:38:44] hmm [20:38:51] there is a preprogrammed APS burn later on [20:39:03] but they send some ground commands [20:39:11] it should fly past the Moon anyway [20:45:42] hmm my mode 5 wont calculate [20:46:23] did the same procedure as before [20:50:26] even with a fresh RTCC MFD, no MPT just doing a simple mode 5 calculation without MPT doesnt seem to work [20:54:43] here is my scenario if you wanted to test [20:54:44] https://www.dropbox.com/s/3kpzotyhm1nztr5/Apollo%2012%20-%20Launch%200022%200026.scn?dl=0 [20:54:51] anyways I gotta run! cya [22:21:58] . [14:15:31] hey [14:16:12] hey Alex [14:16:19] seems to be yet another patched conics bug [14:17:15] the mode 5 issue? [14:17:31] yeah [14:17:38] with an earlier TIG it works fine [14:17:48] yeah I noticed that [14:18:03] but when the TIG is beyond 90° eccentric anomaly there is another atan vs. atan2 issue [14:18:25] it's a simple fix, but not necessarily an easy one [14:18:40] have to play through a few scenarios in my head, with the sign of the number etc. [14:18:53] easy to fix this case and break all other cases :D [14:19:06] right [14:20:16] its weird how it worked on my old Apollo 12 scenario [14:21:57] it's close to 90° [14:22:10] maybe a TIG a few minutes later would already fail in the old scenariod [14:22:18] due to slightly different trajectory [14:22:35] I see [14:24:29] difficult to say [14:24:41] the function that fails only serves as the initial guess for the patch time [14:24:53] so maybe sometimes even with the bug it manages to work, by luck [14:26:25] yeah [14:27:26] the good news is my mode 9 was 2 fps :D [14:28:03] MCC-1 scrubbed obviously [14:28:22] haha, yeah [14:28:25] I tried one as well [14:28:30] takes a bit longer to calculate [14:28:40] mode 9 at MCC-2 time would be 7 ft/s [14:31:58] the DV I get for MCC-2 is a bit larger than planned [14:32:02] but it works at all TIGs now [14:32:06] 83 ft/s [14:32:18] if I make the LOI TIG a bit closer to the flight plan it is 86 ft/s [14:33:33] ok [14:34:22] no big issue I guess [14:35:48] oh [14:35:49] oops [14:35:56] had the LOI hour wrong :D [14:36:40] all very much as planned now, haha [14:37:14] let's see, what is this patch function used for... [14:37:35] backwards from pericynthion to MCC and from Moon to Earth is both hyperbolic [14:37:45] which uses a different part of the function which didn't have any issues so far [14:37:53] it's only the eccentric orbit that was a problem [14:38:02] and I think that is only used for Earth to Moon patch [14:38:25] and it works for all TIGs now, so, hopefully it's fully fixed now. Will test a few other missions [14:39:26] but I have pushed it already so you can continue [14:39:33] I also implemented SFP block 2 saving/loading [14:51:50] ok thanks! [14:58:29] works well [15:01:48] now I need to work on the TLI planning page [15:02:03] or disable it for now, haha [15:02:20] not that you really need it with all the missions having presettings [15:02:50] the real planning tool actually uses TLMCC routines [15:03:18] is there a way to view SPS trim angles for a burn using the DMT or another display? [15:04:18] isn't it on the DMT? [15:04:23] to the right [15:05:00] DEL p [15:05:02] DEL Y [15:05:47] right [15:06:57] hmm [15:07:04] those numbers don't look right [15:07:57] yeah [15:08:04] 2.15, -0.95 [15:08:22] isnt that some hard-coded value? [15:08:27] yeah [15:08:36] that's the electronic null position of the SPS [15:08:44] the trim angles are relative to that [15:15:02] I guess we should see that null position as 0,0 on the DMT [15:15:35] yes [15:15:39] so it's at least two bugs :D [15:15:47] first it should have the CSM/LM docked angles [15:15:58] and then not show the absolute but the relative angles [15:25:38] just a few status indicators were wrong, not the calculation [15:26:09] it wanted to use the system gimbal parameter and not the calculated ones [15:26:33] as in, you can specify specific angles at ignition [15:27:52] pushed the fix already if you want it [15:28:04] nice [15:28:11] it was working correctly for direct input maneuvers already [15:28:13] it will come in handy for MCC-2 [15:28:30] but not for all those that go through the function that makes a finite burn out of an impulsive one [15:29:49] right [15:31:59] hmm [15:32:12] I have to check though if the ignition attitude is correctly calculated [15:34:28] works on my 1st test [15:35:00] ah [15:35:18] it subtracts the offsets in the DMT display function [15:35:21] and not before [15:35:47] so on the MPT itself the body attitude and gimbal angles include the offset [15:35:55] is that good? [15:36:01] I think so, yes [15:36:04] ok [15:36:07] gives the right IMU angles [15:36:27] the DMT angles agree with the maneuver pad page angles [15:37:03] could be that the offset should be subtracted somewhere else, but it does give the right results [15:47:57] have you tried the replace option with the MPT yet? [15:48:09] I haven't, need to debug that some time if it's not working right [15:49:18] I have tried yes but didnt work for me, thought it may have been an input error [15:49:38] one time it seemed to duplicate the maneuver on the MPT, instead of replace it [15:56:29] haha [15:56:33] I'll check it [15:56:40] can be quite useful I think [15:56:55] as you don't have to delete all the time before adding a new maneuver [15:59:54] yeah [16:00:23] does SV update work in non-MPT mode? [16:00:44] I just want to give it a SV on my present trajectory [16:02:43] ah yes it does [16:02:53] it definitely should [16:03:29] MPT mode should also give a SV from the current trajectory [16:03:34] well [16:03:37] from the ephemeris [16:03:43] provided you haven't done any thrusting [16:03:51] and a TUP not too long ago [16:04:38] also, if I am in MPT mode, with a bunch of maneuvers on it, and then deactivate MPT mode, will the MFD work just fine in non-MPT mode, or wold that be buggy? [16:07:57] that should work [16:08:07] it really only looks at the status flag [16:08:11] active or not active [16:08:53] ok [16:20:17] whats parameter in the checkout monitor? [16:21:51] depends on the option [16:21:54] oh [16:21:55] right [16:22:00] GET or MNV number [16:22:06] yeah [16:22:08] or the new options [16:22:11] flight path angle [16:22:16] radius and altitude, both in NM [16:22:36] flight path angle as 0 is a good check on the pericynthion passage [16:22:43] similar to space digitals column 2 I gues [16:23:01] and altitude = 0 to see where it impacts, if it does [16:23:07] I actually checked that in your scenario [16:23:17] I think the S-IVB had still some dumping or thrusting to do [16:23:28] beause it had a -600NM pericynthion height [16:24:26] yikes [16:24:47] I think that was still before the LOX dump, which does the majority of the DV [16:26:39] oh, and the threshold time for the checkout monitor [16:26:44] it says optional there [16:26:48] but it's more complicated [16:27:17] optional for GET, GMT [16:27:23] illegal for MVI, MVE [16:27:27] mandatory for RAD, ALT, FPA [16:27:58] threshold time for GET and GMT are taking a SV from the ephemeris at the threshold time [16:28:13] and then propagate the SV to the input time [16:32:10] ok [16:39:30] LOI will be 3 seconds off from flightplan [16:39:45] 1 fps difference in DV [16:39:59] quite good I think :D [16:50:55] yeah, I had the same [16:51:10] once I did not cause it to be 1 hour off by adding a wrong limit [16:51:58] the LOI GET is only an estimate on the midcourse tradeoff display, but shouldn't be too far off from what it would actually calculate [16:52:14] I added LOI to the MPT, and compensated the MCC [16:52:17] at least it's not the impulsive time [16:52:51] one of the cases where having multiple versions of the same document is useful, as only the first version of the TLMCC processor document had the calculates for the LOI (and TEI) GET [16:52:54] calculations* [16:53:45] what do you mean with "compensated the MCC"? [16:54:12] LOI GET was 45 seconds later then the tradeoff estimate [16:54:26] so I just used a TLMIN 45 seconds earlier [16:54:36] ah [17:21:40] alright good MCC-2 [17:21:52] confirmed with space digitals [17:22:39] is it too late to tell you that I have not tried actually performing a maneuver of the new TLMCC processor yet? :D [17:23:00] I have confirmed the DV with old Maneuver PADs from the MCC though [17:24:08] well I will say I had a scare after MCC-2, I checked the space digitals column 2 and my closest approach height was 1600 NM [17:24:28] but it was simply due to not updating the trajectory in the MPT [17:24:46] I had removed MCC-2 from it before the burn [17:25:18] but I had to push TUP again after the burn then space digitals showed a perfect PC state [17:29:09] sounds about right [17:29:29] the history delete option is DH instead of D in M62 [17:29:37] which might work right or not :D [17:29:48] that's for maneuvers that already happened [17:31:39] ok [17:38:48] for LOI, I will bias the landing site so that at DOI I have a better alignment [17:38:57] LS latitude [17:39:53] which should make my LOI even more accurate then the real Apollo 12 :D [17:40:07] at PDI* [17:44:52] indy91, I would previously use the MPT in combination with the landmark tracking pad to check LS alignment at PDI time [17:45:06] to bias the LS latitude at LOI [17:45:30] but is there any new tools, other then the landmark tracking pad to accomplish this now? [17:45:55] to check for LS alignment at PDI time, but from before LOI [17:50:17] maybe orbit digitals, if I give it the LS longitude on the PDI REV, it will give me the latitude [17:50:32] and then I can calculate the bias [18:00:35] hmm [18:00:56] I'm not sure about the rev crossing table, if that can be defined so early [18:01:25] in theory the real landmark tracking display would do it [18:01:37] not quite sure right now if that already works [18:08:55] worst case is you need to manually find the longitude with the checkout monitor [18:09:06] by trial and error with the time [18:10:22] but the space digitals you can specify a rev and longitude, wouldnt that work? [18:10:27] orbit difitals* [18:10:28] uhh [18:10:35] landmark tracking page is MPT compatible [18:10:52] yes, but the rev table is not defined for the Moon yet [18:11:21] try the landmark tracking pad [18:12:30] ok [18:12:53] basically what I used to do, worked well [18:13:05] and there is a very similar display [18:13:10] which I have not implemented yet [18:13:40] and in theory it should also be possible with the Predicted Site Acquisition Table (PSAT), but that probably doesn't work yet [18:16:02] so many ways to do it [18:16:17] and yet they failed to on Apollo 12 :p [18:18:30] btw sometime times are displayed in the RTCC MFD as for example 83:28:60 or 016:22:60.00 [18:19:44] in the 2nd case I am guessing that means 016:22:00 [18:39:11] yes, sometimes the centiseconds are useful [18:39:38] "and yet they failed to on Apollo 12" what do you mean with that? [18:45:26] they was quite a high cross-range at PDI [18:45:44] right [18:45:54] in part due to an preflight RLS that was quite inaccurate [18:46:12] but also I thin because of LOI targetting [18:46:15] I guess potentially they also didn't have the lunar gravity 100% worked out yet [18:47:03] right [18:49:54] the pre-flight RLS we have for 12 is a few thousand feet north of the target I believe. You definitely have to update it in order to get near surveyor :D [18:50:20] Ill update mine at the time they did [18:50:44] right, the Surveyor [18:50:45] which means I should still have a bit of a crossrange error at PDI [18:50:56] had to delete that from the scenario you gave me [18:51:03] which one do you have installed? [18:51:12] delete what? [18:51:18] the RLS? [18:51:39] "right, the Surveyor" [18:51:48] oh yeah [18:52:09] I just had implemented saving/loading of the SFP [18:52:27] and then I started your scenario and it CTDed. I thought, what did I break this time :D [18:52:27] its a model that I modified from an addon [18:52:51] right [18:53:06] I never committed it for copyright reasons [18:53:49] right, I remember [18:54:23] once I have the new LOI targeting implemented the latitude bias shouldn't be necessary anymore [18:55:00] I mean, I even tried to implement an interim version of the backwards integration in the current LOI targeting [18:55:14] but I really can't say if that improved it or not, wouldn't want to commit that [18:55:45] right [18:55:55] any news from Ron? [18:56:06] not yet [18:56:19] I wouldn't expect it this week yet [18:56:52] he has to rescan some LM schematics, as the settings that NARA wanted him to use didn't work [18:57:01] so he is a bit behind his schedule [18:57:46] I just hopes it's not handwritten again, haha [18:57:49] ah bummer [18:58:30] yeah no kidding [21:32:12] night! [16:00:24] hey [16:05:45] hey Alex [16:07:55] I think I am not going to update the TLI planning display for now [16:08:18] I don't think they even had a real time capability to target TLI to a nodal state or to free return [16:08:34] they had some RTCC processor that did this [16:08:39] but it wouldn't have been used [16:10:07] ok [16:10:50] what they had was an ability to simulate TLIs with various state vector sources [16:11:08] and I think they also could target a specific apogee for TLI [16:11:12] for an E-type mission [16:12:29] and we have presettings for all missions now anyway [16:12:46] I'll re-add that capability at some point [16:15:26] what I am adding though is the ability to add a 2nd TLI opportunity to the MPT [16:15:35] and on either MPT [16:18:24] nice [16:18:54] I had a good LOI-1 & 2 last night [16:19:15] good to hear [16:33:53] works [16:34:11] although now you have the problem that you can't really tell which TLI belongs to which MPT [16:34:20] on the MPT display [16:35:20] never was sure though if the first letter of the maneuver code should be the thrusting vessel or the MPT vessel [17:06:39] sounds like the MPT vessel would make the most sense [17:48:52] sure [17:48:54] I'll change it [17:49:08] only with the RCS would there be any confusion [17:49:16] if it's an CSM or LM RCS maneuver [17:49:28] in most cases it would be on the CSM or LM MPT anyway [17:49:33] so a rare case [18:31:59] can the DMT display AGS info yetÉ [18:32:11] ?* [18:45:52] yes [18:46:06] I think it calculates AGS info for any LM burn [18:47:00] needs both CSM and LM MPTs being active [18:51:15] ah great [18:52:16] IMU gimbal angles are properly converted for the LM I guess [18:52:27] I think it shows both [18:52:30] IMU and FDAI [18:52:47] for the CSM it shows the same [18:52:48] ok [18:52:58] although it might still be labelled wrong [18:53:43] YB, PB, RB are always FDAI angles [18:54:34] OY, IP, MR [18:54:44] I guess that should show the same as N20 [18:54:53] so the Y, P, R order is wrong for the CSM [18:55:05] of the labels [18:55:09] numbers are probably right [18:55:14] have to check that [18:56:44] OR, IP, MY would be right for the CSM [18:56:49] outer, inner, middle gimbal [18:56:52] roll, pitch, yaw [18:58:28] OY, IP, MR labels are correct for the LM [18:58:33] I'll change that [18:58:45] great [18:59:34] btw I at LOI I biased the landing site latitude, if I hadn't at PDI I would have had an over 5 NM cross-range error! [19:00:41] and curiously, the effect on the LOI was more on the DVz then the DVy [19:01:19] yeah, you shifted the node to earlier or later [19:01:50] so TIG was different more than DVY I guess [19:01:56] and TIG has a big influence on DVZ [19:02:25] the real Apollo 12 PDI pad had a 4.9 cross-range [19:02:44] right [19:03:45] there is a section in the mission report on that [19:03:49] yeah [19:04:38] I remember reading the error was partly due to LOI targeting and partly to an inaccurate pre-flight RLS' [19:04:44] yeah [19:04:57] but mainly wrong prediction of gravity shifting the orbit [19:05:30] they were using the AEG in the LOI processor still, which is not so good at this over a longer period of time [19:05:54] numerical integration should be better [19:06:47] so from Apollo 14 on [19:07:49] I guess they could have used the MPT and check the orbit at PDI time nonetheless? [19:09:29] yeah [19:09:40] how much better that would make things I don't know [19:09:52] Apollo 11 had good results with the latitude bias [19:10:00] Apollo 14 PDI PAD, +0.4NM [19:10:29] despite the high approach azimuth [19:10:36] definitely worked better [19:12:34] im showing a 0.1 NM cross-range 10 hours before PDI [19:12:50] will probably a bit more once I plug in the updated RLS [19:15:42] does LDPP use the TLAND vale in the RTCC MFD as an initial guess? [19:15:49] value* [19:16:28] Or does it calculate it independently based on the LDPP initialization data? [19:26:34] independently [19:26:53] so a sanity check on the landing time it comes up with doesn't hurt [19:27:03] could be off by 2 hours with the wrong inputs [19:27:28] GETTD [19:28:20] did you have to do a MCC-4? [19:42:28] nope [19:43:42] also, when calculating DOI, looking at the descent planning view, it will give a GETIG and GETTD, those are based on the impulsive DOI I think [19:44:16] those are PDI time and touchdown time [19:44:44] then I put it on the MPT, configure it with the proper DPS settings, 15 seconds then 40% thrust, and it gives a later TIG by a few minutes [19:44:52] hmm [19:45:07] I'll have to check that [19:45:07] si I can assume the TD time is also a few minutes more then the descent planning display? [19:45:35] or maybe there's a way to update the descent planning display with the non-impulsive solution on the MPT? [19:46:26] I don't think impulsive vs. non-impulsive is the issue [19:48:14] it must be something else [19:48:26] you mean the PDI TIG is inconsistent, right? [19:49:57] well, I calculate DOI with the LDPP and it gives a PDI TIG of 110:20:23 [19:50:29] then put it on the MPT with 15.0 s and 0.4 for the DPS [19:50:49] and MPT shows a TIG of 109:22:49 [19:51:07] for DOI or PDI? [19:51:30] DOI [19:51:54] both those numbers are within seconds of the flight plan [19:52:04] for DOI and PDI [19:52:14] yeah [19:52:32] the DOI TIG on the LDPP is further up [19:52:37] GETTH/GETIG [19:52:51] yes [19:52:52] PDI is where it has GETIG and GETTD [19:53:04] you're right and the number further up makes more sense [19:53:22] so all good? [19:53:25] 109:23:18 for PDI TIG [19:53:33] that wouldn't be good [19:53:45] then the MPT PDI TIG is 109:22:49 [19:54:11] hmm [19:54:20] I think you need to use -15s and not 15s [19:54:27] to make it bypass the short burn test [19:54:37] you probably have a very long DOI burn time as it is [19:54:59] "Delta T of 10% thrust for DPS (negative to ignore short burn test):" [19:55:08] if it is positive it won't throttle up at all [19:55:12] from 10% [19:55:20] same TIG with the -15 [19:55:32] hmm [19:55:34] that's strange [19:55:54] I have to run, but I can give you a scenario if you want [19:55:58] yeah [19:56:31] https://www.dropbox.com/s/mxjocqcjw428192/Apollo%2012%20-%20PDI%20day%200001.scn?dl=0 [19:56:40] thanks [19:56:41] and cya [19:56:59] I have an updated RLS in there btw [19:57:01] cya! [19:57:41] and a Surveyor [20:04:21] .tell AlexB_88 I got a good result for the PDI TIG on the MPT. Maybe you tried to take the CSM down to you to the lunar surface (initial config on the LM MPT being CSM/LM). [20:53:34] back [20:53:50] aha [20:54:06] yeah thats probably it [20:56:44] oh I get a string message when I open my latest scenario [20:57:38] something about MFDButtonPage::SwitchPage() page index beyond max size [21:00:33] yeah, that happens when you have two or more RTCC MFDs open when you save [21:00:35] some loading bug [21:00:39] should be fixable [21:03:12] I think Orbiter supports saving for two MFDs, so it saves all the MFD twice that is only really needed once [21:03:24] MFD data twice* [21:04:13] do I still do -15 for the DPS? [21:05:07] yes [21:05:08] ok 109:23:19 for the impulsive and 109:23:01 on the MPT for DOI [21:05:10] ok [21:05:18] yeah, I had about the same [21:05:22] great [21:05:33] maybe it didn't make a difference for you, because the CSM was still attached [21:05:36] making the burn longer [21:05:42] and therefore it will throttle up [21:05:42] yeah [21:05:49] the test is on 95 seconds burntime at 10% [21:10:01] the transfer to MPT logic probably should have stopped you adding a PDI with the config CSM/LM [21:10:05] I'll look into that [21:10:20] even with that, I'm not really seeing why it had PDI an hour too early [21:10:31] as far as I am seeing it should ignore the CSM mass [21:10:46] possibly some config weirdness anyway [21:18:16] you know ,I was looking at the PDI TIG and I had DOI TIG in my head [21:20:12] I think I was just confused about it, it may have very well a correct TIG (110:20:xx) but I had DOI in my head so it wasnt making sense to me [21:20:23] haha, could be [21:20:32] sounds like what I did with MCC-2 in your scenario [21:20:51] had the LOI TIG off by an hour in my head :D [21:21:28] haha [21:21:38] lots of TIGs to juggle I guess [21:22:00] true [21:22:30] so it does sound like you are flying a precise mission close to the flight plan then [21:22:44] yeah as close as I can get it [21:22:57] PDI TIG on LDPP display and MPT were different by a few seconds for me [21:23:00] not too worried about that [21:23:08] same here [21:23:20] LDPP uses some assumptions on burn arc and time of PDI [21:23:49] while the PDI on the MPT will have gone through the ignition algorithm [21:24:00] still with Apollo 11 parameters though [21:24:15] so many numbers to load for AGC and LVDC... [21:24:51] in the case of the LVDC I can directly copy the stuff over [21:25:03] yeah [21:25:05] AGC is a bit more tricky, needs conversion from octal etc [21:26:39] had a question about PDI simulation. I see a button for it on the MPT, but also a section for it in the LDPP, is it eventually going to be only in the LDDP, then transferred over to the MPT that way? [21:26:53] LDPP* [21:26:53] hmm [21:27:46] so there is definitely a MED independent from the LDPP to put a descent maneuver on the MPT [21:27:48] M86 [21:27:55] ah ok [21:28:04] but what I am not sure about is this [21:28:23] you can actually transfer multiple maneuvers at once to the MPT [21:28:39] doesn't work yet in the RTCC MFD, but they could add a whole CSI/CDH/TPI sequence for example [21:28:45] and the 1-4 maneuvers of the LDPP [21:28:52] and maybe also PDI with that? [21:29:04] not entirely sure [21:29:20] ah so thats why the LDPP would have it [21:29:26] even if not, the LDPP would be the main display to have PDI numbers before transferring to the MPT [21:29:41] I guess a bit like the TLI Planning Display [21:29:51] you could play around with different settings before transferring it [21:30:03] if you wanted to [21:30:23] is the PDI pad MPT-compatible? (with the PDI simulation) [21:30:25] I have to go back to the Apollo 11 FIDO look [21:30:29] loop [21:30:34] and see if the PDI transfer is separate [21:31:08] PDI PAD is MPT compatible [21:31:18] but [21:31:23] it only calls the ignition algorithm [21:31:29] it does not simulate the whole descent [21:31:39] so some numbers are probably a little bit off because of that [21:31:44] right [21:31:47] similar to the TLI PAD before [21:32:34] I have to add some stuff to the ascent and descent simulations anyway [21:32:43] they don't give all the numbers for the DMT yet [21:32:52] and they don't store a continuous ephemeris yet [21:32:59] only ignition and touchdown state vectors [21:33:33] right [21:34:19] I think I remember they actually used some numbers from their LM simulator at MSC for the PDI PAD [21:34:51] TGO on the PDI pad is one that sometimes is off on my previous missions [21:34:58] yeah [21:35:14] that depends on the ignition algorithm and descent targets [21:35:21] which are hardcoded to Apollo 11 right now [21:35:34] it's a bunch of numbers, all of which would be mission specific [21:35:49] so either I preload them in the MFD or add a method or download them from the AGC [21:37:05] add a method to* [21:37:55] I guess method 2 is the easiest [21:38:06] you would be wrong, haha [21:38:15] it might be slightly less work [21:38:31] but you have to get the numbers from the right addresses (will change from mission to mission) [21:38:42] ah, right [21:38:43] convert them from octal with the right scaling [21:39:08] already a bit challenging with the REFSMMAT downlink [21:39:11] sounds like pulling teeth [21:39:42] if I am counting right it is 26 numbers [21:39:48] that need to be loaded [21:39:50] not that bad [21:40:15] the RTCC would have them stored internally, identical to onboard, so I think I'll try that way [21:40:43] pretty sure 15 to 17 have the same numbers, so it's not different for every single mission [21:44:18] ok [21:59:28] good night! [16:50:46] hey [16:54:35] hey Alex [17:08:20] Intrepid is up and running [17:13:29] great to hear [17:13:40] I bet having the Surveyor as a target is always fun [17:15:27] yeah [17:15:48] and using some better landing site imagery [17:16:15] should be able to find it without the marker [17:17:09] right [17:17:27] one of the planned missions might have flown to another Surveyor [17:17:44] Apollo 20 at some point [17:18:09] outer rim of Tycho crater [17:18:19] pretty much where I landed with my Zerlina tests [17:23:20] I haven't done much on TLMCC modes 2 and 4 lately [17:23:30] kind of waiting if the new LOI document might help [17:31:29] right [17:31:49] mode 5 seems to work great [17:32:28] now that I can use a TIG past 28 hours :p [17:34:44] yeah, haha [17:35:02] each mission uncovers a new bug. Once every mission works it's surely bug free [17:35:11] in my dreams [17:48:39] in UDT button on the MPT (M58) what does the "S or C" parameter mean? [17:51:17] that's for the trim gimbal angles [17:51:42] you can let it choose on a maneuver per maneuver basis if it should calculate the angles or use system parameters [17:51:46] S = use system parameters [17:51:54] C = use trim gimbal angles [17:52:12] I guess if you don't want to change it just skip it [17:52:23] you don't even need the extra , for it [17:52:31] M58,CSM,1,U; works [17:54:02] C = compute trim gimbal angles [17:55:26] so I have a maneuver displayed on the DMT and the OR,IP,MY are 0,285,0. I want roll to be 180 so I did the M58,CSM,1,U; but instead in changes the YH,PH,RH values instead [17:56:44] those are the LVLH angles [17:56:48] I guess they would change as well [17:57:06] but only they change, that is weird [17:57:07] the maneuver in question is the soft undock. I used P1, LVLH=270 0 0 [17:57:23] oh [17:57:28] so you have a specified attitude [17:57:37] then the heads up/down logic isn't used [17:57:39] oh [17:57:45] of course [17:58:04] specify the roll 180 in the 1st place [17:58:05] oh [17:58:12] check the online monitor :D [17:58:15] does it say something? [17:58:28] that module is one of the few where I already implemented something [17:58:47] hmm [17:58:49] no [17:59:14] it says "you moron" [17:59:43] but in a seriousness, no it says nothing :D [17:59:50] all* [18:00:11] yeah, there is no message for this [18:00:32] because I think something would happen [18:00:44] ah! [18:01:04] "cannot delete as future" [18:01:29] I was trying to delete my maneuver but I passed it [18:01:37] nice to see its telling me [18:02:06] yeah [18:02:10] and lots more will come there [18:02:20] you can try DH instead of D [18:02:23] at your own risk [18:02:45] yeah [18:03:02] I was just practicing so I will reload my earlier scenario [18:03:21] so, what you did with the maneuver [18:03:22] now I have to figure out how to put the CSM separation maneuver on the MPT [18:03:26] it will have done something [18:03:51] as the maneuver was already run through the maneuver simulation, it will have calculated the specific attitude in inertial [18:04:01] and calculated an inertial velocity vector I guess [18:04:24] so it probably would have the same inertial direction as before [18:04:38] but the attitude you input might no longer be valid [18:05:16] haven't really tested that case [18:05:26] but it's not causing an error, it does something [18:09:41] the angles it outputs match wit hthe flight plan [18:10:09] LVLH=270 0 180, so nose pointing at the center of the moon [18:10:28] and FDAI 180 285 0, which is what the flight plan indicates [18:11:33] it's a bit dated (1967) but I have pretty good sources for the DMT calculation and display [18:18:30] so for the CSM separation burn its in the same attitude as undocking, but 1/4 orbit later so level with the horizon, and 2,5 fps +Z thrusters. Just trying to figure out how to put that on the MPT [18:19:20] oh +Z [18:19:26] yeah [18:21:37] not really sure [18:22:40] not very important to have on the MPT anyway, Ill just keep the same attitude and do a P30/P41 with 2.5 +Z [18:23:30] separation procedures document says it is -Z [18:23:44] -Z is "on top" of the CSM [18:23:59] but same issue with the MPT of course [18:25:02] "2.5 fps directed radially downward toward the center of the moon" [18:25:07] thats from the SCOT [18:25:25] yes [18:25:29] but using the -Z thrusters [18:26:04] right [18:26:30] maybe they get that far in the Apollo 13 FIDO loop [18:26:41] finished listening to the first tape today [18:26:47] at 14:30h right now [18:26:49] its confusing since the flightplan says +X thrusters haha [18:26:53] +z* [18:27:12] hmm [18:27:22] in any event 0 0 +2.5 in P30 [18:27:27] in that case maybe the sep document is older [18:28:35] and if all fails Ill just look outside to make sure the RCS plume is pointing up :D [18:32:13] maybe they had undocking and sep as two maneuvers in the MPT [18:32:23] undocking as a 0 DV, undocking maneuver [18:32:26] with the right attitude [18:32:33] and sep with the right DV [18:32:55] CMP Solo Book says "thrust up" [18:38:05] I see [18:42:03] "108:26:48 Conrad: Boy, do you look neat down there against the Moon, Dick." [18:42:21] makes me think the CSM thrusted down [18:45:23] but the CSM will be on top of the LM by separation TIG [18:45:37] so thrust up is more plausible [18:46:30] who knew such a simple maneuver can be so confusing :D [19:03:15] even the separation procedures document seems inconsistent [19:03:24] and it's from November [19:06:26] operational attitude document says -Z and radially downward [19:09:00] actually I was wrong, at separation TIG the CSM will be level with the LM with respects to the horizon [19:09:18] so based on Conrad's comment I am pretty sure its thrust down [19:28:00] you can also argue it with orbital mechanics [19:28:12] indy91, LDPP PDI TIG prediction from my DOI solution was 110:24:24, the PDI simulation TIG is 110:20:09. I am thinking the LDPP one would be more accurate since the PDI sim is loaded with Apollo 11 targets? [19:28:16] but then I come to the opposite conclusion I think [19:28:38] hmm [19:28:44] I had a 20 seconds difference when I tried it [19:28:48] not 4 minutes [19:28:59] uhh [19:29:01] no sorry [19:29:17] they are both 110:20 [19:29:18] difficult to say what is more accurate [19:29:25] typing error [19:29:29] ok [19:29:45] PDI sim would be be more accurate if it had the Apollo 12 LGC padload numbers [19:29:54] but the LDPP version is really quite simple [19:30:06] so, probably the PDI sim a bit better [19:30:38] yeah [19:30:41] Ill use that [19:30:48] btw PDI calculation failed [19:30:53] PDI PAD* [19:31:04] using the MPT [19:31:14] ah [19:31:16] I think I know why [19:31:38] it uses a SV from the MPT, but after the last maneuver [19:31:51] so if you have no PDI in the MPT it would probably work [19:31:57] ok [19:32:11] in your case it will try to use the the SV at the landing site [19:32:41] how do I improve that... [19:32:53] yes [19:32:57] it works [19:33:03] I could make it the opposite [19:33:17] in MPT mode require the descent to be in the MPT [19:33:25] and let it take values from the MPT for the PAD [19:33:25] whats the REQ button on the PDI PAD for again? [19:33:59] it's the same page as the Maneuver PADs, right? [19:34:04] yeah [19:34:24] accidentally clicked it [19:34:24] then it's the old functionality that I stole from the PAMFD to get P30 burn data from the LTMFD [19:34:36] oh right [19:35:02] used for something that the RTCC MFD couldn't calculate at the time [19:35:10] was it TEI? [19:35:40] or even TLI [19:36:24] did it crash when you clicked it? [19:36:56] clicking it again makes it stop requesting [19:37:22] back to the sep maneuver. At DOI you need the LM to be behind, or else the LM will come towards the CSM. [19:37:45] how do you get the LM to be behind? By having the CSM be faster [19:37:52] how is the CSM faster? By being below [19:38:07] how does the CSM get below? By thrusting away from the Moon [19:39:46] on 11 the CSM was below and used the -X thrusters [19:39:52] to go even lower [19:42:42] so [19:42:51] very contradicting documents :D [19:54:05] right [19:56:06] Ill thrust up then [20:07:53] ohhh [20:08:29] well [20:08:49] the CSM is heads-down at sep TIG [20:09:22] so you "thrust down" but that is really thrust down [20:09:44] really thrust up* [20:10:35] right [20:14:16] but "thust up" in the CMP solo book seems to me like what it sounds, pull back on the THC [20:14:30] which would mean a downward thrusting [20:14:48] since the CSM is head-down [20:16:49] yeah, that's how I interpreted that thrust up [20:17:42] and to make things even more confusing, the SEP pad in the flight plan has N81 +2.5 0 0 [20:19:45] fun [20:20:23] it should be z-axis in any display [20:20:29] in P30 coordinates it's Z [20:20:43] and in body axis as well, which you see in P41 [20:23:10] I think they may have loaded P30 as 2.5 in the X to get the correct attitude, but then burn the Z axis in P41 to 2.5 [20:23:29] CSM solo book seems to indicate this [21:01:22] hmm AGS rate needles seem buggy [21:01:53] in 400+2 z body axis steering [21:02:13] needles seem to center but them jump to a different attitude [21:03:23] like steering from the AGS is constantly shifting back and forth between different attitudes [21:03:33] weird [21:26:51] I had SV for DOI minus 10 in both CSM+LM slots, so SV in the future [21:26:57] and did the V47 with that [21:27:09] I wonder if the AGS doesn't like that [21:35:04] ah [21:35:09] there is some restriction [21:35:12] let me find it [21:37:42] well yeah, I think it might not like that [21:37:47] SV in the future [21:38:15] yeah [21:39:42] it doesn't like one 2 hours or more in the past [21:39:45] it als* [21:39:46] also [21:51:57] night! [21:53:48] .tell indy91, ah yes, when I did a V47 after DOI minus 10m, error needles seem much better [15:31:17] morning [15:34:26] hey Alex [15:34:43] ah interesting [15:35:06] yeah [15:38:25] implementing a bit of backend stuff for the proper RTCC REFSMMAT handling [15:38:54] great [15:39:34] some things for that are only displayed on the on-line monitor [15:39:38] so it gets a few more uses [15:39:56] but there will be two MCC displays for a bunch of alignment things [15:40:00] one for the CSM, one for LM [15:40:08] and I guess they will be filled with buttons for MED inputs [15:40:23] most are quite short MED inputs [15:40:37] the longer ones I'll handle differently [15:41:14] oh and I found a better source for the MPT maneuver codes [15:41:23] it actually has both MPT and maneuvering vehicle [15:41:27] so it gets an extra letter [15:42:24] so if it starts with "CCS" that means the CSM MPT, CSM is maneuvering, with the SPS [15:44:04] ah I see [15:44:18] should have thought of that myself, haha [15:44:22] makes sense to have both [15:48:28] had a good landing last night with Intrepid right by Surveyor 3 [15:48:34] yeah I saw your pictures [15:49:05] hope you dont mind I showcased a bit of the RTCC MFD :D [15:50:51] haha yeah, no problem [15:55:54] I have the feeling the new RTCC MFD manual will be a short novel [16:00:26] just tell people to read the real RTCC documentation haha [16:09:04] I'll definitely copy & paste a lot of real RTCC documentation [16:16:08] time to start the 2nd Apollo 13 FIDO tape [16:16:15] goes all the way to MCC-2 [16:16:28] at my rate I'll be there in 2-3 weeks :D [16:16:51] night shift right now, the FIDO seems a bit bored [17:05:38] for the CSM Prelaunch Plane Change, SEQ - PPC [17:05:52] I hit CLC in the DPT but nothing displays [17:06:09] is there something to configure in init? [17:07:40] oh the TH1 TH2 maybe [17:07:59] I have them all set to TIG, but maybe TH2 must be set to desired alignment time [17:08:44] yeah, I think that's what it is [17:09:10] although [17:09:18] well [17:09:21] it would be TH4 [17:09:33] but if you change TH2 it will also change TH3 and TH4 to the same time [17:09:39] right [17:09:58] does the LDPP just use the RLS stored in the RTCCMFD? [17:10:02] that's one case where the MED input has some useful logic [17:10:16] because it als automatically sets TH2-4 to a later time, if necessary [17:10:41] yes [17:11:29] ok so I can update it with Intrepid's actual location and it will on the Landing Site Update page [17:11:33] hmm [17:11:39] still wont calculate [17:12:17] TH1 set to 119:00:00 and TH2 to 4 set to 142:01:18 [17:12:29] hmm [17:12:35] I'd have to debug that [17:13:46] ok it worked after a few tries [17:14:30] only thing I did was cycle through VEH LEM and back to CSM on the main LDPP page [17:14:43] then back to DPT and it worked [17:15:20] very weird [17:15:43] what was your vector time? [17:15:47] solution looks good [17:16:00] same as TIG, 119:00:00 [17:16:46] no azimuth input? [17:17:22] optimized [17:17:30] oh should I put something? [17:17:36] nah, should work without [17:17:42] gives best DV with optimized [17:21:04] yeah [17:21:29] DV is about ~10 fps from flightplan value and within 1 minute [17:21:50] that sounds pretty good [17:22:07] yep [17:22:35] part of the logic for this maneuver is in a document that I got from Ron in early December [17:22:41] so I'll revisit the LDPP soon [17:22:52] then also with the descent maneuver calculation option [17:26:03] I must say I've gotten lazy with not doing maneuver pads on this mission, the DMT display is a maneuver pad in itself! [17:26:38] well yeah, that's where most values for the PAD came from [17:27:07] and as I probably said before, they took this one step further with Shuttle where the DMT contained the full format for a Maneuver PAD [17:27:38] right [17:27:53] and with the REFSMMAT stuff I have started getting into the G-code MEDs [17:28:06] that's also where e.g. the sextant star check is [17:28:21] probably on the CSM Guidance Optics Support Table [17:29:09] nice