[15:18:14] NASSP Logging has been started by thewonderidiot [15:18:46] hey Mike [15:18:47] crew charts start at 32 [15:18:58] yeah, I already had found them, haha [15:19:00] good stuff [15:19:03] haha [15:19:06] not so good was my estimate of the number of pages [15:19:19] rescue book and crew charts are both twice the size of Apollo 12 [15:19:33] so "not more than 100 pages together" was a pretty bad estimate, lol [15:19:37] yeah :P [15:19:46] what about the SPS burn schedule from the Apollo 7 flight plan? [15:20:30] hm, must have been a phone pic [15:20:51] where was that... [15:20:53] your link is only to one picture, but I still had the old link [15:24:56] https://photos.app.goo.gl/dxxbpqqun2MPGKA27 [15:25:53] great, thanks! [15:27:05] there was a weight update, so burntimes are different in the SPS burn schedule [15:27:29] SPS-3 is way different, that is good to know [15:27:51] different plane change [15:28:12] SPS-5 as well [15:30:29] and the rest as well [15:30:37] these numbers do help me, great [15:30:57] when I will fly Apollo 7 again and fine tune the burn calculations [15:31:07] :D [15:33:22] numbers agree with the SCOT, but the SCOT didn't have all the same numbers [15:36:11] I like how they forgot to update a number in the final version [15:36:16] :P [15:36:23] sounds about right [15:36:40] Preliminary SPS-6: X +16.9 Y +0.0 Z +0.0 total 16.9 [15:36:50] Final SPS-6: X -17.0 Y +0.0 Z +0.0 total 16.9 [15:36:55] haha [15:36:59] close enough [15:37:03] nailed it [15:37:29] one other fun piece of trivia: even though Luminary 163 was released for manufacture, as the Apollo 14 program, they apparently canceled is manufacturing before it even began [15:37:45] got a bunch of more updates then [15:37:46] there's only enough rope module dash numbers for 173 to have been made [15:38:35] oh, and I don't really know what "No takeover when Abort from P60's" means [15:38:50] not even sure about abort [15:38:55] could that be a computer term? [15:39:00] or definitely descent abort [15:39:02] haha, damn [15:39:08] I'm not sure [15:39:18] takeover could be AGS taking over from the PGNS [15:39:20] but whatever takeover is, I'm guessing it can be delayed by 163 seconds [15:39:22] or astronaut manually [15:39:39] AGS wouldn't be affected by the AGC timers though [15:39:44] what exactly would be delayed [15:39:53] could the DAP be affected? [15:40:07] "activity" [15:40:09] "takeover" [15:40:15] I dunno, I gave you everything I have :P [15:40:21] and when would this occur [15:40:29] with a restart or anything else going on? [15:40:44] or simply, "normal" abort from P60s [15:40:47] it'd have to be an ENEMA occurring during P60 [15:40:54] what's an ENEMA [15:40:57] I don't know if that happens during normal aborts or not [15:41:06] it's a way to cause a fast POO :P [15:41:16] flushes out the system [15:41:25] well, P00 is not goo for descent [15:41:28] it's a software restart [15:41:29] good* [15:41:30] yeah [15:41:34] ok, so restart [15:41:44] so restart at a bad time delays something for 163 seconds [15:42:04] it could be that a regular abort causes an ENEMA [15:42:13] and the restart groups get you onto the abort programs [15:42:13] oh, ok [15:42:34] but I haven't found that code path yet [15:42:48] if this was the Revision 1 for Luminary 099 [15:43:00] do you know how to create Luminary Revision 0 then? [15:43:07] well, no revision [15:43:23] could we test what happens? [15:43:24] we already have! [15:44:32] didn't we just change some constants? [15:45:16] oh, that was for a possible revision 2 [15:45:18] not 0 [15:46:10] yeah, the rev 2 that never existed :P [15:46:30] 99 to 99R1 was the label STARTSB1 moving up a few lines in FRESH START AND RESTART [15:46:38] ah, I remember that now [15:47:11] if we needed more convincing, I found the original anomaly report for those constants, and the resolution was to wait until 1B to fix them [15:47:21] still have the binary for LMY99R0 [15:47:34] August last year, of course I don't remember! [15:47:40] lol [15:47:53] oh awesome [15:48:01] I really want to read that anomaly report [15:48:16] didn't scan it, sorry! [15:48:19] noooo [15:48:33] too much to scan [15:48:36] yeah [15:48:43] next time [15:48:50] those Apollo 11 constants make my life more difficult, haha [15:48:59] hehehe [15:49:00] usually the constants stay the same for the whole year [15:49:05] work time, be back in a bit [15:49:15] cya later [16:44:10] back! [16:45:57] so I was thinking [16:46:14] the three timers that get reset are TIME3, TIME4, and TIME5 [16:46:33] TIME3 is under control of the waitlist, and all of the waitlist's tasks are flushed, so it seems unlikely that TIME3 would delay anything [16:46:50] TIME4 is controlled by the T4RUPT routine and is regularly scheduled for every 20-120ms [16:47:00] so I'm thinking the culprit must be TIME5, somehow [16:51:12] however... [16:51:13] https://www.ibiblio.org/apollo/listings/Luminary099/P70-P71.agc.html#5356455849544144 [16:51:23] just above there, TIME5 is reset just before the ENEMA [16:52:56] Hey. What's up? [16:53:42] Something going on with the enema's and interrupts? [16:53:56] we figured out which anomaly was fixed in Luminary 99 Rev 1 [16:54:21] and have two high level descriptions of the problem, but nothing detailed, and I couldn't find a copy of the anomaly report [16:54:37] so we're trying to figure out what exactly the problem is, and reproduce it [16:56:06] Ooh I like reproducing problems [16:56:39] so we know what changed between 99 and 99R1 [16:56:48] the anomaly fixed was LNY-77 [16:56:53] and we have two descriptions of that [16:57:01] I remember reading something about a takeover in the last few days, but I just can't remember where I read it [16:57:11] "Software restart will not now cause up to 163 sec activity delay" [16:57:11] and [16:57:24] "No takeover when Abort from P60's" [16:58:03] if it would cause the DAP to not work for 163 seconds then that would be the take over [16:58:13] astronauts has to fly the abort manually [16:58:17] yeah, that's sounding like the most likely thing here [16:58:25] and definitely severe enough to remake the rope [16:58:29] just a theory, not really one I am convinced of yet, haha [16:59:01] I don't know if I randomly read through your photos or something in Luminary memos [16:59:17] but somewhere was talk of something like this [16:59:59] oh [17:00:12] ForBurkey180927 [17:00:19] those new papers [17:00:27] where were those even from? [17:00:35] Don scanned them and sent them [17:00:42] ah, Don scanned them, ok [17:00:51] those were the last things in his personal collection, apparently (as opposed to Silver's and Larson's) [17:01:01] I think I read something there then [17:01:06] I'll try to find it [17:02:32] might have been totally unrelated, but still [17:03:28] yeah, worth checking [17:19:15] can't find it [17:19:37] boo [17:39:34] oh wait [17:40:45] want some supporting evidence that we're on the right track? :D [17:41:02] sure [17:41:22] https://github.com/virtualagc/virtualagc/blob/master/Luminary099/P70-P71.agc#L204 [17:41:42] here, in the abort jask, TIME5 is set up just before the ENEMA [17:42:04] https://github.com/virtualagc/virtualagc/blob/master/Luminary116/P70-P71.agc#L179 [17:42:17] that bit of code was removed in 116 [17:42:35] takover could also be P70/P71 taking over control of guidance [17:42:38] takeover* [17:42:42] yeah [17:42:56] but how does a restart work into this [17:43:05] the ENEMA is the restart [17:43:11] like, how would I be able to reproduce this [17:43:20] get into P70? [17:43:30] but the question is [17:43:32] the anomaly [17:43:59] why is this not sufficient. what can happen to TIME5 between here and STARTSB1, that requires STARTSB1 to reset TIME5 [17:45:19] something that could set TIME5 to almost zero... [17:45:47] well the DAP uses TIME5, maybe something goes out of sync [17:46:04] out of sync? [17:47:34] the DAP uses multiple timers [17:48:03] one thing I found while looking through the papers was that there could be an accidental 14 millisecond RCS firing [17:48:08] instead of 15 millisecond [17:48:26] and someone from NAR(?) said the RCS could blow up if that happens [17:48:32] lol [17:48:34] this was related to aborts as well [17:48:42] let me try to find this again... [17:48:44] it was quite funny [17:48:45] that would be TIME6 controlled, though, wouldn't it? [17:48:50] there was a comment from Neil in there [17:51:16] I never find anything in these again... [17:51:40] lol [17:55:12] found it, but wrong year, haha [17:55:43] not related anyway [17:56:22] the math checks out though [17:56:25] TIME5 is 10ms [17:56:33] overflows at 163.84 seconds [17:56:50] 10ms per increment [17:57:01] yeah, it's got to be TIME3, TIME4, or TIME5 [17:57:43] really feels like it must be TIME5 [17:57:45] just... why [17:58:03] as I said, maybe the DAP breaks somehow [17:58:09] again: how can I reproduce it? [17:58:20] Do I have to do a restart just before aborting? [17:58:24] I'm guessing TIME5 must overflow [17:58:34] at such a time and in such a way that it doesn't reschedule itself [17:58:49] so that 163 seconds have to pass before it fires again [17:58:50] that would be bad for the DAP indeed [17:59:30] maybe the answer will lie in looking how T5RUPT is gotten into, and where the rescheduling happens, and if there is ever any path in which it won't reschedule itself [17:59:54] oh wait, is ENEMA just part of the abort selection? [18:00:08] ENEMA is a generic software restart [18:00:31] so how do I reproduce this? [18:00:33] what this code in P70-71 does is set up the phase tables such that the restart logic will kick off the abort programs [18:00:40] selecting abort and...? [18:00:43] you keep asking that, but we don't know what the problem is lol [18:00:52] this code, and ENEMA, will be hit with every single abort you do [18:00:58] oh [18:01:00] if you get into P70, you went through ENEMA [18:01:05] that is the misunderstanding then [18:01:10] it internall does a restart [18:01:40] yeah, presumably in an effort to make sure that nothing that was running during the descent is active for the ascent [18:01:45] better to do a restart and flush out the system [18:01:46] I was thinking there is a chance of this anomaly to happen when there is a restart (due to power loss or other such things) and aborting [18:01:50] oh no [18:01:59] that's why I was asking [18:02:05] gotcha [18:02:09] like in which order should this happen, abort first, then restart etc. [18:02:18] nah, just a regular old abort [18:02:45] so, I guess it's unlikely that the issue happens every time, right? [18:03:06] yeah [18:03:22] might be related to CPU load, or need an unfortunate confluence of events, or something like that [18:03:24] Can I use LUM99R0 safely with the state of the erasable memory of revision 1? [18:03:36] oh yes, absolutely [18:03:56] the difference between the two only takes effect while ENEMA is running [18:04:11] so if I do N attempts of aborts I might hit the anomaly, haha [18:04:30] hahaha yes, that is a possibility :D [18:05:27] so the DAP probably is broken for 163 seconds then [18:05:35] rest of the guidance might be ok though [18:05:46] so you could maybe fly the error needles manually, until the DAP works again [18:06:12] any idea when the anomaly was discovered? [18:16:18] late May or early June [18:16:41] maybe even mid June? [18:17:17] all I know is that 99R1 was released for manufacturing in "June" :P [18:19:13] it probably depends what value TIME5 has at the time of abort [18:19:32] Larson said up to 163 seconds [18:20:03] so something happens when it is 0 again [18:20:30] or -0 or whatever [18:23:55] man there is too much to do with all of this new stuff lol [18:23:58] I really want to dig into this [18:24:07] indeed [18:24:09] but I also need to complete the scans [18:24:17] and I also want to finish my rope module spreadsheet [18:24:18] lol [18:24:33] you mean make PDFs out of the scanned images? [18:24:53] that, stitch together foldouts, remove duplicate pages, etc. [18:25:06] just create final products out of all of these things, for posting online [18:25:31] yeah [18:25:45] there isn't any hurry for that I would say [18:25:46] https://docs.google.com/spreadsheets/d/1crLHv_OM_fpFm443n0uRj4eyAGjp_2uK5R-XrRDOwVo/edit?usp=sharing [18:25:53] read this as: I already got everything I want [18:25:58] haha [18:26:26] I want to finish filling that out so we can easily say what any given rope module contains [18:26:51] along those lines: if you ever find any pictures of any rope modules where the serial number and part number are visible, please pass it a long so I can fill it in [18:27:48] or any references to serial numbers in documentation or anything like that [18:27:54] interesting that there was a first meeting on manual ascent in June 1969 [18:28:18] maybe triggered by that anomaly, haha [18:28:57] hehehe [18:29:08] well, a meeting specifically about that topic [18:29:19] manual ascent procedures were already planned [18:31:21] right [18:47:50] you know what I think I'm going to do tonight though? [18:47:58] instead of doing any of these things, go to bed a few hours early :P [18:48:01] I am exhausted [18:51:07] sounds reasonable [18:51:09] Ah yes, sleep is so nice [18:51:30] Im a it jet lagged myself [18:51:31] talk about sleep, Alex reappears [18:51:36] a bit* [18:51:38] lol [19:12:27] just working a new nodal target and EMP latitude for the Apollo 16 RTCC constants, using the corrected approach azimuth [19:12:55] pretty similar, just minor tweaks [19:14:33] also make the new post DOI apolune 60NM [19:15:06] ok [19:15:30] that should be done for 13-17 I guess [19:15:50] not necessarily [19:16:12] well, post DOI apolune, probably [19:16:18] I was thinking too far ahead, haha [19:16:26] because, nominal DOI only has a DVX component [19:16:45] and that can only mean that the pre DOI perilune also has to be 60NM [19:16:59] so LOI would be target the standard 60x170 again [19:17:03] targeting* [19:17:24] and the whole rotation of the apsides would only be adjusted with the pericynthion altitude I guess [19:17:48] so 160x70 should be a standard [19:18:21] I have to check if that is for all missions [19:18:37] I remember that DOI might have nominally a DVZ component for a mission [19:18:43] but Apollo 16 is clear [19:19:13] in the SCTO it's: altitude of the DOI maneuver, pre DOI perilune and post DOI apolune are all 58.6NM [19:19:15] What we have in there right now is literally the flight plan ApA/PeA after LOI [19:19:16] SCOT* [19:19:22] yeah [19:19:50] that is also based on targeting some ApA/PeA but the guidance doesn't achieve that 100% [19:20:11] or simulation of the burn for the flight plan [19:20:21] on the LOI Maneuver PAD the apolune is 170.0 [19:20:30] and not the 170.6 or whatever is in the flight plan [19:20:37] so I am quite sure it targets 170 [19:20:47] lower perilune for the weird lunar gravity [19:20:58] but for us that is 60 as well [19:21:41] looks like Apollo 17 would have a non-zero DOI DVZ [19:21:42] So basically we should put in 170x60 post LOI target in the constants, and optimize everything with that [19:21:52] yes, for Apollo 16 [19:22:01] ok [19:22:03] not 17 [19:22:09] but likely all previous missions [19:22:42] three times 58.4NM in the SCOT for Apollo 15 [19:22:56] so that one also has only a DVX for DOI [19:23:08] and so doesn't contribute to the apse line rotation [19:23:19] so we should also use 60x170 for that then [19:24:14] Apollo 14 has a DVZ [19:25:24] not sure about 13 [19:25:34] a small DVZ maybe [19:25:58] so I guess you can use 60x170 for Apollo 15 and 16 and adjust those missions, but not the other ones [19:26:21] or adjust the other ones as well with the 60NM post DOI apolune [19:26:32] but not change it to 60x170, that's what I meant [19:28:34] Ill start with 16 for now [19:28:54] I can also make the DOI altitude 52,500 as the SCOT says [19:30:37] yeah [19:30:49] that probably has other reasons that gravity [19:30:57] flying over terrain or something like that [19:31:15] than* [19:33:16] Can I get an early TLC scenario for Apollo 16 if possible? (Before MCC's) [19:33:54] I already had one obviously, but Id like to compare the results [19:34:30] sure [19:36:42] have one at 23h GET [19:36:49] MCC-2 would be at 30h [19:38:23] https://www.dropbox.com/s/hob2mf2uxy5qva8/Apollo%2016%20-%20At%2023h.scn?dl=0 [19:41:50] thanks [19:42:56] so I got it to 60.3 x 8.6 post DOI [19:43:19] With the PC altitude of 71.26 NM and 170x60 LOI target [19:43:36] good enough [19:43:56] Now, if I set the PC altitude to 76 NM then its a perfect 60x8.6 [19:44:12] But 76 is way above what the SCOT says it should be so yeah [19:44:44] yeah, sounds high [19:45:53] Ill just stick with 71.26 NM. SCOT says 71.4 above LLS, so 71.26 is above mean radius I think [19:46:47] yeah [19:47:20] should roughly give the right rotation of the apse line anyway, small apolune differences doesn't change it much [19:47:33] the main issue in my case was probably the LOI perilune [19:47:50] and my slight off nominal trajectory [19:48:10] which might have been fixed with adjusting the LOI perilune and accepting a DOI DVZ [19:48:30] but no planning tool for that yet when it's MCC-3 or 4 [20:09:05] PR sent [20:12:58] merged [20:13:04] good night! [11:57:20] hey [12:00:37] hey Alex [12:19:19] whats up? [12:20:33] was thinking about adding some MCC display, but couldn't decide, haha, so I am working on padloads [12:22:40] I wanted to do the relative motion display, but as I had to find out, it doesn't even have a phase angle display [12:22:43] haha padloads are always fun [12:23:10] all the descent targets Apollo 14 to 16 will change [12:23:23] nice [12:23:35] I guess we already had the real Apollo 13 and 17 ones [12:24:38] yeah, 17 looks the same [12:24:44] as in the digital sim [12:24:52] but I'll check 13 and 17 anyway [12:25:09] Will you use the real padloads for the AGC Correction Vectors (504LM and such) [12:26:00] no [12:26:06] right, I thought so [12:26:23] Orbiter Moon doesn't do the libration motion I think [12:27:40] This is great we have all the padloads now [12:28:24] Apollo 11 and later we have [12:30:43] ah, right [12:31:29] still need cofirmation about the scaling and value for a Colossus 237/249 DAP setting [12:33:38] The abort constants can be update for most missions too I guess [12:33:44] updated* [12:34:17] 12, 14-16 anyway [12:35:22] yeah, the new nominal values should be pretty good [12:36:44] oh wow [12:36:59] I had overlooked that, but the Apollo 11 padload got an abort constants update [12:37:17] I wonder if that is now closer to what the RTCC MFD is calculating [12:38:04] before I thought only the Apollo 11 TLAND was updated [12:38:10] have to check that more carefully [12:38:30] but one mission at a time, first I finish Apollo 14 [12:38:41] so many padload updates, haha [12:52:10] Now I have a good excuse to re-fly all the missions with the updated padloads lol [13:03:43] Apollo 14 certainly got a lot of updates just now [13:03:56] had a lot of Apollo 17 numbers until now [13:04:05] because we are using Luminary 1E for it [13:04:25] but it's not even the heavier J-Mission LM, so e.g. the ignition algorithm constants are way different [13:04:33] and Apollo 17 also had the fairly steep descent [13:10:06] Apollo 15 LM padload is hard to read, hopefully I can extract everything [13:10:32] it helps that I get octal, imperial engineering value and metric engineering value, so I can always comparw [13:12:11] And are these padloads confirmed to be the exact ones loaded on the real mission? [13:12:50] well, the only real confirmation would be a E-Memory dump from a flight [13:13:12] but yes, I think it's quite likely that these are the final ones [13:13:19] dates close to the launch day [13:13:43] and it does say final in some documents [13:14:03] "Final E-Load Apollo 15 (Mission J1) Prelaunch Erasable Load (LUMINARY 210)" is what I am currently reading [13:14:16] final is not a word I trust much though [13:14:32] I've seen "revision 1 to final..." too often :D [13:15:01] here is an weird fact [13:15:19] the Apollo 15 padload is identical to the Apollo 17, but in the Z-Axis only [13:15:24] the descent targets [13:15:30] so downrange targets are the same [13:18:41] I guess they are close enough anyway ;) [13:18:45] interesting [13:19:23] I guess you can imagine that as following a similar basic trajectory, but different in altitude [13:19:56] makes sense [13:20:06] also, Id be interested to know what RLS is in the padloads, are they identical to what we've already had? [13:21:00] some are slightly different [13:21:03] in any event, we probably should update the RLSs for all the missions with the actual one [13:21:21] yeah, I agree [13:21:33] or the ones from the actual padload I mean [13:21:38] hmm [13:22:00] the actual padload would have a decent altitude error for most missions [13:22:35] and I think we shouldn't expect people to do perfect P22s to update that [13:23:08] so maybe it's better after all to use the lat/long as in the padload, but with the radius as in Orbiter [13:23:33] yeah maybe [13:23:47] But why would the padloads have such an error in the 1st place? [13:24:08] because you can't determine that very well from Earth [13:24:28] and all else they had were Lunar Orbiter photos [13:24:44] the terrain models also had fairly significant erros [13:24:49] errors* [13:25:04] with P22 you are looking at the landing site from 5 fairly different directions [13:25:05] right [13:25:10] which you can't really do from Earth [13:25:30] so with observations from Earth you can get very accurate lat and long [13:25:34] but not in radius [13:25:43] Also, would the RLS they had in the padloads be the same as the RLS they used in the RTCC? [13:25:52] I would think yes [13:26:07] the initial one, sure [13:26:41] So should we also make the RTCC RLS have the same radius as orbiter? [13:27:03] I think that would be unrealistic though [13:27:33] hmm [13:27:45] Orbiter and the real Moon agree very closely at least [13:27:51] I think it's using LRO data [13:28:18] RTCC and padload should be consistent in any case [13:29:11] I will say this: I find the LR is pretty good at updating the altitude during a lunar landing. I think that an imperfect P22 would not be that bad [13:29:46] it's not just the P22 [13:30:04] on telemetry they also can look at the W-Matrix data directly [13:30:13] so they can determine how good the P22 was [13:30:17] and then update the RLS or not [13:30:26] we can't really do that yet [13:30:43] right [13:31:26] wrong radius also make the SV worse [13:31:47] after all the LR updates the SV, not the RLS [13:32:03] true [13:32:10] if you abort from the surface, then your insertion altitude will be off [13:32:52] So maybe like you say, make the RLS like the padload in lat/long, and with Orbiter height [13:32:53] and in reality they did have a better RLS at that point for all missions [13:33:10] and then make the RTCC RLSs identical to that [13:35:56] I guess that will also make the PDI altitude more accurate [13:37:53] and any pre P22 targeting less accurate, haha [13:38:00] there really is no right or wrong [13:44:28] in the case of Apollo 15, our RLS is almost identical to the one from the padload document [13:44:36] just rounding of latitude and longitude I guess [13:47:48] but will be updated during the mission by as much as 0.5NM [13:50:56] hmm [13:51:46] the Apollo 15 descent target were very slightly different in their engineering values, but it seems like the octals are identical to what we used before [14:02:06] looks like Apollo 15 to 17 all have the same descent targets [14:02:10] which we have already been using [15:43:26] Can the Space Digitals page be used in LEO? [15:46:22] hmm does not look like it [15:58:40] no, that's not really what it is for [15:58:57] the other display is for low Earth and lunar orbit [15:59:02] FIDO Orbit Digitals [15:59:06] good morning [15:59:10] hey [16:01:22] the real Space Digitals display would interact with the Mission Planning Table [16:02:02] so if you had a planned TLI in there, then the Space Digitals display would show that trajectory [16:04:46] ah ok I see [16:10:54] back in a bit [16:19:59] morning! [16:20:25] indy91, have you ever heard of Sundisk 267? [16:20:54] hey Mike [16:21:00] not that specific version, no [16:21:05] hmm [16:21:24] flown was Sundisk 282 apparently [16:21:34] so late 1967-early 1968 is a bit blurry regarding rope module releases and part numbers [16:22:41] I can look through my Apollo 7 documents [16:22:54] was Sundisk 267 released for manufacturing? [16:23:20] according to that MIT Status Report I got from UHCL, yes [16:23:30] however, it's not listed as a released rope in R-700 [16:23:38] so I can't tell if it was actually made or not [16:24:09] but, the list of ropes released in R-700 isn't enough to fill up all of the available dash numbers I have in my spreadsheet [16:24:23] so there's either an earlier program release, or a revision, that I don't know about [16:24:40] so I'm thinking that maybe they built Sundisk 267 [16:30:42] I have nothing on 267 [16:37:47] yeah me neither [16:39:06] the 24th SCB meeting had a funny Sundisk reference [16:39:24] title [16:39:25] Sundisk PCR's Approved at SCB!!! [16:39:40] There was a flurry of excitement among SCB members when a SUNDISK PCR was introduced. [16:39:54] The excitement subsided when the members found out that only the GSOP was being changed. [16:40:27] September 17, 1968. Pretty sure the last actual Sundisk changes were much earlier. [16:52:16] hahaha [16:52:18] nice [16:52:31] yeah 282 was in February [16:52:37] 267 would have been November 67 [17:41:26] so I got through processing most of the scans, apart from ones that need foldouts stitched, last night [17:41:41] so tonight will start foldout stitching, and then I need to figure out what to do with the camera pictures [17:42:07] also the more I read Luminary 99 source, the more I don't understand how T5 can be at fault [17:42:40] at least if the ENEMA path in P70-P71 is the abort/software restart in question [17:43:39] STARTSB1 attaches the DAP Idler to T5RUPT, and the code leading up to the ENEMA sets TIME5 to the same number that 99R1's STARTSB1 does [17:43:56] I don't see how the change could affect TIME5 behavior at all, if coming from that ENEMA [17:44:10] so either it's a different ENEMA, or it's TIME3 or TIME4 [17:44:23] aren't TIME3 and 4 7.5ms? [17:44:37] what do you mean? [17:45:07] "TIME5 is a 15-bit 1's-complement counter which is incremented every 10 ms. " [17:45:14] oh [17:45:21] so are TIME3 and TIME4 [17:45:22] 7.5ms is just the offset [17:45:26] you might be thinking of their relative phasing [17:45:26] yeah [17:45:36] so yeah, any of those then [17:47:24] T4RUPT at least is also doing stuff for the DAP [17:48:36] yeah [17:48:49] so maaaaybe there's a code path where it doesn't reschedule itself [17:48:52] but that seems unlikely [17:49:39] did Luminary99R1 get an intermediate fix and 102 then the proper one? [17:49:45] or was it all fixed in 99R1 [17:50:13] well, presumably 102 had the TIME5 adjustment in P70-P71 also deleted, in addition to the label move [17:50:43] for 99R1 it was just redundant and probably would have meant a second module to remanufacture if they removed it [13:11:56] hey [13:19:13] hey Niklas [13:20:52] not that im getting bored of NASSP, but I just spent the last 40 minutes watching a video on how to start a steam locomotive ;) [13:21:06] pretty cool actually: https://www.youtube.com/watch?v=xx9Q8PphAVo [13:21:41] I've seen that one. Very cool. [13:22:25] yeah, looks great [13:23:00] as a kid I watched a VHS we had many times, about refurbishing an old steam locomotive [13:23:10] I wonder what the latest train sim these days [13:23:12] nice [13:23:45] my dad bought us MS Train Simulator when it was just released [13:24:06] in typical fashion for him he bought as a gift what he really actually wanted for himself [13:24:29] MSTS is still one of the best train sims in my book. [13:24:45] haven't played any others I think, haha [13:24:54] haha, I remember MS train sim [13:25:17] I could never keep to the schedule for the passenger trains [13:25:36] so I mostly did the US freight train route [13:25:37] Wasn't it made by the same dev's that made MS's flight sim or something [13:25:51] I never managed to stop at the right place in the stations. I always overran or stopped way early. [13:26:04] AlexB_88: I think it was. [13:26:22] there were also lots of German routes to buy, I had one or two [13:26:36] fun to drive through train stations I have been to many times [13:26:48] I had a bunch of dutch sceneries and trains. [13:29:01] Alex, we both especially have done most of what is possible with lunar missions [13:29:16] there isn't that much exciting new things to explore I guess [13:29:36] alternative landing sites and missions [13:29:44] and hopefully eventually Skylab and ASTP [13:31:01] I'm done with most of the new padloads we got [13:31:05] Venus flyby :) [13:31:09] now I want to start the mission planning tool [13:31:39] Venus flyby needs just a little bit of work all over, haha [13:32:23] I think most work will go into the AGC if you want it to do guidance. [13:32:40] yeah, solar system compatible scaling [13:33:20] but you also have to shut down all the systems [13:33:30] need O2 and power supply [13:33:44] crew doesn't stop breathing [13:33:51] I got that part covered. I've shutdown and restarted the CM multiple times. [13:35:16] yeah I have dome all missions except 10 now [13:35:20] To be fair. The AGC might be able to do some rudimentary guidance if I'm not mistaken. As long as dV is uplinked you might be able to do burns. It just needs to be prevented calculating the new orbit in P30. [13:36:36] I can still find ways to challenge myself with fun scenarios though, like aborts, failures and delayed launches [13:37:16] I will finish that Apollo 11 July 18th launch eventually, haha [13:37:49] need to check everything again, because I forgot why I didn't release it yet [13:38:25] and of course, the recent padload updates... [13:38:46] but first I want to start the mission plan table [13:39:02] also, did you make Orion's O2 tanks bigger on your Apollo 16 run? [13:39:06] yes [13:39:11] still at 100%, lol [13:39:21] lol, I had forgotten on 15 [13:39:41] guess you have to scrub one or two EVAs then... [13:39:44] I did it with the CSM but not the LM [13:40:01] yeah [13:40:08] try an any time liftoff at the time you realize you don't have enough :D [13:40:30] and then we have to figure out why rendezvous procedure applies to that [13:40:34] which* [13:41:21] also, you probably would want the Apollo 15 CSM Rescue Book from UHCL for that [13:41:36] LM doesn't have enough DV for any off nominal rendezvous [13:41:37] yeah that would have been my obvious next step at that point... But nope I ended up finding a spare tank sitting in a crater nearby [13:41:44] convenient [13:41:58] somebody as NASA was thinking ahead [13:42:01] at* [13:42:50] Ill have to request it soon [13:43:30] Which surface checklist will you be using? I ran out of power using the Apollo 14 SC [13:44:45] You're probably using the Apollo 15 one obviously. Id like to know how it works out, if you end up with enough power. [13:44:59] Apollo 16 one* [13:46:04] sure [13:46:11] I am still considering going back to before MCC-4 [13:46:20] don't like that the apolune will be 57NM instead of 60NM [13:46:41] haha sorry again about that [13:46:53] oh, it's also caused by me not doing MCC-4 [13:47:06] and not being able to plan around that properly [13:47:18] that's also why I want to implement the Mission Plan Table now [13:48:14] what I probably have to do is adjust the LOI perilune [13:48:45] and the other reason for the mission plan table is that the RTCC MFD can do the same things as the MCC [13:48:53] like calculating the TLI+90 and TLI+4 abort PADs [13:49:13] planning the Apollo 9 rendezvous is also not really possible with the RTCC MFD [13:49:16] not properly at least [13:49:44] and I do want the RTCC MFD to be able to calculate everything for a mission as well as the MCC [13:50:56] I've been thinking for a long while how to best implement it. And reading every RTCC document about it I can find [13:51:06] I like this idea [13:51:20] let's say you are in Earth orbit [13:51:26] You can essentially fly the whole mission theoretically from the MFD lol [13:51:31] you go to the mission plan page and active the planning mode [13:51:37] sounds boring :D [13:51:51] then you simulate TLI. Not sure if I leave that on the TLI page or not [13:52:17] that will put the TLI maneuver (state vectors at TIG and cutoff) in the mission plan table [13:52:37] and every compatible calculation page will then use the trajectory from the mission plan table [13:52:51] so next you would calculate the two direct return aborts [13:53:07] calculate Maneuver PADs for them and delete them again, because you don't actually want to perform those [13:53:23] after TLI you would also delete the TLI maneuver [13:53:47] and the midcourse correction planning can start [13:53:52] then* [13:54:03] makes sense [13:54:18] TLI would be transferred directly as an impulsive maneuver [13:54:39] finite, not impulsive [13:55:12] but most processors would deliver an impulsive maneuver, which the mission planning tool can convert into a finite burntime maneuver [13:55:30] then I can also add more options for the engine choice [13:55:39] SPS, RCS with 2 or 4 jets [13:55:41] that kind of stuff [13:56:29] in reality you could also input a manual maneuver there [13:56:36] so not from any calculation processor [13:56:55] and I guess the MCC displays can pull from the maneuver table if you want [13:57:07] yeah, those would all be connected [13:57:21] on the Space Digitals display the other GET inputs would also be useful then [13:58:01] there are some features of the real thing I don't fully understand yet or which we might not need [13:58:07] you could freeze a maneuver for example [13:58:22] so nothing about it could be changed anymore, because you are commited to executing it that way [13:59:15] and I am not sure if I understand it correctly, but some maneuvers were even iterable [13:59:30] so (maybe) it would store the input parameters you gave it [13:59:33] for e.g. MCC-1 [13:59:41] but now you change something about the previous maneuver, TLI [13:59:49] then the trajectory wouldn't be right anymore [14:00:17] but it would take the input parameters you used originally for MCC-1 and recalculate that maneuver automatically with the new post TLI trajectory [14:00:27] but I have differing sources on that [14:00:39] and not many processors were compatible with that I believe [14:01:20] I guess it would help if you are manually tweaking targeting parameters multiple times and would have to delete the later maneuver a bunch of times [14:02:21] ah right that would be logical [14:03:15] but I will definitely implement that any time soon [14:03:30] not [14:03:33] not any time soon, lol [14:05:56] yeah for sure we dont need all the bells and whistles right now [14:06:31] first I want to make TLI compatible and then be able to tweak my Apollo 16 LOI and DOI without doing a MCC-4 to get a good orbit [14:11:29] so like calculate MCC-2 so that it works without further MCC's [14:11:59] oh I see what you mean [14:12:53] just so that if you get to MCC-4 and your wondering if or not you should burn, then the 2nd option is to fix any dispersions by building the corrections in LOI and DOI itself [14:15:25] yep [14:15:30] which I currently can't do [14:15:41] TLMCC option 4 display LOI and DOI parameters [14:16:03] but not option 1 and also not the scenario without MCC-4 at all [14:16:53] there is an interesting Apollo 15 document about that [14:16:57] they did burn MCC-4 [14:18:42] PDF page 11 [14:19:06] the things they considered for MCC-4 were DOI DVZ component, rev 2 crossing and PDI time [14:20:54] I guess they would really have made many passes through the mission planning table by trying different combinations, trial and error until they were happy [14:21:11] And then decided if or not they would burn MCC-4 [14:22:39] something like that, yeah [14:22:53] maybe they also developed some RTCC displays that help with that directly [14:23:22] which I don't have any information about, the latest state of all the displays I know is Apollo 11 [14:25:32] also have no RTCC requirements document for the time when they started doing the early DOI [14:25:46] might just have been included in the full mission simulation though [14:28:50] is the "full mission simulation" part of this maneuver planning table? [14:29:23] no, I meant what the TLMCC processor does [14:29:38] ah right [14:29:48] it has the ability to do a simple simulation of a whole mission, with conic trajectories [14:30:05] that is used as part of the optimization that is done in the options 2-5 [14:30:36] and that optimization might simply include the new DOI and constraints on it [14:30:48] would be in: "RTCC REQUIREMENTS FOR MISSION H-2 [14:30:49] NON-FREE-RETURN MODES OF [14:30:49] THE TRANSLUNAR MIDCOURSE [14:30:50] CORRECTION PROCESSOR" [14:31:11] I said to Mike that I don't want him to fly back home from Boston, haha [14:31:30] and divert him to NARA where he should continue scanning documents for me, like that one .D [14:31:31] :D [14:33:54] yeah lol [14:35:03] or we pay money. But I don't expect any big revelations from those documents [14:35:17] very useful for sure [14:36:28] the magic likely happens with preflight planning, useful displays and manual adjusting [14:49:40] btw I think on Apollo 15 the final DOI orbit was intended to end up with an apolune of 60 NM [14:50:14] instead of the 58.4 initially targeted 58.4 [14:52:57] yes [14:54:41] was that not what we concluded for 15? [14:54:48] I went through all the SCOTs [14:55:17] most of them should be 60NM post DOI apolune, but some missions have a nominal DOI DVZ component and so you can't simply also make the LOI perilune 60NM [14:56:33] right, such as 17 [14:58:03] yeah [14:58:21] but post DOI should be 60NM, yeah [14:59:55] special thing about Apollo 17 was of course the perilune location after DOI [15:00:16] you flew 17 with that targeting, right? [15:00:39] pretty high negative altitude rate at PDI instead of 0 as uusal [15:01:39] and for those missions that target 0 DVZ DOI, we are making our LOI apolunes 60 NM. The real missions made them lower, anticipating that it would go up to 60 NM over time. Since we are making them 60 NM right in the LOI itself, we probably should increase the TLMCC PC altitude by the amount we are correcting our LOI perilune. IE. On Apollo 15 real targeted LOI was 170x58.4. In NASSP we will use 60 NM. Maybe we should then add 60 [15:01:40] minus 58.4 = 1.6 so PC altitude was 66.18 above mean radius, so 66.18+1.6 will be 67.78 PC altitude we would use for the 170x60 LOI [15:02:48] might be roughly right [15:03:11] My initial test with that with TLMCC option 4 seems good [15:03:13] but it all depends on how much a non-60NM pericynthion rotates the orbit [15:03:45] without correcting the PC altitude DOI is 60.2 x 8.2, with the correction its 60.1. Very small difference of course [15:03:58] yeah, I guess the altitude difference is the important thing [15:04:11] if post LOI orbit is higher, pre LOI orbit needs to be higher [15:07:09] So I can add the LOI perilune/DOI apolune correction, and add it to the PC altitudes where applicable [15:08:12] if that leads to the right orbit, sure [15:09:08] it will require to reoptimize the other values to get the right REV 2 crossing etc. but thats not too difficult [15:09:40] yeah, it makes the DOI DVZ closer to 0 [15:10:24] that's certainly good [15:11:11] An other thing I was wondering, our LOI apolune/perilune target in RTCC MFD is above LLS? [15:11:14] it probably won't make DOI DVZ completely 0, because it optimizes the mission from scratch [15:11:21] yes [15:11:38] DOI DVZ would only be 0 in pre mission planning [15:11:41] But our LLS height has known error already [15:11:43] let's see what the real missions had [15:12:12] yeah, that is one of the arguments against changing the landing site radius to the actual [15:13:45] Apollo 14 DOI: -206.3 +0.0 -3.6 [15:13:49] for example, Apollo 15 LS in RTCC MFD: -1.92. Orbiter 2016: -1.04 [15:14:05] oh, that much [15:18:08] I have good data from the actual mission on that [15:18:21] -1.92 was definitely the premission number they had [15:18:46] on LM activation they have the LGC a RLS that was 0.232NM higher than that [15:18:50] not sure what that's based on [15:19:24] then incorporating the P22 they arrived at -1.3255NM [15:19:44] that's what the LGC had during the descent I believe [15:21:27] not sure about the actual though [15:21:32] -1.04 seems really low [15:22:03] uhh [15:22:04] high [15:22:19] lol [15:22:26] a small number :D [15:22:32] I know what you mean ;) [15:23:18] But Im quite sure I compared with some recent online data about the landing site altitudes and the Obiter 2016 terrain is accurate [15:23:36] trying to find the link again [15:25:54] http://www.lroc.asu.edu/featured_sites/ [15:26:44] Apollo 15: -1926 m [15:26:49] -1.039957 NM [15:27:12] So that matches up almost perfect with what Orbiter 2016 says [15:27:26] yeah [15:27:32] well [15:27:33] haha [15:27:38] not a very scientific method [15:27:49] you confirmed the numbers with the same source [15:28:03] Orbiter terrain for the Moon uses LRO data [15:28:11] so of course that agrees with it :D [15:28:35] yeah I guess that is true [15:28:59] the last estimate I found in this Apollo 15 document was more like -1.3NM [15:29:09] -1.3255NM [15:29:24] not sure what all that is based on [15:29:30] more P22 as one source [15:29:57] but LRO should be quite a bit better [15:30:04] I guess in any event maybe we should with the height data from LRO as that is what we have in Orbiter 2016. [15:30:38] we should work* [15:31:41] work with it for what? [15:32:09] if we use a RLS with -1.03NM for LOI targeting, then we will diverge from the flight plan [15:32:19] after all it's almost a NM difference [15:32:57] the ideal scenario really would be to update the RLS in lunar orbit [15:33:24] yeah which is what Ive been doing in my missions so far [15:35:48] right now I am against changing the RLS in padload and RTCC MFD [15:35:55] to the more correct number [15:35:59] probably does more harm than good [15:37:45] ok im fine with that too [15:38:02] It would not be realistic anyway to have it perfect [15:39:07] btw are all the RLS's now updated from the new padloads for 11-17? [15:39:08] only the LGC while using the LR doesn't like this decision [15:39:15] uhh [15:39:18] no [15:39:32] but I believe there are no significant differences left [15:39:58] some missions are completely identical [15:40:10] but the difference looked like a few meters at most [15:40:31] ok [15:40:52] like if the flight plan said e.g. -1.92NM but the padload had -1.915NM or so [15:41:00] rounding differences [15:41:12] pretty similar [15:41:33] I skipped RLS updates when I went through the padloads [15:41:40] wanted to look at them as a block [16:18:48] the Apollo 15 DOI altitude is indeed 50000 ft and not 52500 like Apollo 16 [16:18:52] according to the SCOT [16:19:18] perilune altitude* [16:27:27] yeah, not sure why it's 52,500 on Apollo 16 [16:27:37] I'm sure there is a good reason, haha [16:27:58] yeah [16:28:50] Id be curious about Apollo 17, for the post DOI-2 apolune but we dont have a full SCOT unfortunately [16:30:20] Maybe if we have a post flight trajectory evaluation doc somewhere like the one you posted for 15 [16:34:31] flight plan burn schedul says 60x7.2 [16:34:36] for post DOI-2 [16:34:39] 60.0 [16:35:45] we also have the mission directors briefing for Apollo 17, which has some interesting stuff [16:35:54] in any case, post DOI-2 perilune is 43,000 [16:35:58] not 50,000 [16:36:12] so that probably helps with being at the right altitude for PDI [16:36:20] despite not being at perilune [16:43:49] Ill have some more RTCC MFD constants updates later today, with the adjusted PC altitudes [16:49:17] morning! [16:49:29] hey Mike [16:49:38] what's up? [16:51:22] just tweaking some RTCC mission constants [16:51:38] hey [16:53:30] I finished my rope spreadsheet last night: https://docs.google.com/spreadsheets/d/1crLHv_OM_fpFm443n0uRj4eyAGjp_2uK5R-XrRDOwVo/edit?usp=sharing [16:54:07] still haven't quite placed the exact dash numbers for the various Sunburst revisions -- Lamesh releases really make things blurry there, I think, but i have next to no info about them [16:54:19] I'm starting to think Lamesh was 3 modules instead of 2, which could explain some gaps [16:56:06] what's Lamesh again? [16:58:24] my holy grail [16:58:25] lol [16:58:46] it's the final factory test rope for the AGC, that allegedly had considerably more diagnostic capability than, say, Aurora [16:59:03] even more than Aurora, nice [17:00:07] based on wording in the Raytheon final report, I'm like 95% sure Lamesh actually uses EDRUPT in its circuit testing [17:01:52] there has to be something that ever tested that [17:02:53] I want to find a copy so bad, haha [17:04:32] my estimate is that it would be 76 revisions better [17:04:38] no, it's not [17:04:55] our Aurora 12, by my best estimate, is somewhere between Aurora 85 and Aurora 88 [17:05:04] bad estimate then [17:05:07] lol [17:05:37] the DAP group forked off the main Aurora, at some point, and made 12 revisions on top of that [17:05:44] adding in Sunburst DAP features [17:05:48] and that's what Don ended up with [17:06:09] and for some reason they didn't bother to change the program name [17:20:29] guess the two Auroras never crossed paths again [17:20:42] or else major confusion ensues [17:46:50] indy91, what method did you use to come up with the PTC REFSMMAT time? [17:47:09] the SCOT has the actual PTC REFSMMAT [17:47:22] the REFSMMAT calculation code has a debug string [17:47:44] and then trial and error until the RTCC MFD calculated REFSMMAT looked nearly the same as the one from the SCOT [17:49:57] ah pretty clever [17:52:24] should work for all the other missions using this type of PTC REFSMMAT [18:05:39] indy91, did you see that the Apollo 17 CM padload is for "ARTEMIS 72(REV 1)"? [18:05:47] it has planted a seed of doubt into my mind lol [18:06:05] that's the same seed as we got from the CSM Data Book [18:06:18] I didn't remember that [18:06:29] now I really want to go back and look at the FSRR packet for 17 and see if they talk about that at all [18:07:01] "Final CMC E-Load for Apollo 17" [18:07:18] "CMC Final E-Load Artemis 72 (Rev 1) for Apollo 16" [18:07:40] "Final E-Load Artemis 72 Apollo-15" [18:10:13] all the same thing [18:10:15] I bet... [18:14:21] wait, Apollo 16 says (Rev 1) as well? [18:14:40] yes [18:14:49] oh okay then [18:14:52] seed crushed, lol [18:15:02] I know the part and serial numbers of the 16 ropes [18:15:10] they were not different from 15 [18:15:22] oh, that is good to know [18:15:26] we didn't know that back then [18:15:37] so we gave it a small chance that there was a change from 15 to 16 [18:15:42] based on that rev 1 [18:15:46] yeah [18:15:52] let me double check those dash numbers [18:16:55] yeah okay [18:17:00] so 16 launched April '72 [18:17:13] so these May '72 assignments will have been flight [18:18:09] 16 was CSM-113? [18:20:01] yes [18:20:07] yeah so CSM-112 flew with rope module part numbers -451, -461, -471, -481, -491, and -511 [18:20:23] no sorry that's Luminary 210 [18:20:46] CSM-112 flew with -381, -391, -411, -421, -431, and -441 [18:21:00] CSM-113 flew with -381, -391, -411, -421, -431, -441 [18:21:03] no changes [18:25:33] revision 1 was something that happened pre Apollo 15 then [18:26:31] So for Apollo 14, the current parameters was giving us a post DOI apolune of 57.5. Ive tweaked those a bit to get closer to 60 NM post DOI [18:27:01] Of course DVZ is not 0, as should be. The SCOT says DVZ of 20 fps in reality [18:27:22] yeah [18:27:30] and no Rev 0 was ever constructed [18:27:41] if there is even a difference [18:27:57] as usual, somebody said 72 was the final one [18:28:09] and then a revision was necessary [18:28:21] well [18:28:28] never was something less final than Luminary 131 of course [18:28:37] hahahaha yeah [18:28:46] that module B5 got a real beating after release [18:29:05] Apollo 13 flew with B1-B4 and B6 from Luminary 130 still [18:29:11] and B5 just got revised over and over [18:29:16] but anyways [18:29:22] that happened when there was further development beyond the release [18:29:34] so 99R1 was made because they were already up to 102 [18:29:59] if there hadn't been further development then they just increased the revision, like from Luminary 130 to Luminary 131 [18:30:12] so an Artemis 72 Rev 1 implies the existence of Artemis 73 [18:31:18] for all I know Artemis 73 would just be Skylark 0 [18:31:29] hmm [18:31:36] no, I think they diverged earlier than that [18:32:17] haha yeah, I was just wondering when Skylark branched off [18:33:57] I think it would be fair to say that Colossus 3 and Skylark were developed together [18:34:13] Skylark has most Artemis features relevant to Earth orbit [18:34:16] yeah, based on this memo it's looking like it branched off around Apollo 14-ish [18:34:17] MINKEY for example [18:34:46] i.e. potentially even from high Comanche revisions rather than low Artemis revisions [18:35:09] "MIT was given an action item to come up with a name for the SKYLAB Assembly. This is to be reported on at the next SCB." haha [18:35:17] oh! nice [18:35:18] haha [18:35:39] oh, and also fun [18:35:40] PCR SLOOl AAP Colossus Downlink Deletions [18:35:41] Status: Disapproved [18:35:51] first Skylab PCR has disapproved :D [18:35:55] was* [18:35:57] hehehe [18:36:01] I wonder if the second one was too [18:36:09] and that's why our first PCR from Margaret is SL003 [18:37:26] 10 July 1970 SCB Meeting has the first Skylab items [18:37:31] but it seems very preliminary [18:37:39] maybe before any coding was really done [18:38:30] and even in the following one it doesn't really say approved, but "Approved for a detail evaluation" [18:38:31] hmmmm [18:38:36] right [18:39:12] SCB41 properly approves Skylark features [18:40:28] and that was when Luminary 1D and Colossus 2E were nearing completion [18:41:08] so yeah, possibly from late Comanche [18:44:44] there were still GSOP changes approved for its AGC versions 2 weeks before Apollo 14 launched [11:50:21] good morning [11:51:12] might be getting fs2crew reboot edition for pmdg 737 ngx this morning [11:57:24] hey [11:57:31] never had any fs2crew [11:58:22] i would consider printing those apollo 12 checklists and fly 12 but my printer is out of ink right now [12:00:09] and as i mentioned before i could probably make it into lunar orbit but the rest of the mission i am not so sure about [12:00:23] well that's a start :D [12:00:38] tlc is very simple [12:01:40] just a bit of barbecue mode [13:44:44] looking forward to sop 3 the pilot in command (me) does alot of the work [15:58:33] morning! [16:21:40] hey Mike [17:03:03] .tell indy91 think I might have found a way to determine precise k factor f [17:03:30] I am around [17:04:31] Hey, so pretty much the same procedure as cmc lgc clock synch [17:06:39] as cmc lgc clock synch? [17:06:57] In other words 99:00:00.38 would be a k factor of 90:00:00.38 [17:07:28] yes [17:07:39] and how does mission control determine that number? [17:08:41] By v06n65 and pressing enter at the same time as the 377 load using the v47 button on the mfd [17:09:23] that is a valid procedure as per AOH [17:09:33] just not the one actually used on the actual missions [17:10:03] oh wait, I think I misunderstood [17:10:30] I mean it’s just a cheaty way for us to determine the k factor [17:11:32] so you would calculate: N65 minus the 377 input [17:12:06] yeah, that probably works [17:12:28] would be cheaty of course, but at least the AGS would be precise [17:12:40] but I still want to figure out how mission control actually did it [17:13:20] Ya as long as you are within a second you can load the decimals into the pad loaded kfactor [17:14:26] I guess this way is similar to the alternative procedure in the AOH, hence my confusing at first [17:14:55] there you use 377+0 and the enter press on the DSKY, while V47 displays the K-factor, sets a new K-Factor [17:15:33] confusion* [17:16:01] this basically does the same thing, just with a non-zero AGS time input and some math still to do [17:16:36] Ya v32 I think resets the kfactor to the current agc time [17:17:05] right [17:17:21] that's pretty much what I added the V47 button for [17:17:29] to be able to do that procedure [17:18:28] The activition procedure calls for v16n65 then 377 load I just thought maybe they left out the simultaneous enter part and mission control would read it that way [17:18:55] it calls for 16 65? [17:19:25] oh wow [17:19:26] Ya I’m pretty sure I’ll double check now [17:19:28] you are right [17:19:42] I wonder [17:20:03] I assumed that is just for the astronaut [17:20:04] Yup it does [17:20:17] but I wonder if that puts precise AGS timing on telemetry or so [17:20:22] AGC* [17:20:50] Well they could read whatever was up on the DSKY couldn’t they? [17:21:08] yeah [17:21:25] but how often does that update on the ground display [17:21:36] probably not more often than the DSKY itself, I would think [17:22:17] They’d only need to see the first update I would think? Which would be on the enter [17:23:33] first update where? [17:24:26] The decimal seconds always stay the same I think anyways so as long as you are within a second [17:24:42] Update On the ground display I mean [17:25:22] just found this in the AOH "MSFN obtains difference via ground checks and AGS telemetry" [17:25:45] I guess then they see when the ENTR on the DEDA is done [17:26:19] and what they need to do is figure out the LGC time of that event [17:29:24] So they read the DSKY? Or some other way [17:29:39] that's what I haven't figured out yet [17:29:50] also, this would have to be done automatically to be precise [17:30:06] and drop of telemetry for a moment at the wrong time and it wouldn't work [17:30:34] so I wondered if they actually did this differently [17:30:52] the AGS does save a precise time of the ENTR press actually and it's on telemetry [17:31:14] but there is no precise "current time" in the AGS [17:31:25] it only gets updated as often as you see on the DEDA, every 6 seconds [17:32:41] But the start time is exactly 0 right? I mean 0-6 seconds [17:35:13] the AGS has a clock time as soon as you turn it on [17:35:43] and when you enter a new AGS time the value it saves as the precise time is derived from the time it had before, somehow [17:35:56] I don't fully understand how it all works yet [17:36:20] Far less user friendly [17:38:30] I guess the procedure you came up with is the closest to the real thing, while also being precise [19:11:28] done stitching, joining, and sorting scans [19:11:33] just need to figure out what to do with the pictures [16:58:13] good evening [17:10:46] hey [17:31:31] no need to fly missions in NASSP anymore, you can do it all in the RTCC MFD now! [07:16:02] .tell indy91 does that make the RTCC MFD... an apollo simulator simulator? [11:27:29] @indy91 [11:27:34] good morning [11:27:38] hey [11:27:45] are you seeing "FIrst Man" in a few days? [11:27:54] not sure yet [11:27:58] i will be [11:27:59] have no plans to right now at least [11:28:06] maybe it will inspire me to fly another 11 mission [11:29:04] I want to launch Apollo 7 soon [11:29:20] 3 days left to the 50th anniversary of it! [11:29:24] yes [11:29:33] and apollo 8 coming up [11:29:39] indeed [11:29:48] want to make those missions fully NASSP 8 ready [11:31:02] right now I am working on a mission planning feature in the RTCC MFD [11:31:23] some things the MCC does can't be done in the RTCC MFD right now. I want to change that [11:31:38] i think for my next 11 flight i will use the rtcc [11:32:37] should support everything for a normal mission, yeah [11:33:39] just need to work on that lunar docking [11:33:55] oh yeah, haha, me too [11:34:20] ascent, csi, cdh, tpi and mcc's are quite simple to do [11:34:30] you say that now [11:34:58] I heard it differently before :D [11:35:05] yeah [11:35:13] but you gained experience in the rendezvous and now it's not so difficult [11:35:50] just have to memorize the num pad numbers for the rcs translation i keep forgetting them [11:37:50] I would just load some scenario with the LM and play around with it from the outside view [11:37:56] or maybe i could attempt 12 now that i have more ink for my printer [11:39:46] many possibilities [11:40:20] like a direct abort maybe [11:41:41] morning [11:41:46] Hey Alex [11:41:48] hey [11:41:57] will you be seeing "First Man" next week? [11:43:37] hmm probably [11:44:38] Alex, I am working on the mission planning feature right now I told you about [11:44:59] ill probably be counting all the inagreat [11:45:24] inaccuracies* [11:45:31] great! [11:46:03] making more and more calculation pages compatible with it right now [11:46:18] but I can basically already plan a whole flyby mission [11:46:29] so I am in Earth orbit [11:46:37] activate mission planning [11:46:50] then the TLI PAD page is what simulates the TLI burn [11:47:00] that is a bit bad, so I might change that in the future [11:47:07] then I calculate a MCC-2 (this is Apollo 11) [11:47:11] 1.3 ft/s, not bad [11:47:27] then a MCC-4, which should be 0.0 ft/s really but ends up being 0.3 ft/s [11:47:30] also not so bad [11:47:51] then flyby, MCC-5 with corridor control is 1.3 ft/s [11:48:04] probably also should be 0, but there will always be small iteration inaccuracies [11:48:08] and MCC-7 would be 0.1 ft/s [11:48:17] so I can plan a whole flyby mission like that already [11:48:49] nice [11:49:11] also applied this to my Apollo 16 mission [11:50:12] it says if I use 170x59.7 for LOI then DOI will get a 60.0 apolune [11:50:40] actually just had tried LOI already and it gave the wrong perilune altitude, so I wonder if I broke anything... [11:52:02] I had a PR btw, dont know if you saw (or if the new functions means we need to change them again) [11:53:20] you changed something back in the PR which I had just fixed, haha [11:54:06] LOIapo = 170.6*1852.0; [11:54:08] LOIapo = 170.0*1852.0; [11:54:31] maybe you had to merge and that happened? not sure [11:56:18] oh right, I had put the Apogee back to the SCOT value as I did not think it was important to have it at 170 [11:56:34] but I can change that back [11:58:05] just wanted to talk to you about that first before merging the PR [11:58:16] sure [11:58:32] I thinhk the SCOT value is just what they get after running through a simulated LOI [11:58:42] on the Maneuver PAD it is 170.0 [11:58:43] right [11:58:47] so they probably did target 170.0 [11:59:23] so this would be true for all the missions LOI apoluner [11:59:27] apolune* [12:00:47] probably [12:00:47] Apollo 17 is 170.8, so I guess that would be targeted 170 as well [12:00:52] damn, wrong orbit again [12:00:55] I don't get it [12:01:08] even the Maneuver PAD [12:01:28] my post LOI orbit should be 170x59.7 right now [12:01:48] Does it have to do with solution 1/2? [12:01:49] but it's actually 171.1x58.1 [12:01:54] don't know [12:02:04] but even the Maneuver PAD says it should be 170x59.7 [12:02:22] Is this after actually burning it? [12:02:26] basically no burn residuals [12:02:32] weird [12:02:46] yeah, after burning it [12:02:54] must have broken something in the process [12:03:02] I changed LOI and other functions a bit [12:03:08] guess I need to debug that [12:03:25] the orbit is more like the original targeted orbit [12:03:30] before I changed it to 170x59.7 [12:03:41] whatever we used before that, with the lower perilune [12:04:18] if LOI targeting would be running into any constraints though, then the Maneuver PAD should still show the same orbit as I get after LOI [12:04:36] have to do a bunch of debugging I guess [12:10:12] alright I have amended the PR [12:17:01] looks acceptable now :P [12:17:08] merged [12:19:04] The apollo 11-14 LOI peri's will have to be adjusted too... right now they yield a post DOI apogee of ~57 NM [12:19:35] 11 and 12? [12:19:46] how does that work [12:19:50] don't even do the early DOI [12:21:30] well 11 is 59.2 and 12 is 58.7 post LOI perigee. DOI obviously cant make a 60 NM apolune after that [12:21:41] hmm or maybe it can [12:22:54] I guess those DOIs were not burnt at perigee exactly, and with a bit of a DVZ [12:24:24] well, ideally they were burned from the 60x60 orbit [12:24:34] so perilune isn't really defined [12:25:07] yeah [12:25:12] Apollo 11 was also the first mission where the post LOI-2 orbit wasn't 60x60 [12:25:20] because it would change to 60x60 over time [12:25:24] or so was the theory [12:25:31] we should use 60x60 [12:25:44] and therefore we also don't need to have a different LOI perilune than 60 [12:26:32] so yeah in our case we should aim for 60x60 post LOI-2, which is why I was thinking we would want a 60 NM perilune for LOI [12:26:36] LOI-1 [12:27:49] yeah, I think that is right [12:27:54] applies to 11 and 12 [12:28:02] 10 aimed for 60x60 [12:28:36] also 13,14 aim for 57 NM peilune [12:29:00] both had a DOI DVZ [12:29:02] I think [12:29:10] ah, yes [12:29:18] I think 20 fps for 14 [12:30:42] I was playing around with the RTCC values to get the proper post DOI orbit. I needed more like 50 fps DVZ to get a 60 NM apolune after DOI [12:31:14] needed to raise the LOI apo up to 58.5 or so too [12:37:04] hmm [12:40:00] I'll give this LOI another try [12:40:08] didn't find anything wrong in the RTCC MFD so far [12:40:12] updated alignment and SVs [12:45:15] could it be a non-impulsive TIG issue? [12:45:32] wrong weight fed into the function or what not? [12:45:34] that's what I checked, but the iteration was right [12:45:55] I'll check the weight, but I think that was also ok [12:46:12] and it would have to be something I changed in the last few days working on this [12:47:56] residuals would mostly have an influence on apolune altitude [12:48:05] and that is something we get of course, some variations to that [12:48:17] but I want 59.7NM perilune and got more like 58.1NM [12:48:21] that is pretty bad [12:49:30] did you accidently use LOI w/mcc for the actual LOI calculation itself? [12:49:31] predicted burn time looks right [12:49:37] I have done that mistake [12:49:45] yeah, me too [12:49:47] but not this time [12:49:56] that option will disappear btw [12:50:03] not needed with the mission planning feature [12:50:37] that will make it simpler I guess [12:51:28] yeah [12:51:31] same orbit again [12:51:37] 58.3x170.6 on the PAMFD [12:51:47] landing site altitude is -0.14NM [12:52:13] damn [12:52:21] even worse with trimmed DVs actually [12:52:31] let's see what the AGC thinks what orbit I am in [12:52:49] the orbit I am actually in [12:52:57] so it doesn't look like it's an AGC issue [12:53:02] must be RTCC MFD then [12:53:39] does the AGC say 170x60? [12:53:53] or 59.7 [12:53:56] AGC says the orbit I am actually in [12:53:58] so neither [12:54:01] right [12:54:10] 58.6x170.8 or so [12:54:13] after trimming [12:54:22] so the AGC knows where it is [12:54:51] maybe ill try a LOI on my end [12:55:05] and that will show if its something very recent or not [12:55:35] ok [12:55:50] what I also find weird is that the DV barely changes when I calculate LOI [12:56:06] still had the TIG and DV in there from when I originally calculated LOI for Apollo 16 [12:56:26] hmm [12:56:37] it could also be V48 [12:56:43] masses wrong there [12:57:03] because of way the AGC calculates the burn attitude [12:57:14] compensating for the finite burntime itself [12:59:34] no, V48 masses are accurate [12:59:35] damn [13:04:15] I am just testing LOI with my Apollo 15 pre-LOI scenario [13:04:39] I am using a fresh RTCC MFD state and re-calculating and uplinking an LOI target [13:05:29] hmm [13:06:39] 1st oddity is, I re-calculated the same burn, but the pitch is 353 instead of 0 [13:07:57] that wasn't an issue in my case [13:08:01] still was 0,0,0 [13:08:42] so maybe that has another reason [13:09:29] if I use solution 2 then it is 0,0,0 [13:09:45] oh [13:09:47] interesting [13:09:48] but the default solution 1 is 0,353,0 [13:10:06] did we even have the solution selection when you flew that Apollo 15 mission? [13:10:50] solution 1: DVX -499 solution 1: -139 and TIGs is only 3 seconds apart in both [13:10:54] no [13:11:16] both of the solutions have the same impulsive TIG [13:11:24] the difference is just in which way they are rotating the orbit [13:11:31] the weird thing is the maneuver pad indicates 170x60 for both, even with that much of a difference in DVZ [13:11:32] which will mostly change the DVZ [13:11:55] and with the different total DV the TIG will vary [13:11:56] right [13:11:57] that is all normal [13:12:19] I will burn now and see if the post LOI orbit is good [13:12:23] there simply are two solutions for a specified orbit like 60x170 [13:12:43] ok [13:12:52] I found one interesting thing in the program notes [13:13:02] but I am not sure if this actually affects the DV [13:13:40] if the resulting orbit is not as expected, I want you to apply a DV in the z-axis of 1.7 ft/s [13:13:52] when "nulling" the residuals [13:13:56] I am not sure in which direction [13:14:01] whichever improves the orbit [13:15:02] ok [13:15:11] Due to roundoff in the P40 preburn VG calculation (half-burn [13:15:11] arc rotation), ILI WIN will be in error by approximately the [13:15:12] following amounts: [13:15:13] VGXLV -- -0.674s [13:15:13] VGZ LV = +1.70 fps [13:15:30] didn't copy paste well, lol [13:15:38] LOI VG_LV that is meant to be [13:15:52] and -0.67 fps [13:16:47] if this actually effects the DV, then this might be a Artemis only issue [13:17:03] and with the not very round values for apolune and perilune, we simply might not have noticed before [13:17:14] but I am not sure [13:17:45] I think my orbit was good after my first LOI attempt [13:18:15] oh no [13:18:16] lol [13:18:19] it wasn't [13:18:25] 56.8x170.8 [13:18:34] same issue, just with a lower targeted perilune [13:19:09] I'll check my old Apollo 15 and 17 scenarios as well [13:21:25] in the flight plan for Apollo 16 MCC-H is looking at the IMU velocity-to-be-gained [13:21:32] maybe this same something to do with that [13:23:37] if this turns out to be true, we need to bias the DV for LOI and Artemis by the -0.67 ft/s DVX and +1.70 ft/s DVZ [13:24:36] 170.7x57.2 off PAMFD [13:24:53] what did you target? [13:24:59] 170x60 [13:25:12] still on the residuals display? [13:25:19] yes [13:25:31] try applying -0.7 DVX [13:25:35] and +1.7 DVZ [13:25:38] ok [13:26:05] residuals display seems to often not take small DV increments [13:26:13] but this isn't super small [13:27:21] 169.9x56.8 [13:27:40] ah fak [13:27:53] I burnt DVZ -1.7 [13:28:16] thankfully I quicksaved right after cutoff [13:28:17] 60x170 for Apollo 15 should be 58.1x168.1 on the PAMFD [13:28:28] looks about right actually [13:28:52] need some more in perilune and some less in apolune [13:29:09] I'll try a biased LOI [13:29:20] with those values directly used in the uplinked solution [13:31:22] 169.9x57.3 [13:31:49] with +1.7 DVZ now [13:32:14] and DVX? [13:32:19] use -0.7 [13:32:29] that should improve the apolune [13:35:12] yep that was done [13:35:21] as I said, I'll try one with the uplinked DV already biased [13:35:29] DVX -0.7 and +1.7 DVZ [13:35:30] ok [13:40:11] but from looking at old scenarios I believe that we always had this with Artemis [13:42:40] right [13:44:45] still needs more investigation [13:44:54] but let's see how this biased LOI turns out [13:50:48] Apollo 17 documents are online btw. [13:50:59] https://www.ibiblio.org/apollo/links.html [13:51:03] search for rescue book [13:53:54] hmm [13:54:03] LOI result is not much better [13:54:14] I think it would need even more DVZ change [15:00:54] Any luck with the LOI? [15:02:24] not really [15:02:42] trying another thing, but it's probably not going to help [15:10:26] ok, what I did changed things [15:12:10] I changed the SPS thrust [15:12:21] what we used did vary from what the CMC expected [15:12:44] we use 92100 N, and the CMC uses 91188.544N [15:12:52] burn time rose from 6:10 to 6:14 [15:12:57] which is the same as Apollo 16 had [15:13:23] and that resulted in an orbit closer to expected [15:14:12] without bias [15:14:20] but when I now apply the bias it almost seems spot on [15:14:32] I'll try again with the applied again [15:14:34] the bias* [15:15:40] so maybe that 900N in thrust and the 4 seconds burntime difference is the key [15:16:00] and also the bias [15:17:07] interesting [15:18:39] it could all have to do with the finite burntime compensation the CMC does itself [15:19:59] which for these long burns is really more of an annoyance [15:21:32] ok, one last LOI [15:21:37] unless I screwed up the sign of the bias [15:21:46] then it's once more after that :D [15:22:26] haha [15:22:31] and I probably want to figure out where the rounding error in the CMC happens [15:22:47] because the program notes values will only be accurate roughly [15:22:51] probably DV dependant [15:22:56] well, certainly [15:23:03] but they were calculated for a specific DV [15:23:20] I guess the aim is to add the biasing in the RTCC function? [15:23:44] yeah [15:23:57] if it's actually needed [15:24:09] probably have to dig through Artemis code with Mike for that [15:24:11] if (mission >= 14) [15:24:12] { [15:24:12] dV_LVLH += _V(-0.67, 0.0, 1.7)*0.3048; [15:24:13] } [15:24:26] is what I have right now in the LOI calculation in ARCore [15:29:13] and also figure out why this wouldn't apply to other CMC versions [15:29:17] that seems strange in itself [15:39:13] 59.4x169.7 [15:39:38] above landing site, and favourably rounded up, that would be 59.6x169.9 [15:39:59] I call that pretty goo [15:40:04] d [15:40:11] 59.7 was the goal [15:40:25] residuals trimmed to 0.1, 0.1, 0.1 [15:41:24] so the next step is to dig in Artemis code (or programmed equations) [16:14:48] ok, I think the roundoff is actually with how much the CMC rotates the DV vector itself for the finite burntime compensation [16:15:19] and the DV bias is just how much the DV would be in error due to that [16:15:47] DV magnitude is correct, just not the direction, so I think we do need the bias [16:21:49] makes sense [16:29:32] I might be able to come up with some equation to calculate the bias [16:52:53] morning! [16:58:23] hey Mike [16:59:08] yesterday I was of course talking about the mission plan table thing I was working on for the RTCC MFD. It can already predict how an entire flyby mission with course corrections is going to look like. [16:59:17] nice! [16:59:27] and right now I am digging into Artemis [16:59:43] due to some roundoff issue the LOI Delta V vector needs to be biased, apparently [17:01:51] have to find out if that applies to earlier CMC versions or not [17:02:03] just from experience and procedures I would think not [17:02:20] but Artemis is perfect! [17:02:59] except for the things in the program notes [17:03:03] and this is in the program notes [17:03:27] I had a nice LOI planned with the new planning tool and the resulting orbit wasn't so good [17:04:04] we probably never noticed before because we have been using weird, unround apolune and perilune altitudes as the LOI target anyway [17:04:11] haha [17:34:55] I don't know much about the simulators NASA had [17:35:06] we have a few documents about it of course [17:35:54] mostly documents about the NAA and MIT simulations [17:35:59] simulators* [17:36:07] yeah [17:36:10] which should be good enough [17:36:17] I don't know how accurate they would be [17:36:32] "capable of simulation" is the primary goal :) [17:36:52] capable of running anything seems like a good first step [18:02:58] trying to replicate calculations Artemis does by taking the octals from the erasable memory [18:03:18] I might finally get a feeling for converting octal to decimal and scaling [18:06:05] haha nice [18:50:26] so I uplinked a biased DV and compared the processed DV in the AGC (compensated for finite burntime) with the same equations in a MATLAB script [18:50:38] the resulting DV is basically written back to the input DV [18:50:56] I think that is why, if you do P30->P40->P30 then you see a modified DV [18:51:08] the difference between the expected DV and the one calculated by the CMC is [18:51:10] -0.455067 [18:51:11] 0.019258 [18:51:11] 1.662219 [18:51:35] that suspiciously looks like the -0.67, 0, +1.7 from the program notes [18:51:47] just DVX is different, but that might just depend on the specific DV vector [18:52:12] so I think there definitely is something going on. Don't know yet where exactly this roundoff error happens in the CMC [18:52:54] the compensated DV would be useful in the LGC, it's basically the AGS input DV the LGC calculates [18:53:03] lol, imagine a LOI done under AGS control [19:10:12] nooooo [19:10:27] but it would be super cool if you could get it to work :P [19:11:29] AGS LOI? [19:11:39] haha yeah [19:11:50] well, I don't think it would be possible under AGS auto control [19:11:59] don't think the AEA can handle hyperbolic orbits [19:12:02] but I can check [19:12:17] what is possible is PGNS targeted and AGS controlled [19:12:24] so PGNS gets you to the right attitude [19:12:37] and manually, under AGS control, you basically just hold the attitude [19:12:51] I've done that before [19:13:06] similar to how you would let the SCS take over control of the CSM during LOI [19:14:01] the subroutine in the AGS is called "ellipse predictor" [19:14:07] so much for hyperbolic orbits... [19:26:56] haha [19:52:23] indy91, yeah those numbers look suspiciously similar to what the program nites said [19:52:26] notes* [19:52:55] tomorrow I'll try to find out where in the Artemis code the roundoff error happens [19:59:08] sounds fun [19:59:34] Does the SPS thrust fix apply to earlier CMC versions as well? [20:00:40] yeah, I think all CMC versions use 20,500 lbf for this [20:01:09] I guess it will make a bit of a difference for LOI for all missions, yes [20:02:26] makes burns 1.1% longer [20:03:01] right, for the slightly lower thrust [20:03:09] just a bit closer to what the CMC expects for steady state thrust [20:03:39] and in the case of Apollo 16 at least the burntime is now right on [20:03:48] good [20:04:21] but I'll do a few more tests [20:04:44] it might be enough to use the CMC thrust value in the RTCC function compensating for the CMC calculations [20:04:58] Will the mission planning table thing be ready soon? [20:05:02] yeah [20:05:10] mostly wanted to find out why LOI is off [20:05:20] but I don't think it's caused by any changes I did [20:05:26] right [20:05:55] and I'll make more calculations compatible over time [20:06:12] right now I have: TLI, TLMCC, LOI, LOI-2, DOI, TECC [20:07:05] thats a good start in my book [20:07:25] there are a few pages where there already were some trajectory calculations like that [20:07:30] like the LOI with MCC option [20:07:51] those will probably all be removed, once the same can be done with the mission plan table [20:08:33] same for the DOI display on the TLMCC option 4 page [20:08:53] really only had to do one manual iteration to get my Apollo 16 trajectory right [20:09:03] right that makes sense [20:09:06] I started with 60x170 and got a 60.3 post-DOI apolune with that [20:09:21] it will be probably more realistic that way [20:09:23] deleted the two planned maneuvers, calculated LOI with 59.7 [20:09:26] yeah [20:09:35] and that got me 60.0 post-DOI apolune [20:10:20] what might be useful is a mode, where you calculate a maneuver with the mission plan table, but that maneuver itself is not directly added to the table [20:10:33] so just using the planned trajectory [20:10:43] that might be good if you want to play around with input parameters [20:11:02] but you'll see [20:12:38] and it's really easy to forget that the mission planning mode is on, haha [20:12:53] like, I calculated a LOI and then changed a parameter and calculated again [20:13:04] but of course it already added the first LOI [20:13:18] I guess when its on the main SV used by the MFD is what the mission planning table calculates [20:13:19] so that was a bit of a weird DV [20:13:41] the table stores pre and post burn SVs [20:14:04] and there is a function which chooses the right SV to use, based on an input GET [20:15:04] if no GET is specified, it just uses the last post burn SV in the table [20:15:15] or if no maneuver is there at all it generates a fresh SV [20:20:01] ah ok, thats sounds more simple then I thought [20:23:11] yeah, no manual SV managementz [20:23:15] yet :D [20:24:45] good night! [12:00:41] hey [12:02:25] hey Alex [12:02:45] doing some final touches on the mission plan table and then I think I can release the initial verison [12:02:58] nice [12:03:05] also made compatible now: TEI, flyby and PC+2, Maneuver PAD [12:03:54] So you'll be able to plan the whole mission before TLI [12:04:08] kind of [12:04:17] you can't use the LM mass before TLI right now [12:04:28] ah, right [12:04:38] but other than that, I just tried just that [12:04:40] in Earth orbit [12:04:54] TLI + MCC-2 + MCC-4 + LOI-1 + LOI-2 + TEI + MCC-5 + MCC-7 [12:05:01] works all very well [12:05:25] MCC-2 is 1.3 ft/s [12:05:28] so [12:05:30] what about lunar orbit plane changes? [12:05:40] not compatible yet [12:05:46] but shouldn't be a problem [12:06:14] MCC-2 is ideally only 1.3 ft/s and we usually get larger DVs for some missions and the MCC is always pointing back at the Earth [12:06:22] so my conclusion is that the S-IVB usually overburns [12:06:36] depends on the tailoff thrust parameter in the LVDC I guess [12:07:55] anyway, I'll release this now [12:08:53] yeah I usually notice that for MCC's, pointing at earth [12:09:03] great! Ill test it right away [12:11:22] Visual Studio is slow... [12:12:39] pushed [12:14:00] good morning [12:14:39] hey [12:15:39] @indy91 flew from LA to Vegas just now with the new fs2crew [12:17:06] fun [12:17:20] with sop 3 the captain does most of the work [12:18:40] astronauthen96__ what aircraft? [12:18:52] 737 ngx [12:19:41] good old PMDG 737 [12:20:06] yeah and i am using the new fs2crew reboot which i just bought two days ago and i am already mastering sop 3 [12:20:27] Theres more then 1 sop? [12:20:33] 3 of them [12:20:38] interesting [12:21:11] Do they say what airline they are based on? Probably not for legal raesons [12:21:15] reasons* [12:21:17] ryanair [12:21:25] oh nice [12:21:39] well hopefully i will do this in real life one day [12:22:29] hopefully not for ryanair [12:22:40] thats in europe [12:23:03] yes [12:23:11] an Irish airline i think [12:23:15] just keep some spare change when you want to use the toilet ;p [12:23:39] yeah, crew probably pays 2x :D [12:24:03] lol [12:24:18] alright, just finished rebuilding modules [12:25:18] Whats the best scenario to test the new features, pre-TLI? [12:25:26] i would like to probably fly for Westjet which is an airline in my country (Canada) [12:26:39] also First Man is coming out in theatres in two days which i will be seeing and will probably start an 11 mission after i see it [12:26:50] pre-TLI to generate the TLI+90 and TLI+4/5 Maneuver PADs for example, yeah [12:27:01] that could previously only be done by the MCC [12:27:13] so you active mission planning on the MPT page [12:27:17] activate* [12:27:23] then calculate the TLI PAD [12:27:35] then go to the MPT table and you'll see the TLI maneuver appeared there [12:27:48] astronauthen96__ yeah I have a few friends that work, there seems like a good place [12:28:00] indy91, ok will do [12:30:29] which mission are you trying, Alex? [12:30:33] 15 [12:30:36] ok [12:31:53] TLI+90 for Apollo 15 would be a impulsive TIG of about 4:14:00 [12:32:07] and atlantic ocean contingency line [12:32:20] and the abort option of course [12:32:53] looks good [12:33:08] and you should also be able to calculate the Maneuver PAD for it [12:33:22] gives me: TIG 4:10:47 -462.5, 0, +4680.1 [12:33:29] hmm [12:33:35] that's quite different [12:33:48] what's the splashdown longitude? [12:33:52] -30 [12:34:00] latitude? [12:34:07] +15.7 [12:34:14] oh [12:34:14] lol [12:34:25] it helps if I compare it to Apollo 15, not any other mission [12:34:30] haha [12:34:51] looks ok then [12:35:02] TIG I gave you is also wrong then [12:35:16] try 4:23 [12:35:35] it would be 90 minutes exactly after TLI cutoff I believe [12:35:49] of course first delete the maneuver you had just calculated [12:36:19] I must say this is actually very easy to use [12:36:49] yeah, I'm quite happy with it so far [12:37:16] 4:23 cuts the DVZ down to +1768.8 [12:37:24] haha [12:37:28] then you didn't delete the maneuver [12:37:40] oh haha [12:38:03] it tried to apply that DV after the TLI+90 you had previously calculated [12:38:12] and with the abort option it will try to return even faster [12:38:28] ok now its normal [12:38:39] -425.4 (-129.7); y, +0.1 (+0.03); z, +4,921.7 (+1,500.1) [12:38:42] says AFJ [12:39:07] probably varies a lot with the TIG so close to the Earth [12:39:25] 4 hours, 19 minutes and 56.99 seconds [12:39:38] the actual TIG [12:41:14] mine is -426.7, 0 +4953.5 [12:41:22] really good [12:41:30] remaining difference will be reentry range [12:41:56] that is still calculated a bit differently in the RTCC MFD than in reality [12:42:11] so now you could calculate the Maneuver PAD for that [12:42:31] write it down, delete the TLI+90 maneuver and calculate the TLI+5 one [12:43:08] no TLI+5 on Apollo 15 actually [12:43:15] it's a liftoff plus 8 hours [12:43:24] so the impulsive TIG is simply 8h GET [12:43:30] to the mid pacific [12:43:48] hmm, no actually [12:43:56] 175°W [12:43:58] not 165 [12:44:10] how did I set that up... [12:44:28] does the RTCC MFD still have a P37 PAD? lol [12:45:27] yes [12:45:31] under PADs [12:45:40] used to be on the entry calculation page, but not anymore [12:46:19] trying in your pre TLI scenario for 15, that calculates right as well [12:52:50] just calculated a whole Apollo 15 mission [12:53:09] without LOPC's of course [12:53:38] entry interface was with 2 minutes or so, and all TECC's were 0 [12:55:53] yeah, they usually are, sometimes 0.1 ft/s or so [12:56:07] mostly the TLMCCs I guess [12:56:28] so yeah, that's the mission plan table [12:56:40] still lots to do to make more things compatible [12:56:47] next is the Entry PAD [12:58:47] and together with the mission plan table there will be a maneuver planning equivalent [12:58:56] "FDO Detailed Maneuver Table" [12:59:15] I think most numbers on the Maneuver PAD are derived from that display [12:59:38] and most processors transfer an impulsive DV to the maneuver planning table [12:59:55] and there you can decide on engine, spacecraft, masses to use for the burn [13:00:11] and only then gets a burn transferred to the mission plan table [13:00:31] that is the workflow as I understand it from reading lots of RTCC documents, haha [13:03:27] there also is a separate rendezvous planning table, not sure how that works together with the mission planning one [13:03:58] I guess a lot of the current maneuver targeting functions that have "MCC" will not require that anymore [13:05:28] yeah, those will slowly be removed [13:05:41] Entry PAD has that as well, so that will disappear next [13:06:06] same for the complicated way of calculating the LOI-2 REFSMMAT for Apollo 8 [13:06:32] which is also how we used to have to calculate the LS REFSMMAT before MCC-4 [13:14:31] so I guess now for Apollo 8 LOI-2 REFSMMAT it will be, calculate everything up to LOI-2 in the mission planning table, then calculate the LOI-2 REFSMMAT by just using the regular P30 REFSMMAT page [13:16:09] it's actually a LVLH REFSMMAT at the LOI-2 TIG position [13:16:31] ah, right [13:16:32] but yeah, once the REFSMMAT calculations are compatible with the MPT, then it will work that way [13:17:15] MCC-4, LOI-1 and LOI-2 in the MPT, and then use the LOI-2 TIG as the GET input for the REFSMMAT [13:23:55] I'll be back later [14:05:57] Im just reading the Apollo 14 post flight trajectory document [14:06:27] It has a good description on the way they targeted MCC-2 (hybrid transfer) [14:07:28] But the real reason I was that I was curious if they targeted a constant GET or constant GMT lunar arrival, and it seems to be indeed a constant-GMT, like the later missions [14:08:07] constant GMT [14:08:28] yeah [14:09:20] you can actually see that in the SCOT [14:09:26] if it has the "Launch Window Summary" page [14:09:31] Apollo 12 for example [14:09:40] Translunar flight time: approx. 81 hours [14:09:53] so I think Apollo 12 has a constant GET arrival time [14:09:57] So they targeted MCC-2 so that after LOI, rev. 2 begins at 84:05:10.07 which is exactly the delay amount (40m2s) substracted from the rev.2 time in the flight time of 84:45:12 [14:10:06] ah right [14:10:32] same for 13 [14:10:42] so probably 14 and later have the constant GMT arrival time [14:10:56] 13 to 14 is a big step in terms of planning and procedures [14:11:04] guess they had lots of time on their hands [14:11:12] at least more than ever before between flights [14:13:13] Apollo 14 SCOT PDF page 3 is interesting for this [14:13:21] HSI-209204 [14:14:28] and the FIDO Orbit Digitals page will also be made compatible with the MPT [14:14:37] so you will able to figure out the rev crossing time there [14:14:39] or actually [14:14:50] I believe there are some other displays showing the rev crossing time as well [14:15:00] without special request for longitude 180° [14:15:20] "Computed Events Summary Sheet" [14:15:32] not sure if that is even a RTCC display or a printout, haha [14:15:38] but that has rev crossing time [14:17:35] another thing it says for Apollo 14 MCC-2: Results in no flight-path angle change at DOI [14:18:14] that means DVZ = 0 [14:18:25] that's the goal really [14:18:31] but interesting [14:18:42] because the SCOT had a non-0 DVZ, right? [14:20:31] yeah [14:21:01] maybe another imperfect simulation in the SCOT [14:21:12] so for targeting it maybe should be 0 again [14:21:43] Why would they want it to be non-zero in the 1st place? [14:23:25] well if you optimize MCC-2, LOI and DOI together it might not result in a 0 DVZ [14:23:39] we get that as well, I believe [14:23:45] right [14:25:54] I guess the SCOT simulation which optimized all that, resulted with the 20 fps or so DVZ in DOI. I guess they were still aiming to have the DVZ as low as possible anyway [14:26:24] sounds about right [14:26:50] also, the people who generate the SCOT data and the people responsible for real-time targeting during a mission are not necessarily the same people [14:27:05] so you often get small differences [14:30:10] hmm also, in the post-flight trajectory document, it seems to indicate that Apollo 14 performed MCC-4 calculated with the BAP-4 program in the RTCC [14:30:41] oh [14:30:42] I was under the impression that the BAP programs was only used for MCC 1 &2 [14:30:47] yeah [14:31:21] maybe they modified it for Apollo 14, because in the Apollo 13 Mission Techniques it still definitely says to not use it for MCC-3 and 4 [14:34:21] "RTCC Requirements for Apollo 14: Non-free-return modes of the translunar midcourse correction processor" [14:34:29] that would be the document to have [14:36:09] yeah, the Apollo 13 mission techniques still give the full description of why it's undesirable to use BAP targeting for MCC-3 and 4 [14:36:49] but in the postflight document you are rading it also said something about "perilune altitude control only" [14:36:55] reading* [14:37:01] so maybe that was an added feature [14:37:21] well, I believe that is really just burning the calculated DVX for a MCC [14:37:31] and not DVZ [14:39:58] hmm, MCC-4 doesn't even iterate when I try TLMCC option 4 on Apollo 16 [14:40:03] that is not right [14:41:18] I have noticed that before too [14:41:51] On all missions I have tried, MCC-4 doesnt not iterate with option 4 [14:42:00] ok [14:42:04] I'll have to debug that [14:48:31] I am working on some updates to the RTCC constants for Apollo 13 and 14 now. The post-DOI apolune was 57 NM with what we currently have [14:49:48] So to get that to 60 NM, having both a 60 NM PC altitude and 60 NM LOI peri target is what seems to get the post-DOI apolune closest to 60 and the DOI DVZ closest to 0 [14:55:41] yeah [15:01:12] im just wondering why the initial orbit was targeted so low in reality (peri=57NM) Maybe there were more perturbations then usual [15:02:04] on 14? [15:02:09] hmm I guess not, because the real post DOI apolune was targeted to 58.4 NM [15:02:11] yes [15:02:20] and that seems in line with the other missions [15:03:58] must be the non-zero DVZ [15:04:03] maybe [15:04:09] DOI altitude is 57.2NM [15:04:56] yes [15:12:56] I have found using PC altitude of 58.7 and LOI peri of 59.5 seems to work best. 59.9 NM psot DOI apolune and a DOI DV very close to the SCOT, with DVZ at +20.7 [15:18:37] oh wait it says in the post-flight trajectory that they target a PC altitude of 60.3 NM for MCC-2 [15:18:48] why would the SCOT say 57.1? [15:22:45] yeah, weird [15:24:59] and using the PC of 60.3 works much better in the RTCC MFD calculations so I think I will work with that target 60.3 minus the LS elevation so 59.54 NM PC altitude [15:27:50] sounds good [17:27:10] PR sent [17:34:10] morning! [17:36:41] hey [17:40:39] hey Mike [17:43:56] what's up? [17:44:41] got the mission plan table commited [17:45:55] got a positive review from Alex I think, haha [17:47:38] nice! :D [18:00:39] its pretty handy, I just simulated an entire Apollo 17 mission, with the 2h40 delay [18:00:55] lunar landing within a minute or two [18:03:35] well, by "entire" I mean up to lunar landing lol [18:03:37] so half [18:03:47] that's pretty awesome [18:16:08] AlexB_88, like the direct return aborts calculated in Earth orbit you can now also calculate the TEI Maneuver PADs you get before LOI [18:16:30] and I'll look at the rendezvous maneuvers soon [18:16:41] so that you can properly plan the Apollo 9 rendezvous [18:21:14] great [18:25:08] well, any rendezvous really [18:25:23] you often get Maneuver PADs early [18:26:17] dealing with mixed CSM and LM maneuvers will probably also be tricky [18:26:33] also, I was thinking about like how the CSM gets a post-insertion SV before the LM has flown ascent [18:28:26] ascent and descents can also be added to the MPT [18:29:49] well, and the MCC can already use a SV from the ascent simulation page [18:31:04] maybe that SV could be automatically transferred to the SV page or so [18:39:11] Im thinking of flying 14 with a launch delay [18:43:23] indy91, whats that procedure again you did to get the PTC REFSMMAT time? Id like to try it on Apollo 14 [18:45:46] 14, ok [18:46:45] actual PTC REFSMMAT is on page 5-5 of the SCOT [18:46:48] PDF page 314 [18:47:48] then in ARCore look for the line [18:47:49] REFSMMAToct[1] = REFSMMATUplinkAddress(); [18:48:03] a bit above that are two commented lines [18:48:18] the lower one (displaying MATRIX3 a) is the one you want to uncomment [18:48:36] ah ok found it [18:48:48] you basically want to make that displayed REFSMMAT as close to the one from the SCOT as possible [18:49:07] the PTC REFSMMAT will be valid for the average launch window TEI, so start around that GET I guess [18:49:38] well, I guess it would be a constant GMT or MJD for the REFSMMAT, not GET [18:53:10] thanks [18:58:16] Looks like its very close to 166:10:00 [19:04:38] 166:10:25 [19:05:00] quite close to the one you came up for Apollo 16 [19:05:40] closer to the normal TEI? [19:06:16] I mean the PTC REFSMMAT time [19:06:25] Apollo 16 is 166:02:50 [19:06:57] oh, that's what you mean [19:07:01] yeah, that is interesting [19:14:04] my next question is, if you have a launch delay, do you need to subtract the delay from that PTC REFSMMAT time? [19:15:15] I guess yes, as it has to be at a constant MJD like you were saying [19:16:24] it's really a constant REFSMMAT [19:16:44] this PTC REFSMMAT from the SCOT would be used for any launch time [19:17:30] "at the average time of TEI for the monthly launch window and azimuth range" [19:18:25] the monthly launch windows is just 1 day launch though [19:18:26] I think [19:18:30] 1 day long* [19:18:56] at least it will be for 15-17 [19:20:43] or one recycle day on the next day, but not any more [19:22:33] maybe the PTC REFSMMAT time should really be an MJD [19:23:33] yeah [19:23:59] I'll change that soon [19:27:21] Now for Apollo 14 do I fly the historical delay (40m2s) or do I go for something else? It would be cool to try one near the end of the launch window... [19:27:32] maybe with a 2nd opp TLI in there too [19:30:50] launch window is a few hours long [19:34:31] 3:50 according to the SCOT [19:34:51] Maybe ill try a 3 hour delay [19:34:54] yeah, a bit below is what I also see in the time vs. launch azimuth graph in the LVOT [19:35:00] below 4 hours* [19:35:13] 3 hours will be roughly 88° [19:35:19] launch window only extends to 96° [19:36:02] Its nice to now have that function in the RTCC MFD to request the launch azimuth from the LVDC [19:37:06] yeah [19:45:52] a 3 hour delay would actually make it an evening launch [19:49:05] ah [19:49:15] so maybe they still had lighting constraints then [19:49:23] hence the end of the launch window at 96° [19:54:57] hmm looks pretty dark at my planned lift-off time, I think I will settle for 2h30 [19:58:47] Ill be launching later this evening probably, but I have to go out for a bit, cya! [20:14:39] night! [12:18:49] morning [12:19:33] hey Alex [12:21:35] oh, the Apollo 17 PDI scenario is in the WIP folder [12:22:05] oh [12:22:16] WIP Mission Scenarios, I see, haha [12:23:11] pre LM ECS scenario [12:23:17] yeah [12:27:23] I should update it really [12:28:43] I won't, haha [12:28:52] enough scenarios to keep track of already [12:29:32] and RCS is broken in that scenario, since it was made before you implemented the LM RCS [12:29:41] haha ill take care of it [12:30:37] before I'll implemented the explosive RCS valves at least [12:30:40] I* [12:30:45] yeah [12:31:21] ill do that now and get that scenario flyable again at least [12:32:41] the person on the forum will probably ask that next, why the RCS isn't working [12:41:24] haha maybe [12:41:40] anyways I have a fixed version of the scenario now in my copy [12:42:39] its actually interesting to look at the diff display in git GUI between the new and old scenarios [12:43:09] you can see all the systems that were added with all the green sections in the LM section [12:59:38] ok time to launch Apollo 14 [13:52:10] Quite spectacular those evening launches [13:52:11] https://www.dropbox.com/s/brsodpbv3i1himq/Screenshot%202018-10-10%2009.36.41.png?dl=0 [13:53:23] yeah, looks great [13:54:25] btw I am looking at the lvlog from the LVDC, Im getting way better SV accuracies then I used to [13:54:39] 983 at TB5 [13:54:46] used to be like 1500 [13:56:30] not sure why that would be different [13:56:45] don't think I did any LVDC updates [14:12:23] yeah might be a fluke [14:31:19] hmm TB6 GET is 26:06:53 on the TLI PAD [14:31:53] and the other values are non-sense [14:32:06] VI +21561 [14:32:08] weird [14:32:37] when did you launch? 2:30 into the launch window? [14:32:41] yes [14:32:41] what was the azimuth? [14:32:49] 85.02 [14:33:22] guess I'll need the scenario [14:33:31] sure [14:34:23] https://www.dropbox.com/s/q5e5n7kxus0875a/Apollo%2014%20-%20Delayed%20Launch%200002%200016.scn?dl=0 [14:34:32] difficult to debug though [14:34:44] the MFD is accessing the LVDC, which is in a different module [14:34:55] so if I just build the RTCC MFD in debug mode I get acces violations [14:36:01] it might be as simple as an issue with the presettings for that late launch [14:39:50] right [14:41:32] looks all good though in the presettings [14:43:51] I know what it is [14:43:56] I knew this would happen one day [14:44:08] there is a launch day mismatch [14:44:36] I am always the person the ends up finding the issues that "could happen one day" haha [14:44:54] RTCC MFD thinks the launch day is one day later, because by now midnight UTC must have passed [14:45:05] maybe because I try so many weird things [14:46:19] and I confirm its not the presettings because TB6 started at the right time [14:46:27] so how do I fix this... [14:47:33] the targeting presettings actually seem to have a launch date [14:52:21] it needs to figure out the day when the launch window started [14:53:39] LVDC only really saves the time since midnight (of that launch window opening day) [14:55:09] probably have to add LVDC clock time to the parameters used for TLI PAD calculation [14:59:54] Is there something I can add in the mean time to get a TLI PAD, or maybe I can just calculate a TLI in the MFD, then get a TLI PAD from that [15:00:10] but without actually uplinking the MFD TLI solution to the IU [15:00:57] revert to a slightly earlier scenario [15:01:02] 40983.0191450864 [15:01:08] .0191450864 [15:01:14] that is 864 seconds [15:01:25] before that it would calculate correctly [15:01:41] so a scenario 864+ seconds earlier than the one you gave me [15:02:06] and of course you will just need to do this to write down the TLI PAD [15:02:07] ah ok [15:02:11] everything fine with the LVDC [15:02:26] But I am flying 2nd opp TLI haha [15:02:28] just the RTCC couldn't figure out on which day the launch actually was [15:02:34] well [15:02:39] then you are out of luck, haha [15:03:02] ill just calculate it in the MFD [15:03:14] won't work [15:03:25] it checks if there is an uplinked solution in the LVDC [15:03:35] only then it uses the MFD own TLI solution [15:04:09] figuring out how to still get a TLI PAD takes longer than fixing the bug [15:04:23] so just be a bit patient and I'll have a fix soon [15:04:34] haha fair enough [15:05:06] just don't want to break other missions [15:09:44] oh damn [15:10:06] a similar issue is in the LVDC code itself [15:10:54] if the launch time is past midnight [15:11:01] but the launch window opened before midnight [15:12:10] hmm [15:12:17] Apollo 17 launch window is all past midnight UTC [15:12:29] does the Apollo 14 launch extend to past midnight? [15:12:34] launch window* [15:12:57] it's close [15:13:01] opens 20:23 [15:14:02] yeah [15:14:04] damn [15:14:10] 14:20 to 18:10 EST [15:14:13] so just past [15:14:20] so I'll need to fix this in the LVDC as well [15:18:43] I'll fix that later [15:18:54] it's only a problem for the last 10 minutes of the Apollo 14 launch window [15:19:01] don't think anything else is affected [15:23:15] AlexB_88, fix is up [15:24:52] awesome, thanks [15:26:24] I knew this could be an issue some day, but wasn't sure in which cases [15:31:03] it works [15:38:31] ok I have the TLI in the mission planning table, but my TLI+90 calculation is now stuck [15:47:25] what input parameters did you use? [15:47:49] pressing CLC again will of course stop the failed iteration [15:50:48] TLI + 90 so 3:41:10 + 1h30 = 5:11:10 I just used 5:12:00. Mid-Atlantic abort [15:51:09] Using 5:15 worked, but the DV was wrong [15:52:29] how did you arrive at 3:41:10? [15:52:49] But I guess I should not use the block data schedule page for reference as that is probably based on nominal launch [15:53:03] oh right thats TB6 [15:53:18] I should have used the actual ignition time + 90m [15:53:20] also, you didn't launch to 72° [15:53:22] yep [15:53:25] TLI ignition plus 90 [15:53:38] and 1h30 is also a risky assumption [15:54:49] so close to Earth it is quite sensitiy to the targeted splashdown longitude [15:55:47] oh, I thought the 1h30 was the one orbit later [15:55:52] but that is of course the +90 [15:56:03] thought you were basing this off an earlier TLI PAD that worked [15:56:31] so it's more like 5:20, right? [15:56:35] yeah [15:56:45] that should work [15:57:10] don't forget to delete the TLI+90 with the wrong TIG from the table [15:58:05] hmm thats weird [15:58:32] it gives a very low DV like 200 fps and has an RRT before the TIG [15:58:53] and there was only the TLI in the table? [15:59:06] TIG is 5:19:49, RRT is 3:51:03 [15:59:08] yes [15:59:11] hmm [15:59:11] I made sure of that [16:00:01] at 3:51:03 it probably is at EI altitude as well [16:00:04] it probably finds that [16:00:26] ah yeah [16:01:11] guess I'll need another scenario [16:01:16] coming up [16:01:25] stop finding these things, I'll never progress with anything :D [16:02:03] oh but theres more... :p [16:02:23] https://www.dropbox.com/s/udeucs0wsxdnkng/Apollo%2014%20-%20Delayed%20Launch%200002%200018%200002.scn?dl=0 [16:03:29] actually just a minor other issue too: When you inhibit TLI after entering TB6, when the IU goes back to TB5, the manual S/C control flag appears to not be reset [16:04:00] Ill shut-up now and fly TLI and carry on with the mission :D [16:05:20] how does that even [16:05:31] why was that flag set in the first place [16:08:38] well I mean when you are in TB5, you can use saturn takeover. When TB6 starts then saturn takeover is locked-out and you cant do it even if you try. If however you inhibit the TLI and go back to TB5, I am thinking should it not give you back the option to use saturn takeover? [16:09:03] right now you stay locked out of it [16:12:02] when after TB6 started did you inhibit [16:13:04] 2 seconds [16:15:01] TLI inhibit is a separate timebase [16:15:05] TB6c [16:15:19] and that should give control back [16:15:23] at TB6c+9.9 [16:15:59] hmm [16:16:12] but it doesn't even TB6c if you inhibit before TB6+41.0 [16:16:17] even go to* [16:16:21] so that is probably the issue [16:17:43] probably another special sequence [16:17:48] it's doing one there already [16:17:49] hmm i see [16:17:54] when going back directly to TB5 [16:18:09] it's already setting the restart alarm to off [16:18:12] S-II Sep light [16:18:31] so I probably have to add that signal to the FCC as well [16:19:28] it must be one of those switch selector commands that is not programmed for a specific time in a specific timebase [16:19:34] but somewhere in LVDC code basically [16:20:39] easily added [16:21:35] ah, I think have an idea what it is with the TLI+90 [16:22:00] remember the issues we sometimes had with it find a time before TIG? [16:22:03] where was that [16:22:07] was that flyby targeting? [16:23:10] or was that direct return abort as well [16:23:23] hmm cant remember [16:23:40] I've fixed that in the function generally used by Orbiter [16:23:44] functions* [16:23:47] not Orbiter [16:23:50] the RTCC [16:24:09] but the entry targeting is still derived from P37 and uses a special function for that [16:24:33] I had that issue where it would send me to the wrong edge of the moon if I calculated an MCC in early TLC [16:24:36] which is using another more general function I had changed for the overall fix [16:24:40] ah, that [16:24:48] but I dont think thats what youre referring too [16:25:15] so I might just have to use the same fix in the entry targeting which I had already done earlier elsewhere [16:26:29] do you have a scenario post-TLI already? [16:26:37] that would be easier to debug [16:29:28] for some reason VS debugging is also super slow for me [16:29:32] I'll update VS first [16:31:33] coming up [16:31:43] half way through TLI [16:37:22] https://www.dropbox.com/s/exltr1paanex2p7/Apollo%2014%20-%20Delayed%20Launch%200002%200018%200009.scn?dl=0 [16:37:37] thats just after TLI cutoff [16:39:05] hope the S-IVB doesn't do weird things when I load this scenario [16:39:27] just after TLI cutoff probably means you didn't wait until it started moving to the LVLH attitude, right? [16:39:58] starting with Apollo 14, the S-IVB stayed in the cutoff attitude for 2.5 minutes and did a bit of venting [16:40:03] with the accelerometers still running [16:41:15] hmm it was probably 45 seconds after cutoff that save [16:42:20] doing the LH2 vent later isn't taken into account for the IU state vector [16:42:37] so targeting the S-IVB on a crash course would be less precise [16:42:43] that's why they changed that [16:43:40] ooh I guess I can try the impact maneuver now [16:44:00] yeah [16:44:07] just to properly calculated targeting yet [16:44:12] but you can do the nominal MCC-1 [16:44:16] S-IVB MCC-1* [16:44:18] morning! [16:44:32] hey Mike [16:44:35] hey [16:44:45] what's up? [16:44:55] fixing bugs Alex keeps finding... [16:45:01] damnit Alex [16:46:22] Visual Studio wants a reboot [16:50:52] and I always keep finding a ton on 14 for some reason lol [16:51:50] Apollo 14 is a bad idea [16:52:00] Apollo 14 to Fra Mauro is a bad idea* [16:52:00] hahaha [16:57:29] you closed the RTCC MFD, Alex, now I need to fix the TEPHEM in the MFD [16:57:42] ... which I of course can't do in debug mode, yay [16:58:09] just need to open the scenario, reload the TEPHEM, close with the RTCC MFD open, build in debug mode... [16:58:15] nothing easier than that [17:00:24] weird [17:00:29] still getting pretty bad results [17:00:44] but not even just reentry time before TIG [17:02:50] hm [17:02:54] something just isn't right [17:04:18] oh, it's nothing [17:12:22] AlexB_88, not so easy to fix, probably something special about this trajectory [17:12:35] but I guess it isn't urgent anyway [17:12:41] just an abort maneuver for 14 [17:13:06] I agree [17:13:08] So its evasive maneuver enable, then timebase 8 enable, in that order? [17:15:00] yes [17:15:43] just never send the evasive maneuver command before LM ejection [17:16:15] reading the flight plan the commands might be confusing [17:16:24] "evasive maneuver enable" is the yaw maneuver [17:16:38] and the APS will be fired at the start of TB8 [17:17:34] so TB8 enable probably should be done at a precise time [17:18:06] right [17:18:31] and with your trajectory being different than the flight plan it will never crash into the Moon without the MCC being different [17:18:49] but you can at least command a burn [17:23:41] yeah I thought so [18:02:40] So the SCOT says hybrid transfer DV is 73.4 to 45.0 [18:03:15] Mine is going to be 49 fps, looks pretty much on par [18:03:52] yeah, for close to end of launch window [18:06:09] cya tomorrow [11:37:13] hey [11:38:10] Good morning [11:38:55] oh, you here as well! [11:39:09] I am! [11:39:19] I have really missed it [11:39:21] good news from like last week [11:39:33] So i took today to make it an NASSP day :) [11:39:40] Mike found a bunch of padloads [11:39:44] Call it a "mental health day" [11:39:45] including Apollo 11 CMC [11:39:50] Oh wow [11:40:00] so we don't need the checklist from the Smithsonian anymore [11:40:08] DAP scaling has been confirmed [11:40:20] Great! Any other appreciable differences? [11:40:40] he actually found padloads for Apollo 11-17, CM and LM [11:40:46] lots of differences all around [11:40:48] most small [11:41:19] morning [11:41:42] Any AGS loads? [11:41:47] no [11:41:49] Damn [11:41:52] Haha [11:41:59] I am getting greedy [11:41:59] he found it in Don Eyles garage [11:42:08] Don had papers and stuff from colleagues [11:42:10] treasure trove [11:42:31] so this wasn't his own collection, which had mostly been scanned already, but from coworkers at MIT [11:42:40] so of course nothing about the AGS [11:42:55] some Apollo 17 checklists and mission techniques documents though [11:43:03] but Mike didn't scan it all [11:43:14] can still be done in the future, it's not going away [11:43:53] what we still need is a CMC padload for Apollo 8 or 9 [11:43:57] more DAP weirdness [11:44:13] but it's also just to confirm that we use the right values and scaling [11:44:28] DAP was correctly configured in our Apollo 11 CMC padload [11:46:19] weird day. We should be celebrating 50 years of Apollo 7, but it's not a good day for human spaceflight [11:46:36] we might see the ISS being decrewed in January or so [11:54:30] Second manned LES abort in history right? [11:55:30] I actually haven't seen it confirmed yet that the LES was used [11:56:14] but one Soyuz had a pad abort [11:56:18] with the LES [11:56:25] and another had an abort after LES jettison [11:58:44] Ah true [11:58:53] It said it was during separation [11:59:00] But again the news reports are vague [11:59:04] yeah [11:59:10] would be close to LES jettison [11:59:21] in Apollo terms either a late Mode 1C or early Mode 2 abort [11:59:28] Right [11:59:33] the G forces weren't so bad, 6-7Gs I read [11:59:43] Not bad for a ballistic entry [12:01:00] yeah, the Apollo aborts I have done with a similar trajectory were all worse [12:01:09] high and slow at abort, not a nice combination [12:02:00] Nope [12:02:23] I'm not sure what the initial orbit for a Soyuz is [12:02:53] Apollo 7 had a fairly high insertion altitude, so an abort would have been up to 16G [12:07:59] rcflyinghokie, oh, you probably haven't even seen the new RTCC MFD feature [12:08:03] the Mission Plan Table [12:08:13] I have not [12:09:02] it's for planning a mission, surprisingly [12:09:20] or rather, to be able to predict the trajectory [12:09:59] in Earth orbit for example you get Maneuver PADs for a post TLI direct return abort [12:10:43] you activate planning mode, put the simulated TLI from the TLI PAD on the mission planning table and then you can calculate maneuvers for after TLI already before TLI [12:11:05] it's as closely derived from the actual feature the RTCC had as I could manage and figure out [12:11:36] I like it [12:11:53] it makes a lot of things possible that previously only the MCC could do [12:14:13] I am flying Apollo 14 right now and I have used it to calculate the TEI-5 abort pad before LOI and TEI-6 before DOI (TEI-6 assumes DOI) [12:14:33] works very well [12:14:57] and I am making more and more calculation pages compatible with it [12:15:05] changing some things on the Lambert page for it right now [12:16:24] indy91, I have not had any of the issues I had with the TLI+90 on any of the subsequent calculations, so I dont know what was up with that. Every thing after worked good [12:17:23] I think it has some issues with being so close to Earth [12:17:35] we must be lucky that the TLI+90 for other missions is actually working [12:20:36] looking at the Apollo 10 operational abort plan right now, maybe they wouldn't even use the Atlantic Ocean in your case [12:23:21] "Launch Window Effects on the Apollo 10 (Mission F) Operational Abort Plans" sounds like a useful document for this [12:23:34] yeah [12:24:18] aha! [12:24:51] Atlantic Ocean TLI+90 DV becomes excessive at 88° launch azimuth [12:25:15] for the first opportunity [12:25:48] hmm [12:26:20] for the second opportunity it actually look really low [12:26:56] for 85° it's roughly 2500 ft/s but a long time to landing [12:27:12] East Pacific (EPL) is the alternative [12:27:23] it doesn't say if EPL would be nominally used [12:27:31] for the second opportunity [12:28:07] but it looks like a better solution really [12:28:16] it would make sense [12:28:46] Apollo 10 constraint was: not more than 18 hours return time [12:29:00] that would only be possible with the EPL, not the AOL [12:29:12] DV is also acceptable [12:29:19] btw the lift-off time update went well, except for the fact that I had loaded the wrong TEPHEM at 1st. I had 1st used the Apollo 15 Artemis072 worksheet to convert my MJD to octal, but it did not work. I ended up using the Zerlina worksheet to convert my MJD to octal [12:29:52] yeah, you need the right year [12:30:06] TEPHEM is 0 at midnight July, 1st [12:30:34] oh [12:30:35] haha [12:30:35] Do we even have an official Apollo 14 CMC/LGC worksheet? [12:30:40] I have [12:30:51] might have forgotten to commit it, haha [12:30:56] I'll do that [12:31:06] if you use the Midcourse instead of the Abort option, then the TLI+90 works [12:31:08] to the AOL [12:31:14] probably because of the DV [12:31:20] it's only a bit more than 2000 ft/s [12:31:35] the abort option tries the fastest return possible and starts iterating with 10k ft/s [12:32:29] ah wait, hadn't updated the TEPHEM [12:32:52] no, midcourse doesn't work then [12:33:16] abort and EPL works [12:34:10] so that is probably what should be used [12:36:52] because the TLI+90 to the AOL would return too slow anyway [12:37:41] any later TLC aborts to the MPL will likely work [12:40:10] yes, I have all filled out all the P37s for TLC [12:41:01] I was able to skip MCC-4 and my post-DOI orbit apolune is still 60 NM [12:41:57] great [12:42:11] haven't included any fix for the LOI issues yet [12:42:28] DVZ was about 35 fps. Had I burnt MCC-4 it would have been about 7 fps. [12:42:38] yeah, sounds about right [12:46:36] that must be a record for me, I flew from launch all the way to post-DOI in one day [12:47:25] and from LEO to post-DOI in one session [12:49:04] that is quite impressive [12:49:16] and here I am, still pondering what to do with my Apollo 16 mission [12:49:28] so you already flew LOI? How was the orbit? [12:49:44] and post DOI was a perfect apolune? [12:50:03] Very good actually [12:50:22] LOI PAD said +170.1 x +59.1 [12:50:37] V82 after LOI: 170.1 x 59.1 [12:51:19] post DOI orbit 60 x 8.2 [12:51:27] but it's the same CMC version [12:51:30] so weird [12:51:39] what am I doing wrong with Artemis, haha [12:51:43] back in a bit [12:54:19] It is weird that it was so perfect when my Apollo 15 LOI scenario was not so [12:54:36] yeah [12:55:01] but it is Artemis, just with a few constants changed [12:55:09] for Apollo 14 [12:55:32] I have a pre-LOI scenario if you want it for testing [12:56:04] nah, I think my Apollo 16 one is enough [12:56:16] I wouldn't know what to test with Apollo 14 [12:56:17] haha ok [12:56:18] really no idea [12:56:25] it shouldn't be different [12:57:08] One thing that is interesting is the LOI DV is higher then the flight plan value [12:57:22] 3078.7 VT instead of 2990 or so [12:57:35] But that is easily explainable by the 2h30 delay [12:57:56] yeah, probably [12:58:17] trajectory to the Moon will be faster [12:58:22] right [12:58:26] so probably arrives with a higher velocity [13:00:42] I have another Apollo 14 TLC scenario with a nominal launch time and I did a full simulation with the mission planning table with it. DV is much closer to what the flight plan says [13:00:53] LOI DV* [13:00:57] good [13:01:12] pushed a few updates [13:01:35] One thing I cant explain is that LOI TIG is always about 3-4 minutes early as compared to the SCOT/real mission [13:01:48] great [13:01:57] mostly more MPT compatibility [13:02:14] the Lambert targeting page had a badly implemented function to search for the TPI TIG [13:02:22] you would enter E=26.6 for T1 [13:02:34] and it previously calculated T1 instantly [13:02:40] from the current trajectory [13:02:51] so that wouldn't be compatible with the MPT, so I reworked that a bit [13:03:28] doesn't calculate T1 instantly, but with the general Lambert targeting calculation [13:04:18] yeah, no idea why it's early [13:04:32] I also had that with Apollo 16, but I blamed the wrong approach azimuth [13:04:36] I think we are missing the padload work sheet for Apollo 14 LGC too [13:04:43] oops [13:04:47] nope we are not missing that [13:04:56] also not commited [13:05:07] will do that [13:06:55] thanks [13:08:14] I see the PDI PAD can be added to the MPT [13:08:57] would that be to update the TLAND? [13:08:57] it can use the MPT [13:09:03] oh I see [13:09:19] I removed the old functionality that gave the DOI burn to the PDI PAD calculation [13:09:36] just uses the MPT now [13:10:10] yeah all this will make the MFD much cleaner [13:11:30] same was deleted for the Lunary Entry PAD [13:12:10] yep I saw [13:12:41] I guess the LOI w/MCC option will disappear? [13:13:44] yeah, soon [13:17:52] I'll be back later [13:18:04] cya [14:39:54] back [14:43:10] AlexB_88, landed yet? :D [14:44:34] nah... im slower today then yesterday :D [14:44:52] just about to do the docked coarse align [14:56:12] DKI isn't compatible yet with the MPT, forgot to add that [14:57:11] just for the case that you want to calculate abort maneuvers [15:27:07] good morning [15:35:49] hey [15:36:10] now i am using dual moniters for my 737 ngx [16:30:26] PDI crossrange will be -5.3 but Ive seen that on Apollo 12 as well [16:44:08] morning! [16:47:35] hey Mike [16:50:44] what's up? [16:58:39] Flying Apollo 14, giving the new padloads a test [17:01:28] hey Mike [17:01:42] AlexB_88, weird, I wonder what Apollo 12 and 14 have in common that causes this [17:01:55] it must be the inclination [17:01:56] AlexB_88: so still causing Niklas trouble, is what you're trying to say [17:02:00] :P [17:03:32] this is likely an issue that actually happened on Apollo 12, but the Apollo 14 PDI PAD doesn't show much of a crossrange, so they probably corrected it [17:03:45] He must get nightmares of the bugs I might find ;p [17:04:24] it can only really be the nodal precession [17:04:36] thats what I was thinking too [17:06:07] Its not an issue with the -90/91 azimuths, just with the weirder ones like 12 and 14 [17:06:35] yeah [17:07:02] on the other hand, the J-Missions all had fairly high latitude landing sites [17:07:12] ah [17:07:14] but of course [17:07:34] if you approach the landing site with -90°, then even nodal precession isn't so bad [17:08:03] if you imagine your orbit as a sine function, then you are close to the maximum [17:08:11] shifting that left and right doesn't give much crossrange [17:08:34] but with the -75° or so of Apollo 14 you are not at the maximum of the sine function [17:08:51] so shifting the function left and right by the same amount gives a higher crossrange [17:09:55] so the nodal precession has a higher influence on the crossrange, if your approach azimuth is further away from -90° [17:11:04] I see [17:12:55] they probably biased the landing site longitude used for targeting LOI [17:12:58] or something like that [17:13:14] ah maybe [17:13:21] I guess you could even try that with the mission plan table [17:14:02] it was showing me -1 NM crossrange when I used the planning table [17:14:35] hmm, ok [17:15:09] on the DOI page? [17:15:15] yeah [17:15:22] I wonder if it uses conic routines somewhere there [17:16:15] ok [17:16:18] oh* [17:16:27] that's the crossrange at DOI TIG [17:16:36] which is of course very early [17:17:21] found something in the Apollo 11 mission report [17:17:33] about "lunar orbit targeting" [17:17:54] "first, the landing site latitude targeting was biased in an attempt to account for the orbit plane regression noted in Apollo 10" [17:18:14] "During Apollo 10 the lunar module passed approximately 5 miles south of the landing site on the low-altitude pass following DOI" [17:18:54] "The Apollo 11 target bias of minus 0.37° in latitude..." etc etc [17:19:24] I guess biasing the latitude has a greater influence on the orbital plane [17:20:20] quite interesting [17:20:44] Is there a way to make the DOI targeting give you the crossrange at PDI ignition? [17:20:53] just calculate the PDI PAD [17:21:01] ah, right [17:21:21] did I make that compatible already? [17:21:26] I think yeah [17:21:39] yes [17:21:43] but if youre in TLC you have to switch to the LM of course to check the PDI PAD [17:21:49] ah, damn [17:22:16] and the mission plan table doesn't work yet using both vehicles [17:22:45] you could schedule a DOI-2 [17:22:52] 0.5 revs before PDI [17:23:05] will have minimal DV and the right crossrange [17:23:26] yeah [17:23:40] I think 5 NM isnt to bad though [17:23:56] too* [17:24:01] it's within the limit, yeah [17:24:21] so we might want to start using biases in the future, but you don't have to revert to before LOI just for that, haha [17:24:37] no lol [17:24:58] if I were to perform a DOI-2, I guess I could use the PC page to target the landing site [17:25:29] yeah [17:25:52] DOI and plane changes were handled by the same processor in the real RTCC [17:26:05] could also combine those maneuvers and perform a bunch of other ones [17:26:17] which was of course used during Apollo 15 [17:26:22] DOI with a plane change [17:26:39] right [17:27:02] also handled LOI-2 [17:27:06] was LOI-2 part of the LOI processor? Or did they just use the GMP to do LOI-2? [17:27:17] same lunar descent planning processor [17:27:26] LOI-2/PC/DOI [17:27:40] and a bunch of weird other maneuvers to get back on track for a lunar landings [17:27:46] Hohmann transfers etc. [17:28:05] probably for the case that you end up in a weirdly shaped orbit after LOI [17:28:35] so that processor has everything you need to get back to a 60x60 orbit (or whatever you want) and in-plane with the landing site [17:28:55] I'll put that together at some time [17:29:20] have no equations for it at all though, just the list of maneuver types in the RTACF Operational Support Plan [17:30:13] from Apollo 11 [17:30:30] must have been expanded, it can't combine a plane change with DOI yet [17:30:32] only LOI-2 [17:44:39] indy91 do any abort constants for the AGS come up in an MCC update? [17:45:11] yeah [17:45:13] in a PAD [17:45:19] Ah yeah activation thats right [17:46:29] nothing calculated there yet [17:46:35] just the same as the padload [17:48:07] speaking of AGS, and your earlier conversation [17:48:10] Are they calculated and changed at any point [17:48:20] there was *some* AGS stuff in Russ Larson's boxes [17:48:27] Ohh [17:49:09] in particular some of the PCRs in "Contents of Luminary 1E" go into a lot of detail of the specifics of the AGC->AGS updates [17:49:42] and one of the FSRR folders had, in addition to the review slides for Colossus and Luminary, a design review book for FP8 I think [17:49:51] I didn't look at it very closely [17:50:26] Hmm interesting [17:50:36] I may have taken a picture, one sec [17:50:41] Might hold more clues as to what FP7 was like [17:53:54] Hmmm lets see [17:55:58] looks like I didn't take a picture of it, and didn't explicitly index it [17:55:59] go me [17:56:10] Its ok [17:56:10] I promise it was there though, in one of the FSRR folders :P [17:56:21] so we'll have to scan that at some point [18:10:54] indy9, I guess the DKI is in the works to be compatible with the MPT? Im wondering because PDI-0 is after the CSM circ burn. Its not very important though I can always calculate it after the circ burn itself [18:11:00] indy91* [18:13:15] well, the circ burn is done by the CSM, PDI0 by the LM, right? [18:13:23] that won't work yet anyway [18:13:57] for that a few things need to be implemented [18:14:05] all RTCC MFD instances need to share a common mission plan [18:14:28] oh man, 5 more Specification Control Drawings incoming [18:14:36] from NARA? [18:14:45] yup [18:15:17] the insulators for the Malco contacts, the 1006323 and 1006310 standard PNP and NPN transistors, and the 1006320 cores used in the rope modules :D [18:15:18] one of these days I have to ask them about some RTCC Requirements documents [18:15:45] I am so stoked to have found another bunch of things in the drawing collection [18:15:58] those sound all useful for preparing to power up an AGC [18:16:09] yeah [18:16:15] they have had every single one I've asked for so far [18:16:18] it's incredible [18:16:46] there will be many more to come -- I want to know more about some of the capacitors, resistors, and diodes :D [18:20:54] 1006320 is going to be particularly interesting [18:24:10] anything about the rope cores we don't know yet? [18:27:07] yes! almost everything, haha [18:27:27] all I know is that they are wound with 1/8 mil molybdenum permalloy tape [18:27:44] I don't know anything about their physical dimensions or their electrical/magnetic properties [18:33:18] indy91, I think I got confused with the circ maneuver... of course its the CSM and not the LM performing the maneuver and so the MPT would do nothing to help... [18:33:49] yeah, that will need some fundamental changes and some additions to work [18:34:00] but the real MPT could mix CSM and LM maneuvers just fine [18:34:04] so that is definitely coming [18:35:40] "all RTCC MFD instances need to share a common mission plan" By that do you mean like all the constants will be saved outside of the MFD itself so that any MFD instance can access the same saved variables? [18:36:58] well there are several levels to the MFD [18:37:12] so it would rather be stored as common memory of the RTCC MFD module [18:37:24] and not an instance opened in one of the vehicles [18:38:01] I wonder if I should even make all RTCC MFD instances use a common core [18:38:20] so that all MFD parameters are shared [18:38:31] hmmm good question [18:38:38] in the end there wasn't a RTCC for the CSM and LM [18:38:41] there was one RTCC [18:38:57] but that would need lots of changes in itself, so it wouldn't come any time soon, I think [18:39:07] I think it would make things easier for sure [18:39:14] right [18:39:43] the RTCC could store e.g. several different launch times [18:40:02] for CMC, LGC, AGS and LVDC [18:40:08] and also GRR times [18:40:59] the AGC also can have a GRR, it just happens at T-0 [18:41:06] for Colossus at least [18:41:44] GRR just means accelerometers and gyros are released [18:42:12] so the handling of all those separately would have to be implemented first anyway [18:42:26] so I'll probably first will make the MPT common between MFDs [18:43:09] yeah [18:43:29] I definitely think we should go in that direction... having a common core [18:43:34] yeah [18:43:58] not very difficult to implement actually [18:43:59] btw circ burn is a nice 60.6x60.1 [18:44:28] because the MFD is already common to all instances you have open in a vessel [18:44:47] so if you open the RTCC MFD twice it has the same state [18:44:56] twice in a vessel* [18:49:03] So it must be easy to extend that to other vessels within the same session [18:49:40] yeah [18:50:02] another advantage would be saving/loading [18:50:10] I could make it persistent like the Checklist MFD [18:50:25] so that you don't loose your MFD state if you had saved with the RTCC MFD not open [18:57:37] I would really like that actually, I have thought about something like that, like how the checklist MFD saves its stuff like if it was a subsystem of the vessel itself [19:01:40] yeah [19:01:44] I'll do that [19:14:06] come on NARA, I sent you my payment info, send me the SCDs :P [19:15:04] there's a lot of traffic on the AGC developer mailing list today for the 50th anniversary of Apollo 7 [19:21:44] well first of all, it would be P23 [19:21:46] even in Sundisk [19:22:10] hahaha [19:22:44] although that might not be necessarily true [19:23:05] Apollo 9 mission report had a list of program alarms etc., but it looks like there were too many on Apollo 7 [19:23:08] but there is this [19:23:26] "...and attempts to take horizon sightings with the [19:23:26] landmark line-of-sight in the orbital navigation program." [19:23:47] that sounds like it, but orbital navigation program would be P22 [19:24:07] this is about things that caused restarts, not just program alarms [19:24:08] from the Functional Description and Operation Using Flight Program Sundance: [19:24:27] Ground Track Determination Program (P21) [19:24:32] Orbital Navigation Program (P22) [19:24:41] Cislunar Midcourse Navigation Program (P23) [19:24:59] same in any CMC [19:25:27] "put together a procedure using a modified [19:25:28] version of the CisLunar Navigation Program," [19:25:41] not sure how to understand this [19:26:06] hmm [19:26:17] he had a modified version on the ground and a procedure for it [19:26:27] and they then tried the procedore in on board? [19:26:52] so that would be a procedure for a different Sundisk build then [19:28:25] I know Sundisk had a fairly capable version of P23 [19:28:41] they did Earth horizon/star sightings which didn't work very well [19:28:51] only really works further away from the Earth [19:29:03] they also tried Moon horizon/star sightings which worked much better [19:30:45] I'll try to find this in the transcript [19:30:52] pretty sure it would be day 8 or later [19:31:39] oooh [19:31:41] I have an idea [19:32:04] "When Donn made the mark the AGC performed a divide by zero (an infinite loop) [19:32:05] because the LLOS did not intersect the earth." [19:32:10] I bet this was P22 then [19:32:21] because normally you point at landmarks [19:32:34] hmm, well, P23 can use landmarks as well [19:33:56] think I found it [19:33:59] in the transcript [19:34:11] "I have a procedure for your P22 horizon sighting" [19:34:28] that's not something you normally do :D [19:34:33] hehehe [19:35:53] blame Ron Evans [19:36:02] he was apparently trying out the procedure in the sim [19:36:10] before they tried it onboard [19:37:14] they read up the procedure during the flight plan update, so I have to find where they actually try it [19:37:22] but it's definitely a revised P22 procedure [19:37:31] marks on the horizon [19:38:20] a few hours later, yet another tweak to the procedure [19:38:25] still haven't tried it [19:38:34] whats PDI-0 TIG again? perigee? [19:38:57] I think so, yeah [19:39:04] one rev before PDI [19:39:36] 213:37h is when they want to try the procedure on Ascension [19:40:22] C_P I m_derstand the objectives, and I understand the [19:40:23] reason, but I Just dontt understand .ll the [19:40:24] oh,,ges and so forth at the last mfnute. I [19:40:24] qhh'lnk it's rather ill prepared and hastily [19:40:25] conceived. [19:40:33] ouch [19:40:46] basically: CMP critizes the procedure and that it is last minute [19:40:50] before even trying it [19:42:12] haha [19:42:15] found it [19:42:39] too bad the AFJ doesn't extend this far [19:42:57] they don't have a lot of COMM during the procedure, so this is all a bunch of minutes after [19:43:18] CMP: Jack, I'll give you the rundown here. Do you read me okay? [19:43:30] CC: I'd rather get to wait till Carnarvon to get the rundown so I don't miss anything. [19:43:43] CMP: You won't miss a hell of a lot if you don't get it here. [19:43:51] Okay, if you like, I'll give you a little preview [19:44:04] We did not get the results you're after. [19:44:10] We didn't get a damn thing, in fact [19:44:20] All we got was a program alarm and a restart light and a CMC light [19:44:23] end quote :D [19:45:56] lots more detail following that though [19:46:36] starting on PDF page 984 of the transcript [19:47:06] "so we did the go-jam procedure" [19:47:24] ah, with reset and reject [19:47:38] 1302 alarm [19:48:11] and after CMP complaining follows the usual CDR complaining [19:48:18] just the usual Apollo 7 stuff [19:51:17] even in Colossus marking above the horizon in P22 would probably be a program alarm [19:51:20] just not a lockup [20:11:40] hahaha [20:11:41] nice [20:17:00] CMC light [20:17:03] that's pretty intense [20:17:09] it takes a lot going wrong for that to come on [20:18:10] well yeah, it got locked up for multiple minutes [20:18:26] and they had to do that reset + reject press at the same time procedure, haha [20:19:54] heh [20:20:13] I guess Sundisk didn't have the little bit of code that automatically does a fresh start if the CMC warning light is on [20:20:20] must have been added after this incident :D [20:20:44] yeah [20:21:31] I have the MSC note "Verification of Sundisk Orbital Navigation Program" [20:21:47] it includes the GSOP section 4 excerpt about P22 [20:21:57] oh even better [20:22:00] MIT flowchart [20:22:19] not really a format I am all that familiar with [20:22:52] do we have any other flowcharts for program? [20:23:00] this is not the GSOP one, it's more low level [20:23:06] well it has both [20:25:04] hmm [20:25:09] I think we do [20:25:49] oh, and it also has the crew checklist for P22 [20:26:07] that is good to understand the special procedures read up by the CAPCOM [20:27:43] and it's a document from exactly 50 years ago [20:27:52] so about as close to launch as possible :D [20:29:26] Maybe I can do the procedure in Colossus [20:29:35] I'll try some time [20:29:40] anyway, good night! [21:56:11] https://drive.google.com/open?id=1pcCchHIKvdeM-0uytHBKMSXpTDIC93rl [21:56:14] SCDs! [22:44:58] nice! [22:46:17] .tell indy91, yeah we can say the LR works pretty damn good now lol https://www.dropbox.com/s/9wxmn8p48ji6031/Screenshot%202018-10-11%2018.22.36.png?dl=0 [22:47:15] night! [12:45:14] good morning [12:45:48] hey [12:46:20] will be flying from Munich to Vienna soon with my Lufthansa 737 600 [12:49:53] I don't think Lufthansa ever had any of those, haha [12:50:24] not even any 737NG I believe [12:50:33] there is is only 69 of them [12:50:51] and the last one was given to Westjet which is a canadian airline [12:51:28] yeah, not many wanted the short version [12:51:35] similar to the A319 I guess [12:51:46] 318* [12:54:06] and there is an airline in Northern Canada which has a 200 [12:58:32] those must be getting old [12:59:03] oh yes [12:59:13] early 60s [13:00:48] I think I've flown in an Icelandair 737-300 about 20 years ago [13:01:27] ah [13:01:34] bot those are next gen compared to the 200 [13:01:36] but* [13:02:25] i think i might have flown on the 600 from Toronto to Montreal in 2007 [13:09:57] also did you hear about the soyuz abort? [13:11:01] yeah, we talked about it here yesterday [13:22:45] I'm away for the weekend, cya on Sunday evening! [01:52:43] Hello [16:22:12] Hey [16:26:29] hey Alex [16:27:11] Had a very good lunar landing at Fra Mauro [16:27:34] great [16:28:17] The new padloads work well, the descent trajectory was definitely different then my last Apollo 14 run [16:28:50] I still can't say I believe fully in the terrain model [16:29:46] but I'll have to look at the terrain itself [16:30:14] Does it not align with the Orbiter 2016 terrain? [16:32:04] not in the first part [16:32:28] Weird [16:33:53] noticed any high DHs? [16:34:23] Hmm not really [16:34:41] Nothing out of the ordinary any way [16:35:00] the first point is especially off [16:35:05] but it would be further uprange [16:35:10] so maybe that's the reason [16:35:16] would be good* [16:37:01] I think the first point of the terrain model is used as the terrain elevation for everything before that point [16:37:49] so that first point has to represent the average elevation from the point of LR acquisition [16:37:56] to itself [16:38:32] good news, we have a new flown checklist [16:38:35] https://thespacecollective.com/image/cache/data/apollo-9-lm-eva-checklist-cdr-copy.pdf [16:38:39] Apollo 9 LM EVA [16:38:46] Ryan should like that one [16:38:56] Nice [16:39:46] I’ll have to fly PDI again tonight, I can pay attention to what the DH does [16:40:16] Can’t right now as I’m on the road [16:40:23] the terrain isn't too bad there anyway [16:40:28] as compared to all later missions [16:40:32] up and down a few 100 meters [16:40:46] and I finally finished Dons book [16:41:15] Nice, I’ll have to pick up a copy [16:44:04] remembering the jittering on the tape meters? [16:44:12] which is fixed in Luminary 210 [16:44:23] I think all previous versions have it [16:44:55] Jittering? [16:45:12] well, it doesn't really show a stable altitude and altitude rate [16:45:21] but it's slightly going up and down often [16:45:28] Ah yeah [16:45:40] when is the last time you used Luminary131 or earlier? :D [16:46:17] anyway, apparently someone implemented that who didn't understand fixed point precision very well and that was the issue with it [16:46:26] Don had to fix it later [16:46:28] A while I guess lol, must be in spring when I flew 12 [16:46:30] so much I already knew [16:47:09] but what I didn't know before is that the had always noticed that on the simulator at MIT, but thought it was an issue with cheap hardware for that sim [16:47:17] they* [16:47:55] Interesting indeed, now I really want to get the book [16:48:22] it wasn't until Don flew to KSC for the first time to train with Pete Conrad (I think) on the LM simulator there [16:48:39] that he noticed that it behaved exactly the same and that it could be a software issue [16:49:35] and the last few things that Don did for the LGC was work on EMPs [16:50:20] there is a very interesting one that he was still testing at KSC in the LM sim after Apollo 17 had launched [16:50:47] they discovered some issues with it, I think, so he was still working on that after the last launch [16:50:55] but the EMP is for a powered descent with failed CDUs [16:51:20] the EMP guesses the attitude based on accelerometer measurements [16:51:29] so you can't have a fully failed IMU [16:51:36] and you have to fly under AGS control [16:51:46] so PGNS does navigation and guidance, AGS does control [16:51:53] sounds interesting, right? :D [16:52:11] Hmm that’s quite the scheme [16:52:45] we have the Luminary 1E EMPs, so we can try that some time [16:53:00] Oh we have that EMP? [16:53:15] yeah that would be fun to try [16:53:18] we have the Artemis and Luminary 1E EMP documents [16:53:29] and some Luminary memos about it [16:53:40] Nice [16:53:41] if CDUX fails (yaw) then it's a much more simple procedure [16:53:59] that is EMP 103B [16:54:14] 103A is for failed CDUY or CDUZ, much more complicated uplink string and procedure [16:54:32] https://www.ibiblio.org/apollo/Documents/j2-80-R-567-SEC7_text.pdf [16:54:39] starts on PDF page 41 [16:55:10] I’ll have a read tonight [16:55:18] MIT never had an AGS or AGS simulator, so, as it says there, it had to be tested at KSC or Grumman [16:55:30] got Don some more time at KSC I guess :D [16:56:32] Definitely something that would be fun to try in NASSP [16:56:41] Anyway I’m off to work! [16:57:00] cya [16:57:15] cya [17:19:59] morning! [17:25:51] hey [17:26:17] what's up? [17:26:49] finally finished Dons book [17:31:25] oh nice! [17:31:37] what'd you think? [17:32:56] there is an interesting EMP he talks about in the end that I want to try [17:33:47] and in general, I liked the "who did what" kind of insights [17:33:51] and the thought processes [17:35:06] and more on the analog displays, haha [17:35:21] haha yeah [17:35:33] why they were jittering [17:35:45] they thought it was bad hardware in their sim at MIT [17:36:03] but when Don was at KSC for the first time he saw that the LM sim there behaved the same way [17:36:37] and apparently there is something in the code that was necessary to make it work on the LM sim [17:37:13] oh yeah, I went and found that after I read the book [17:37:18] where was it... [17:38:54] Zerlina throttle routines is attached to the landing analog displays job, which made it run more often, and as is says in the book, leads to really crisp throttle response [17:42:31] he calls Zerlina 56 "the state of the art for a piloted landing on an airless body with inadequately surveyed terrain" [17:42:48] and I don't think there is anybody on this planet who could dispute that [17:42:51] not even today [17:44:19] :D [17:44:34] and we have it! super awesome [17:45:24] I guess it's missing some Luminary 1E features [17:45:54] nothing major [17:46:22] I still want to make a version some day that has all of the features of both [17:49:16] my least favourite part of the book [17:49:32] a picture with Apollo 14 listings [17:49:37] both CM and LM [17:49:41] so close [17:49:41] hahaha yeah [20:07:19] night! [15:11:17] good afternoon [15:12:01] hey [15:14:26] just tested PDI again, I noticed DHs around 2000 at the beginning (around 39000 ft) [15:16:12] unfortunately we have nothing to compare that again from the real flight [15:18:32] when they finall had LR acqusition they had a big jump in the calculated slant range though [15:21:34] hmm interesting [15:22:09] could make sense with the not so accurate terrain model [15:35:33] there is one graph in the GNC mission report supplement [15:37:46] difficult to tell the terrain from it though [15:41:16] found a post flight Luminary memo [15:44:23] "Jim Aiphin of MPAD reports that this terrain model mismatch was intentional;" [15:46:04] oh really [15:46:15] https://www.ibiblio.org/apollo/Documents/LUM208-AK_text.pdf [15:46:18] still reading it [15:46:38] I had saved a terrain model picture online, but can't find it anymore [15:46:42] let me get that again [15:47:33] https://i.imgur.com/GsmtRuT.png [15:48:22] the graph is in meters [15:48:34] the new terrain model is from the new padload document [15:48:43] old LGC one from an earlier Luminary memo [15:50:29] the memo says to not use the terrain model to shape the trajectory [15:50:36] but it looks like exatly that was done [15:50:53] intentionally off terrain model to cause a certain trajectory behavior is my guess [15:51:35] interesting [15:51:49] and the two LGC terrain models are effectively MPAD vs. MIT [15:53:18] Apollo 14 (H3) Mission Operational Trajectory Simulator Data Package [15:53:21] that is reference 1 [15:53:25] might be good to have [15:54:03] I have to check if we have any [15:54:08] UHCL has the Apollo 10 one [15:56:05] I wonder if that document type has targeting parameters of all sorts [15:56:10] definitely want that [15:57:46] "APOLLO 14 LAUNCH WINDOW INCLUDES A POSSIBLE NIGHT LAUNCH " oh really :D [15:58:12] I can confirm :p [15:59:11] another interesting document type could be "REAL TIME SUPPORT OF THE APOLLO 14 MISSION" [15:59:35] but I can't find reference 1 of the terrain model memo unfortunately [15:59:40] Are these all at UHCL? [16:02:38] the ones I quoted in all caps, yeah [16:04:54] good morning [16:06:39] hey [16:06:48] saw First Man yesterday [16:06:50] just loved it [16:09:03] how accurate do you think is the movie? [16:09:23] i dont want to spoil it but it mainly focused on the events leading to 11 [16:09:54] i think it portrayed him very well [16:12:30] spoiler, he lands on the Moon [16:12:42] does it have his test pilot career? [16:13:12] indy91, thanks, now I have no reason to see the movie :p [16:13:29] will they come back [16:13:48] haven't spoiled that part, so still some excitement [16:14:11] not with the RTCC MFD at least: https://github.com/dseagrav/NASSP/issues/409 [16:15:16] Ill have to fly Apollo MCC myself... I have 2 weeks of vacation now to do it [16:15:21] Apollo 11 MCC* [16:15:30] Hey Alex [16:15:33] hey [16:15:37] that bug seems to be a rare case though [16:15:40] still needs fixing [16:15:59] Niklases 11 mcc's are just perfect [16:17:11] always perfect, unless they aren't, then Orbiter crashes [16:26:41] indy91, I just tried the landing site biasing during TLC procedure to get a better cross-range at PDI [16:26:45] works like a charm [16:27:33] oh great [16:27:39] are you looking at the PDI PAD? [16:27:42] or a second DOI [16:27:50] I realized I could of course get the PDI pad to display from the CSM, just select the LM from the config page [16:27:59] oh, right [16:28:04] messy solution, but it works [16:28:11] yeah [16:28:42] I was away for the weekend, but on Friday I started with the shared mission plan table between all RTCC MFDs [16:28:45] I biased the latitude of the RLS south by 5.3 NM [16:28:52] great [16:28:56] and on Sunday all I did was delete it all again because it was bad :D [16:29:02] haha [16:29:03] latitude in miles? [16:29:42] I calculated the new latitude here: https://www.lpi.usra.edu/lunar/tools/lunardistancecalc/ [16:29:50] 5.3 NM so 9.8 km [16:30:11] ah, I see [16:30:23] and that gives a good crossrange on the PDI PAD? [16:30:34] 0.9 [16:30:52] it doesn't translate exactly to latitude of course, so some trial and error is expected [16:30:54] that was my 1st attempt, I can surely make it better too [16:31:00] yeah [16:31:14] pretty sure this is the procedure that would have been used on the real missions [16:31:19] I guess it would be better with the -90 approach azimths [16:31:26] azimuths* [16:31:27] one of the reasons why the real RTCC was never very user friendly... [16:40:33] I bet the RTCC MFD is already more user friendly then the real RTCC lol [16:42:48] yeah [16:45:29] it only gets better, haha [16:45:37] morning! [16:45:37] well, not if we use biases like that of course :D [16:45:43] hey [16:49:46] what's up? [16:49:54] we probably figured out the Apollo 14 terrain model question [16:49:56] hey [16:50:06] with the new one we found being different [16:50:22] "The apriori terrain model ( LGC model) was found to not match the "real" [16:50:22] terrain defined by Table IX of Ref. 1. The apriori terrain model was about 500 ft. [16:50:23] higher than the real model at 47, 000 ft. before the landing site." [16:50:32] the original one was from MIT [16:51:22] it's basically MIT vs. MSC [16:51:38] MIT says to not use terrain model for trajectory shaping [16:51:44] MSC uses it for trajectory shaping [16:51:53] basically as simple as that [16:52:50] https://www.ibiblio.org/apollo/Documents/LUM208-AK_text.pdf [16:52:55] the relevant Luminary memo [16:53:32] and the terrain: https://i.imgur.com/GsmtRuT.png [17:28:47] hahahaha [17:28:49] fascinating! [17:29:09] way to go MSC [17:29:56] you might think it's smart to make the terrain higher than it really is to gain some ground clearance [17:30:17] but then you suddenly have a downrange error in your state vector [17:30:25] and the terrain isn't actually where the LGC thinks it is [17:31:01] in that case you wouldn't want a more pronounced terrain model than necessary [17:33:04] I know all about downrange errors. Remember the LGC clock issues we used to have? Combine that with an extreme terrain like Apollo 15 [17:33:25] DHs of +10k feet and -10k feet [17:45:06] yeah it certainly seems like a bad idea [17:45:44] well this is a postflight memo, haha, the bad idea flew [17:46:25] hehehe [17:47:07] "MIT results are the reverse [17:47:08] of MPAD results" ah, fun stuff [17:47:21] reverse how? [17:51:21] the intention terrain mismatch [17:51:24] intentional* [17:51:49] "he terrain model mismatch increases navigated altitude error at [17:51:50] the end of the braking phase, and the error persists for the first 20 seconds of [17:51:50] the approach phase. In addition, the curve of LPD angle vs. time is not as flat [17:51:51] and the persistent vertical error produces a small LPD error." [17:53:43] also [17:53:44] "The problem was aggravated by a downrange [17:53:45] position error; for any error in excess of about 7000 ft. the LM would crash" [17:53:51] that should be interesting to test [17:54:10] just doing a N69 with the 7000 feet [18:00:31] :D [18:00:50] I'm glad the padloads Don had are correct [18:01:11] the 14 one will never not look weird to me, haha [18:01:57] hehehe [18:02:06] wasn't 15 giving you problems too? [18:02:07] but I think it is what flew [18:02:08] or one of the others? [18:02:12] a little bit [18:02:28] 15 was more off than the other one we had [18:02:34] from the Delco manual [18:02:45] 16 and 17 were 100% identical to what we already were using [18:02:50] also from the Delco manuals I think [18:04:09] of course you can never sure what they uplinked before PDI, haha [18:04:15] never be sure* [18:06:24] if we ever get an erasable memory dump from a mission, that would be awesome to look through [18:42:33] is DEDA 225/226 on the ascent pad valid for Luminary210? [18:43:57] comparing the G&N dictionaries for Apollo 12 and 17, they seem to have slightly different descriptions for those addresses [18:44:34] but its hard to tell if they are indeed different, or its just describing the same addresses with more detail [18:57:17] not the same I think [18:57:53] just an address difference though, I think [18:57:59] 224/226 in FP8 [19:01:28] ah ok [19:01:55] and other stupid question: Is that 224 to 226 or 224 and 226? [19:03:49] same value needs to be input for both addresses [19:03:58] right [19:04:42] 224 seems to be the same description for both older and newer LGC verions [19:05:39] I think they got rid of a lower limit and instead added the two segment abort [19:06:53] also, AGS versions* [19:07:02] sorry yes [19:07:07] AGS not LGC [19:07:29] so 224 and 226 should have the same vallue [19:07:35] value* [19:08:55] that's how it is on the Ascent PAD for FP8 [19:09:00] 224/226 [19:10:22] makes sense now [19:11:09] AGS Manual actually suggests to make sure only the first segment targeting is used [19:11:12] with some procedure [19:11:33] but setting both 224 and 226 makes sure that the "abort" segment doesn't matter [19:11:46] or rather phase angle at liftoff [19:17:37] I had set 225 and 226 with FP8 on a direct insertion test shortly after the ascent pad was implemented a few months ago. The AGS controlled ascent started to do some weird things after liftoff so I guess I now know why, 224 and 226 with FP8 [19:19:26] I can't say I fully understand it yet, haha [19:19:35] but the targeting is the same as for an abort [19:19:46] you just have to make sure it's using a fixed insertion orbit [19:21:22] in FP6 you simply set the upper and lower limit to the same number [19:21:27] that is 225 and 226 [19:21:40] that's how you get the fixed insertion orbit [19:23:35] right [19:23:48] ah, now I get it [19:24:01] in the procedures for FP8 you set 662 and 673 to 0 [19:24:43] those are the numbers mulitplied by the current phase angle to calculate the insertion semi-major axis [19:24:57] so that's how it is made phase angle independant in FP8 [19:25:28] the two values you set (224 and 226) are then the first and second segment semi-major axis [19:25:52] you still got segments because there still exists a phase angle and a phase angle threshold for switching between them [19:26:40] so while you set two values to the desired number in both FP6 and FP8, it's for very different reasons and done in very different ways [19:42:49] just tried a direct insertion with FP8, AGS-controlled and with the ascent pad values in the correct addresses [19:42:59] tweak burn only 3 fps [19:45:49] implementing the whole P12 guidance equations in the RTCC MFD must be good for something :D [19:53:07] but I enjoyed doing tweak burns [19:54:26] but did you really [19:55:24] ah maybe not ;) [19:56:08] I did notice something interesting... This is the same scenario where after a PGNS-controlled insertion, the LM is out of plane [19:56:46] due to the alignment I think. The odd thing is the AGS controlled insertion is perfectly in plane [19:57:00] but got the exact same SV and alignment that PGNS had [19:57:07] that's weird [19:59:14] maybe thrust tailoff? [20:00:39] the question is also what the reason is for the out of plane error [20:00:43] guidance or navigation [20:02:15] I was under the impression it was the slightly wrong alignment in the lateral plane so that lateral errors accumulate throughout insertion [20:03:13] yeah [20:04:25] but you'd think the exact same would be true for the AGS, it gets the same alignment from PGNS [20:05:13] haha NARA being sneaky [20:06:21] just got an email from them saying that they finished this next batch of scans, and that I can call them from 8:00am to 3:00pm to make the payment [20:06:21] they sent the email at 3:01pm [20:06:22] guess I won't have any SCDs to process until tomorrow [20:06:38] haha, perfect timing [20:08:52] also briefly got scared [20:09:02] they found all of them except for 1006291 for a transformer [20:09:13] but I'm just an idiot and the number for the transformer is 1010291 [20:12:17] easy to confuse, haha [20:12:43] what was the per page cost again at NARA? [20:13:56] $0.80 per aperture card [20:14:17] so... when I call tomorrow I'll have paid ~$250 for all of these SCDs [20:14:22] but the drawings are worth it [20:14:28] yeah [20:14:32] and pages as in actual pages [20:14:45] for example RTCC Requirements I can't anywhere else [20:14:49] those aren't aperture cards [20:15:01] and is probably significantly larger than any of these things [20:15:05] most drawings are only a few pages lol [20:15:50] it is surprising to me that aperture cards cost less to scan than actual pages [20:15:59] might be an easier process [20:16:03] must be [20:16:13] not really a manual scanning process [20:16:29] they probably have a dedicated device for this [20:16:34] I hope it is easy for them, because I still have like 25 to request [20:16:56] you pay good money for it [20:17:08] I'll reserve my "feeling bad for requesting too much" for UHCL [20:17:16] hahaha yeah [20:17:32] so what is the per page cost for actual paper pages then? [20:17:44] uhh, let me find my last bill [20:18:20] I paid $20 for the 1006323 lead failure study [20:18:22] how many pages was that [20:18:31] 16 [20:18:43] $1.25 per page [20:18:54] oh [20:18:59] ouch [20:19:10] yeah, pages are stupid expensive [20:19:13] prohibitively so [20:19:19] the RTCC Requirements documents I would want might be up to 100 pages [20:19:23] yep [20:19:47] difficult to predict for the LOI and return-to-Earth ones [20:19:54] because I don't have any version of it [20:20:02] I want all of the MIT System Status reports very badly right now [20:20:15] but they're ~50 pages each and I don't know which ones have the info I want, or if they even have it [20:20:25] and there's like 40 of them [20:20:29] welcome in my world [20:20:38] so I'd have to pay $2500 to see them all lol [20:21:04] this is why somebody needs to go there and scan things [20:21:04] >_> [20:21:05] <_< [20:21:31] well you very spontaneously flew to Boston for that kind of thing ;) [20:21:44] that was different [20:21:47] was it? [20:22:10] for sure [20:22:13] certainly in the magnitude of the things to scan, haha [20:22:21] number of* [20:22:34] and I got to meet Don [20:23:01] and there was a much greater probability of finding something useful for the AGC powering effort than at NARA [20:23:11] right [20:23:31] and NARA is a business, and I can go whenever. Don's a person and who knows if I were to wait for a year if the opportunity would still be there [20:23:40] yeah [20:23:53] business, haha [20:24:04] with these kind of prices they are :P [20:24:09] yeah [20:24:26] in Germany you would either have no access at all because reasons or easy and free [20:24:32] that's how it usually goes [20:24:35] even with ESA actually [20:24:53] I mean, I'd rather have to pay for this stuff than have no access at all [20:24:54] ESA is much more restrictive with data than NASA... until it isn't [20:25:01] I guess it depends on where the dividing line falls [20:25:03] heh [20:25:04] it's a bit weird [20:25:18] sometimes they suddenly have a lot of stuff available [20:26:44] what you got us from Don has a higher "good info per page" ratio than always anything I could request from NARA, haha [20:27:01] there are only a few select documents I know would be really good for RTCC stuff [20:27:15] anything else is taking a chance if it even has anything useful [20:27:28] yep [20:27:45] also good that the NARA list keeps getting smaller [20:27:50] because we found other sources [20:28:18] but only someone private who worked at MSC at the time would have anything I want [20:28:23] if even UHCL doesn't have it [20:28:25] and they have a lot [20:29:31] very randomly down to branch internal memos [20:30:13] even NTRS is quite random [20:30:39] RTCC Requirements for Apollo 13: Earth Orbit Insertion Processor [20:30:47] give me anything else for Apollo 13, NTRS, anything else! [20:30:57] but no, just this one [20:31:15] well, aside from the restricted stuff that shouldn't be restricted [20:33:39] and switching topics completely, about Dons book. I really would like to try the development LGC version with Delta Guidance [20:33:44] Amelia it was? [20:33:47] there was another one [20:34:18] hahaha [20:34:29] uhh [20:34:36] I really don't think the DPS would like it though [20:34:45] DIANA? [20:34:48] could be [20:35:01] too much throttle changes through the erosive throttling region. But if you do it quickly it might be fine [20:35:10] we got so close on that program you're talking about though [20:35:19] its binder was reused for one of the simulation printouts [20:35:26] hahaha, damn [20:35:41] would be fun to try after reading his description [20:36:22] Tindall seems to also have liked it [20:38:49] Amelia was the name [20:39:11] Amelia 11 [20:42:22] and apparently we even got the padload for it, haha: https://www.ibiblio.org/apollo/Documents/LUM123_text.pdf [20:42:30] PDF page 2 [20:42:52] oh man [20:42:53] damn [20:42:59] doesn't even seem to need that many different constants [20:43:02] well that one is definitely lost to history sadly [20:43:06] if Don doesn't have it nobody will [20:43:40] Allan Klumpp probably came up with the guidance scheme, right? [20:43:44] oh yeah, true [20:43:59] Don hasn't talked to him in quite a while but I think as far as he knows he's still around [20:44:51] oh, interesting [20:48:52] but I doubt he has program listings [20:50:00] not really his area of expertise I would think [20:50:20] yeah [20:50:31] it's like you and me, haha [20:50:38] also totally unrelated: Scott Manley is here in our office today [20:50:44] haha [20:52:28] I can better deal with octal vs. decimal now [20:52:33] but still no desired to read AGC code [20:52:37] desire* [21:10:55] night! [14:15:59] good afternoon [14:18:23] hey [14:18:46] I think I found a SCOT for Apollo 13 & 17 [14:19:03] on the JSC search page [14:19:14] SPACECRAFT OPERATIONAL TRAJECTORY FOR apollo 13 ( MISSION H-2 ) VOL I ( VOLUME 1 ) MISSION PROFILE [14:19:22] SPACECRAFT operational trajectory APOLLO 17 * LAUNCH DECEMBER 6, 1972 C.S.T. * VOLUME I: MISSION PROFILE [14:20:40] we have the Apollo 17 one I think [14:20:48] or at least an amendment to it with just 29 pages [14:20:57] yeah [14:21:06] I am hoping these are the full ones though [14:21:17] I think I will request them [14:22:05] "It appears that there is one document in the list that I cannot locate: #41223, 3/11/70, Spacecraft Operational Trajectory for Apollo 13 (Mission H-2) Volume 1. We do not have the boxes on site so I am contacting JSC to see if it can be located." [14:22:24] so I did request that last year [14:23:17] this is what I request and got for Apollo 17: [14:23:24] 481156 10/30/1972 SPACECRAFT operational trajectory APOLLO 17 LAUNCH DECEMBER 6, 1972 VOLUME 1 MISSION PROFILE 080-44D [14:24:19] never got the Apollo 13 one [14:25:00] hmm 080-44D or 080-44B? [14:25:06] maybe they eventually got the document back from JSC and Lauren just forgot to contact me about it [14:25:59] oh [14:26:03] there is multiple ones [14:26:13] the weird thing about the 17 one is that it does not have the * beside it [14:26:30] I definitely requested and got: HSI-481156 [14:26:40] and not the other Apollo 17 ones [14:26:53] so they probably do have the full document after all [14:27:34] 481096 and 481170 might be the same, but not sure [14:27:42] they have the same date [14:27:47] and same report number [14:28:20] could be simply two copies of the same document [14:29:33] 481096 MSC-07197 08/18/1972 SPACECRAFT OPERATIONAL TRAJECTORY APOLLO 17 * LAUNCH DECEMBER 6, 1972 C.S.T. * VOLUME I: MISSION PROFILE APOLLO 080-44B [14:30:10] HSI-481156 has a date of 10/30/72 [14:31:32] yeah [14:31:32] I can ask Lauren how many pages its is too [14:31:35] that's the Amendment [14:31:44] 481156 is the one we have [14:32:12] so you could request either 481096 or 481170 [14:32:32] it will be about 300-400 pages [14:32:39] so I am thinking its not the same as 481156, so I am hopeful [14:32:51] not the same date* [14:33:12] I am not 100% sure how I decided what I request, but I probably looked at the dates and only requested the most recent one [14:33:15] 481156 [14:33:28] because it doesn't say it's only the Amendment and 29 pages [14:33:47] so either of the other ones is probably fine [14:36:09] in combination with 481156 of course, which has updated values for a few things [14:43:55] alright I sent for them [14:44:02] which one? [14:44:28] the 13 one I didn't get and one of the 08/18/72 Apollo 17 ones? [14:44:40] I included both the 17 ones and the 13 one [14:45:00] But I asked her only to send 1 of the 17 ones, if one of them is 300-400 pages [14:45:06] yeah [14:45:17] I am 99% sure the two Apollo 17 ones are identical [14:45:59] I just never went back after getting the Amendment document and looked if the original document was on there [14:46:26] was a while between requesting and getting it [14:51:03] I hate nothing more than doing a fix in a function that gets used a lot [14:51:17] it's for this bug: https://github.com/dseagrav/NASSP/issues/409 [14:51:35] and the function I need to fix gets used in TPI calculations, map updates etc etc [14:52:04] if I didn't do it properly then a lot more gets broken than fixed :D [14:54:19] lol I bet [14:54:44] is this issue something that would happen with the RTCC MFD as well? [14:55:57] yeah, general RTCC issue [14:56:00] got it fixed now [14:56:02] ... I think [14:56:11] but it was a rare case [14:56:30] but with the CSM orbit nearly circular when calculating a liftoff time, it would be random [14:57:54] in the case that he had the TPI point (orbital midnight) and the initial guess point were both close to 180° true anomaly [14:58:25] but one was just after 180° and one was just before it and that messed things up somehow so that it found the solution almost one orbit earlier [14:58:47] but now I am using a function there that will make sure the shortest way between two angles is used [14:58:57] so that hopefully should do it [15:00:12] must have been a rare case because I never encountered it [15:01:27] if I introduced new issues in that function I'll give it a proper overhaul not just a fix [15:01:39] but now I want to go back and work on the mission plan table again [15:06:07] I see the DKI is now compatible [15:07:16] I said it a few times already but I am very impressed with the mission plan table [15:07:23] adds so much flexibility [15:12:31] yeah, I think so as well [15:12:33] and more to come [15:17:30] will the SV page be compatible? Like for example, uplink a LM SV to the CSM after the lunar ascent page has been used to calculate a lunar ascent and can output an insertion SV, which the SV page can use to uplink to the CSM [15:19:35] I guess that will require the feature where multiple vehicles are supported by the mission plan table of one RTCC MFD instance [15:21:28] I think of that as quite a special case [15:21:56] I don't think there is ever any other uplink that includes a SV for after a maneuver [15:22:13] not entirely sure how I'll do that [15:25:13] in the long term I'll probably make the RTCC MFD as vessel independant as possible [15:26:52] yeah [15:27:12] that was a good idea at one time but it has developed away from that concept [15:28:52] btw meik84 had the great idea of making the DEDA work with the keyboard [15:31:39] with CTRL + numbers? [15:31:44] DSKY is Shift [15:33:02] yeah [15:33:28] would help greatly when say taking manual RR marks with the DEDA [15:34:21] for typing more quickly? [15:35:23] I'm not very familar with manual RR marks, haha [15:35:56] yeah basically [15:36:29] You have to look at the tape meter and then go back to the DEDA very fast, unless you have a large enough monitor to display both at once [15:37:05] ah, right [15:37:50] but even having both displayed on the screen, I think its more natural to use the keyboard for that procedure [15:43:43] looks easy to add [15:55:48] some default Orbiter key overlaps, but I can override those [16:38:58] I was curious about this: RTCC: Integrate TPI and TPF search into Lambert targeting [16:39:28] What does that mean? It will search for the TPI time based on desired light conditions? [16:52:49] there is no new functionality [16:53:31] there was the option to use "E=26.6" to calculate the T1 time for Lambert targeting based on elevation angle [16:53:50] that generated new state vectors and calculate the time from that [16:54:00] which of course would be incompatible with the MPT [17:29:41] new method is that you can input either a time or an elevation angle for T1 and it will keep track of the option used [17:30:02] and it won't use the elevation angle until you calculate the maneuver [17:30:12] so that way it's no MPT compatible [17:30:15] now* [17:30:45] for T2 you can input time, delta time from T1 or like Colossus and Luminary doing it, using a travel angle (usually 130°) [17:30:51] input method is WT=130 [17:46:55] ah, I see [17:47:38] I think on some pages you can use a code to put TIG at periapsis [17:48:44] I was trying to remember it for my PDI-0 calculation. Ended up just taking the periapsis GET from the orbit digitals display [17:51:43] yeah, I'll have to make a list of these codes and where they can be used [17:54:20] morning! [17:54:50] NARA was being sneakier yesterday than I thought [17:55:02] the guy who did the scanning didn't mention it in his email but he is out today [17:55:14] and apparently I guess that only he can process the payment because he did the scanning? [17:55:30] AlexB_88, those features are not really unrealistic, it just helps so that you don't have to write down a GET to input on another page [17:55:33] hey Mike [17:55:47] so more waiting it is, haha [17:56:36] AlexB_88, and with the orbit digitals page you should also be able to input a future GET and get apoapsis and periapsis time for that. not sure if I have added that feature yet. [17:59:38] ah yes, you can input GET of longitude [18:00:56] that as well [18:01:13] but also a GET and it will display the values as on the left column [18:01:21] guess I didn't add that yet [18:01:48] so that you can get apoapsis and periapsi GETs and location any time in the future [18:11:59] That will be quite handy [18:12:28] oh another email in my imbox... No no I dont care about Groupon Getaways 4-Star Canadian Rockies Resort... I want some SCOTs lol [18:15:21] hahaha I hate that [18:15:38] anxiously waiting for an email containing documents or something and getting something else [18:15:50] haha yeah [18:16:15] I am just hoping its the actual SCOT and not the amendment [18:17:42] it will be the actual one [18:17:55] there only was Amendment 1, which I got [18:18:05] and the date is two months earlier than that [18:18:08] I like your optimism ;) [18:18:26] I think it's quite clear, not sure what else it should be [18:18:33] of course it could be missing lots of pages [18:18:37] we've had that with others [18:18:38] But yeah I tend to agree the date gives it away [18:19:23] thewonderidiot, at UHCL there were 3 Apollo 17 SCOTs with identical names and last year I requested the one with the most recent date [18:19:36] many months later I finally got it and it was only 29 pages, Amendment 1 to the SCOT [18:19:47] and then you forgot about the others? :D [18:19:49] I had totally forgotten though that there were two others in the list [18:19:53] hahaha [18:19:57] so I never requested those [18:20:03] so probably the SCOT and then a couple of amendments [18:20:20] two from August with everything identical [18:20:26] I bet it's two copies of the same document [18:20:36] and the one we already have, from October, Amendment 1 [18:21:00] and Alex also today requested the Apollo 13 SCOT again. I originally did and Lauren said it was in a box currently at JSC or so [18:21:06] maybe it's at UHCL again now [18:21:25] great [18:22:02] after I get these SCDs tomorrow I will have one more request for 19 drawings for them [18:22:25] and then we'll have drawings for almost all of the parts used AGC and DSKY [18:22:41] awesome [18:22:43] minus one that they were unable to find this request, and whatever they can't find next time [18:23:15] the one they couldn't find this time was 2006291, which was a thermistor used only once, in the oscillator module [18:23:51] apparently it was quite fragile, and became hated enough that it got its own 2-paragraph section in the computer design review book, talking about how bad it was and that they really ought to replace it [18:24:03] I'm guessing that at some point MSC just deleted the drawing for the thing [18:24:52] haha, ok [18:25:18] we got so close to having every drawing though [18:25:21] just this one so far! [18:25:23] :( [18:27:46] I guess my equivalent goal is to get all Mission Planning and Analysis Division internal memos, haha [18:28:03] that sounds a lot harder :P [18:28:11] a few hundred per year [18:28:14] so all "MSC Internal Note No. 69-FM-77" type of thing [18:28:43] yeah I have... probably 50ish SCDs total to cover all of the AGC and DSKY parts [18:28:46] there are even division or branch internal notes which don't really count for these, so there is much more [18:28:59] and they are all in one place :P [18:29:14] well, NARA also has nearly all of these [18:29:37] aaaaand it is monetarily feasible for me to have all of mine scanned [18:29:42] https://archive.org/stream/NARASWSelectedApolloBoxes/NARA-SW-selected-Apollo-Boxes#page/n1 [18:29:45] yes [18:29:49] that's where you easily win :D [18:29:59] I already got maaaany from NTRS at least [18:30:24] those scanned first pages are mostly in the internal note order [18:30:37] starting with 67-FM-167 [18:30:49] I have to catalogue what I have a bit better [18:31:06] I do think I might be close to having 50% of them [18:31:38] oh man [18:31:41] that is a lot [18:32:17] yeah [18:32:29] some of the most interesting are missing unfortunately [18:32:48] and the percentage drops a lot starting with 1970 memos [18:33:58] that's where NARA is really the main source [18:34:21] and NTRS and UHCL almost stop having anything [12:36:16] morning [12:39:26] hey Alex [12:40:59] If you hadn't seen yet I posted a few shots of my 14 run: https://www.orbiter-forum.com/showthread.php?t=20&page=487 [12:42:42] yeah, good stuff [12:43:19] I'm not sure how closely you follow the last part of the Apollo 14 terrain model discussion [12:43:52] but reading the relevant Luminary memo, it seems possible that the LM would crash when the downrange error exceeds 7000 feet [12:44:01] so if you want to, you could try that with N69 [12:44:14] I'm not sure about plus or minus, haha [12:44:41] yeah I saw when you were discussing that [12:44:47] maybe ill give it a go [12:44:58] at least MIT seems to think that that could have happened [12:45:05] likely with the MSC terrain model that was flown [12:45:21] and the crash would happen in early P64 [12:45:29] into a mountain not far from the landing site [12:49:08] reading a bit more in the little MPT documentation we have [12:49:16] how it handles CSM vs. LM maneuvers [12:49:45] There is more mountainous terrain leading up to the landing site then after it [12:49:57] nice [12:50:08] should help me decide how to implement that [12:50:38] here is the terrain again: https://i.imgur.com/GsmtRuT.png [12:50:50] and the mountain in question is the very last one before the landing site [12:52:00] terrain goes from about -200 to 100 meters [12:52:09] I think that is the main issue there [12:52:50] and also the terrain model before that [12:52:58] Ill try a -8000 feet I gues [12:53:17] yeah [12:53:25] that moves the landing site uprange I think... [12:53:34] so the landing site would be closer to that mountain [12:53:45] right [12:53:57] and P64 might start you right ahead of it [12:54:29] 7000 feet was the threshold in the memo, so 8000 will be good [12:54:40] although the memo seems to confuse feet and meters a few times [12:54:49] or I did in creating this graph, haha [12:56:17] and the problem might also be a very high negative altitude rate at high gate [12:56:31] as the cause of a potential crash [12:56:53] caused by the MSC terrain model [12:57:10] in combination with the downrange SV error [12:59:39] alright, im testing this now [13:16:58] well, "crashed"... I definitely collided with the moon, but at a very nominal 2-3 fps ;p [13:17:49] could you identify that peak? [13:17:58] but yes actually [13:18:22] and it did seem to come close to it during P64, so I can see where the issue was [13:18:56] Its not a peak or mountain rather a "hill" leading down to the normal landing site [13:19:16] but definetly higher in altitude then the landing site itself [13:19:22] definitely [13:19:57] yeah, it's not really extreme terrain [13:20:28] the simulation that MIT did might have had other inaccuracies thrown it, not quite sure [13:20:29] So early to mid P64 it come much closer to the terrain then when landing at the normal landing site [13:20:45] Ill try a -10000 [13:20:46] I see [13:21:01] yeah, it also talks about one run using 11,400 feet [13:21:07] Because further back the hill is even higher [13:21:10] right [13:21:41] "One simulation - with a combination [13:21:42] of an 11,400 ft. downrange dispersion. Iff* dispersions in all other state variables [13:21:42] and measurements, and a slow pitchover at the start of P64 - crashed into a hill [13:21:43] midway in P64, " [13:21:56] Iff* meaning 1 sigma :D [13:23:46] the next step would be to change the terrain model back to what MIT was using [13:24:42] right because we are not using the exact same terrain model they were, right? [13:31:17] MIT was testing two terrain models [13:31:29] for the LGC [13:31:33] one they derived themselves from the reference terrain [13:31:45] in the memo that is called the "real terrain" [13:31:51] as good as they knew it [13:32:12] we know the MIT terrain model for the LGC from another Luminary memo [13:32:19] and that was what we have been using before [13:32:48] and at MSC they came up with the terrain model which was actually flown [13:32:56] or very likely that it was the flown one [13:33:06] and in this Luminary memo MIT did tests with both LGC terrain models [13:33:27] and came to the conclusion that the MSC one might be able to cause crashes, which MSC did not find in their simulations [13:34:13] you are right now using the MSC terrain model, the flown one [13:37:02] -11400 came very close to crashing [13:39:30] yeah, I guess with some other randomness thrown in, as they did, there is a chance of crashing [13:39:51] and of course MIT might not be 100% in the right with the argument with simulations were better, MSC vs. MIT [13:39:56] which* [13:40:13] but probably closer to the truth than MSC [13:40:33] their "real terrain" would still be quite inaccurate [13:40:47] yeah I weas just about to say [13:41:07] as it clearly was for Apollo 15, a few 1000 feet off in the slope up to Mount Hadley Delta [13:41:15] They probably had nothing close to what Orbiter 2016 terrain offers [13:42:19] yeah, I think just Lunar Orbiter photos and previous Apollo mission photos [13:42:28] not sure how much they could really do from the Earth [13:43:05] LRO was a real game changer [13:43:19] and that is a quite recent mission [14:27:04] Should the CDR/LMP status on the PAMFD ECS page be set to In Suit for EVAs? [14:41:35] yeah, I think so [14:41:55] but I don't think it matters, you would set the number of astronauts in the LM to 0 anyway, right? [14:44:01] thinking about it, if you don't have it in "In Suit" then you might leak some oxygen into the cabin during an EVA [14:44:13] also bad for depress probably [14:45:13] yeah that did happen actually [14:45:27] I left it to in-cabin and could not get the hatch open [14:45:37] then set it to in-suit and then the hatch opens [14:46:46] in suit also means that the suits are connected to the suit loop [14:47:02] although you probably should be able to shut that all off even without the PAMFD [14:47:48] Ryan would know [14:48:11] any news on the SCOTs yet? [14:51:44] nothing yet [14:53:04] So something weird happens during the post-eva procedures. When I turn both the SUIT ISOL valves back to SUIT FLOW, the CO2 indicator goes full scale high [14:54:29] it does drop back down but very slowly [14:54:37] that's weird indeed [14:55:24] also another oddity is before the EVA, you pull the SUIT FAN 2, SUIT FAN DP CBs [14:55:54] then select SUIT FAN - 2 and the ECS caution & H2O SEP comp lights should come on after 1 min [14:56:20] but neither the ECS light nor the H2O SEP comp lights illuminates [14:56:31] I don't know anything about that [14:56:40] but the crew is connected to some tank [14:56:43] come on Ryan, log on :D [14:56:50] and I wonder if that accumulates CO2 [14:57:00] which isn't transported away [14:57:20] depends on the PAMFD setting I guess [14:57:58] nothing should accumulate if there is no crew in cabin or suit though [15:02:27] was switching to suit flow before cabin repress? [15:02:46] hmm [15:02:49] shouldn't matter [15:02:56] after [15:03:01] the CO2 is measured in the suit loop [15:04:02] Maybe time accel during the EVA has something to do with it [15:04:59] maybe [15:27:39] plane change seems to be 1 hour off from what I put as TIG [15:28:07] I remember 14 being the most problematic with this [15:28:25] flight plan says 118:09:40 and thats what I put for TIG, but the solution is at 119:12 or so [15:28:53] plane change targeting still hasn't been revised from a long time ago [15:29:15] I wanted to for Apollo 11, but it all calculated right, so I never worked on it again, haha [15:29:27] Apollo 11 MCC* [15:29:55] DV is not bad like 380 fps or so. If I put in a TIG of 117:45 then that seems to force it to the correct location, TIG at 118:12:44. DVY is very close to the flight plan, -355.7 But the issue is that DVX is -10690.6 lol [15:31:39] oh right [15:31:42] that fun thing [15:33:01] I'll have to look at it again [15:33:10] I really have nothing on that plane change targeting [15:33:18] from any RTCC documentation [15:33:31] I think what I based ours on was a 1967 GSOP [15:33:41] so the CMC was planned to have a program for this [15:34:35] the original P33 [15:34:43] P32 was LOI guidance [15:36:07] do you think with the calcualtion I did at 118:12:44, with the correct DVY (-355.7) but with the -10960.6 DVX, if I take the PCT (plane change/time) program of the GMP and use the TIG and then try and adjust the DW to get DVY to -355.7, maybe that would work? [15:37:18] *TIG was 118:12:44 on the PC page [15:37:27] it could, yes [15:37:47] I have some info on how the Apollo 15 plane change was calculated [15:37:54] at least then I can do the plane change at the correct TIG [15:37:57] it seems too easy in a way, haha [15:38:03] and not one hour late [15:39:17] so you have two opportunities each orbit for the optimal plane change [15:39:28] 0.25 revs before the landing site or 0.75 revs [15:39:49] I think the RTCC MFD always uses the 0.25 revs one [15:39:54] plus N of course [15:39:59] 1.25, 2.25 and so on [15:40:09] depending on the initial guess [15:40:12] time [15:40:47] the main challenge is that both the landing site is rotating away and the CSM orbit is precessing [15:41:44] right [15:42:10] so what Apollo 14 did was probably simply the N + 0.75 orbits before flying over the landing site [15:42:13] instead of 0.25 [15:42:16] for some reason [15:43:17] On the Plane Change page, is the TIG output from a calculation adjusted for the burn duration? Is it non-impulsive? [15:43:38] I think so [15:44:17] So I could not really use the TIG if the burn had 10700 fps DVX component probably [15:44:29] I mean I could not use the same TIG in the GMP [15:45:19] yeah, I think that is right [15:46:29] I think I will just use the solution that is one hour late [15:46:46] 0.25 [15:49:20] do you have "Apollo15_Navigation_Results.pdf" ? [15:50:14] PDF page 205 has some info on plane change targeting [15:50:27] they seem to come up with a target latitude to fly over [15:50:36] that is the used to target the burn [15:50:40] then* [16:43:15] morning! [16:43:34] hey Mike [16:43:56] hey [16:44:41] Alex nearly made Apollo 14 crash with the MSC terrain model and a downrange error in the state vector! [16:44:45] indy91 good news! [16:44:58] both docs are 360 pages [16:45:02] as expected [16:45:07] which both [16:45:09] 17 and 17? [16:45:11] or 13 and 17 [16:45:46] all 3 [16:45:50] ah, good [16:45:53] so the 13 one is back [16:45:56] so she gave me 1 0f the 17 and 13 [16:46:06] and I'm sure the 17 ones are identical [16:46:14] they just ended up having two copies of it [16:46:19] scan already done? [16:46:47] ah, very good [16:47:30] well I guess I had my part in bringing the 13 one back to UHCL, haha [16:50:30] do we now have all the Mission Profiles? [16:51:00] btw, why did you think about the SCOTs again and that we didn't have all of them yet? Just randomly? [16:51:10] or did you want to look up something specific [16:54:44] yes we have them all for 12-17 [16:55:02] I just new we were missing those ones so thats why I requested them [16:55:05] and 10 [16:55:12] not 11 though [16:55:19] but also I want to re-create the PTC REFSMMAT [16:55:24] right [16:55:37] we probably have the latest Apollo 9 one, but it's not for the right launch day [16:55:45] I think there never was an update version [16:55:48] updated* [16:55:50] but not sure [16:55:54] we also have 7 and 8 [16:55:58] so basically all but 11, haha [16:56:47] Apollo 17 does the LOPC 2.75 revs before LM ascent [16:58:10] oh almost crashing is fun :D [16:58:53] it's not as bad as MIT thought, at least not with only a downrange error [16:59:02] but probably worse than MSC admitted [17:07:24] I have some UHCL documents to request as well, which might have some RTCC targeting numbers for Apollo 10 and 13 [17:08:54] oh nice [17:09:28] for 13 there are documents with the same name from before and after the flight [17:09:30] REAL TIME SUPPORT OF THE APOLLO 13 MISSION [17:09:34] the Apollo 17 SCOT says DOI-2 lowered perilune to 40000 ft [17:09:58] Apollo 17 had a planned DOI-2, right? [17:10:30] yep [17:10:42] I think I've seen that not a long time ago [17:10:52] probably helps with the trajectory [17:11:00] I hope it did, DOI-1 perilune is 84000 feet :D [17:11:02] it should have the fairly normal altitude at PDI then [17:11:16] with a not so usual altitude rate of course [17:12:47] APOLLO 10 (F) MISSION OPERATIONAL TRAJECTORY SIMULATOR DATA PACKAGE FOR MAY 18 LAUNCH [17:13:06] the Luminary memo about the Apollo 14 terrain model quotes this type of document [17:13:17] the 14 one has the "real" terrain model [17:14:00] haven't found the 14 one anywhere though, just this Apollo 10 one [17:54:28] hmm, so I got the new SCDs finally. the new DSKY alarm part number does cover the command module version, but not the LM version [17:54:37] so there must be a third part number for the one with ALT and VEL lights [17:54:43] I wonder where I can find that number... [17:55:56] what's the date on those? [17:56:03] LM didn't have ALT and VEL lights until Apollo 11 [17:56:43] and then even another version with NO DAP and PRIO DISP, haha [17:58:32] nah, I'm pretty sure that they just used stickers for NO DAP and PRIO DISP [17:59:01] ah yes [17:59:02] I don't know if I scanned it, but one of the memos I found in one of Don's boxes was a note about those lights [17:59:16] somebody writing to inform that he had successfully managed to turn on the unused lights on a LM DSKY [17:59:18] what's different for ALT and VEL then [17:59:37] well, this drawing doesn't even have the bottom four lights at all [17:59:43] hmm [17:59:45] I see [17:59:45] so there is a big physical difference with their addition [18:00:58] maybe one failed [18:00:59] I hope one failed [18:01:33] a light? [18:01:59] or anything :D [18:03:23] some of the CM ones certainly failed [18:03:56] a bunch did, even [18:07:48] hm, but no sign of any LM module failures [18:07:51] seems unlikely [18:25:31] indy91: super dumb question [18:25:52] (I don't have enough time to properly look it up, sorry) [18:26:02] haha, sure [18:26:27] what drives the 8-ball? is there any real AGC->8-ball communication? could we make use of one if we had a working AGC and simulation? [18:27:07] the FDAI gets the data from the IMU [18:27:10] not even through the CDUs [18:28:16] so we'd need a totally different thing [18:28:40] in the case of the LM, it goes through another system, the GASTA, to convert it from IMU angles to "astronaut relative" or whatever, haha [18:28:54] huh [18:28:59] but in the CM it's just direct-to-IMU? [18:29:44] yeah, IMU resolver voltages [18:29:56] great, thanks! [18:30:13] sure [18:30:39] AGC can drive the error needles of course [18:30:46] that is through the CDU error counter [18:30:49] counters* [18:30:59] but attitude works without the AGC [18:31:06] oh interesting [19:57:34] night! [12:18:49] good morning [12:21:44] hey [12:29:01] i just have a question about performance [12:29:56] i am trying some scenarios from my last 11 mission and when i go to 60x i get lags but when i run orbiter ng as administrator the problem goes away do you know why this would be happening [12:31:17] not really, no, but it's interesting [12:31:25] I also get performance issues, on the CSM main panel [12:31:49] yeah i just have not done some nassp in a while and i would like to get back into it [12:32:04] CPUs hate the CSM main panel [12:32:28] although at 60x the Virtual AGC might start having an effect [12:32:47] i can run 60x fine in the LEB with no lag at all [12:33:01] ok, then I would do just that [12:33:26] no need to be on the main panel when in time acceleration [12:34:46] before we release NASSP 8 we have to do some performance improvements [12:35:00] I just know nothing about that topic and have no idea where to start [12:36:56] also for my next 11 mission i will be making a rendezvous series for Youtube [12:37:15] sounds good [12:58:21] hey [12:59:22] hey Alex [13:00:37] Going to fly ascent rendezvous today, give the ascent PAD a good test [13:01:32] working on CSM+LM support for the MPT [13:01:53] the tricky thing is that when the CSM does a maneuver while docked then that also has to influence the LM trajectory [13:02:25] so how I have it set up right now is that when in the Config menu the vehicles are docked, then that forces the trajectory of the docked vehicle [13:05:47] makes sense [13:06:00] I guess when docked, both vehicles get the same postburn SV [13:06:45] yes [13:06:55] keeping track of the mass is tricky though [13:07:05] mass is saved as part of the state vector [13:07:19] so when the other vehicle does a maneuver then the mass has to be kept constant [13:08:22] I see [13:08:38] good test case is: [13:08:41] CSM MCC-2 [13:08:43] LM LOI-1 [13:08:46] CSM LOI-2 [13:08:55] or whatever the one alternate mission wants [14:38:49] for the liftoff page and ascent page, must the configuration page be set to Ascent stage for the ascent simulation to work correctly? [14:39:21] I guess the ascent simulation page calculates based on the ascent stage only anyway [14:40:59] I think that is just for Maneuver PADs calculated before staging [14:41:04] but are supposed to use the APS [14:41:12] Ascent PAD shouldn't need that [14:41:34] hmm, LM LOI-1 [14:41:41] the LM doesn't have enough DV for that :D [14:41:43] not even close [14:42:09] so why is that an alternative mission for Apollo 11 then... [14:42:27] must be a dispersed TLI and the CSM burning enough propellant so that a DPS LOI becomes feasible? [14:44:25] oh [14:44:39] they wouldn't use 170NM apolune for the DPS LOI [14:47:07] but much higher [14:48:22] interesting [14:48:39] depending on the SPS DV left [14:48:51] well, how much CSM mass is gone really [14:49:01] Apollo 10 Alternate Mission Plan has more details [14:49:22] it has an example for a dispersed TLI and the CSM burning half the SPS propellant for midcourse corrections [14:49:37] DPS LOI-1 would then be an 60x700 orbit [14:49:41] and SPS does LOI-2 [14:50:08] followed by a photography and landmark tracking mission [14:50:19] and the SPS should then have enough left to do TEI on its own [14:52:51] so much for that example mission plan, haha [14:53:20] I think a PDI0 would be better [14:53:36] as a test of the new MPT calculations [14:53:43] because it needs to take into account the CSM circ burn [15:08:15] there isn't even a PDI0 on Apollo 16, haha [15:08:20] did they drop that again? [15:09:15] Apollo 15 still has one [15:09:18] Apollo 16 and 17 not [15:23:40] Do you want my Apollo 14 PDI-0 scenario? [15:23:59] nah, I'm testing Apollo 16 No PDI1+12 instead [15:24:37] seemed to work all very well, just the TPI time calculated by the DKI was off [15:24:44] so I am pretty close to getting it all to work [15:33:08] sounds awesome! [17:13:34] morning! [17:17:25] hey [17:22:56] what's up? [17:24:20] still working on the mission planning table [17:24:31] getting mixed CSM and LM maneuvers working is tricky, haha [17:30:47] ah, and I was chasing a bug that turned out not to be a bug, just a bad input [17:41:51] hahaha [17:41:53] nice [17:43:49] seems like this "worst case" is working right [17:44:16] it has docked maneuvers (updating the trajectory of both CSM and LM, but not LM mass), CSM alone maneuvers and a whole bunch of LM alone maneuvers [17:47:23] next step would be following the Apollo 9 rendezvous planning "cooking recipe" and see if that can now be done with the RTCC MFD [19:11:25] indy91, sounds impressive [20:13:58] DVY at insertion was only 2.5 fps this time [20:14:10] I think it really helps to use the stars on the checklist [20:15:43] Hey [20:18:28] .tell indy91 Question about the Apollo 11 separation maneuver, the mcc calculates a -2.5 dvz with +x thrust, yet the flight plan calls for a +2.5 dvz with -x thrust [20:22:02] hey lotisully86 [20:22:11] Hey [20:22:21] what do you mean calculates [20:22:28] on the Maneuver PAD? [20:22:34] Yes [20:23:45] well in reality they barely got a Maneuver PAD [20:23:50] 098:53:19 Duke: Roger, Mike. SEP PAD, RCS/G&N: Noun 47 and Noun 48 are NA; Noun 33, 100:39:50.00; Noun 81 is NA. Roll; 000, 007, 000. Rest of PAD is NA. [20:25:06] but you are right [20:25:16] looks like it is missing a line of code [20:25:31] opt.directiontype = RTCC_DIRECTIONTYPE_MINUSX; [20:25:38] I think that's all that needs to be added [20:27:38] DV should still be 0 0 -2.5 to get into the right attitude [20:27:43] I think... [20:29:33] From what I’ve figured it should be +2.5 dvz auto maneuver to the burn attitude, start p41 by bass that auto maneuver and burn -x thrust [20:29:53] Bypass* [20:30:19] P41 will only put you in a +x thrust attitude [20:31:33] hmm [20:31:54] that doesn't seem to be what the CSM Solo Book excerpts want [20:32:12] that loads DVZ -2.5 in P30 [20:32:23] and then you can use the auto maneuver [20:32:24] I wonder why they didn’t just use p47 if the only pad variables read up were gimbals and tig [20:32:35] because you can use P41 and auto maneuver [20:32:45] you just don't null the 2.5 residuals, but instead burn it to 5.0 [20:33:38] That’s true [20:34:48] night! [20:37:17] that is the procedure used. The CSM Rendezvous Procedures document has some CMP Solo Book pages with more detailed procedures for the CMP [20:37:55] and when I use the -X thrusters calculation method then the attitude isn't right [20:38:13] Huh I must have missed that I’ll have to go thru it again [20:38:40] so the Maneuver PAD is basically calculating the wrong maneuver [20:38:46] but the DV for P30 and the attitude is right [20:38:47] Is that the mission g rendezvous procedures? [20:39:16] yeah [20:39:17] https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19700025402.pdf [20:39:36] starting with PDF page 34 [20:39:41] that is pages from the CMP Solo Book [20:39:51] the Checklist MFD should have the same procedures [20:40:09] not sure though if that has been updated [20:40:27] If rcflyhokie doesn’t mind I can try updating some of the checklist mfd [20:42:54] I'll talk to him when he is here the next time. I think he was still flying Apollo 11, not sure how far he got. He probably has some local changes to the checklists as well. [20:43:32] good night! [20:43:51] Cool well maybe I could start on 12 or another mission [20:44:00] Night! [16:27:52] hey [16:40:58] morning! [16:41:55] what's up? [16:42:19] I sent in my last big request for drawings to NARA [16:42:23] 23 more [16:42:32] bye, bye $$$ [16:42:39] haha [16:42:51] it's only a few hundred total for all of the drawings I think [16:43:04] worth it to have them before this upcoming trip [16:44:51] AGC related trip? [16:46:04] yep, 9 days with the AGC, along with three experts in old computer restoration [16:46:27] we're going to be able to get a ton of work done [16:46:47] oh, awesome [16:47:12] I fly out two weeks from tomorrow :D [16:47:24] lots of AGC trips, haha [16:47:26] expect many pictures [16:47:53] I will [16:48:18] my usefulness starts very late in the process [16:48:41] veeeery late [16:49:53] hehehe [16:51:04] what work do you plan to get done in these 9 days? [16:51:14] as much as possible [16:51:32] there is some small probability that we will begin trying to execute instructions or small programs [16:51:46] but it depends on how much works [16:51:49] and how long testing it all takes [16:52:02] oh wow [16:52:12] so maybe actually powering the thing on [16:53:02] hey guys [16:53:11] hey [16:54:28] just about to fly TEI [16:54:52] I suspect your LOPC change the orbit in a way that's not so good for the TEI DV [16:55:30] hmm its not too bad actually, DV is actually less then the flight plan says [16:55:39] ah, ok [16:55:49] had they dropped the 40° inclination restriction yet? [16:56:36] actually sorry, not true its just a tad more: flight plan DVT: 3450 fps, mine: 3399 fps [16:56:37] according to the SCOT, no [16:56:48] so it's 40° ascending [16:56:51] erm no it is less [16:56:59] cant count [16:57:11] that's a lot of DV [16:57:31] yeah [16:57:34] seems unusually high for TEI [16:57:40] yeah 40 ascending [16:57:51] Apollo 8 had like 3600 ft/s but that was a return 24 hours earlier [16:58:07] it has a lot of DVY [16:58:08] I guess you can always downgrade if you spent more DV before TEI than planned [16:58:12] ah, right [16:58:16] 1460 fps [16:58:53] 11° plane change [16:58:55] and I did try calculating a slow TEI, it would of been 300 or so fps [16:59:00] 3000 [16:59:19] good to have that reserve [17:00:38] Apollo 15 and later don't have the 40° restriction anymore [17:01:02] for some reason the maneuver pad on RTCC MFD does not give SET STAR and R,P,Y ALIGN values [17:01:13] just says N/A 0,0,0 [17:01:17] oh wow [17:01:19] that is rare [17:01:28] I have never seen that, thanks for testing that it works :D [17:01:42] there are 3 sets programmed [17:01:50] and it checks if the stars are available [17:02:09] the sets are very spread out, so it's very unlikely that all of them are unavailable [17:02:49] but it is possible [17:03:18] I comfirm that the maneuver pads for the previous maneuvers are still working and giving set star values [17:03:31] so yeah, probably just an unlucky attitude [17:03:47] plus the Moon in the way of probably 2 out of 3 sets [17:04:07] no, only that, it doesn't depend on burn attitude [17:04:10] just REFSMMAT [17:04:23] right [17:04:37] there is a default set with the brightest stars [17:04:45] and then a north and a south set as the alternatives [17:05:03] I think I got that from the AOH [17:05:13] I wonder what the real TEI Maneuver PAD said [17:06:30] the calculation for those stars isn't using the time parameter you can use for e.g. the sextant star check [17:06:40] that should probably be changed [17:07:15] but if such a situation would occur during an actual mission, then they would have gotten a comment "not available after TIG minus 10 minutes" or something like that [17:09:02] makes sense [17:10:49] haha [17:11:03] 05 23 38 08 CC: Okay. P30 purpose, good-bye LM. [17:11:09] I wonder which burn was that :D [17:12:00] their TEI-34 PAD had: Sirius, Rigel [17:12:06] the attitude is interesting [17:12:19] the burn attitude that is, not GDC align [17:12:20] 180, 000, 000 [17:12:33] yeah [17:12:43] so it's a preferred alignment, but then rolled [17:12:56] I have 180,356,002 [17:13:44] which is almost the same [17:13:58] I just calculated a normal heads-up P30 REFSMMAT [17:14:05] yeah [17:14:08] and then selected head-down in the maneuver padd [17:14:27] fixed gimbal angles working against you [17:14:31] SPS* [17:15:07] I guess in reality they could actually calculate the REFSMMAT as a P30 head-up w/180 roll or whatever] [17:15:44] yeah, yet another option for that [17:19:28] you could probably input any desired IMU angles for the burn [17:20:25] actually, I might rework it that way [17:21:24] it would take TIG and DV as before, and also heads up/down [17:21:34] and then a desired IMU attitude [17:21:49] so it could be 0/0/0 or 180/0/0 or 180/180/0 or anything [17:22:03] that should then cover all the previous options we had as well [17:22:40] I think that is how the RTCC did that [17:22:47] there are some pages about: [17:23:00] "IMU Alignment Locker Maintenance Element (CSM/LM)" [17:23:27] has a list of REFSMMAT types it can handle [17:23:36] Deorbit is a separate one there though [17:25:29] sounds like a good way to do it [17:25:57] btw I am looking at the REFS from attitude page, how does that one work? [17:26:17] I cant really find a way to change the attitude on the page [17:26:32] right, it takes an attitude from the VECPOINT page [17:26:37] oh [17:26:41] only the hatch alignment I think [17:26:54] for Apollo 9 [17:27:06] that page calculates the attitude for that with the current REFSMMAT [17:27:40] and the "REFS from Attitude" option then calculates a new REFSMMAT for that specified attitude which will result in 0/0/0 IMU angles [17:27:52] I it possible t oinput angles maunally? [17:27:56] input* [17:28:06] not right now I think [17:28:46] wouldn't help with your TEI REFSMMAT [17:29:58] it's interesting how the RTCC really handled REFSMMAT [17:30:11] it could store a handful of them at the same time [17:30:29] Current, Previous Current, Manual Entry, Telemetry, Maneuver, Optical Sighting, Local Vertical, Deorbit [17:30:46] that's for the CSM [17:31:27] I was thinking: Find the heads-down TEI angles from the current REFSMMAT (180,109,026 on the maneuver pad) then input the angles on the REFS from attitude page but with roll = 0 so 000,109,026 [17:32:06] don't think that will work [17:33:03] of course I am just pondering what I could of done... I am proceeding with the TEI I already calculated before with the slightly off REFSMMAT [17:34:17] in 3 dimension just changing the roll wouldn't work [17:34:24] right [17:34:55] I'll add an attitude input for the REFSMMAT page [17:35:44] tomorrow I should be able to get the MPT update done, then I can work on something else [17:36:08] getting sick of the MPT I take it :p [17:37:04] the CSM/LM and docked/undocked thing really added a magnitude of complexity, haha [17:37:36] I don't like how you need to switch around the vehicle configuration right now [17:37:39] yeah, you were saying [17:37:47] well worth it though imho [17:37:56] like, from CSM/LM docked to CSM if you want to calculate an undocked maneuver [17:38:23] right [17:38:49] if you switch back to docked again then it will suddenly have the LM trajectory attached to the CSM [17:39:07] while the LM previously might have been somewhere else [17:39:16] that is what the user can do wrong right now [17:39:30] not sure if there should be any protection against that [17:39:54] but this shouldn't even be done anyway [17:40:01] why would you plan something like that [17:41:25] in the future lots of maneuver calculations are transferred to a maneuver planning page where you will then choose the vehicle configurations [17:41:31] that will make it less messy [17:41:51] yeah [17:43:02] very few maneuver pages should be doing the finite burntime compensation on their own [17:43:06] only TLI and LOI really [17:43:34] TEI maybe? [17:43:54] don't think so, no [17:44:20] because LOI can be so long it already needs a bit of a special function to do the finite burntime compensation properly [17:44:24] TEI is never that long [17:44:32] right [17:44:32] well, with the DPS maybe :D [18:03:31] whew, national archives got back to me with the scans [18:03:35] 234 more pages to process [18:03:47] they couldn't find two more [18:04:05] 1006327 (an inductor) and 1006363 (a transistor) [18:04:43] so only three missing SCDs total across the AGC and DSKY combined [18:05:43] that's still unfortunate, but I guess as good as we could hope for [18:13:54] 62 out of 65 drawings isn't bad at all [18:14:11] 95% [18:14:25] the transistor is kind of a bummer though [18:19:54] although on the other hand I think it's only used in the DSKY electroluminescent power supply [18:20:02] which we don't have and probably wouldn't use if we had it [18:32:52] right [18:33:12] haha Antares's lunar impact did not quite go as expected [18:34:01] It ended up hitting the side of a mountain, which deflected its trajectory upwards and up to an apogee of 127 NM [18:35:00] some pieces of it might have done that [18:35:29] So pretty sure the post impact burn trajectory was good, but Orbiter 2016's collision simulation obviously does not take the actual break up into account [18:35:54] yeah [18:36:06] that's up to the vessel simulation [18:36:23] I only know that the DGIV simulated breaking and burning up [19:12:54] I think Apollo 14 is quickly becoming my favorite mission [19:14:22] One of the reasons being there seems to be much less long periods with nothing happening. For example after ascent, TPI and docking you go right into TEI preparations. No waiting fussing around in lunar orbit for many orbits like the later missions [19:15:45] I thought the same about 11 [19:16:06] 10 has a whole day just doing landmark tracking, before TEI [19:16:13] not super exciting after a while [19:18:21] and on Apollo 16 they returned home a day earlier [19:18:31] than planned [19:18:36] with another liftoff time update to keep to the flight plan [19:20:01] what was the reason again? [19:21:01] the TVC issue that delayed the landing [19:21:26] didn't want to wait for it to fail in lunar orbit after the successful mission [19:21:40] fail completely* [19:21:58] so they returned home soon after lunar ascent [19:40:03] I did not know they actually came back to the CSM before attempting PDI [19:40:20] as the CIRC burn is where the TVC issue began [19:40:29] or just before the CIRC burn [19:40:56] yeah [19:41:15] they added those really weird looking charts then for Apollo 17 for that case [19:41:37] in the LM Rendezvous Charts [19:42:17] because they had some trouble getting back [19:45:14] there is a detailed account of that in one of my favourite documents on NTRS, "History of Space Shuttle Rendezvous" [19:45:40] https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20110023479.pdf [19:45:59] starting with PDF page 46 [19:48:57] and looks like they had no pad to get back to the CSM (PDI-0) [19:52:40] oh, I just realized that [19:52:53] one rev before PDI the circ burn hasn't been done yet [19:53:46] so that is why PDI0 is nonsense for Apollo 15 and later [19:54:11] Apollo 13 and 14 flight plans do the circ burn 1.5 revs before PDI [19:54:18] Apollo 15-17 0.5 revs [19:54:23] am I seeing that right? [19:55:36] so PDI0 would be a mini football rendezvous [19:55:39] like Apollo 16 did [20:00:00] hmm I think 15 has a PDI-0 [20:00:35] pretty sure 15 is like 13 and 14 [20:11:55] ah yes [20:39:29] night! [11:14:13] good morning [11:14:20] just started 11 now in LEO [11:18:00] hey [11:18:01] you seem to be flying Apollo 11 quite often :D [11:18:16] yes [11:18:25] it's of course the one i am most familiar with [11:18:37] thats because its the only full mission i have flown [11:21:01] just curious what are you working on right now? [11:23:25] mission planning table [11:23:31] that is a thing that the real RTCC had [11:23:47] very nice [11:23:49] right now you can't do some things with the RTCC MFD that the MCC can do [11:24:01] which require some trajectory in the future [11:24:15] like planning a rendezvous with the right lighting for TPI [11:24:30] not sure if i have asked you this but will there be a scenario for the alternate launch dates for 11? [11:24:48] haha, those already exist! In my local copy [11:24:59] but they aren't 100% finished yet [11:25:25] I can update them today I think, let's see if I can get them into a releasable state [11:25:39] the planned alternate launch dates were July 18th and 21st [11:26:14] with different landing sites of course [11:29:01] the flight plan has some info on those [11:29:18] and it's unlikely that the MCC will work with it. It might after a bunch of tweaks. [11:30:32] I think I can at least get the July 18th done today, no promises [11:31:35] would there be some numbers in the rtcc? [11:31:52] hmm, right, that is another issue [11:32:13] the initially loaded numbers wouldn't be right [11:32:24] for e.g. the translunar MCCs [11:35:06] 2 days later the Earth-Moon geometry shouldn't be that much different though [12:29:55] morning [12:36:31] hey [12:42:14] whats up? [12:45:43] did what I hope are the final MPT changes for this update, just needs a bit of testing [12:48:32] nice [12:48:45] I should finally finish Apollo 14 today [12:49:17] took much longer to do the return then the 1st half [15:24:30] ok, MPTtest has been successful [15:24:34] MPT test* [15:24:43] AlexB_88, I'm sure you will find lots of bugs anyway :D [15:25:28] oh I will try my best (sorry) [15:27:50] pushed [15:29:07] awesome [15:32:00] the maneuver code has changed a bit [15:32:10] first digit is C or L for CSM or LM [15:32:17] then the number of the maneuver, 1, 2, 3 and so on [15:32:22] and then the maneuver type, e.g. TPI [15:32:49] in the real thing it also had letters for guidance option, X for External Delta V and others for AGS or manual or so [15:50:06] so selecting the vehicle config on the configuration page is what decides the post burn SVs of each vehicle? [15:51:13] it decides if a CSM maneuver takes the LM with it [15:51:23] and vice versa [15:51:59] because even a CSM burn changes the LM trajectory if they are docked, of course [15:52:15] I can across this issue when I wanted to calculate a rendezvous from before LOI-2 [15:52:27] suddely I was thinking "oh wait" [15:52:30] came* [15:53:21] so the vehicle config should be in the same state as you want the calculated maneuver to be [15:53:47] I se [15:54:05] oh nice, the GMP now works with the MPT [15:54:23] GPM [15:55:06] yep [15:55:42] and all the rendezvous calculations should take all CSM and LM maneuvers into account [15:55:55] great [15:55:57] they use the latest state vector from the table [15:56:02] state vectors* [15:56:21] I think most maneuvers are now compatible with the MPT, correct? [15:56:37] and the MPT and the flag for it (active and inactive) are now in shared memory [15:56:51] yeah, most that would ever need the MPT anyway [15:59:04] I guess removal of the LOI-1 w/mcc page and the REFSMMAT pages are next to make compatible with MPT [15:59:12] yeah [15:59:20] REFSMMAT will need a few changes [15:59:58] because it used to (and still does) a few calculations itself for taking a maneuver into account [16:00:31] I guess all the MCC buttons on the various REFSMMAT calculation pages will be no longer needed [16:00:33] and if I remove that then the MCC doesn't know what to do anymore, haha [16:00:42] ah, right [16:00:58] so I have to give the MCC a MPT as well or find a similar solution [16:01:07] that has to be the order really [16:01:18] do a bunch of MCC changes, then the REFSMMAT page then the LOI-1 w/ MCC [16:01:36] right [16:03:10] ok, for a test I will now calculate PDI-0 from the LM, before the CSM CIRC burn is performed (but with PDI-0 taking into account the CIRC burn) [16:05:06] yeah, then first you need to calculate the circ burn in the CSM [16:05:44] ah ok [16:06:05] So I need to calculate each burn inside their respective vehicles [16:06:09] yeah [16:06:11] ok [16:06:20] that probably won't be necessary at some point [16:06:25] but still right now [16:06:42] I dont think its that bad to have to do that anyway [16:06:53] just have to switch around [16:06:57] right [16:07:03] I've done a similar test with Apollo 16, about as complicated as it gets: CSM DOI, CSM CIRC, LM No PDI+12, CSI, CDH, TPI [16:07:04] CTRL-F3 [16:07:08] yeah [16:07:32] did you end up landing yet? [16:10:35] no, haha [16:10:45] probably will continue from the pre LOI scenario [16:16:36] so I see the MPT active status is in shared memory, that works well [16:17:03] Could making also things like liftoff MJD, RLS be in shared memory too? [16:17:46] like when you hit the Update Liftoff MJD in the CSM, then you switch to the LM and you wouldnt have to hit that button again [16:20:10] yeah, that makes sense [16:20:11] TLAND [16:20:17] and probably a few others [16:20:24] landing site coordinates [16:20:27] yes [16:20:36] easily done [16:20:42] launch MJD, RLS, TLAND [16:20:53] probably not REFSMMAT [16:21:15] yeah, REFSMMAT is vehicle specific [16:21:22] and not always the identical one is used [16:21:31] well almost always, just not for the Apollo 9 rendezvous :D [16:22:51] at some point I'll add the REFSMMAT management as it worked in the real RTCC [16:23:10] I wrote about the types of REFSMMATs it was all storing at the same time [16:24:20] mission parameter can probably also be shared [16:25:13] alright 1st test looks good [16:26:49] hmm, mission number is tricky [16:27:02] it derives that from the vessel name [16:27:36] so it's not really vessel independant [16:27:52] hmm [16:27:56] that's a general issue [16:27:59] So I calculated CSM CIRC from the CSM, then the PDI-0 from the LM. The burn solution matches the original PDI-0 pad I had calculated when I was at that point in the mission (I had calculated it after the CSM CIRC maneuver of course) [16:29:56] so now with the PDI-0 solution on the MPT, I could theoretically get a CSI, CDH and TPI pad out of it if I wanted to, correct? [16:30:27] yes [16:31:04] nice [16:31:13] not they they got that in reality [16:31:39] they just got the CSI and TPI TIGs which are part of the PDI-0 pad [16:31:41] no, but they plan for it [16:31:43] get DVs etc [16:31:49] but they could* [16:32:06] ah, I know what to do. When a RTCC MFD is opened for the first time in a session it will derive the general parameters from the vessel that was used to open it [16:32:17] like mission number [16:32:42] of course afterwards it will be overwritten with saved parameters from the scenario, if it was open [16:33:58] the global state doesn't need to save the initial vessel, just use its name for getting the mission spcific numbers [16:35:45] I think I may have found one issue [16:36:53] the PDI-0 burn solution looks good, so I proceed to calculate a maneuver pad from it, and it all looks good except for the HA which should be around 137 NM, is shown as 219.7 NM [16:37:25] but everything else on the pad is good, including HP (7.8 NM) [16:37:46] hmm, ok [16:38:08] what about the DV? [16:38:40] exact same as my original PDI-0 pad... +98.1, 0, +1.0 [16:38:41] does the DV correspond to 219.7 or more like the 137NM [16:38:45] ok [16:39:02] it corresponds to the 137 NM one [16:39:02] at which point are you calculating this [16:39:05] after DOI? [16:39:13] yes [16:39:16] but before CIRC [16:39:21] did you calculate the circ burn docked? [16:39:34] basically shortly after LM separation [16:39:40] no undocked [16:39:44] CSM only [16:39:47] ok [16:40:04] I have an idea [16:40:11] it might be getting a post burn SV [16:40:29] and then it calculates the trajectory for the Maneuver PAD taking the burn yet again [16:40:39] so basically twice [16:40:41] ah that would make sense [16:41:07] that was a thing I had fixed before, maybe I re-introduced it by accident when changing to the CSM and LM logic [16:42:24] I think this might be a bug for the first burn of a vehicle only [16:42:25] the PDI-0 HA and HP shown on the MPT page are definetly correct [16:42:29] yeah [16:42:31] 136.2x7.8 [16:44:04] and to confirm it, I just deleted the PDI-0 calculation from the MPT, then re-calculated the maneuver pad and it works [16:46:04] yeah, I accidentally deleted the code to get a SV from before a burn [16:46:12] before the first burn in the table I meant [16:46:28] maybe the maneuver pad code can just be set to always use the pre-burn SV of the last maneuver calculated on the MPT [16:46:41] ah ok [16:47:28] it uses the TIG as the input for the MPT trajectory function [16:48:50] most displays do that, some specific GET and wherever the vehicle is at that time it will get a SV for that [16:49:01] all the calculation pages take the latest SV [16:49:15] so no searching necessary, just the last saved SV after a burn [16:54:39] also if I set the LM config to ascent stage, the maneuver pad still uses the full LM weight of 33863 [16:55:03] I think it will use the APS then [16:55:08] not quite sure where that is all used [16:55:23] guess it doesn't really do staging there [16:55:35] but it probably could use the post staging mass [16:56:43] I noticed the LM maneuver pad page still says LM Weight: 33538 instead of the ascent stage only weight (with ascent stage selected on config page) [16:57:30] yes, it still uses the mass [16:57:37] that can probably be changed [16:57:47] useful for e.g. Apollo 10 [16:58:50] the descent or ascent stage selection only is used for the DPS vs APS decision and the DAP PAD calculation right now [16:58:55] but that can be extended [17:01:46] approach azimuth, free and non-free return EMP latitude, pericynthion GET [17:01:56] those can all probably be used globally, right? [17:02:26] if e.g. you did a normal MCC-2 with the CSM but then want to do a maneuver based on the updated parameters with the LM [17:04:05] AGS K-Factor not. Wouldn't be relevant to the CSM anyway, but it would also be vehicle specific (if for some crazy reason you have two LMs) [17:05:46] quite a bit can be moved to the global core really [17:06:51] yes the mission constants I would think can be shared [17:07:05] also, the node data? [17:07:43] it would be uselful in this situation: You use BAP 2 or 4 to calculate MCC-2 from the CSM, which updates the node target [17:09:17] later during TLC you switch to the LM to do the initial activation and then quicksave, it would be nice for that quick save to have the new node data because when you switch back to the CSM, you might still need it later for MCC-3 and 4 [17:10:44] yeah [17:11:00] in the case you had saved scenarios with the LM during TLC [17:11:06] exactly [17:11:17] and you load one from the LM [17:12:27] yeah [17:12:45] it's pretty easy, just a bit of work changing all that stuff [17:13:23] right [17:14:08] btw on the TPI/TPF page of lambert targeting, for T2 it used to be like T1+35min. That doesnt work anymore. Is there a new procedure for finding the T2 of TPI? [17:15:53] ah, bad me, I changed the syntax [17:15:58] DT=35min [17:16:24] ah ok [17:16:30] mostly because the saved parameter for that is called lambertDT, haha [17:16:31] sorry [17:16:45] for T2 you can input time, DT or travel angle like 130° [17:16:50] WT=130 is the syntax [17:16:54] no problem [17:17:11] WT is new [17:17:37] morning! [17:18:42] hey [17:19:08] hey Mike [17:19:49] indy91, and with that I have computed an entire rendezvous from before even doing the CIRC burn! [17:20:08] great [17:20:29] one weird thing I noticed with a No PDI+12 calculation is that the DH wasn't super consistent [17:20:38] CSM CIRC, PDI-0, CSI, CDH, TPI [17:20:54] No PDI+12 targeted 15NM for the CDH position [17:21:08] weird [17:21:10] then when using the same parameters for the CSI calculation I got 14.23 or so [17:21:26] what can I put for T1 for TPI+15m [17:21:30] probably something using conic routines [17:21:52] you mean for midcourse corrections? [17:22:02] ah, ill just put in the exact GET [17:22:04] yeah [17:22:13] no option for that [17:22:26] just adding 15 should work :D [17:22:55] yep [17:23:08] and they are both DV 0, unsurprisingly [17:23:26] yeah, I would have been surprised if it is even 0.1 [17:24:17] I guess there is a max amount of maneuvers that can be put on the MPT [17:25:06] I haven't added a limit yet [17:25:16] but you probably wouldn't want more than the page can display, haha [17:25:22] yeah haha [17:26:01] I mean if you need that much then that is where some needs to remind you "hey bud dont think to far ahead here, one thing at a time" :D [17:26:27] well, that is only half true actually [17:26:54] in the RTCC the preflight mission planning tools and the real-time tools are mostly the same [17:28:39] its certainly extremely versatile now [17:28:51] most of the preflight planning at MSC was done by the Orbital Mission Analysis Branch, which had their own variations of RTCC processors [17:29:02] something like the DKI probably existed in three related versions [17:29:06] OMAB, RTCC and RTACF [17:29:24] A memo about the DKI for Apollo 14 talks about that [17:29:58] "two programs have slowly diverged because part of the RTCC DKI has been eliminated and because changes have been made to the OMAB program as a result of mission planning requests" [17:30:19] I could literally calculate myself all the way to a LM abort like PDI-0 or NoPDI+12 to a full rendezvous.... All from LEO before even doing TLI LOL [17:30:31] yeah [17:30:40] wouldn't reflect the actual trajectory very much though [17:30:49] so as you said, there is only so much value in actually doing that [17:30:56] right [17:33:03] I guess we could almost build our own SCOTs for custom missions [17:33:53] yeah [17:34:12] let's see who made the SCOTs... [17:34:32] Lunar Mission Analysis Branch, Landing Analysis Branch and OMAB [17:34:42] so no the RTCC people [17:35:07] I think I knew that from Gene Kranz book [17:35:21] that the mission planning people were not the "computer people" [17:36:11] sometimes could lead to problems when the people working the mission like flight controllers were not directly the ones that were planning the missions [17:43:27] right, makes sense [17:45:36] so now I am simulating a DKI calculated NoPDI+12 for Apollo 14. It includes the BOOST and HAM burns [17:46:37] I used the input maneuver page of the GPM to put BOOST on the MPT (FCT, point is time with the GET of BOOST) DV 10 fps [17:47:51] now I am going to calculate HAM. CSI page and calculate a normal CSI from the post BOOST SV. gives a CDH DH of 13.79 NM [17:48:23] good enough [17:48:24] So I can either use the HAM chart directly to find the required DVX that corresponds to 13.79 DH [17:48:39] or is there a way in the RTCC MFD? [17:49:36] for the HAM calculation? [17:49:44] yeah [17:49:54] DKI page again, but CSI/CDH Sequence [17:50:04] ah ok [17:50:23] I think [17:50:36] for that case the initial maneuver should be a HAM [17:51:34] and of course with the HAM TIG as the input [17:52:20] yes it works [17:52:34] so HAM is calculated at 0.9 DVX [17:52:41] yeah, seems about right [17:52:49] add that to the MPT, now recalculate CSI and DH is now 14.3 [17:52:50] and then CSI [17:54:09] and again, I think this is calculations using conic trajectories mixed with trajectory calculations using precise trajectories [17:54:27] I guess 14.3 is pretty good though [17:54:35] if that was all conic or all taking non-spherical gravity into account you would get 15.0 all the day I would think [17:54:37] yeha [17:54:38] yeah [17:54:46] all the way* [17:58:24] so I re-did the HAM calculation, but this time using the HAM chart. DH 13.79 NM in the chart indicates 2.2 fps. So I simply re-used FCT in the GPM with DVX 2.2 fps for HAM [17:58:47] then recalculated CSI, CDH is now a perfect 15 NM [18:00:02] charts were calculated with good trajectory estimators then, haha [18:00:08] yeah [18:08:07] I guess in reality they would have tweaked the NoPDI+12 on the MPT so that the HAM burn itself becomes 0 [18:08:44] probably didn't need to be tweaked, I'm still using more conic calculations than the RTCC would for the rendezvous calculations [18:08:53] because I started with the AGC as the basis [18:09:12] ah, right you said [18:09:44] but in any event its already pretty damn accurate [18:10:32] yeah, I'm quite happy how the MPT works together with the rendezvous calculation pages [18:10:46] I am too [18:12:44] all the actual trajectory calculations are done with the integrated trajectory, so with the MPT the calculation pages will show all their flaws anyway. For that it is working quite good [19:57:50] oh, the Apollo 11 CM Padload document also had some numbers for the July 18 and 21 launches [19:57:52] that's quite handy [20:03:13] landing site vector and ephemerides [20:05:52] oh great [20:06:51] no guessing about the landing site then [20:07:01] well, the flight plan had some numbers [20:07:06] yeah [20:07:22] I still have a week of vacation so I will probably fly another mission [20:07:28] probably 10 or 11 MCC [20:08:06] Add some more scenarios to that forum post I made [20:08:37] yeah [20:13:46] or the Apollo 11 July 18 launch scenario, trying to get that done, finally [20:14:44] trying to get that done today actually [20:15:19] hmm that I could maybe do [20:15:32] its MCC compatible, correct? [20:16:14] barely [20:16:41] so probably not, but I tried to not make the MCC launch day specific as much as I could [20:17:27] stuff like reading the TEPHEM from the CMC before any calculations are done help with that [20:18:41] oh and a few numbers for the TLMCC processor are in the normal Apollo 11 launch scenario [20:18:56] so we first should do a non-MCC run with the RTCC MFD to generate those number [20:20:10] we don't have the SCOT Volume I for Apollo 11, but we do have Volume III: Mission Summaries: July 1969 Launch Window [20:20:19] which should have numbers for that [20:20:22] like pericynthion state [20:24:19] ah I see [20:25:13] we also have that for September 1969 [20:25:25] and a LVOT for September 1969 [20:25:32] for Apollo 12, but still Mission G [20:25:43] so that is another set of alternative launch dates we could in theory try [20:26:01] Are the alternate landing sites of Apollo 11 similar to actual? [20:26:15] flat and boring, yes [20:26:19] for the july 18th launch date [20:26:36] but further west [20:26:43] always shifting west due to lighting [20:26:55] ah right [20:27:04] 23.7°E, 1.3°W, 41.9°W for July 16, 18 and 21 [20:28:59] can't have much further east than Apollo 11, or else you might have PDI before AOS [20:29:34] hence the weird trajectory Apollo 17 does [20:31:17] Ah so thats why [20:32:46] ok, mostly for more tracking [20:32:48] before PDI [20:33:00] to get more accurate data for N69 [20:33:17] but there definitely is a limit somewhere there in the east, haha [20:42:28] luckily we dont need any N69s ;) [20:42:45] only with bad LGC clocks [20:42:51] right [20:43:13] which we also don't get anymore [20:43:45] which was also something I watched out for because of my liftoff time update [20:44:19] I made sure my TEPHEM was valid for the time in my CMC [20:46:28] all to say I made sure my clock was very accurate, and the LGC CMC clock sync procedure works very well [20:47:44] yeah, with the procedure the clocks should be at most 1 timestep apart [20:47:47] so 1/60 seconds [20:48:50] yeah [20:49:11] just have to be sure not to do a PAMFD clock sync in the CSM [20:49:59] yeah, that uses the mission time as displayed by the PAMFD [20:50:40] which has a 0 time that is not the same as the 0 time (TEPHEM) in the CMC (very close but not identical) [20:52:57] that as well [20:54:12] UHCL has a flight plan for the July 21 launch, but not July 18 [20:54:31] but I think I got the July 18 one ready now [20:55:02] nice, with presettings? [20:55:22] yeah, I did those ages ago [20:55:39] I'll go over them again to check [20:56:17] hmm [20:56:18] no [20:56:20] too lazy [20:56:23] I trust my past me [20:58:41] do you think the value sharing thing between the vehicles is something coming soon as well? [21:01:17] update pushed [21:01:21] that will come tomorrow [21:02:34] ok great [21:02:56] It will mean I wont have to write down so much in my notebook during a mission :D [21:03:56] Finally something working in the fictional missions folder [21:05:55] you can try to fly it, but we really don't know much about it [21:06:03] how the trajectory goes etc. [21:06:31] I am not even 100% about the planned time of landing [21:06:36] the post-TLI trajectory should give a good idea of the nodal target [21:07:50] I guess Ill launch it to EPO, then simulate a mission using the MPT [21:08:01] we have some ideas [21:08:05] https://i.imgur.com/YHuYJe7.png [21:08:24] July 18 is free return, -89° approach azimuth [21:08:31] July 21 would be hybrid [21:10:45] just need a TLAND then [21:12:41] https://web.archive.org/web/20100523151918/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740072760_1974072760.pdf [21:12:47] good luck finding something [21:14:43] good night! [12:37:32] hey [12:59:50] hey [13:00:28] working on replacing the old method for the LOI-2 REFSMMAT. Such a mess, haha [13:03:27] haha yeah I bet [13:07:05] especially because I need to implement the new method before I can really remove the old one [13:07:53] 000,182,359 seem like the right angles [13:08:14] when I tried it the first time I got weird results, inconsistency isn't so great [13:19:04] thats odd [13:19:25] so the new method relies on using the mission planning table? [13:20:17] I probably just did something wrong [13:20:26] yeah, the LOI-2 REFSMMAT is just a LVLH REFSMMAT [13:20:32] at LOI-2 TIG [13:21:03] so you would calculate MCC-4, LOI-1 and LOI-2 and then use the LOI-2 TIG as the REFSMMAT time input [13:25:32] hmm [13:25:47] the old method doesn't give good results, weirdly [13:37:20] oh wow [13:37:44] the LOI-2 REFSMMAT calculation has never considered the landing site radius [13:38:07] no wonder I am getting inconsistent results [13:40:27] I think I'll just remove the old method without much further testing [13:40:36] the one with the MPT seems to give good results [13:45:15] great [13:46:52] 0,0,0 attitude for a +1.0 +0 +0 burn at the LOI-2 TIG [13:47:03] with the RCS [13:56:46] that looks pretty good [13:57:49] unfortunately the old Apollo 8 scenario is broken [13:57:57] didn't save nodal targets yet [13:58:39] need to do some trickery to test it [13:59:18] Ill have to re-fly it and make some fresh scenarios [14:00:26] those could directly replace the ones we have [14:00:37] no need to put them on the forum [14:00:47] right [14:01:02] I will of course fly 10 and 11 1st I guess [14:01:29] fly what you want, haha [14:02:44] Ill start by finishing 14 lol [14:29:34] I guess the map update and landmark tracking pad pages can be made MPT compatible [14:32:01] yeah, they will be [14:43:41] haha so just before TEI, I checked on Antares and it had stopped bouncing around the moon and had settled on the surface of the moon, however about the opposite side of it as where the initial impact happened. Now I am 1/3 of the way towards earth on TEC and I check again on Antares... which is now mysteriously in a solar orbit with the earth and moon as tiny dots off in the distance lol [14:46:30] My theory... Aliens found it and decided to mess with me [14:48:11] Aliens, or even worse, Orbiter 2016 touchdown points [14:48:59] yeah [14:49:07] they might still need a bit of twaeking [14:49:12] tweaking* [14:51:31] I am quite sure its the single touchdown point that defines the top of the LM, Ive seen it cause issues. Combine the LM falling on its head with 30x time accel I was using while coasting in the CSM and yeah that probably explains it [15:37:37] now the difficult task of deleting a REFSMMAT calculation mode and untangling everything related to it [15:40:26] fun [15:41:48] I'm moving the attitude option from number 9 to 7, replacing the LOI-2 one which was 7 before. A spare option would be even worse to handle than such a change, haha [15:44:19] the LOI with MCC option was actually never a general RTCC thing, just RTCC MFD [15:44:24] so that makes it much easier to remove [15:55:50] ah in the lunar insertion page? [15:56:25] yes [15:56:52] the MCC there was taken into account in RTCC MFD code, so the MCC has never used that option [15:56:57] I guess that will still be used "behind the scenes" by the TLMCC MAP programs [15:57:05] BAP* [15:57:44] well yeah, that code uses the LOI targeting in the iteration [15:59:03] but the option in the RTCC MFD (LOI with MCC) was always just RTCC MFD code [15:59:33] right [15:59:48] RTCC did it differently, so I don't have to change much [16:00:18] its good that it will be simplified now... I have almost actually burnt an LOI w/mcc solution I dont know how many times :D [16:08:13] easy to make mistakes with the MPT as well, haha [16:10:27] right [16:10:48] one idea would be to always have a message on the top of the MFD that says MPT active or not [16:15:34] yeah, something like that [16:23:18] morning! [16:23:31] hey [16:27:17] hey Mike [16:33:24] what's up? [16:44:41] finishing Apollo 14 [17:03:28] indy91, I am working on something that I think would be useful [17:03:43] https://www.dropbox.com/s/urnkt1pl7dhni16/Screenshot%202018-10-21%2013.02.59.png?dl=0 [17:04:42] for me at least I use that button quite a lot and I think an on-screen reminder would be good [17:05:53] cheater [17:06:15] is that an annotation in PAMFD? [17:06:38] yes [17:07:12] what I did was use oapiCreateAnnotation to add it to the top right of the screen aswell [17:07:29] looks good [17:07:54] I have it semi-working right now [17:08:09] but it wont always go away when I deselect it [17:08:52] I have it tied to NOTEHANDLE title;, but I think I have not properly initialized that variable [17:10:20] it just needs oapiCreateAnnotation and oapiAnnotationSetPos once [17:10:26] yeah [17:10:30] this is my new code [17:10:31] https://www.dropbox.com/s/6ws9d14jmie114q/Screenshot%202018-10-21%2013.09.29.png?dl=0 [17:10:32] and then oapiAnnotationSetText with text or empty [17:11:54] only do the text every timestep [17:13:36] create and Set Pos in the constructor of PAMFD [17:14:29] ok [17:14:33] and this worked: [17:14:34] oapiAnnotationSetText(title, "KILL ROTATION ACTIVE"); [17:14:35] } [17:14:35] else { [17:14:36] oapiAnnotationSetText(title, ""); [17:14:36] } [17:15:21] yeah, setting the text to nothing every timestep is good [17:15:35] and Ill put create and Set Pos in the constructor [17:15:37] whenever killrot is not on [17:30:12] alright works good, except if kill rot is on, then you switch to the LM and then deselect it, the message stays [17:31:16] deselect it in the CSM or LMß [17:31:17] ? [17:33:10] Like if you are in the CSM and select kill rotation on and off, the message will go on and off normally. However is the message is on, then you switch vehicles then the message is on in the new vehicle (as it should) but if you then deselect kill rot from PAMFD in the new vehicle, the message on the top right wont disappear [17:33:38] the message becomes stuck essentially [17:33:50] CSM and LM have separate killrots though [17:34:01] seems to be caused by the switching of vehicles [17:34:47] well the kill rot usually will be copied over (If I have kill rot in the CSM, I switch to the LM and kill rot is already on) [17:34:59] hmm [17:35:02] that is bad actually [17:35:20] looks like the killrot variable is global in the PAMFD, so all instances will use it [17:35:27] that should probably not be the case [17:35:31] yeah [17:36:00] does the messages disappear if you descelect it in both CSM and LM? [17:36:31] ah, that doesn't work [17:38:21] and switching back to the CSM doesn't make it go away? [17:38:49] no [17:39:06] please test this [17:39:08] CSM only [17:39:14] open PAMFD and use killrot [17:39:33] close PAMFD and open it in the other MFD [17:39:43] and stop killrot [17:39:47] doe sit go away? [17:40:04] the other MFD as in the LM one? [17:40:12] no, left vs. right [17:40:15] oh ok [17:40:19] ill check [17:40:38] I think the issue is that the MFD constructor is called whenever you open the MFD [17:40:43] and it's always a new one [17:41:27] so it's not the same annotation handle anymore if you open the MFD again or somewhere else [17:41:52] okdid the test, the message did not go away [17:42:00] ok did* [17:42:19] so yeah that explains it [17:44:46] not entirely sure what the best solution for that is [17:45:05] probably adding the note handle to g_Data [17:46:35] btw, this is the reason why everything that needs to persist in the RTCC MFD is not in the MFD class but in a separate one, ARCore [17:47:00] in the MFD constructor is searches through the list of ARCore instances that were already there, one per vessel [17:47:23] so when you open and close the RTCC MFD it will find the same ARCore with the same data again [18:02:38] pushed a few updates [18:17:09] great [18:33:46] looks good, I like how the variables are now shared [18:38:01] What if killrot becomes part of the vessel itself, and not part of PAMFD [18:38:18] and we would have a keyboard press to turn it on and off [18:38:34] with the re messenage displaying on-screen [18:38:38] red* [18:38:45] message* [18:40:09] would probably ensure they are only activated locally with its respective vessel [18:41:28] no, there are better ways than that [18:41:43] also, Numpad 5 :D [18:42:22] switching vessels while doing killrot is bad anyway [18:42:37] just move the note handle to g_Data and then it's global [18:42:49] ok ill try [18:44:27] hmm [18:44:32] there is a problem with that [18:44:48] the init code for the notehandle would still be in the MFD constructor [18:46:57] what if I initialize it in g_data too [18:51:10] no, that doesn't work [18:51:19] g_data is just a static struct [18:52:32] right [19:00:30] cya [12:28:00] good morning [12:40:08] hey [13:12:14] hey [13:12:59] hey Alex [13:13:04] I'll be back later [16:34:51] good evening [16:37:01] wb [16:38:00] I think the new D3D9 client (R84) is causing a CTD for me. [16:38:29] So I reverted back to both Orbiter Beta R73 and D3D9 R73 and that seems to have fixed it [16:40:56] oh [16:41:02] in what situation? [16:41:53] t was quite random actually [16:43:11] It would only happen 50% of the time during session start, and the end of loading [16:43:12] and no debug option unfortunately [16:44:12] I saved the orbiter logs and sometimes it would have texture loading errors [16:44:14] I updated a few days ago, hadn't had the issue yet [16:44:14] IE: 000000.000: D3D9: WARNING: Texture Cape20_n.dds not found. [16:45:49] weird [16:45:50] Cape20_n doesn't even exist [16:46:09] if you search for it there have been some people missing that and other textures in the past [16:46:15] Cape20.dds exists though [16:47:18] default Orbiter texture [16:49:41] yeah [16:50:26] maybe report it in the DX9 Client thread [16:51:44] seems unlikely that it's a NASSP issue [16:52:21] yeah [16:52:29] I dont think it is [16:52:57] did it happen when you were working on annotations [16:53:05] ? [16:53:20] as you know, but maybe never seen it yourself, those can cause CTDs as well [16:53:30] at least with some PADs when the MCC is using it [16:53:46] I reverted everything to make sure [16:53:53] and it was still happening [16:57:07] btw about the kill rotation message I was working on, I tried using a debug string to display it instead, and that seems to work [16:57:33] I dont know however if thats a good way to do it (use a debug string) [16:59:48] I was trying to find some case where annotations are used by an MFD [17:00:20] but didn't find anything [17:00:55] hmm [17:00:57] haha [17:01:05] I think there is an easy way [17:01:28] it can stay in the MFD class and get initialized in the constructor [17:01:43] it simply needs to remove it in the MFD destructor [17:02:11] that already exists, it's just empty [17:02:30] right [17:03:20] oapiDelAnnotation [17:03:25] that might be enough [17:04:00] so the Create and setPos functions in the constructor and that in the destructor [17:04:06] setting text in the timestep [17:04:15] ok [17:04:19] ill try that [17:04:29] and the notehandle defined in the MFD class of course [17:10:38] hmm [17:10:53] no did not really work [17:11:17] on top of that, when I close the MFD, the message disappears [17:11:25] yes, that was the point [17:11:57] if the MFD isn't open then it doesn't do killrot anyway [17:12:00] or does it? [17:12:28] oh, it's in the separate timestep [17:12:52] how are you using killrot anyway? :D [17:13:08] I have only ever used it to quickly kill any rotation for e.g. P52 [17:13:14] and instantly disabled it again [17:13:27] I have never had it on for more than 1 second at a time, haha [17:15:40] the reason was so that I could know it was on when the MFD was closed [17:15:55] because it does stay on even with the MFD closed [17:16:10] but yeah I guess I use it quite a bit more then I should lol [17:16:35] yeah, it does that in the Orbiter module timestep of PAMFD and the Checklist MFD [17:17:08] that's how it is independent of the MFD being open or not [17:17:15] I just don't understand your use case [17:17:28] do you have it on for longer stretches of time? [17:17:47] why? [17:18:13] it doesn't change attitude after that, unless gravity gradient torque is on [17:18:42] and I would argue that disabling gravity gradient torque is still more realistic than having killrot on for long periods of time :P [17:20:26] hmm I do use it sometimes for long stretches, yes, for example in the 30mins prior to a burn with the CMC in AUTO, keeping kill rot on will ensure that there is no chance the CMC will start firing the RCS if the attitude rates are completely 0, (and the CSM is already in the correct attitude) [17:21:05] I forgot to add, for the case above is using time accel leading up to the burn [17:21:18] and gravity gradient torque on? [17:21:23] and then of course just before it I would take kill rot off [17:21:31] its off [17:21:40] then I don't understand the issue [17:21:43] but I think I will try and change my ways ;) [17:21:45] quickly do killrot [17:21:49] yeah [17:22:01] and if it doesn't fire in that attitude it will never fire [17:23:15] it would never drift outside the deadband for firing the RCS [17:23:20] I guess the thing I would really like is to have a key command to do a "kill rot" without having to even go into the MFD [17:23:33] a one-time kill rot of course [17:23:50] we could overwrite the default Orbiter command for that actually [17:23:54] Numpad 5 [17:23:57] right [17:24:13] but since it is cheating we could make it CTRL-5 maybe [17:24:15] which I will have to do for the DEDA keyboard commands [17:24:32] because CTRL and numpad keys were already used by Orbiter [17:24:40] ah, right [17:24:51] wanted it to test more before I commited that [17:25:06] but basically, in the vessel function for keyboard commands, you can return either 0 or 1 [17:25:24] in one case it overwrites the Orbiter function for that key combination, in the other case it would do both [17:25:46] so maybe just numpad 5 to make it like default orbiter, but instead of using RCS to killrot, just straight do SetAngularVel(_V(0, 0, 0) [17:26:14] yes, that could probably be done [17:26:45] on the other hand, in my opinion because it is cheaty anyway, making you have to go through PAMFD seems about right [17:27:48] weren't you complaining that the plus and minus keys on the numpad were still starting or cutting the engines in some vehicle configurations? :D [17:29:16] so the solution with the MFD destructor doesn't really work [17:30:00] yeah I had a weird situation with taht on Apollo 9, but couldnt replicate it [17:30:17] not really, but I think I will leave it as-is finally [17:30:28] It already has the red message on the MFD anyway [17:30:52] maybe we should make it only killrot for 1 timestep anyway, like you said [17:31:01] I'll take any working, memory safe solution for an annotation that you can come up with [17:31:01] not have it on all the time [17:31:14] even if I don't find it necessary, haha [17:31:48] did another Apollo 16 LOI, still don't like the orbit [17:31:57] I think I'll go through with changing the SPS thrust [17:32:10] that is the easy solution for me [17:32:10] the only reason I was as to remind that it is on when the MFD is off. But I think your right, we should use it like that anyway [17:32:21] shouldnt* [17:33:07] more difficult solution is to just change it in the functions that do the finite burntime compensation [17:33:16] ah, right the SPS thrust was a bit wrong from what the CMC expected you were saying [17:33:31] well, the SPS thrust always varied a bit [17:33:48] the CMC had a fixed number for its internal finite burntime compensation [17:34:27] and any DV uplinked has to be first compensated for the finite burntime but then also backwards compensated for what the CMC does [17:34:31] quite annoying [17:35:38] I believe it also has a big influence on this specific LOI, because the orbit before has a 71NM pericynthion [17:35:52] so the perilune is changing quite a bit in the second leading up to cutoff [17:35:55] weird that I got a perfect orbit with Apollo 14 LOI [17:36:05] ah right [17:36:14] what's the pre LOI pericnythion for that? [17:36:27] 59 [17:37:27] and burnout altitude is pretty close to that [17:38:59] I guess for now I am changing the thrust [17:39:03] that is the easiest way [17:39:36] if we ever have different SPS thrust values for different missions then I'll have to use the separate value for the CMC re-compensation in the RTCC [17:43:02] it's not a super big change anyway [17:43:32] burns will take 1% longer [17:49:54] morning! [17:57:36] hey [17:58:14] travelling? [18:08:27] hey Mike [18:08:51] indy91, I got shift-K as a key command working for killing angular rates. [18:09:14] I think that would be a good solution [18:09:15] great [18:09:18] sure [18:10:03] its not part of the MFD, I added it to clbkConsumeBufferedKey of both Saturn and LEM class [18:12:17] yeah [18:16:28] that's not toggle on/off but only once killing the attitude rate, right? [18:20:03] yes [18:20:07] just one-time [18:20:43] basically exactly the same as going in the scn editor and hitting kill rates [18:34:50] PR sent with this and a new Apollo 17 pre-PDI scenario for the WIP folder [18:43:00] simple enough [18:43:14] merged [18:44:47] I was thinking maybe I should have put a stage >= CSM_LEM_STAGE for the Saturn one [18:46:50] nah, not necessary I think [18:47:14] ok [18:54:56] cya [11:50:29] good morning [11:53:36] went to my first hockey game last night [11:54:00] tried some german beer and it was good [12:03:01] hey [12:03:18] you are Canadian, right? So you probably mean ice hockey [12:03:25] yes [12:03:37] in Germany we call field hockey just hockey, and ice hockey hockey [12:03:51] uhh [12:03:57] ice hockey we call ice hockey [12:03:59] interesting [12:04:00] that way around :D [12:04:11] it's also more popular than ice hockey here [12:04:15] probably the reason for that [12:04:35] in Canada we call ice hockey just hockey and floor hockey as floor hockey [12:05:10] yeah [12:05:12] what kind of German beer was it? [12:05:39] i dont remember the brand but it was a bit expensive [12:08:10] just debating whether to use the rtcc or the mcc feature for my mission as i am just before the first state vector update in earth orbit [12:08:38] standard Apollo 11 launch or the July 18 scenario? [12:08:49] standard [12:09:00] didn't know there was an 18 scenario [12:09:19] we talked about it [12:09:29] and I managed to get it done and commited it [12:09:34] oh [12:09:44] maybe i might try it [12:09:52] I'd still call it quite experimental, could have a bunch of bugs [12:10:15] and any preloaded values in the RTCC MFD won't be valid for it [12:10:49] so not easy to handle the scenario [12:10:55] okay [12:10:59] it's up to you, just an option now [12:11:12] and the July 21st launch scenario will follow soon [12:11:19] i think i'll stick with the 16 launch for now [12:11:21] for that there is at least a flight plan in reach, at UHCL [12:11:46] speaking of UHCL, I have a few documents to request for scanning there [12:13:01] the main reason I am creating those scenarios is because we can [12:13:08] we have the right targeting data for the LVDC [12:13:11] for launch and TLI [12:13:28] we don't even have that for most actual launch days [12:14:26] if Apollo 11 had failed to land on the Moon, they would have launched Apollo 12 as the same mission type (Mission G) in September 1969. For that we also have the targeting data. [13:20:26] good morning [13:25:30] hey Alex [13:25:41] finally burned an Apollo 16 LOI that I am happy with, haha [13:30:41] haha finally :p [13:31:03] Was it the updated SPS thrust? [13:31:21] yes [13:32:04] the problem is more the thrust value that the RTCC uses for calculating the P30 DV than the thrust itself [13:32:20] now it's using the same number that the CMC uses [13:32:56] that thrust value and the mass in the CMC both have to be exactly the same as in the RTCC targeting, or else you get a very slightly off burn direction [13:35:06] and the apolune and perilune altitudes change so quickly at the end of the Apollo 16 LOI burn that it does make a difference [13:35:45] the 4 seconds burn time difference isn't so significant, in reality it would be even 10+ seconds longer if the whole burn was done with a single SPS bank [13:36:06] it's all because of the stupid CMC internal finite burntime compensation [13:38:20] what were they thinking [13:38:59] oh, pretty simple [13:39:06] it's useful for manual DV inputs [13:39:11] let's say +300 0 0 [13:39:27] that would be a few seconds burntime at least [13:39:53] so it will have a burn arc in low Earth or lunar orbit [13:40:28] by adjusting the pitch attitude of the burn a bit it will apply the DV in the right direction [13:40:44] so it will start the burn slightly below local horizon and will end slight above local horizon [13:41:08] without any compensation it will simply start at e.g. 0° and end at 2.5° over the local horizontal [13:41:24] so not quite apply the DV in the right direction [13:41:35] so it is useful for medium length burns [13:42:02] but if you suddenly have 3000 ft/s instead of 300 ft/s that scheme doesn't work as good anymore [13:42:16] and even gets in the way of ground targeting [13:42:21] or at least make it more complicated [13:56:56] I'm removing a few more of those direct vs. MCC options in the RTCC [13:57:28] REFSMMAT page is done, and for the Lunar Entry PAD and PDI PAD only the MCC is still using those options [13:58:01] the MCC can already store a state vector for later use, but it will probably end up using a MPT as well [13:58:16] mostly needs saving and loading now [14:06:55] yeah I guess most of the remaining MCC option pages were in the REFSMMAT section [14:07:42] There also seems to be a REFSMMAT option now with nothing associated to it, was that the old LOI-2 REFSMMAT? [14:10:03] oh [14:10:19] that shouldn't be the case [14:10:48] fixed [14:12:48] pushed a few more of those changes [14:12:55] about the saving and loading you said thats about the MPT, right? [14:13:00] great [14:15:14] yeah, if the MCC is going to use the MPT it will need saving and loading for that [14:15:19] it's a bunch of things to save [14:15:25] per maneuver [14:17:03] would be useful for the Lunar Entry PAD in the MCC [14:17:11] right now it's a bit of a bad solution there [14:17:23] if a TEMCC is scrubbed it saves a DV of 0.0 [14:17:51] and the Entry PAD calculation checks if the DV is 0 and then uses that for its logic [14:18:26] with the MPT it will simply get the latest SV from the MPT, maneuver there or not [14:21:01] just a bit more elegant [14:25:30] yeah makes sense [14:26:07] also were you still considering saving RTCC MFD variables outside of the MFD itself? IE like checklist MFD [14:27:13] yes [14:27:21] so that the MFD state is saved regardless if the MFD is open or closed when quicksaving [14:27:32] yes [14:28:41] how would that work? would part of the variables be saved to the CSM and another part to the LM? Or would it be all in one subsection of Saturn5? [14:29:17] probably only the global variables [14:29:23] and saved separately somehow [14:29:26] not quite sure yet [14:41:14] Just trying the new changes from today. I tried for fun to see if I could calculate a Lunar Entry REFSMMAT from before TEI. So I calculated TEI and a corridor control MCC and put both on the MPT. I then calculate the Lunar Entry REFSMMAT and then go an calculate the Lunar Entry PAD. For some reason the .05 RPY is 044,256,018 [14:43:31] ok [14:44:10] I have an idea [14:44:24] the MPT trajectory function has two modes, one with an input GET and one without [14:45:00] the without GET option simply gives the last SV, the GET option finds the SV at the GET [14:45:10] and I have been just using the general REFSMMAT time input there [14:45:29] that probably doesn't apply to the Entry REFSMMAT [14:46:02] that time is probably 0 [14:47:34] thinking about it [14:47:44] that time is also not used for a preferred REFSMMAT either [14:52:12] for preferred REFSMMAT it should get the SV at TIG [14:52:32] for LVLH at the specified time [14:53:05] for lunar entry the last SV [14:55:18] I knew the REFSMMAT calculation would make this complicated, haha [14:56:34] haha yeah [14:57:12] and if I use the LVLH page and calculate a REFSMMAT with a time input of RRT, then I get a good RPY 000,152,000 [14:59:35] ah, good [15:11:14] hmm sorry I keep finding bug today ;) But the DEDA keystrokes seems to have weird behavior on my end... when I enter data, then use CTRL-ENTER, the data does not go in [15:12:36] and I made sure I do CTRL-DEL to clear it 1st, then enter data say 400+10000 and then CTRL-ENTER. The numbers stay displayed however and do not go in for some reason [15:13:03] if I do the exact same thing with the mouse then it works fine [15:16:36] ah I figured out why [15:18:13] the CLEAR button CTRL-DECIMAL, for some reason does not clear it fully, but if I clear it by clicking clear with the mouse and then doing everything else with the keystrokes then it works fine [15:18:40] so in summary, the CLEAR keystroke is not fully working it seems [15:37:53] hmm [15:38:59] clear maybe needs to be pressed longer [15:42:41] the DEDA is weird like that [15:42:48] or rather the DEDA/AEA interaction [15:44:46] I tried longer presses with the keyboard but still doesnt take it [15:44:59] maybe the longer press doesn't work with keyboard commands [15:45:49] the auto checklist can do DEDA clear, right? [15:46:37] hmm, but that's different [15:46:48] that is actually causing a button press [15:47:20] oh I think I found something in lm_ags.cpp [15:47:48] ClearPressed has a separate function [15:48:00] LEM_DEDA::ProcessKeyRelease(int mx, int my) [15:48:17] Key release has a separate function* [15:48:31] and includes a ResetKeyDown(); after [15:50:52] ProcessKeyRelease is an unused function [15:50:54] should be removed [15:51:08] but the ResetKeyDown is interesting [15:52:07] hmm [15:52:28] when you press a button it calls ClearCallback [15:54:34] it calls ClearPressed but does some extra stuff [15:55:09] ah [15:55:25] it probably needs to calls a key release function in the LM button code [15:57:47] that should do it [15:58:02] I'll have that in a commit soon, you can test it then [16:01:51] great [16:02:01] ill try not to find more bugs [16:04:13] try to find them naturally and not looking for them :D [16:06:24] ill "try" :p [16:13:33] I guess a Lunar Entry REFSMMAT is also just a LVLH REFSMMAT, but it does have the additional calculation for finding entry interface, so I'll not remove that [16:17:04] yeah [16:54:53] ill be back in a few hours [18:52:44] back [18:59:45] indy91, clear keystroke works perfectly now thanks! [18:59:55] ah, good [19:01:32] I requested two documents from UHCL this morning, still not done. Not sure what that means :D [19:01:51] I don't expect them to be huge [19:02:45] cool, which ones? [19:04:01] Apollo 10 and 13 mission planning documents [19:04:13] the Apollo 10 one could potentially be really good [19:04:27] oh right, you were saying they might have RTCC targets [19:04:35] yeah [19:05:05] I would be curious to see what they used on 13 [19:05:30] 13 one is a different document [19:05:36] REAL TIME SUPPORT OF THE APOLLO 13 MISSION [19:05:44] there is one of those also from after the flight [19:05:56] APOLLO 10 (F) MISSION OPERATIONAL TRAJECTORY SIMULATOR DATA PACKAGE FOR MAY 18 LAUNCH [19:06:00] this is the other one I requested [19:07:45] nice [19:08:37] Entry pad RPY is now also good now btw [19:08:42] great [19:09:46] there is a similarly named document as the Apollo 10 one [19:09:55] flight crew simulator data, we have that one [19:10:09] but its definitely another memo number [19:10:46] not of the MSC wide type [19:11:18] 69-FM-137 for example would be a MPAD memo released for use in the entire MSC [19:11:29] FM probably stands for flight mechanics [19:11:43] 69-FM13-218 [19:12:07] that is a memo released by FM13, some part of MPAD, no idea what 13 stands for, haha [19:22:21] So I just calculated the LOI-2 REFSMMAT for Apollo 8 before MCC-4 with the new way. 000,181,359 [19:22:24] Pretty Good! [19:22:41] it used to be like pitch 168 or so with the old method [19:23:34] which is weird, because I remember the old method working fine. Maybe it got broken at some point [19:25:36] Should I calculate the LOI-2 REFSMMAT with the LOI-2 maneuver on the MPT, or should it be calculated from the post-LOI SV, before putting the LOI-2 itself on the table [19:25:59] ?* [19:26:10] forgot the question mark lol [19:27:40] I guess it shouldnt matter as you use the TIG of the LOI-2 anyway so it will use the pre-burn SV anyway [19:39:57] yeah, just input the LOI-2 TIG and it should give the right SV [19:47:25] hmm if I make a P30 REFSMMAT for LOI-2 then the angles are a bit off [19:49:09] sorry meant to say LOI-1 [19:49:45] is LOI-2 in the MPT? [19:50:05] LOI-2 is fine, if I calculate a P30 heads-up for LOI-2 then the angles are 0,0,0 as expected. If I calculate the same for LOI-1, its 000,007,357 [19:50:19] yes all this is with the MPT, calculated before MCC-4 [19:50:51] how can you calculate a P30 REFSMMAT for LOI-1 when LOI-2 is in the MPT as well? [19:52:35] I deleted everything and started over [19:53:13] so this a P30 LOI-1 REFSMMAT [19:53:23] and the IMU angles are for LOI-2 [19:54:02] ? [19:54:52] sorry the LOI-2 and LOI-1 tests were separate [19:55:03] I have no idea what you are doing now, haha [19:55:45] just a preferred REFSMMAT for LOI-1 with LOI-1 in the MPT? [19:55:46] to put it simply P30 REFSMMAT calculations seem to be not working right for the longer burns like LOI, even with MPT off [19:55:58] ok [19:56:14] I've change those quite a bit, so not really unexpected [19:56:45] I have a pre-LOI scenario and just calculated a simple LOI without MPT enabled. The LOI angles are 006,242,351 [19:56:49] and I think I already found the issue [19:57:09] for choosing the right time for the REFSMMAT calculation it had: if, if, else [19:57:13] not: if, if else, else [19:57:49] let's see if that small fix does it [19:58:46] that made it use the input REFSMMAT time even for a P30 REFSMMAT [19:58:51] so probably 0 in your case [20:00:08] yeah, I think that was it [20:00:10] simple bug [20:00:17] I'll push the fix for it [20:01:32] I must say I did not find that bug "naturally" as you put it haha [20:02:26] yeah, but it's a very obvious one [20:02:49] right [20:02:50] any news on the docs? [20:03:19] nope [20:03:53] pushed, please tell if it is fixed [20:04:34] thanks [20:04:38] will do right away [20:08:17] 1st test worked [20:09:52] 2nd test as well [20:10:20] I tried and without the MPT activated and its working well now [20:11:37] ah, great [20:11:43] so just that simple oversight then [20:12:41] find some more bugs for me [20:12:44] good night! [14:36:35] hey [14:38:13] hey Alex [14:40:07] in P24, has the CMC ever done optics rate commands for you while in optics mode manual? [14:40:49] I'll have to check if any commands are getting sent, but it doesn't seem like any got through [14:40:56] or I don't understand properly how P24 works [14:42:13] hmm not even sure Ive ever tried P24 [14:42:27] how many J-Missions have you flown? [14:42:43] many lol [14:42:57] apparently not thoroughly, haha [14:42:59] all of them [14:43:04] no haha [14:43:53] hmm, there is one thing we probably don't simulate [14:44:07] there is a output bit for "inhibit read counter to error counter feedback" [14:44:52] so it might be that the code we have instead of CDUs for the CMC optics isn't quite right, so that this mode isn't working [14:45:56] have to implement the OCDUs and ICDUs at some point, but they are different and more tricky than the RR CDUs [14:47:24] map update and landmark tracking pages are now MPT compatible [14:50:56] ill have to make the bitmap changes soon for the CSM optics as well [14:53:05] and the switch code changes [15:52:23] getting a bit further with 16 now I guess? [15:56:17] yeah, post DOI [15:57:46] have you given PGNS -> AGS auto RR marks a try? I guess not as that would be after insertion according to the checklist [15:58:23] yeah, haven't done anything with that yet [16:24:35] heard back from Lauren [16:24:50] the Apollo 13 document is just a list of people responsible for the real-time support [16:25:08] like who is at which console during which flight period [16:25:36] interesting that it talks about "termination of all RTACF support" [16:28:22] Apollo 10 document is also not super interesting [16:28:34] it has the same kind of data as the other simulator document [16:28:58] which is: maneuver loads, state vector updates, Maneuver PADs [16:29:26] in the back it has lunar and solar ephemerides for the CMC which is kind of interesting [16:29:40] and the exact RLS [16:30:00] hmm I guess biter-sweet then [16:31:35] and REFSMMATs [16:31:54] so most of the things you would need to set up a simulator to simulate a specific maneuver [16:32:33] right [16:32:34] it has data for all major CSM and LM maneuvers [16:35:02] like for LOI-1 it has state vectors for CMC uplink and in different formats for the simulator for TIG minus 5 hours, 2.5 hours, 1 hour and 20 minutes [16:35:14] and exactly ignition [16:35:21] so whatever you would want to practice again [16:35:27] full pre LOI period or just the burn [16:38:19] it's just tables with data, I think this is a department internal document that then supplied the SCOT Volume that has the exact same numbers [16:38:32] and that SCOT document we already had [16:52:56] sounds interesting [16:53:18] could be used at some point for setting up scenarios I guess [16:56:48] yeah [12:45:10] hey [12:45:26] hey Alex [12:45:33] finally PDI day for Apollo 16! [12:46:48] haha nice [12:51:14] and re-entry day for Apollo 14 [12:51:58] any request what should be made compatible with the MPT next? [12:56:22] hmm is there anything left to be made compatible? [12:58:00] oh maybe the MCC displays? [13:00:17] yeah, right, those [13:00:30] and I could add some more that use the MPT [13:00:36] like the Relative Motion display [13:00:54] could the Lunar ascent processor be able to be read by the MPT? [13:01:09] that way you could calculate rendezvous before luner liftoff [13:01:16] lunar* [13:03:00] ah yeah [13:03:03] that can be done, yes [13:03:20] will need a bit of additional logic I guess [13:08:33] to handle LM staying at the landing site [13:14:05] right [13:15:18] and the map update, landmark tracking pads, but I think youy said that was on the way [13:16:13] yeah, that's done, just hadn't pushed it yet [13:16:40] is the P37 pad compatible? [13:17:02] I think the PAD right now doesn't even have a calculation [13:17:16] just a display from a previously calculated RTE maneuver [13:17:30] ah ok [13:17:42] so should work off the bat [13:17:50] yeah [13:18:31] the nav check and DAP pads would be useless to have with the MPT I guess [13:19:06] yeah [13:20:15] next big MCC thing would be the maneuver planning display [13:20:56] which takes an impulsive burn calculated elsewhere and has a bunch of thruster options to calculate a finite burn with it and put it on the MPT [13:21:17] and then display a whole bunch of maneuver values, most of which would also be found on the Maneuver PAD [13:22:53] nice [13:27:54] the real process of assembling a Maneuver PAD would be taking the values from that display and then other stuff like the sextant star check would be coming from a display for optical systems [13:34:18] makes sense [13:34:51] Is this what we would be moving to? Or will we still keep the maneuver pad calculation page as well? [13:36:25] we will probably keep it [13:40:42] yeah I agree [15:57:05] indy91, just a minor thing I have been noticing with the RTCC MFD in all my missions so far. If you take a fresh RTCC MFD instance during TEC and downlink the splashdown coordinates to the lunar entry pad for some reason the downlinked coordinates are slightly off from what the coordinates are on the N61 display just before re-entry [15:58:12] I had downlinked -26.80, -171.31 from the CMC to the lunar entry pad, but when I actually did P61, N61 shows-26.82 and -171.33 [15:58:54] hmm [15:59:14] and the N61 values were previously uplinked? [15:59:21] yep [15:59:36] this might be an issue with negative octal numbers actually [15:59:50] might be processed wrong for these [15:59:57] so it would be one bit off [16:01:00] would explain why it is both off by 0.02° [16:01:07] let me check what the scaling is for these [16:01:21] yeah I notice its always off by 0.02 [16:02:03] yeah, one bit is roughly 0.02° [16:02:13] that is probably an easy fix [16:30:10] AlexB_88, I'm having some trouble with the P52 spirale technique [16:30:21] what do you load in N79? [16:32:21] ah [16:32:23] I think nothing [16:32:27] V21 [16:32:33] I think I just marked one display too early [16:32:42] yeah [16:34:13] or V22 for spiral rather [16:36:28] looking at the G&N Dictionary now [16:36:37] you load both cursor and spirale in R1 [16:36:47] and you change the display with ENTR apparently [16:36:59] and just press mark and then give the data [16:38:00] hmm [16:38:08] there is also V22 [16:39:30] all very confusing [16:39:47] I'm back to the 52 71 [16:39:53] 52 is for curso [16:39:55] cursor [16:40:11] but can you then enter spirale data anyway with V22? [16:40:29] what's the process here [16:41:07] I think I did the V22 at the wrong time [16:49:15] -0.07° [16:49:23] what does minus mean, lol [16:51:06] oh, I forgot about the comm troubles they had [16:51:22] reading up the REFSMMAT for a manual P27 [16:55:57] I just noticed how the P52 technique is so much different from the P57 one [16:56:16] but -0.07 does not sound bad at all [16:56:58] I sometimes get minus too, I think its fine. Pretty sure ive seen the real pads show minus in some cases [17:15:21] is minus a LM only thing? [17:15:30] or only in this technique? [17:39:49] ive only seen it in the LM [17:39:55] during P57s [17:43:38] I see [18:31:13] alright finally finished 14 [18:50:26] I added my Apollo 14 mission pack to the the forums [18:50:27] https://www.orbiter-forum.com/showthread.php?p=583087#post583087 [19:18:10] great [19:30:19] bug with the splashdown coordinates being 0.02° off is fixed [19:30:40] REFSMMAT downlink used the same function actually, so downlinked REFSMMATs probably were very slightly off [19:32:56] pushed [20:05:47] thanks [20:32:39] did you notice the spikes in the terrain on the approach to Descartes btw :D [20:35:01] yeah, have seen them on 2-3 revs so far [20:35:22] are they a problem for the LR? :D [20:38:36] dont remember any issue [20:39:26] I'm sure it gets fixed in a future [20:50:46] night!