[19:00:18] NASSP Logging has been started by thymo [19:00:30] had a question about the DKI, the MPT is not yet compatible with is I guess? I tried a PDI-0 but could not get a valid solution unless MPT was off [19:00:47] it should be compatible so that must be a bug [19:00:52] the PDI-0 PAD is read up before the CSM CIRC [19:00:56] I see [19:01:29] it didn't calculate at all in MPT mode? [19:02:00] I noticed it didnt have the "chaser/target" logic that the Lambert and SPQ now have with MPT on [19:02:07] hmm [19:02:12] it gave no good values [19:02:54] I wonder if it is only partially compatible, so you might still have to calculate from the vehicle you want to be the chaser [19:03:11] that could be [19:03:47] but I will of course implement that chaser/target option for it as well when I try to find the issue [19:07:47] ah ok [19:07:52] Ill try it from the CSM [19:15:20] current FIDO doesn't believe in getting DOI DVZ to 0 [19:15:53] but he is kind of stuck with it because previous FIDO made it that way and it's a bit too late to play around with it [19:24:24] yeah, I kind of listened to that part myself [19:24:32] just before MCC-2? [19:25:45] about 2 to 2.5 hours before MCC-2 [19:27:24] I'll continue listening to the accident, should be some interesting stuff about how they are planning MCC-3 and 4 [19:27:48] although I don't expect them to make many adjustments for DOI DVZ or rev 2 time or so [19:27:58] not on this mission [19:29:51] Apollo 13 is such an annoying mission to get this audio for, they do the whole LOI/DOI thing but in the totally wrong way! [19:34:45] morning! also lol [19:36:19] hey [19:42:51] and I still need to implement that "integrated" DOI option, the calculation in the LDPP is degrading somewhat over so many revs between DOI and PDI [19:43:19] we don't have that documented anywhere, but the Apollo 13 FIDOs keep mentioning that option [19:53:50] indy91, is there an easy way to find the SIVB SEP FDAI = X Y Z inputs all missions? Maybe converting the LVDC_XLunarAttitude string? [19:55:02] right, although in my trials, PDI time predicted by the LDPP is still quite accurate [20:07:33] the sep attitude on the TLI PAD? [20:08:16] oh inputs [20:09:50] so converting the LVDC_XLunarAttitude to the numbers you need to input for the 0 DV maneuver? [20:10:14] yeah [20:10:36] I want to make a list of them for all missions [20:10:50] yeah, I was thinking about a list like that as well [20:11:04] pitch will always be 120° I guess in the LVDC LVLH coordinates [20:11:11] I made a "mission-specific data" page in my guide [20:11:30] the numbers I've seen being used are 0°, +/-30 and +/-40 for yaw [20:12:00] it's essentially just a different convention for the order of pitch, yaw, roll, I had written a small script to do it [20:12:22] but if you want to make a list I can generate all the numbers for the yaw angles above [20:12:48] ok [20:13:15] or add it in some of the Excel tools we have [20:13:30] so P: +41.561, R: -131.93, that is valid for all launches? [20:13:45] just the Y that changes [20:14:04] no, it's the same pitch and roll in the LVDC LVLH coordinates [20:14:12] in LVDC_XLunarAttitude [20:14:32] that's always 120° pitch and 0°(I think, or 180) roll [20:14:46] just the yaw changes [20:14:59] right [20:15:00] but then in the different convention that the RTCC uses all three numbers change [20:15:14] I see [20:17:04] I don't think there really is an easy way to do the conversion [20:17:26] I calculate a rotation matrix from the three LVDC angles and then extract the RTCC type of angles from that matrix [20:18:03] more trial and error than knowledge of coordinate systems really [20:18:51] right [20:26:30] I guess the difference is, one of the two convention will always make you heads up/down with 0/180° roll and the other won't [20:27:02] maybe it's the RTCC one. Then we would have at least found one advantage to it [20:33:51] night! [17:22:16] morning! [17:28:39] hey [17:29:02] what's up? [17:29:34] just finished writing a "QRH" for RTCC MFD [17:31:13] nice :) [17:31:18] basically a guide that gathers all the inputs that you need for a given mission [17:31:34] you? [17:32:11] facing the restorer's dilemma again [17:32:32] I'm making really good progress on this computer buffer unit, but it would be so much easier to go forward if I removed the potting [17:32:44] and I'm torn between doing that or leaving it pristine [17:33:35] ah I see [17:33:40] I'm also learning that the documentation I got from North American for this box is utter garbage, and a good number of the test points are actually important-looking inputs lol [17:35:47] https://photos.app.goo.gl/nnh3VJqrbBsZPZPB7 [17:36:06] the white stuff is a super soft rubber and could be removed without too much difficulty, especially for that module [17:42:07] what is the unit part of? [17:43:18] this box is the G&N Computer Buffer Unit [17:43:40] it was the part of the DTCS that sat at the top of the mobile launch tower and sent commands into the AGC [17:43:47] all padloads would have gone through it, for example [17:43:57] ah interesting [17:44:19] https://photos.app.goo.gl/ZYii8a8TV3cf4B147 [17:44:22] there's the whole album [17:45:09] nice [17:46:51] I was looking at one of those and thought "is that a USB port?" :D [17:47:16] hahahah [17:47:22] USB would make this much easier and cheaper :D [17:47:40] I bet [18:24:41] hey [18:27:31] hey Niklas [18:28:25] hey Niklas [18:28:51] I have pretty much finished the guide [18:29:23] nice [18:29:26] I would like to put in the NASSP document folder when its ready [18:29:33] sure [18:30:29] oh and I figured out the inputs for the SIVB sep angles [18:30:53] CSM LVLH P: +120 Y: +/-40 R: 0 = LVDC LVLH P: +41.6 Y: +/-120.8 R: +/-131.9 CSM LVLH P: +120 Y: +/-30 R: 0 = LVDC LVLH P: +48.6 Y: +/-130.9 R: +/-139.1 [18:31:22] I think thats right [18:32:05] sounds about right [18:32:11] well, you figured those out, I just went and found them in the logs :D [18:32:32] but I made a list for each mission [18:32:50] the ones with the 120° pitch are the LVDC coordinates though [18:33:06] and the other is the MPT [18:34:01] the only thing missing there is the 0° yaw case, I think Apollo 8 had that [18:34:07] I'll calculate those for you when I can [18:35:13] right [18:36:15] if theres anything to add or change [18:36:48] I have really bad Internet right now, I'll try to download it, the connection might drop :D [18:37:12] no worries [18:37:24] the size is 137 kb [18:38:37] ok [18:38:37] just opening the browser is scary :D [18:50:07] I guess your connection did indeed drop :D [19:01:20] the guide is good [19:03:16] I got to MCC-2 today in the Apollo 13 FIDO loop [19:03:33] there was a bit of talk about the burn using the short burn logic (3.5 seconds burntime) [19:04:14] the MPT CSM burn simulation will execute the burn like the CMC [19:04:26] so for short burns that can mean that the desired DV isn't exactly achieved [19:04:29] but [19:04:36] using the iterate option fixes that [19:04:53] anf the iterate option now works like in the real RTCC apart from some fixes maybe [19:05:25] so if you have trouble with some short burn not achieving the DV you wanted exactly, use iterate [19:05:58] interesting [19:06:14] I think I ran into that issue before while building an Apollo 9 rendezvous plan [19:06:23] I guess the Apollo 13 MCC-2 really is that small [19:06:36] short burn logic is up to 6 seconds [19:06:55] although 1-6 seconds will be very close to the targeted DV [19:07:24] I added a note for which maneuver requires iterate in the guide [19:07:46] definitely LOI, but the Apollo 13 FIDOs also used it for MCC-2 [19:08:02] I think I had added it to LOI, LOI-2, DOI [19:08:10] the AGC doesn't update the cutoff time during the burn for any maneuvers shorter than 6 seconds, so that's where there can be a over or underburn [19:08:23] maybe not really needed for LOI-2/DOI [19:09:06] I did notice the LOI-2 hA/Hp was a bit more accurate on the MPT with iterate [19:09:16] it's useful for all long burns and apparently also for the short burns to compensate the short burn logic [19:10:06] I wonder what the combination iterate + impulsive TIG will do [19:10:35] haven't seen anything in the iterate logic that it would NOT change the TIG [19:10:49] these same options also existed for the Shuttle maneuvers [19:10:56] in the Shuttle FIDO Console Handbook [19:11:18] and there it is quite clear that that only changes the DV vector, not the TIG [19:11:36] should impulsive TIG be used for MCC's? [19:11:42] no [19:12:03] I think you would only use that to model onboard targeted maneuvers [19:12:08] CSI, CDH, TPI would be on time [19:12:29] right [19:13:08] it's funny though, when the FIDO for MCC-2 talked to the FIDO from the previous shift they talked about the earlier one doing most of the MCC-2 FIDOs job [19:13:32] and the MCC-2 FIDO then said his proudest achievement was to have MCC-2 on time with regard to the flight plan [19:14:00] so what he did was change the MCC-2 impulsive TIG so that the actual TIG would be on a full second, the flight plan value :D [19:14:07] that's one way to do it I guess... [19:14:45] I sometimes though of doing that on my missions [19:15:10] seems a bit trivial though lol [19:16:00] maybe it helps for crew monitoring [19:18:09] or to keep a bored FIDO busy [19:18:43] tell him to just wait 20 hours or so :D [19:18:54] did you keep listening a bit after MCC-2? [19:18:59] not yet [19:19:25] they are betting on something, Jack Daniels vs. Pepsi [19:19:36] either about DOI DVZ or DOI calculation runtime [19:19:44] didn't quite understand it [19:20:03] oh really [19:20:17] and if that seems a one sided bet, the person betting the Jack Daniels was quite sure he was right and did win [19:21:18] that's as far as I got [19:21:32] and I think they will actually use TLMCC mode 4 for MCC-3 and 4 [19:21:39] for later missions as well [19:21:44] not always, but as an option [19:21:49] oh [19:21:54] hmm [19:21:56] to get DVZ to 0 and the rev 2 time crossing right [19:22:13] I think that just isn't really possible with mode 1 [19:22:47] so even the updated mode 1 from MCC-2 cant help much for MCC-4 I guess [19:23:15] I'm sure they would run both modes [19:23:29] and use the mode 1 burn solution if DOI DVZ and rev 2 crossing time are ok [19:24:40] makes sense [19:27:42] with the right constraints that shouldn't be a problem [19:27:56] but I haven't tried it much, using any of the BAP modes for MCC-3 or 4 [19:28:08] just testing it now [19:28:19] Apollo 14 MCC-4 with mode 4 [19:28:41] Apollo 14 and 15 both had an MCC-4 I believe [19:28:55] yeah [19:29:58] and for both I have documents that talk about MCC-4 adjust the DOI DVZ and rev 2 time [19:32:38] works good [19:33:40] Ill ad a note on that for MCC 3&4 in the guide [19:34:10] so I guess all missions with a constant lunar arrival GMT [19:34:15] Apollo 14-17 [19:34:26] hmm 13 as well? [19:34:57] if the pericynthion height is varying over the launch window then it's constant arrival GMT [19:36:22] not on 13 [19:36:51] ah no [19:36:59] 210 to 60 NM [19:37:01] so yes [19:37:04] yeah [19:37:13] Apollo 12 its fixed [19:37:17] that gets you the same lighting conditions for any launch [19:37:22] launch time [19:37:28] at the landing site [19:37:38] I was under the impression that only Apollo 14+ had that profile\ [19:37:39] but you can't always do it because of permance [19:37:42] performance [19:37:49] and maybe Earth-Moon geometry [19:37:57] I guess since the flight plan doesnt have the "REV 2 GET" note [19:38:14] but I guess there is a fixed value for that [19:38:32] do they talk about it in the tapes REV 2 GMT or so? [19:38:45] they used the time between 13 and 14 to change some procedures regarding the SCOT and the mission timing [19:39:01] no, I don't think they were worried about that [19:39:25] pretty early one they put in the arrival time constraint for the TLMCC processor [19:39:32] to get the LOI time about right [19:39:41] but nothing beyond that [19:39:42] ok [19:40:40] I guess it comes down to lunar science requirements, which become more important later on, especially the J-missions [19:40:49] you want the lighting as planned at all times [19:41:01] I guess they would do an on-board liftoff time update in the case of a late launch (even for Apollo 13) [19:41:08] and arriving at all spots on the moon all the time [19:41:16] if the time of arrival was constant [19:41:25] good question about 13 [19:41:33] as the flight plan doesn't have much on it [19:41:40] I'm not so sure actually [19:41:51] they might have done some extensive flight plan changes [19:41:54] hmm but the SCOT also has a constant flight time value [19:42:10] usually there is a range when the arrival is constant GMT [19:42:53] weird [19:42:59] Apollo 14 has a range [19:43:12] and a fixed sun elevation angle at landing [19:43:32] Apollo 13 flight time fixed, and a range for the sun elevation [19:43:41] to me thats not constant arrival GMT [19:43:45] yeah [19:44:27] I wonder if the 2nd TLI opportunity is 60NM pericynthion [19:44:32] for the full launch window [19:44:45] and the high pericynthion is just for the 1st opportunity [19:44:57] there was some document talking about this topic [19:45:02] have to find that again some time [19:47:59] yeah [19:48:40] mode 4 up to MCC-4 time seems to work well [19:49:49] mode 3 and 5 won't work too well I think [19:50:05] there are a bunch of documents that talk about the need to use mode 1 for MCC-3 and 4 [19:50:20] but I guess that applied to the pre LOI/DOI missions [19:50:39] well, pre Apollo 13 [19:50:57] Apollo 13 had its own MCC targeting, different from 12 and before and 14 and after [19:51:22] separate RTCC requirements document which we don't have [19:51:56] but it seems to support using mode 4 for the MCC-3 and 4 [19:52:14] did 13 use mode 4 for MCC 3 & 4? [19:52:30] I guess for the DOI DVZ [19:53:00] they talked about doing that post MCC2 [19:53:16] not sure they already did it, I think first they tried a LOI without MCC-3 or 4 [19:53:38] and followed by a DOI calculation, which was that bet aboutr [19:53:55] pericynthion is a bit too high, so they got a high DOI DVZ [19:54:59] this is my latest note on that: MCC 3&4: Option 1 (on Apollo 13+ , option 4 may be used to ensure proper post-DOI ellipse) [19:55:33] hmm not post-DOI [19:56:20] post-LOI I guess [19:56:29] yeah [19:56:42] post DOI ellipse is done by the LDPP [19:56:54] even if that might get you a high DVZ [19:56:59] or even high apolune [19:57:58] at least that issue is mostly fixed, right? [19:58:08] not even being able to get a 60NM apolune after DOI [19:58:24] that's what we had initially most of the time [19:58:30] only issues I get is with Apollo 17 LDPP-wiese [19:58:34] yeah [19:58:35] wise* [19:58:56] not only 17 really, they used some sort of alternative method for DOI in some cases [19:59:45] that Apollo 14 document you got from UHCL says [20:00:13] "DOI was generated with a processor other than the FDO would use in real time to generate this maneuver", talking about the SCOT [20:00:28] I mean I did get (I think) a good solution with Apollo 17, by biasing the ROT parameter in TLMCC/LOI targeting, then using the GPM for DOI [20:00:33] right [20:00:45] why do you get your documents and I never got mine about Apollo 16, that would help us right now :D [20:00:59] that is weird [20:01:24] maybe they still remember all the SCOTs you asked them :D [20:02:04] and the IBM RTCC documents [20:02:25] of which I still don't have all [20:02:45] although the remaining ones are very likely ones I already got from the archived NTRS [20:02:54] all about AS-200 rather than AS-500 [20:03:03] so definitely nothing lunar [20:03:26] do you have all the lunar ones? [20:03:33] yes [20:03:40] all the AS-500 documents they got [20:03:49] and it's still only maybe 1/3 of all RTCC equations [20:04:05] and if I remember only earth-centered RTE left to implement [20:04:25] yeah, RTE is a topic I will go to next [20:04:40] I did implement a lot of the Earth-centered RTE logic already [20:04:49] used by the tradeoff displays [20:05:04] Ill have to learn that [20:05:20] not too complicated really [20:05:23] I guess those will help with finding the best abort solutions? [20:05:40] yeah, give an overview of DV, landing times etc. [20:05:54] how it works in the real thing is that there are separate conic processors for Earth and Moon centered. [20:06:17] and that is used as initial guesses for the precision logic, which is for both Earth and Moon [20:06:31] for us it's entirely separate logic right now [20:06:55] with the Earth centered RTE logic still using AGC equations rather than RTCC [20:08:50] I put some not-so-ideal precision logic on top of the conic Moon-centered logic from the RTCC documents [20:09:03] which might be the source of the TEI inaccuracies [20:09:35] so when I revisit that the precision logic will use the generalized iterator and hopefuly work properly [20:11:08] ok [20:11:36] so MOD: Near-Earth/Remote-Earth [20:11:57] whats that for? [20:12:04] ok, so the RTE tradeoff display has 5 pages you can scroll through [20:12:19] I think they had a button for that on their consoles in the MOCR [20:12:37] you can generate 5 separate plots for TIG vs. DV [20:12:48] with... one of those options, forgot which :D [20:13:03] but the other options uses 3 of the pages at once [20:13:06] option* [20:13:34] ok [20:14:01] does all this need a TEI solution to be pre-calculated or does it work independently? [20:14:05] TIG vs. DV, TIG vs. splashdown latitude and TIG vs. splashdown time [20:14:24] oh, it's quite useless anywhere but in TLC [20:14:39] ah [20:14:45] it works on its own [20:14:52] I think I only made it work in MPT mode [20:15:16] maybe, but that doesn't necessarily have to be that way [20:15:28] is there a specific abort it would be used for? (direct or fly-by/pc+2) [20:15:40] no [20:15:44] it's really just plots [20:15:53] it calculates many aborts at once [20:15:59] only using conic logic [20:16:02] ok [20:16:13] all you get is an idea of which TIG gives you which DV [20:16:41] it would work in the Moon sphere of influence as well, but I didn't make that work yet [20:17:04] the Apollo 11 RETRO made a lot of hardcopies of the tradeoff displays [20:17:16] and I think he gave them to people working on recovery [20:17:32] for all the landing areas [20:17:59] so they could get an idea, if they abort at that TIG then they would splash down at that GET [20:18:36] so the MOD option, doesn't really matter either way, just try it and you will see [20:20:16] I'm not quite sure, but I believe they didn't implement the lunar search option for TEI in time for the Apollo 8 mission [20:20:37] so they would maybe have used the tradeoff display to find the TIG [20:20:44] very crude method of course :D [20:22:28] right [20:23:20] back to the short-burn logic for MCC's being used, the threshold where you would want to iterate is 6 seconds and less? [20:24:34] well, I don't think there is any harm in always using iterate [20:24:57] it's definitely better for long burns as it will be more precisely simulating the burn with changing gravity [20:25:01] like LOI [20:25:32] ok [20:25:55] and for short burns it will kind of compensate the burn not being executed (in the burn sim) exactly as you wanted to [20:26:12] so all burns basically [20:27:28] I really don't see the harm other than runtime [20:27:29] which is not much of a concern for us [20:27:30] the iterate option iterates on 4 variables, TIG, pitch, yaw (so burn direction) and DV [20:29:11] iterate option has to simulate the full burn many times until it converges on the desired trajectory [20:29:18] so I think that's the only downside really [20:29:45] other than it being a fairly new feature in our RTCC and needing more testing :D [20:30:08] https://web.archive.org/web/20100525000249/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19730062603_1973062603.pdf [20:30:16] this is one of the IBM RTCC documents [20:30:24] it has a pretty good section about the RTE [20:30:39] and explains what the tradeoff display shows and what's it used for [20:30:47] starting on PDF page 222 [20:33:19] thanks [20:35:14] you said earlier "CSI, CDH, TPI would be on time" I guess that would not be iterate? [20:35:23] yes, right [20:35:50] hmm and impulsive TIG? [20:35:55] using a different TIG in the RTCC than the onboard times would just be messy procedurally [20:36:02] hmm [20:36:54] I have the RTCC documents with me, I can look how it should work [20:40:55] Hey, quick question. Is doing an azimuth change in the AGC enough or do I also need to uplink to the IU? [20:40:56] ok, I think what it would do without iteration and impulsive TIG is consistent with the onboard calculations [20:41:19] Thymo, you want to launch later in the launch window? [20:42:15] No, I'm doing Apollo 7 to the ISS. Wanna play around with rendezvous and stuff. [20:42:20] oh [20:42:22] hmm [20:42:42] we don't really have flexible launch targeting like that yet [20:43:13] you would have to change LVDC parameters in the scenario, no uplink for that yet [20:43:33] although a bunch of necessary steps for that are already done [20:43:46] in the Saturn IB LVDC at least [20:44:50] let me look how I implemented that [20:46:31] changing the LVDC azimuth parameter in the scenario might be enough [20:47:20] other required numbers are calculated from that azimuth [20:47:38] for both Saturn IB and V [20:48:09] Right. I'm already halfway through prelaunch though, I can do an inclination change in orbit. Launch azimuth is 72 degrees and ISS is on 67 [20:48:41] However, we do need a launch trajectory to Venus at some point :) [20:48:47] yeah [20:49:12] in the Saturn IB LVDC I already implemented the logic for launches to Skylab [20:49:24] Nice [20:49:29] with the same few input parameters, but unfortunately no uplink for that yet [20:49:59] that would cover your case nicely of course [20:50:39] but without closing the scenario you will have a hard time getting to the ISS [20:51:19] I can just separate and work from there can I not? [20:51:32] im about to PR the guide [20:52:10] sure, but you would have to do a pretty large plane change maneuver to get into the ISS orbit [20:52:31] AlexB_88, I can't do PR merges right now [20:52:57] ISS orbit is currently directly over the cape. Should be good right? [20:53:23] Apart from the 5 degrees of inclination error [20:53:25] ok, no rush to merge it [20:54:10] if you get the difference in the ascending nodes to almost 0 (so near perfect launch time for the ISS orbit) then you might have enough DV to get there [20:55:58] AlexB_88, what I was saying about the impulsive TIG, it should do the same rotation of the burn direction as the AGC does [20:56:07] Oh, I guess that's a no then. [20:56:23] so if it was calculating a DV with P32 and giving it to P40 [20:56:39] the no iteration and impulsive TIG is consistent with that [20:57:01] makes sense [20:57:01] I'd love to dive deeper into how the LVDC actually works. However my orbital mechanics knowledge is pretty much limited to knowing how to raise my apoapsis and periapsis. [20:57:36] maybe you want to read the LVDC Equation Defining Documentsthen [20:57:39] Document* [20:57:43] I guess I just change LVDC_Ax[0]? [20:57:49] it's on the Virtual AGC website [20:58:02] are you launch Saturn IB or V? [20:58:05] launching* [20:58:07] 1B [20:58:38] hmm, I thought the 1B didn't even have LVDC_Ax anymore [20:59:10] let me check [21:01:35] is LVDC_Ax in the Apollo 7 launch scenario? [21:01:58] It is [21:03:05] I'm a bit Internet challenged right now [21:03:05] just takes a bit longer [21:07:26] Welcome back [21:07:54] Ax[0] is also hardcoded in the source as 72. Comment: Azimuth polynomial (AS-205) [21:08:03] LVDC.cpp:374 [21:08:32] found it [21:08:35] Azimuth = Ax[0] + Ax[1] * Inclination + Ax[2] * DescNodeAngle + Ax[3] * Inclination*DescNodeAngle; [21:08:52] that's for Skylab launches [21:08:55] so if you set Ax[0] to what you want and keep the others 0 [21:09:01] then you'll launch to Ax[0] [21:09:52]