[19:20:53] NASSP Logging has been started by thewonderidiot [19:24:15] oh right, haha [19:25:50] hasn't been on for a while apparently :P [19:26:13] not that there's been a lot to record over the past week or so, haha [19:31:46] yeah [19:31:51] Thanksgiving I guess? [19:32:33] yep [19:32:44] lots of traveling and family stuff [21:03:33] night! [21:31:32] Hmm. Is it just me or does it seem Guenter stops logging more often than usual? [21:31:53] Has it lost connection recently? I haven't done anything on my end. [21:33:13] hmmm [21:33:16] good question [21:33:22] I haven't really been paying attention recently [21:33:28] (past week or so) [21:33:58] I just figured you were messing around with the server [21:34:07] I can ping you next time I see the logging stop [21:53:24] Yeah. Might be my ISP or something [17:44:01] morning! [17:53:26] hey Mike [17:55:55] what's up? [17:56:26] same as ever, although right now I seem to break the RTCC more than I am fixing it, haha [17:57:23] hehehe [18:15:50] morning! [18:28:51] hey [18:30:18] what's up? [18:31:07] still fixing things while making other things worse [18:31:20] specifically, I changed about one thing to be in GMT instead of MJD [18:31:39] which is correct, the RTCC computed stuff in terms of GMT, from midnight launch day [18:31:58] but oh boy did that lead to many days of changing and fixing code [18:33:17] one or two more days and I can at least build again I think [18:48:50] hahahaha [18:48:53] oh man [18:49:28] yeah that sounds like it would be a hell of a change [18:49:35] with many places to break [18:59:10] it's fairly straight forward changes at least [18:59:22] and it is a good step to it being more like the real RTCC [21:03:18] night! [18:21:37] morning! [18:24:37] morning! [18:41:06] hey [18:43:10] what's up? [18:43:36] slow but steady progress with the MFD update, haha [18:43:58] goal is to have it done before Christmas, shouldn't be too difficult to do that [18:44:38] oh nice! [18:45:13] I think I might be able to AGC4 assembly fully done by then as well :D [18:47:11] awesome [18:47:38] I learned something interesting while working on pass 3 last night [18:48:19] the reason why we never got anything other than "GOOD" assemblies is because what's printed in the listing can only be "GOOD", "FAIR", or "BAD" [18:48:30] the more colorful descriptions go out to the typewriter console [18:48:46] so we probably do have some SUPERB listings :) [18:51:23] so it's different ratings in different places [18:51:39] yep [18:58:26] what I am currently working on is luckily very compartmentalized [18:58:40] it's a lot to go through, but it's now one function at a time [18:58:44] not 1000 build errors [18:59:00] not even 1 build errors, but one issue at a time [19:01:47] haha, that's nice [19:01:59] sounds like a good change of pace from where you were :D [19:03:14] yeah [19:03:23] I did take some shortcuts with the build errors [19:03:26] commented some stuff out [19:03:32] but not too much and it's already fixed [19:32:52] yeah that's a good way to do it [19:49:00] well the functions in question are all implementations of real RTCC routines [19:49:27] in most cases that does give nice results [19:50:03] in some important cases though functions have multiple uses, with a bunch of global memory being used [19:50:08] that is not so nice to implement in C++ [20:24:09] hahaha no, no it is not [20:56:38] so here is the hackiest thing the RTCC software does I have found so far [20:56:54] the RTCC stores large ephemeris tables [20:57:00] it has a header and the data [20:57:27] the data is just many time, position and velocity vectors (so state vectors) in a row [20:57:50] header contains some general parameters, how many state vectors there are etc. [20:58:20] right [20:58:23] sounds reasonable so far [20:58:25] there is a functionality to interpolate between these state vectors [20:58:47] but you don't want to mix free-flight and powered-flight state vectors for that [20:59:21] so what if you want to interpolate e.g. at a time just after a maneuver? [20:59:41] the last state vector inside the maneuver is backed up [20:59:52] the ephemeris header is saved there instead [21:00:11] and the interpolation function is given that modified ephemeris pointing to the header [21:00:31] so it will thing the state vector at the end of the maneuver is the beginning of the ephemeris [21:00:50] think* [21:00:58] afterwards it is restored [21:01:38] hahaha [21:01:44] that makes sense I guess :D [21:01:50] it does, yeah [21:01:55] that sounds like it may be difficult to translate to C++ [21:02:15] I haven't made ephemeris header and table compatible for this [21:02:22] yeah [21:02:43] I used an offset instead, and then some code a bit more complicated than maybe necessary in the RTCC code [21:04:15] it wasn't described very clearly, so it took a bit until I understood that they were doing it this way [21:04:26] "save area that is about to be changed" [21:04:32] "move header to vector" [21:04:39] "restored vector" [21:04:43] restore* [21:05:24] at least I don't need to handle lunar stay phases separately [21:05:30] yeah when all you have to go on is that it can take a bit to figure out what is happening, and even longer to figure out why, haha [21:06:00] lunar stay phase always is bordered by maneuver (descent and ascent) and it's basically treated like free-flight [21:06:20] having a third case for this would be very complicated [21:13:28] yeah [21:13:38] for my port of Yul to python, I'm trying to keep the general logic flow the same [21:14:11] but for data structures like this (symbol table, punch tape data, etc.) I'm just completely reimplementing it to something that works better for the language [21:14:23] so for the symbol table in python I'm just using a dict [21:14:38] instead of the crazy linked list thing that Yul used [21:15:26] oh yeah, I'm using std::vector for this all the time [21:16:01] so data structures I'm definitely doing differently as well [21:17:00] I really want to use the same functions with each having the same functionality though, even if they are implemented somewhat differently [21:17:06] that's what I am struggling with the most [21:17:33] but this hacking in the ephemeris header into the place of a state vector, the thought never occured to me that I should even attempt that :D [21:19:48] hehehe [21:20:07] can you just pass a subset of the table into the function? or add a "starting index" parameter to it? [21:20:52] well that's what I meant with offset, basically the starting index [21:21:10] oh oh yes [21:21:12] I missed that [21:21:13] so it won't use any vectors before that [21:22:44] nice advantage of having implemented a bunch of MCC displays, it let's me this all this quite easily [21:22:51] test* [21:23:42] add a 7 second SEP maneuver at 100:30:00 GET, and then let it interpolate at e.g. 100:29:00, 100:30:02, 100:31:00 [21:24:12] it uses 8th order interpolation for free flight, linear interpolation for powered flight [21:24:41] the display even has the number of vectors used (2 and 9), so that already tells me it differentiates between those [21:25:11] and the apogee and perigee of the orbit is stable even if I use times just before and just after the maneuver [21:25:24] which tells me it doesn't use powered flight state vectors for the interpolation [21:25:45] very nice :D [21:26:42] interpolation is often used instead of numerical integration in calculations [21:26:56] it should definitely be faster [21:27:10] and what if you want to find e.g. the orbital sunrise time if it is inside a maneuver? [21:27:32] then you would have to do powered flight integration and some scheme that survives going back and forth to find the right time [21:27:49] so interpolation is definitely superior for that [21:29:20] of course in terms of storage space having a large number of state vectors saved is bad [21:29:45] but the RTCC computers had megabytes of space. MEGABYTES [21:34:07] oh man [21:34:09] that's a lot of bytes [21:34:11] millions! [21:38:18] yeah. Although I don't really know how much and in what form [21:41:12] disk drives and tape drives [21:41:15] IBM 2314 [21:41:40] https://www.ibm.com/ibm/history/exhibits/storage/storage_2314.html [21:42:40] hmm [21:42:41] no [21:42:54] it was used, but probably not for fast access [21:43:18] the RTCC mission program itself was loaded in IBM 2361 LCS, Large Core Storage [21:45:41] 4 million bytes capacity in the RTCC for that [21:46:25] Apollo 11 mission program size being 3,269,548 bytes as of April 1969 [21:46:39] but I don't know about RAM and ROM [21:46:49] well, RAM [21:50:57] hahahaha [21:51:09] there was 1 Million Bytes in "processor memory" [21:51:14] I didn't know you had a figure that precise, that's great [21:52:03] yeah the "RTCC Operations Support Plan for Mission G" has that number [21:52:13] about every module (function) actually [21:52:21] some of them are not final numbers [21:52:32] but most of them are [21:53:18] actually helps a bit in figuring out how much functionality one module should have [21:53:25] especially when I have zero writeups of them [21:53:50] hehehe [21:55:25] good night! [18:15:08] morning! [18:28:20] hey Mike [18:32:51] what's up? [18:33:27] fixing many bugs, and the ascent maneuver can be put on the MPT again [18:34:03] I had started a bit with TLI, but that is the main thing left now [18:35:21] DOI had a few fun bugs [18:35:46] the special thing about it, is that you throttle up manually to 40% at 15 seconds after ignition and hold it there [18:36:20] but that can be properly modelled now. Not a thing I had to fix from before, but something actually new, lol [18:45:32] hahaha [18:45:33] nice [18:46:28] what I don't think can be modelled is the 10%/40%/100% schedule from the Apollo 9 docked DPS burns [18:46:45] well, burn [18:47:01] oh really? did it lose the capability or were they just never able to model that? [18:47:29] probably never, but then it's not super important [18:47:35] not for such a long burn [18:47:47] where the vast majority of the burn is at 100% thrust [18:48:02] you can probably get it quite close by adjusting the 10% thrust period [18:48:28] but I am not sure [18:49:23] it's mainly important to finding the right TIG, when converting an impulsive burn into a finite one [18:50:03] for the DOI it will be important [18:50:11] fairly short, all of it at 10% or 40% throttle [18:50:22] gotcha [18:50:49] and what was buggy was also the auto throttle up check [18:51:05] the LGC checks if a burn takes more than 95 seconds at 10% thrust [18:51:14] if yes, it does the automatic throttle up [18:51:35] if not and you don't manually throttle up then it will complete the burn at 10% [18:53:28] oh, and the code you're working with models that? [18:53:48] yeah. But you can disable it if you set the time at 10% throttle negative :D [18:54:05] which is needed, as the 40% is the "full thrust" for the burn [18:54:27] so it wouldn't model the manual throttle up, if you let it decide if it should throttle up [18:54:39] ah, cool [18:54:39] DOI is too short, it wouldn't throttle up if you just let the LGC do it [18:54:51] I think they didn't like such a long burn at small thrust [18:55:04] that's why they came up with the 40%. I'm sure there is a Tindallgramm on it [18:56:05] DOI would be a bit above a minute at 10%, vs. 27 seconds with the manual throttle up [18:56:58] there definitely was a "DPS throttling for DOI" meeting :D [19:02:05] haha [19:02:27] Tindall wrote a note to the RTCC people that maybe they should model manual throttling somewhat for Apollo 9 :D [19:03:08] hehehe [19:03:41] but there definitely never was a way to have three separate thrust settings [21:08:45] night! [18:40:32] morning! [18:48:17] I see how it is :P [18:22:25] good evening [18:32:49] morning! [18:37:53] what's up? [18:39:05] I've punch-cardified Solarium up through IMU PERFORMANCE TEST 2, so I'm probably 2/3rds of the way there [18:39:13] and I've almost got the first part of pass 3 working [18:40:09] https://pastebin.com/raw/iyvHNRu0 [18:40:55] for the symbol table listing, it's correctly sorting the symbols, breaking them into columns, and inserting vertical separators for initial letter changes [18:41:13] so now I just need to actually interpret and print the values and healths of each from the symbol table [18:44:28] I'm at over 400 cusses but that's gonna go down really fast soon. most of them are undefined references to PINBALL stuff, and PINBALL is the next big section to transcribe [18:44:49] I would imagine PINBALL having a few references [18:45:03] yep :) [18:46:58] I also have the rating thing implemented now [18:47:01] sounds like you are quite far with it all [18:47:09] so at the moment Yul is calling my work BILIOUS [18:47:20] fair judgement [18:47:25] hehehe [18:47:32] yeah it's coming along really well [18:47:58] how's your stuff going? [18:49:34] slow but steady [18:49:56] the main interruptions are, when I have to think about an intermediate solution for a while [18:50:13] even if this change is big, it can't have everything all at once [18:50:33] so in some cases I am not implementing something just yet, and first have to figure out how to fix it in the mean time [18:50:41] yeah that makes sense, doing it all at once would be super hard [18:50:54] but things start to actually work now again [18:51:41] ephemeris, cape crossing and station contact tables automatically being created with each trajectory update [18:52:00] lots of MCC displays associated with those [18:52:12] most rendezvous programs [18:53:27] for most calculations a thread is created, so that Orbiter doesn't freeze while it calculates [18:53:42] and the function calls there are in a switch-case [18:53:54] so I can fairly systematically go through those and fix them [18:55:25] ah nice [18:56:11] so if you're talking about intermediate solutions, do you have a good feel for what all this first update is going to encompass? sounds like you're planning on doing it in multiple stages? [18:57:19] yeah, I think I know what has to work before I will push it [18:57:31] there is a whole REFSMMAT update which I will not do now [18:57:46] the RTCC stores a whole bunch of REFSMMAT types at once [18:57:57] while the MFD right now only has one, the current one [18:58:16] the other REFSMMAT would get used in various parts of the RTCC, but I'll skip over that right now [18:58:59] REFSMMATs* [18:59:28] and I will not focus on getting 100% of the Detailed Maneuver Table display working just yet [18:59:52] only when that is ready I'll think about removing the old function, that gives you a Maneuver PAD directly [19:00:03] versus what the flight controller would see [19:00:10] for Shuttle they were more clever [19:01:22] https://balettie.com/wp-content/uploads/2015/03/dmt.gif?cb0acc&cb0acc [19:01:50] the Maneuver PAD as the crew would get it is the middle part of the more detailed Detailed Maneuver Table [19:02:03] but they didn't have this format yet for Apollo [19:05:31] oh yeah, that's nice [19:09:07] in my Shuttle FDO MFD I have only implemented that middle/PAD part so far