[15:32:08] NASSP Logging has been started by n7275 [15:32:10] hello [15:32:56] hey [15:34:53] hopefully a one day project lol, make LVDC cutoff timing slightly more precise [15:35:14] I think all the flowcharts are helping a lot [15:35:55] are we over/under-burning? [15:36:46] overburning now [15:36:57] before venting it was a bit underburning [15:37:30] or rather, J-2 burn was slightly over on average, but lack of venting meant overall the pericynthion was low [15:37:53] I caught some bits of information on Discord, but I don't watch it closly enough [15:37:59] the on average is key, I believe we got a randomness factor in there at the moment because cutoff condition isn't checked often enough [15:39:01] cutoff is checked every 1/25 second in the minor loop [15:39:19] 1/25 at nearly 2G is already 2 ft/s which propagates to 20 ft/s error at MCC-2 time [15:39:25] that is what Ryan had [15:39:49] 2 ft/s from the slightly delayed cutoff timing I mean [15:41:51] what change are you making? [15:43:49] two things probably. One I had already accounted for with a time bias, but the actual command for S-IVB cutoff is slightly delayed because of lengthy switch selector processing. [15:44:43] switch selector commands take several steps to do, but for S-IVB cutoff it has some special logic to prepare everything already ahead of time and then do the final step with precise timing [15:45:02] I was confused how that worked for TLI cutoff, but the flowchart told me immediately what I got wrong before. [15:46:00] this change shouldn't make a huge difference because I had implemented a time bias. The other change would be for scheduling cutoff. [15:46:19] There are some status flags involved in this in the flowchart, hopefully it doesn't get too complicated [15:56:01] flags that need to be reset somewhere between 1st and 2nd S-IVB cutoff, I am not finding where that is done in the flowcharts... [15:56:35] there is a slightly cheaty but easier way, then I don't have to add new variables :D [16:39:29] morning! [16:46:02] hey Mike [17:02:00] what's up? [17:11:24] hey Mike [17:11:41] argh nothing is ever easy, I thought this was going to be a quick LVDC improvement... [17:11:55] hehehe [17:12:04] those darn rabbits have dug holes everywhere :D [17:41:07] I can't deal with this right now haha [18:30:40] speaking of rabbit holes, Mike. just the PCM decommunication part of that document is quite the adventure [18:32:30] hahaha oh yeah? [18:44:02] I read the section on how the two memories interact with eachother last night and I' [18:44:11] m still not sure I know how it works [18:48:23] the frame and subframe synchronization seem to work very similarly to how our telemetry client does though [18:50:51] nice! [18:53:52] anything about the word order code? [18:54:43] our telemetry clients will need to have their frame synchronization code rewritten because of erasable memory dumps [18:55:09] I sorta got something working, but it was a bit of a mess and special cases [18:56:28] the word order code bit is currently not used by our code, but it will have to be for clean switching between normal downlink formats and the erasable memory dump one [18:59:14] that's where I need to do a bit more reading [19:00:30] it almost seems like bits from the downlinked words are used as or as part of opcodes in the decommunicator [19:00:47] maybe I'm misreading it though [19:06:57] yeah I am sure something like this is done [14:35:45] hey [16:20:39] morning! [16:20:46] hey guys [16:21:46] hello hello [16:26:39] what's up? [16:27:14] exploring the wonderful world of bitmaps in Orbiter... [16:27:53] lol you've picked some fun things to work on this week :P [16:30:55] LVDC is fun haha, it just wasn't a simple one day project that I originally thought it would be [16:31:18] of course this issue goes away when the real software is cleared to be used in NASSP :P [16:32:47] someday hopefully! [20:08:38] night! [12:44:12] hello [14:54:34] good morning [14:55:35] good afternoon! [14:56:48] my next document to study is... past IRC logs to remember what Alex said that lead me to put the failure PR back to draft and abandon the project for a few months :D [14:58:05] the ATDP must have just been released, because he mostly talks about that haha [14:58:30] and also [14:58:33] [17:36:05] Not to get too far ahead of ourselves, but do we know enough about that Belcomm 3-inpulse trajectory to impliment a mission design around it? [15:03:22] I've changed the UI in the PAMFD so far, all available malfunctions can be set/reset in it now. Previously a lot of them required scenario editing. [15:04:09] Maybe this is also a good tool to e.g. plan a sequence of failures for someone else, then copy and paste the malfunction section to another scenario for that [15:11:11] whoops, got distracted for a bit. I'm back. [15:12:53] I will confess to not being super well-versed in that 3-impulse document. I'm happy to do some research though. I havn't read it in a while [15:16:54] I've mostly focused on putting together some code to optimize specific lunar missions so far. The current ATDP does some analytic initial guesses so that an integrated trajectory can converge and then it immediately goes into the complicated code to run the one mission profile it works with. [15:17:12] so what I have there is not very flexible [15:18:07] There have also been a bunch of papers with three impulse LOI during the Constellation program era [15:18:27] for a while that was the planned lunar landing mission profile [15:18:43] probably not anymore with Artemis and its lunar orbit station I guess [15:20:30] I think there are a few variations in the specific profile that have been thought about [15:21:49] my ideas for some advanced, analytical planning tools should enable it to just brute force search through all possible trajectories to find the optimum one [15:31:37] all sources agree about no plane change during LOI-1 and then after LOI-1 you are in an orbit with a one day period [15:32:27] where exactly LOI-1 happens, if it rotates the line-of-apsides at all, where LOI-2 exactly happens (near apolune) and if LOI-3 does any plane change is sort of undecided and up to optimization [15:35:53] in terms of a schedule I think the 24 hours coast works out fairly well. You maybe have a rest period after LOI-1 [15:36:01] hmm [15:36:07] maybe better after LOI-2 [15:36:27] and then LOI-3 and a possible CSM DOI can be done on the same day [15:37:00] LOI-3 gets you a 60x60 orbit, everything else just because overly complicated [15:37:05] becomes* [16:24:14] do we have any of the referenced documnts from the belcomm 3-impulse document? [16:32:40] one of the other Bellcomm documents we have [16:33:19] NTRS ID 19790072380 [16:33:45] which I don't find overly useful [16:34:23] "PATERN, A Direct Search Minimization [16:34:27] Routine" I have a TRW document with a routine of the same name [16:34:49] "Mission Analysis and Open-Loop Trajectory [16:34:55] Targeting Theory for the Bellcomm Apollo Simulation Program" this would be a great find, but we don't have it [16:37:30] that TRW PATERN is actually the one I want to employ with my optimization scheme [16:56:23] morning! [17:05:38] hey Mike [17:11:30] what's up? [17:12:27] jumping between projects a bit, but I went back to my failure simulation branch and I think I made a good UI change [17:12:32] and you? [17:14:43] more or less same haha [17:15:12] I got a new laptop recently and have been spending a lot of time making sure everything works on it [17:15:22] which has required lots of changes to the rope reader and AGC monitor GUIs [17:18:50] but also I've been making good progress on my resolver compensation circuits [17:25:49] ah nice [17:26:23] my PC feels almost new now that I figured out how much garbage various VS installation had left in temporary files [17:26:52] hahahaha nice [17:27:28] this laptop is straight up twice as fast as my old one. AGC/CDU verilog simulations that used to take 20 seconds to complete now only take 10 [17:27:34] which is very nice :D [17:39:35] must be a superior CPU in the new laptop I guess [19:25:57] cya!