[22:44:26] NASSP Logging has been started by thymo [22:44:32] I hate my ISP [16:49:06] morning! [16:49:46] Hey Mike [16:49:52] what's up? [16:50:03] Working on some OpenCV stuff for college [16:50:18] oh nice [16:50:23] opencv is pretty cool [16:50:50] Yeah, teacher doesn't have a clue about what he's talking about though. [16:50:58] lol [16:51:31] So much so that I'm having trouble interpreting what he wants with the assignments. [16:51:38] They're in very broken english [16:51:42] oof [16:52:14] that's interesting, are all of your classes taught in english? [16:52:55] We've got multiple international students so, at the moment, yes. [16:53:31] We usually got taught in Dutch during my major though. Only the slides in the lectures were english [16:53:46] Considering the international students get taught at another location. [16:54:04] But during my minor everything's English. [16:54:35] Still getting used to dual monitors :P [16:54:53] Whenever I want to close a tab in my browser I close an IRC channel insted [16:58:24] I'm gonna watch the press conference from the government. Back in a couple of minutes [17:00:42] huh, interesting [17:36:39] I'm back. Measures have been extended from April 6th to April 28th. [17:36:46] What's interesting? [17:38:28] yeah our shelter-in-place order was extended to May 1st yesterday [18:24:38] hey [18:24:56] Hey [18:25:19] what's up? [18:25:26] OpenCV [18:25:53] what's that? [18:26:05] computer vision [18:26:26] I'm following a course about it in college [18:26:51] college, is that the thing that is closed everywhere? [18:27:13] Physically yes [18:27:26] Everything is online now [18:27:27] hey Niklas [18:27:30] hey [18:27:44] testing my NO PDI+12 pad [18:28:00] which mission [18:28:04] that I made before PDI a few days ago on Apollo 11 [18:28:11] July 21st [18:28:30] I had everything right, except for CSI TIG [18:28:31] ah, so direct to CDH maneuver [18:28:36] yeah [18:28:41] my CSI was 0.8 fps [18:28:54] that's sounds really good [18:29:11] CSI TIG seems like something that would be easy to find for this [18:29:14] but it isn't [18:29:24] half a rev before CDH [18:29:29] CDH DV's are high on this one, but thats accurate [18:29:44] yeah, some have crazy high DVZ components [18:30:01] how did you figure out the CSI TIG? [18:30:06] oh wait, I can look in your guide [18:30:34] TAR, REN, CDH, MOD: CDH, TIM: Find GETI, TIG: 1st guess, CLC [18:30:59] ugh sorry you said CSI [18:31:06] so just above that [18:31:23] oh but you might not have the updates I just made [18:31:36] right [18:31:43] I added a separate section for CSI/CDH and TPI [18:31:46] I have to listen to that part in the FIDO loop again [18:31:54] if there is any mention of the CSI TIG [18:32:35] https://www.dropbox.com/s/vmzt2qscwz48tsi/Screenshot%202020-03-31%2012.32.18.png?dl=0 [18:33:37] can you look at the TPI procedure below it too? I think I got that right [18:34:12] sure [18:34:21] just takes a bit to load [18:34:27] tomorrow I have better Internet again :D [18:34:51] ah sorry I forgot haha [18:34:51] I'm just too cheap to add more volume for my phone Internet [18:35:00] I can paste it on here [18:36:07] it's loading [18:37:23] is that even the No PDI+12 CSI in that screenshot? [18:37:55] es [18:37:56] yes [18:38:35] I used to have the CSI TIG calculation in the No PDI+12 section but I separated it its own section [18:38:59] ah [18:40:06] well it might be a bit special for No PDI + 12 [18:40:09] as it's not the initial maneuver there [18:40:09] you just want to get the CSI time that is compatible with the CDH you used in the Lambert targeting [18:40:10] which is half a period before CDH [18:40:11] so that P32 gives the right DH [18:40:55] ok, no browser for me [18:41:02] hmm, thats maybe why my CSI TIG was wrong [18:41:07] haha no worries [18:41:28] kollllllllllloooooolkllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll;;;'' [18:41:33] Ill stop pasting files on here :D [18:41:47] the cat says hello [18:41:49] I think Dan just fell asleep [18:41:52] or that [18:42:03] I was trying to shoo her off the desk [18:43:17] left a nice message before that [18:43:20] some variation of lol [18:43:28] Yeah, I saw [18:43:39] There's three keyboards here and she has to be on at least one [18:44:30] Me being home all the time has screwed up her schedule and she's still wound up about it [18:44:54] I think she's taking this whole thing worse than I am [18:45:33] her favourite keyboard is not hers all the time anymore [18:45:56] Her favorite is actually the lispm keyboard but I'm actually using that one so she got this one [18:46:20] I took a picture of her sitting on that one and it drives the keyboard collectors insane [18:46:38] which is fine because I consider them to be detestable creatures (to put it lightly) [18:46:58] or collectors in general [18:47:17] well there are about 5-10% of good collectors, who share what they have with the world [18:48:07] Collectors are one thing, keyboard collectors will actively destroy working equipment so they can "rescue" the keyboards, which they then either hoard or mutilate to turn them into PC keyboards. [18:48:25] I have recieved legitimate death threats over this particular keyboard. [18:48:39] Those not-people-but-things are insane [18:48:45] I am imagining someone hollowing out a C64 to just use the keyboard [18:49:23] I have been offered $5000 for mine. [18:49:36] what makes yours so special? [18:49:43] It's a lispm keyboard. [18:49:49] They're the "rarest of the rare" [18:50:01] Having one is a status symbol in keyboard collector circles [18:50:27] and the cat also appreciates it [18:50:40] Well, it's larger than a regular keyboard [18:51:28] https://www.youtube.com/watch?v=oDozftThFMw <-- Here's one of them going insane over one that isn't even in a case [18:53:14] This one isn't symbolics (he got it wrong) and doesn't even have a controller [18:53:21] it's a non-functional wall decoration [18:53:26] he paid $12,000 for it [18:53:33] indy91, I think some of the issues with the rendezvous programs are happening with more then 1 maneuver on the MPT [18:53:36] sounds like a collector [18:54:00] AlexB_88, what kind of issues? [18:54:09] you mean the issue you had with the DKI? [18:55:24] hmm not quite the same as the DKI [18:56:13] if I am on the surface, and put an ascent on the MPT, any rendezvous calculations seem broken most of the time [18:56:43] hmm, ok [18:56:51] surface can be tricky [18:56:55] and therefore buggy [18:58:18] in this case (no-PDI+12) after the initial burn, I put CSI/CDH on the MPT (both were good) but the TPI calculation was not working [18:58:43] then I burned CSI, then with only CDH on the MPT, TPI calculation worked [18:59:06] and that didn't even involve LM on the surface [18:59:11] no [18:59:27] another thing was I tried a post-LM insertion yesterday [19:00:01] you better write these things down somewhere, I'll not be able to anything about it for at least a few more days [19:00:13] to od* [19:00:15] to do* [19:00:19] CSI/CDH/TPI calculations weren't looking good (might of been user error too) [19:00:33] sure [19:01:13] I am pretty sure most of these things worked fine at some point, so there must have been a "fix" that broke it again [19:01:38] right [19:01:54] here is my procedure for TPI: [19:01:55] - TAR, REN, LAM, OPT: TPI/TPF, T1: -1:0:0, T2: -1:0:0, N:0, SPH: Perturbed, AXI: Multi, OFF: All 0, CLC [19:02:23] yes [19:02:26] T1: may need to be the desired TPI time though [19:02:50] negative T1 time makes it search the time based on elevation angle [19:03:01] which must be specified on the initialization page I think [19:03:21] there is no init page in that processor [19:03:25] hmm [19:03:53] which led me to my next thing, I accidently somehow made it display T1= 0.00 and had no way of reverting it back [19:03:57] negative T2 time makes it use the central angle like the AGC, 130° usually [19:04:03] t1= E:0.0 [19:04:12] that's elevation angle then [19:04:13] E [19:04:21] how did I implement the input method... [19:04:36] yeah, I accidently made it T1: elevation 0, but could not revert [19:05:05] I finally just restarted with a fresh MFD [19:05:56] I'll check the code for that [19:06:40] two impulse processor [19:07:01] doesn't that use MED P52 [19:07:46] might just for NCC/NSR calculation [19:07:47] just be* [19:23:23] AlexB_88, back :D [19:23:27] have the code open now [19:23:42] two impulse processor inputs [19:24:01] it has three modes, general, TPI/TPF and NCC/NSR [19:24:15] the OFF button has different functions for those three modes [19:24:40] TPI/TPF uses MED P51 values, NCC/NSR mode uses P52 values [19:25:43] only in TPI/TPF mode can it use the negative T1 and T2 inputs [19:25:57] if T1 is negative it will use elevation angle from P51 instead [19:26:20] and as far as I can see to get back to using a time input all you have to do is input a time equal or greater than 0 [19:26:58] so if you got "t1= E:0.0" then the time is smaller than 0 still [19:27:02] elevation angle used there is only input with the OFF button [19:27:25] all the same applies to T2 and the 130° travel angle of the target [19:28:29] and it probably uses the vector time as the initial guess time for the elevation angle search [19:29:11] ah I understand now [19:29:14] thanks [19:29:34] could be made more clear in the display [19:29:40] I'm open for suggestions [19:30:02] so for TPI it would be "P51,0,0,26.6; [19:30:34] "Format: P51, Delta Height, Phase Angle, Elevation Angle, Travel Angle;" [19:30:36] maybe just show the current elevation angle under PHASE and DEL H [19:30:47] P51, 0, 0, 26.6, 130.0; [19:30:56] right [19:31:26] I think you can leave it open so that it won't update a number [19:31:43] so what you wrote is correct and won't touch the 130° or any other value it currently uses there [19:32:19] I guess this setup is optimized for a situation like Apollo 7 [19:32:30] right [19:32:31] you can have separate targets for NCC-1 and TPI [19:32:50] even if it's the same processor [19:32:50] different modes of it though [19:39:41] so I guess your TPI procedure is right, just needs P51 inputs first [19:41:07] your problems with multiple maneuvers on the MPT are probably all the same issue/bug [19:42:14] I see CDH so many times in your guide because that is what the buttons still says [19:42:21] probably will change that to SPQ [19:43:00] it used to be the page to calculate the Apollo 7 NSR maneuver only [19:44:48] ure [19:44:50] sure [19:46:41] I'll change those buttons from time to time so that you don't get bored with your guide :P [19:47:13] oh btw, did you ever test that fix for the AGS? [19:49:40] haven't gotten around to it yet no [19:49:52] Ill do that today [19:50:53] btw I just went back to pre-PDI, I re did the whole NO PDI+12 calculation with CSI+CDH+TPI on the MPT [19:50:57] all worked much better [19:51:12] ok [19:51:29] I still don't know the best procedure for determining the CSI time [19:51:55] I think the procedure in the guide works quite well [19:52:30] with the NO PDI+12 in the MPT, I tweaked the TIG until DH was 15, and that gave a 0 DV CSI [19:53:15] before I had used a TIG that was much later, that also gave a DH of 15, and that was why my CSI TIG was wrong [19:53:30] interesting [19:54:47] one other thing was when I originally calculated it, it was before the CSM separation maneuver/DOI, so I had the CSM sep and DOI burn on the MPT [19:54:50] I'll try to find out the real procedure to determine the CSI TIG [19:54:53] I think I have the right audio file with me [19:55:19] sounds correct [19:56:38] its the same way? [19:56:49] iterated CSI TIG manually? [19:57:16] no I mean "sounds correct" to calculate the No PDI stuff with sep and DOI in the MPT [19:57:23] I doubt they iterated manually like that [19:57:35] maybe someone down the foodchain had to calculate it by hand [19:58:12] you just need to get the orbital period for the time between No PDI+12 and CDH somehow [19:58:16] divide by 2 [19:58:22] subtract that from the CDH time [19:58:25] and you have the CSI time [19:58:56] ah [19:59:05] because that's what P32 in the AGC will do [19:59:10] half a period between CSI and CDH [19:59:34] not that hard to do [19:59:45] which display has the period [19:59:52] orbit digitals [20:00:03] right, but only for the current trajectory, right? [20:00:12] brb [20:03:51] wb [20:03:55] thanks [20:03:58] dont think the checkout monitor has the period [20:04:05] yeah [20:06:29] oh about tweak burns [20:06:53] there is a function in the RTCC called LM ascent rendezvous monitoring (ARM) [20:07:28] and I believe it is a display that refreshes automatically at a fairly low interval and goes through a whole rendezvous calculation to calculate a tweak [20:07:34] even Apollo 11 had that [20:08:01] they would have done a tweak in some cases if they took the descent stage back into orbit for some descent aborts [20:08:19] but it might also be usable for a nominal ascent [20:08:36] the calculations are probably just conics, not integrated [20:08:47] but give a rough estimate of how off you are [20:09:03] and for the short rendezvous profile this because simpler anyway [20:09:30] unfortunately I have not much on this, only the MED inputs for its initialization and a few time being mentioned in the FIDO audio [20:10:19] this becomes* [20:12:53] interesting [20:13:04] although I find the current way works pretty well [20:14:04] yeah [20:14:16] pretty much the same, just more dynamic I guess [20:14:32] they didn't have the luxury of most calculations working instantly :D [20:14:52] so they had to come up with a system that comes close to it [20:15:16] if I ever find more information about it I'll implement it, but not a high priority [20:18:09] right [20:24:56] I am testing my post-insertion scenario again, with a CSI/CDH/TPI calculation [20:30:23] its the Apollo 11 post-insertion scenario from NASSP [20:31:16] when I try and calculate CSI with the procedure to iterate TIG until CDH is 15 NM, then the CDH DV's look weird: DVZ -60 fps [20:32:10] hmm [20:32:16] that's nominal ascent? [20:32:21] yes [20:32:44] what about the CSI TIG? [20:32:46] nominal? [20:33:11] early [20:33:42] if I set CSI to insertion + 50 minutes (nominal) then the CDH DV's are near 0 [20:33:56] well 10 fps about [20:34:10] but then DH is under 12 NM [20:34:21] so maybe the insertion wasnt all that nominal [20:34:58] the actual Apollo 11 mission overshot the CSI altitude a lot [20:35:03] CDH was 18 ft/s [20:35:30] but I guess it's quite sensitive to the CSI TIG [20:35:55] how did you come up with your early CSI TIG though [20:36:58] well I was iterating the TIG to try and force the DH of 15 [20:37:14] but I guess the better thing to do is get the CDH - 1/2 period time [20:38:23] hmm no, that procedure only really applies to the No PDI+12 abort [20:38:52] from lunar ascent you can only really get the 15NM with a perfect launch and ascent [20:38:58] otherwise you don't even want it [20:39:02] TPI time is more important [20:39:19] for lighting [20:40:11] and I think any CSI after ascent that is not happening at apolune is just going to make your CDH DVZ worse [20:40:34] ok so after ascent its CSI at apolune [20:40:59] yeah [20:41:19] in reality you wouldn't want to change the CSI TIG from the pre lunar liftoff estimate [20:41:25] you could, if you have to [20:41:32] if it's quite off nominal [20:41:40] but you would just mess up the tight crew timeline [20:41:56] if you have the freedom then CSI would be at apolune, yeah [20:41:58] so the one displayed by the liftoff page [20:42:02] yeah [20:42:12] what isn't implement is a CSI search mode they added at some point [20:42:20] Apollo 11 already had it [20:42:29] will find the optimal CSI time [20:42:49] they used that all the time for the post ascent CSIs [20:43:35] well "optimum" [20:43:48] in reality, did they have all the times displayed like we do on the liftoff page? [20:43:53] RTCC document says it will achieve both the DH constraint (15NM) and the TPI time constraint [20:43:59] but that isn't necessarily DV optimal [20:44:19] I think the liftoff time processor was outputting to the rendezvous evaluation table [20:44:31] also used by SPQ and DKI [20:44:47] not implemented yet, but we have a source for the display [20:44:59] let me find that [20:47:57] NTRS ID 19740075028 [20:48:00] archived NTRS [20:48:04] do you know how to get that? [20:48:55] hmm [20:48:56] oh [20:49:02] it loaded quick for once :D [20:49:03] https://web.archive.org/web/20100519051814/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740075028_1974075028.pdf [20:49:10] thanks [20:49:19] I can't load it myself though :D [20:49:25] got it [20:49:29] I think it's the rendezvous evaluation table [20:50:09] I think CSI at CDH - 1/2 period would apply to PDI-0, NO PDI+12 of the later mission profiles? [20:50:23] looking at the Apollo 14 timeline book seems to be yes [20:50:34] LM timeline book* [20:50:53] hmm [20:50:58] isn't it easier there? [20:51:04] CSI is not 0 for those [20:51:09] and you already get it from the DKI [20:52:01] or am I confusing that [20:52:36] ah right [20:52:41] the DKI is used for those [20:58:18] I think I found the No PDI+12 calculation in the FIDO audio [20:58:22] talk about a 1 ft/s CSI? that must be it :D [21:01:00] ok so this is starting to make more sense then last night [21:01:08] the post insertion scenario [21:01:31] the biggest issue is the initial trajectory itself [21:02:02] the best DH I can get is 11.6 NM and that gives a good CSI/CDH [21:02:20] oh, I think they used that optimum CSI time capability [21:02:41] as that will find you the right CSI time for DH=15 and E=26.6 at the desired TPI time [21:03:01] guess that needs to be a priority to be implemented then :D [21:03:15] last night I was trying to force a CSI to give a 15 NM DH CDH, and my apolune was only 42-43 NM, I can see why DV's would be weird lol [21:04:04] right [21:04:48] FIDO calculated it that way [21:04:58] some other person came up with a slightly different number [21:05:03] leading to this conversation [21:05:21] "Did you iterate on it, FIDO?" "Yeah" "That's cheap" "I hear ya" [21:05:31] I guess the other person did it manually :D [21:05:45] callsign Rendezvous I think [21:05:54] at least I know the MPT now doesnt seem badly broken like I thought it was last night [21:06:14] more of a "garbage in garbage out" [21:07:07] that's very easy to do with the MPT [21:07:23] Dynamics, the person taking the RTCC inputs from the FIDO, is very much a "filter" [21:07:36] often adding inputs that FIDO was missing [21:07:50] or changing them on the readback to him as he knows FIDO said it wrong [21:10:26] "di you iterate on it" the CSI TIG? [21:10:34] yep [21:10:42] like what I did [21:10:46] computer did all the work [21:11:01] yeah, except with automatic version of it [21:11:12] with the* [21:15:55] hey my download worked [21:16:06] PDF page 31 of the document I linked earlier [21:16:31] that's a display for the DKI, SPQ and also the launch window procesor [21:16:53] looks a bit like a modified MPT [21:17:21] ah yes [21:20:49] P52, "nominal time of NSR" [21:21:05] does that need to be set to something? I usually leave it blank [21:21:29] ie. NO PDI+12 P52,,15,-4.475; [21:21:31] hmm [21:21:32] nah [21:21:53] the real Two Impulse display (there is more than one actually) will show some numbers for that [21:21:59] but for us right now it's not relevant [21:22:14] "Two Impulse, DH 15, Delta Theta -4.475, elevation angle 26.6, central angle 130" [21:22:28] I am just at the point where the FIDO does the calculation [21:22:41] and then the fixed TIG time and the arrival at CDH [21:22:48] but then you can also let it vary the arrival time [21:23:19] 60 seconds icrements, 600 seconds total range [21:26:11] and they must have had a way to then figure out which solution gives the right TPI time [21:26:24] within a minute I guess [21:28:04] does ascent processor solution placed on the MPT change the config to LM Asc? [21:32:33] I think the config after the maneuver it uses is always LM Asc, yes [21:32:45] ok [21:32:57] ... [21:33:06] which is not always the case [21:33:20] although I don't know if there is any way to put a descent abort on the MPT [21:33:30] I would say that ascent processor solutions placed on the MPT are buggy [21:35:17] I have a pre-launch scenario, I did a liftoff (concentric) calculation + ascent processor and placed it on the MPT [21:35:55] noted the liftoff CSI estimate, and then calculated a CSI pad but the DH is no where near valid at the estimated CSI time [21:36:00] -20 NM or so [21:37:36] so I think the 2 issues I have seen is that (post ascent state vector on MPT )from ascent processor and the other is the DKI compatibility with MPT issues I was having [21:37:40] hmm, ok [21:41:08] maybe that would explain that weird phasing issue we observed a few days ago [21:41:24] oh yes [21:41:27] definitely possible [21:41:35] that was based off a DOI+PDI+ascent on the MPT [21:41:40] both issues should be easy to check [21:43:40] getting late, good night! [17:05:22] morning! [17:08:26] hey Mike [17:08:37] what's up? [17:10:59] just doing some RTCC MFD tests with Apollo 17 [17:11:20] the only mission that isnt yet really compatible with the new features [17:18:05] nice :) [17:33:17] Evening [17:35:54] hey [18:15:49] hey [18:16:59] yo [18:19:35] hey [18:19:39] what's up? [18:19:46] playing with Apollo 17 again [18:20:54] trying stuff with the GPM for DOI-1 and 2 [18:21:10] definitely one way to do it [18:21:26] I still don't know what they would have actually used for that [18:22:20] I'm writing a bit for the TLMCC and LOI guides [18:22:29] for the manual [18:22:32]