[14:16:18] NASSP Logging has been started by n7275 [14:16:20] good morning [14:55:29] morning [14:55:53] Just did an abort to orbit pretty manually and for some reason the RTCC seems to not be working [14:56:12] GPM wont calculate anything and the MPT won't accept an anchor vector [14:58:06] whoa [14:58:38] https://www.dropbox.com/s/1rwio396go5sfb5/Screenshot%202022-02-07%20075824.jpg?dl=0 [14:58:41] Look at the GMT [15:04:46] I am very confused lol [15:04:53] This was Apollo 11 -30s scn [15:36:08] hey [15:39:29] rcflyinghokie, do you have something build in debug mode? [15:40:28] oh, I think I know [15:40:58] in the MCC scenarios the MCC initializes the RTCC at orbital insertion [15:41:17] in non-MCC scenario that happens when you open the RTCC MFD for the first time [15:41:49] did you disable mission tracking? Maybe it does that on its own if you abort [15:42:23] it probably gets mostly fixed by doing a liftoff time update on the RTCC MFD config page [15:52:25] hey guys [15:55:47] hey Alex [15:55:57] yeah the SM looks weird on the pad [15:56:08] seems to be mostly gone when the tower is jettisoned [15:59:08] its caused by the metalness shader [15:59:34] so thee entire scene is included in the metallic reflection [15:59:41] the* [16:00:30] the sky/water might make it seem a bit bluesish [16:02:19] orbiter is probably a bit too saturated on the ground. [16:02:33] oh and about the cockpit night textures, it looks impressive but its very dark...I think that for cases where we are in sunlight, it should be that dark [16:02:42] shouldnt* [16:05:52] indy91 sorry was in a meeting, since I did an SIVB/SPS abort I bet it never initialized at "insertion" [16:06:02] yeah [16:06:17] I should probably move some parts of the initialization to prelaunch [16:06:18] that explains it [16:06:29] can I manually initialize it? [16:06:30] I just didn't want to split it up over many different MCC tasks [16:06:41] I think it's mostly the liftoff time that isn't set [16:07:05] Sounds like something that should be initialized at liftoff lol [16:07:35] yeah [16:07:50] Right now the MCC goes through some steps that are the same for every mission [16:08:05] and only at orbital insertion diverges it between the different missions [16:08:12] but that can probably be changed [16:08:43] ah I see [16:08:48] you might also have to initialize the date, not only the time [16:08:50] What about non MCC missions currently [16:08:53] even if it already has a date [16:09:09] RTCC MFD initializes with default values when you open it for the first time [16:09:15] specifcally when the MFD creates the MCC vessel [16:10:24] in MCC scenarios that gets bypassed because it has already a launch date loaded [16:10:41] and the MCC vessel of course already exists [16:10:50] so that's why opening the MFD in an MCC scenario doesn't fix it [16:13:23] ahh [16:14:31] Yeah i did a manual SPS after SIVB cut off and got into something like a 500x80 orbit, then tried GPM with no luck so a few P30 iterations I managed to get perigee around 100 [16:14:58] Testing people saying they had CTD on tower jett I just decided to mess around [16:16:39] I saw that. somewhat concerning. [16:17:10] yeah [16:17:18] I dont even get a frame dip on tower jet [16:17:33] so I am unable to reproduce [16:20:46] never had one [16:21:00] not since I fixed a bug a few years ago that had to do with the thrusters on the LET [16:26:23] Me either [16:26:40] tried in 2d, external, and vc, not even a frame dip for me [16:27:07] Tells me its likely a performance issue with the system running it [16:30:09] I'm looking at deorbit targeting right now. One thing I was staring at was the Apollo 15 deorbit simulator data package that Mike scanned. [16:30:28] And there is a standard procedure for separating from the S-IVB [16:30:34] 20 minutes before deorbit TIG [16:30:53] in the same kind of attitude as the deorbit burn with the window line on the horizon [16:30:55] assuming SIVB to COI? [16:31:07] assuming you have to get back home real quick :D [16:31:17] Ah haha [16:31:41] and that sep burn is 5 ft/s [16:31:51] which isn't that insignifciant for the deorbit TIG and DV [16:32:06] and the real RTCC program could simulate both the sep and the deorbit burn as a pair [16:32:15] so that's what I want to add [16:32:44] RCS deorbit or SPS [16:32:57] should be the same, at least for the sep maneuver [16:33:18] always 5 ft/s with the RCS [16:33:26] and then whatever deorbit technique you want [16:33:44] although the RTCC can't specifically simulate the hybrid technique I think [16:33:57] would just be like a SM RCS burn [16:34:16] of course I'm also looking at all the old code and thinking about it [16:34:26] the 31.7° window line on the horizon [16:34:28] at what time... [16:34:36] TIG or ullage on... [16:34:53] right now the calculations assume main engine on [16:35:11] but at least according to an Apollo 7 document the technique is this [16:35:25] "the SCS is aligned to the horizon by maintaining the [16:35:26] window mark on the horizon using the SCS rate command mode and com- [16:35:27] pleting GDC align at ullage on releasing button. The attitude set, thumb- [16:35:27] wheels will have been set from a previous GDC/IMU alignment to [16:35:28] 180-180-0 for this operation." [16:36:07] is this assuming the SIVB/stack is in orbit? [16:36:26] yeah [16:36:27] Pre TLI [16:36:44] like if you have to get home because of some CSM system failure [16:36:55] 5 ft/s sep burn from the S-IVB [16:36:58] 20 minutes later deorbit [16:37:01] normally SPS of course [16:37:11] but that might be what has failed [16:37:34] and the burn even for the CMC gets calculated in that attitude for the backup technique [16:37:49] 15 seconds of ullage makes 1° difference in the burn vector [16:38:30] if you have the window line on the horizon at ullage on vs. main engine on I mean [16:38:47] oh interesting [16:39:05] why the difference, thrust vector differences between SPS and RCS? [16:39:21] burn is inertial [16:39:35] so if you have the window line on the horizon at ullage on [16:39:40] and then freeze the attitude [16:39:56] the horizon has moved by 1° due to your orbital travel [16:40:07] Ah makes sense [16:41:05] well it's easier to calculate with ullage on haah [16:41:20] because the RTCC burn simulator wants as input a state vector at ullage on [16:41:36] so might as well calculate the burn vector at that time [16:41:51] All as one burn [16:42:31] yeah [16:42:38] it can simulate the different thrust phases [16:42:47] keep track of how much RCS and SPS propellant it used etc. [16:44:10] oh nice [16:44:21] oh, side note...did you see this https://www.orbiter-forum.com/threads/raytraced-vc-textures-with-panel-lights.40347/ [16:44:26] sure [16:44:32] quite impressive [16:45:17] to combine the topics [16:45:35] AlexB_88, feature request. A hatch window texture where you can actually see the window markings in the VC [16:45:46] for flying reentries with that [16:45:52] that worked pretty well in the 2D [16:46:05] side hatch window* [16:46:17] ah yes, that is definitely on the plan [16:46:32] I should probably redo the entire hatch while im at it [16:46:42] yeah, you can see the handle on it, too [16:46:48] even if there is a mesh for the handle :D [16:46:52] haha [16:47:11] I guess it's just the old VC texture which never got updated [16:47:16] even less resolution than the 2D ones [16:47:38] lol [17:13:50] indy91 looks like we are coming up on Wedge's completion of Apollo 15 with RTCC :) Nice to see things working outside of our little group haha [17:14:20] after lot of coaching and realizing how user-unfriendly some things are, yes, it's working lol [17:14:40] it's been great feedback though for sure [17:14:58] and I am hoping those threads encourage more people to try it [17:15:57] morning! [17:16:36] morning Mike [17:16:49] I am loving those scans haha so much material [17:16:57] :D [17:17:16] all of the Block I functional integrated systems schematics I've been working on are up on the virtualagc site this morning [17:18:03] hey [17:18:21] I also resorted my boxes yesterday due to the recent influx of LM stuff.... and there's still more to scan that I had forgotten about lol [17:18:22] yeah I want to make some sort of FIDO worksheets for a mission that isn't covered by the MCC [17:19:04] Apollo 12 probably. Not an input guide, but specific inputs for a mission. The FIDOs didn't know all the inputs they had to give the RTCC people from memory [17:22:28] was there a "cheat sheet" of sorts? [17:23:02] yeah, they referred a lot to worksheets [17:23:10] in the audio [17:23:29] I don't think the FIDOs usually knew the specific MED code for something [17:23:47] but the inputs they gave to the RTCC are often the full MED input data [17:24:01] and they could say it all in one go, as if read from a piece of paper [17:24:32] yeah that makes sense [17:24:34] so I think they definitely had some sort of checklist for themselves [17:25:18] Probably the case for most MOCR positions especially WRT interaction with RTCC guys [17:30:05] that would be cool. I think I might fly 12 next. [17:32:33] You should! [17:32:41] Get your RTCC practice in [17:32:50] yeah, especially FIDO, GUIDO and RETRO will all have their cheat sheets [17:34:17] the only thing for 12 I didnt get cleanly from RTCC is the desired orientation for photography [17:34:31] I remember having to fudge that around a bit [17:34:32] right [17:34:47] I'll come up with something if I fly that mission to create the worksheet [17:39:53] Might come in handy for other similar orientation changes [17:40:30] I think for 16 or 17 I used google moon to determine a ground track and heading to change orientation/orbit :P [17:43:08] thankfully I had a "strip" of many targets so I just created a flight path between those [18:00:54] Evening [18:02:41] hey Thymo [18:08:55] hey [18:09:11] rcflyinghokie, your Apollo 9 checklist update, is that based on new scanned documents? [18:20:32] It was an update based on the incomplete CMP checklist [18:20:59] The TD&E procedure was just Apollo 8's before I tweaked it [18:21:49] we have the crew abbreviated checklist now [18:22:00] not sure how much that agrees with the final, flow checklist though [18:22:30] last change February 1st, 1969 [18:22:52] https://www.ibiblio.org/apollo/Documents/apollo_9_csm_104_flight_crew_abbrev_checklist.pdf [18:23:01] flown* [18:28:59] I'll check and see [18:31:34] Okay checking again I do have current to the LM. The test meter is vibrating around 0 [18:31:39] I think that looks pretty accurate [18:32:06] Thymo yeah need to work on the heater power draw by tweaking the radiators [18:32:26] I think they are a bit too isolated and the heater current stays too low..you will see it pop up time to time though [18:34:20] indy91 looks like the handwritten changes on the abbreviated dictionary made it into the CMP checklist pages I have [18:34:40] So I think it's close enough to edit the whole TD&E procedure to follow it [18:34:53] ah nice [18:35:18] it doesnt change too much, just a few orders of operation and also getting back into full suits for it [18:39:02] I will go through and make the appropriate changes to the rest [18:43:57] I just downloaded that abbreviated checklist. I see they do a V83 and then V47 after docking. I think we actually have V66 there. You might want to add that to your PR Ryan [18:45:17] Yeah as I said I am going to redo launch/TLI/TD&E based on the abbreviated checklist [18:45:49] I will update the PR when complete [18:46:14] Thanks for finding those differences Thymo, I think I did these Apollo 9 checklists before we had those [18:50:19] I will go through them this afternoon [18:58:40] Please rebase onto the current Orbiter2016 [18:58:45] Thymo not sure what this means [18:59:07] git rebase origin/Orbiter2016 [18:59:26] That replays your commits on the new state of Orbiter2016 [18:59:45] I did nothing changed [19:00:17] This explains it pretty well: https://git-scm.com/book/en/v2/Git-Branching-Rebasing [19:00:28] Try git fetch --all [19:00:31] Then try again [19:01:30] no change [19:02:26] says it's up to date [19:37:13] Sorry I got distracted [19:37:41] I can't progress after LM ejection. Orbiter keeps crashing after a couple of minutes and right before the earth tiles get corrupt: https://puu.sh/IHDL0/162df1784e.jpg [19:39:21] Oh thats interesting [19:39:36] indy91 have you seen that one before? [19:39:41] Did my last two messages go through? I got kicked by the netsplit. [19:41:14] yes about the crash? [19:41:21] Yes [19:41:34] yeah I havent seen that one before [19:41:41] Maybe something with the texture install? [19:42:04] I can test the scn with my install to check [19:43:07] There is no way the scenario causes this [19:43:18] Something in Orbiter is calling abort() when it happens [19:43:21] nah, I haven't seen it like this [19:43:44] sometimes there are artifacts on Earth and Moon, but it looks different [19:43:48] and doesn't cause a crash [19:54:27] Yeah that looks like maybe a bad texture install perhaps? [19:55:11] difficult to say [20:04:53] I worry that we have something very unsafe happening with memory. [20:06:01] I've been worrying that for years [20:07:21] but this would surely be something new [20:07:45] I'll start flying Apollo 12 [20:07:49] maybe I see something [20:18:19] rcflyinghokie: Try this: [20:18:24] git fetch origin [20:18:31] git reset --hard origin/Orbiter2016 [20:18:36] git cherry-pick 6a602fc93d7e50b8070737dbdd5b7d38be85d25c [20:18:38] git push --force [20:20:00] uhm, careful [20:20:27] with hard resets [20:20:36] I just did it... [20:20:49] I checked out his branch in a fork. He only has one commit so resetting and cherry-picking that commit resolves it. [20:21:08] it failed [20:21:26] What's it saying? [20:21:36] https://www.dropbox.com/s/pmg6ingnblar37c/Screenshot%202022-02-07%20132123.jpg?dl=0 [20:22:23] what does git push do when you don't specify a repo? [20:22:41] It picks your remote tracking branch [20:22:48] rcflyinghokie: How do you push normally? [20:23:00] git push fork Orbiter2016 [20:23:03] Push button in the gui [20:23:07] Oh haha [20:23:38] Can you post a screenshot of `git branch -vv`? [20:24:23] https://www.dropbox.com/s/t1d82drk166i1o1/Screenshot%202022-02-07%20132408.jpg?dl=0 [20:24:49] Right, it's tracking upstream. [20:25:15] Before we proceed. git checkout -b checklist [20:25:20] Move to a new branch to be sure [20:25:53] warning: cancelling a cherry picking in progress [20:26:02] normal? [20:26:03] git cherry-pick --abort [20:26:13] That's the next thing we'll look at [20:26:25] error: no cherry-pick or revert in progress [20:26:26] fatal: cherry-pick failed [20:27:19] Oh I think it implicitly cancelled it by checking out. Does git status say you're on the new branch [20:29:09] yeah [20:36:52] Okay so it did abort it automatically, good. [20:36:58] git push -u origin checklist [20:37:05] Then I'll take a look what it has now [20:42:58] if I write a bit of a walkthrough of Apollo 12 with the RTCC MFD, should that be with or without MPT? [20:47:17] Good question [20:47:59] On the one hand, computing MCC's should use it to see results based on planned burns [20:48:11] But you dont "absolutely" need it [20:51:24] Thymo done [20:52:13] indy91 it might help clear up MPT use if it's included, but I can see it quickly becoming confusing unless used for specific applications [20:54:42] I already know I'll find some things in the RTCC I want to improve, hindering my progress, as usual haha [20:54:45] Ah [20:55:11] Ryan. What you have as upstream I have as origin. [20:55:33] So you want to do git reset --hard upstream/Orbiter2016 [20:55:58] done [20:56:19] Try the cherry-pick again [20:56:43] hmm [20:56:46] lost a needle in the VC [20:56:56] If that doesn't say it's empty do: git push --force [20:57:23] says its empty [20:57:52] with more frequent crashes etc, maybe it's something in the VC which people are now using more [21:00:41] This is what you should be seeing https://puu.sh/IHEGz/9f31a948cb.png [21:01:41] nope [21:02:06] https://www.dropbox.com/s/678g1kkmq4dxrtg/Screenshot%202022-02-07%20140154.jpg?dl=0 [21:02:44] Why did you do reset to origin/Orbiter2016 [21:03:11] You told me to? [21:03:26] I did the 4 steps for cherry picking again [21:03:27] That fetch and reset before your cherry pick got you back where you started. I said do the cherry-pick again [21:03:29] Sorry [21:03:39] I assumed those were all together [21:04:33] No, I meant specifically the cherry-pick and none of the others. No worries, just redo this and only this: [21:04:39] git reset --hard upstream/Orbiter2016 [21:04:48] git cherry-pick 6a602fc93d7e50b8070737dbdd5b7d38be85d25c [21:05:15] Then show me so I know all is good :) [21:05:42] lots of messages [21:06:10] https://www.dropbox.com/s/aayx4is0n0py13u/Screenshot%202022-02-07%20140555.jpg?dl=0 [21:07:00] no idea what happened [21:07:04] The > indicates you probably didn't close a string somewhere. [21:07:18] hmm, needles on the meters shouldn't randomly disappear and reappear when you reload the scenario [21:07:20] If you do Ctrl-C it should give you the prompt indicated by a $ [21:07:36] schroedinger's needles [21:07:43] Probably not wise to do this while working haha [21:08:05] I am still on that "checklist" branch btw [21:08:28] Yep all good [21:09:52] Ok [21:10:45] indy91 in my experience that is an indication of NaNs poisoning the simulation somewhere [21:10:46] So whats next [21:10:56] Oh bad memories of NaNs.... [21:10:57] You got your prompt back? [21:11:00] yeah [21:11:17] Retry those two reset and cherry-pick commands [21:11:27] indy91 probably remembers the LM NaNs :P [21:11:53] Thymo done [21:12:12] Cool. How does it look this time? [21:12:16] https://www.dropbox.com/s/1ab5orcdoiae949/Screenshot%202022-02-07%20141206.jpg?dl=0 [21:13:10] Exactly what I wanted to see. We're gonna do two more things, push this branch and reset your Orbiter2016 to prevent this issue going forward. [21:13:19] git push --force [21:13:38] That just overwrites the checklist branch on GitHub [21:13:49] git checkout Orbiter2016 [21:13:58] Moves you back to that branch [21:14:35] Next command will remove all commits that have not been merged upstream, they will still be in your checklist branch though. [21:14:46] git reset --hard upstream/Orbiter2016 [21:14:51] That's all [21:15:06] Thymo, if I rebase a branch that has a bunch of merge commits in it, will it just erase the now-unnecessary merge commits? [21:17:18] No, they'll still be there. You can do a git rebase -i though. That opens up vim. You can delete all lines that are merge commits and then exit. That'll drop them [21:17:49] git will complain when you try to push again since you removed those commits from the history. So you'll need to force push [21:18:10] Thymo in work [21:19:05] https://www.dropbox.com/s/7e51q4aex1rd5wn/Screenshot%202022-02-07%20141856.jpg?dl=0 [21:19:27] You made a typo on the last command [21:19:34] Ah [21:19:36] Forgot a 6 [21:19:41] Just redo it [21:19:53] There we go [21:20:08] Again splitting attention not conducive to bash commands :P [21:21:20] Cool you're all set now :) [21:22:44] So now what should I do to properly get the checklist changes back in there without messing it up again haha [21:24:13] that needle is gone again. Surely it's another case of the wrong animation being set by something [21:24:26] we had that in the LM, I thought we fixed any cases of it. I guess not [21:24:56] Properly? I would only make changes on feature branches like checklist,CMECS,CMRCS,etc. and then PR that. I would not use Orbiter2016 as it is ambiguous to where it points to. It exists both in upstream and your fork [21:24:59] Wait, LM NaNs are back? [21:25:19] no [21:25:24] Oh you scared me [21:25:43] Thymo ahh I understand now [21:25:47] Usually animations for the VC are directly associated with the switch or meter class [21:26:17] but in rare cases they aren't. In some cases the switch class tried to set an animation when there wasn't an animation for it defined [21:26:30] so it instead set some other animation [21:26:41] in the LM that was one of the RR axis [21:27:39] rcflyinghokie: If you recreate the PR from checklist you'll see it's only one commit now [21:27:59] Makes sense completely [21:30:08] In retrospect we could've done this with a rebase but I got confused by the setup of your Orbiter2016. The combination of a reset and cherry-pick is (roughly) the manual equivalent of a rebase. [21:30:41] All a rebase does is go back to where you tell it to and then replay the creations of the commits from that point. [21:32:57] Yeah my setup is how I configured it a long time ago based on the contributor post on the old forums [21:37:38] hmm, can't reproduce the needle vanishing, so I don't think it's one particular switch I am setting [21:38:53] but it's quite likely an animation gone rogue [21:38:59] with the VC we a lot of animations now [21:44:20] is this the test meter needle? [21:46:25] RCSHeliumPressMeter [21:46:53] needle doesn't reappear, even if I switch it to one other of the 6 positions for CM and SM RCS [21:48:08] rcflyinghokie is this the same system that keeps getting reset? [21:48:39] context? [21:52:05] I recall you mentioning someone on Discord got an rcs press c/w alarm, but when the reloaded the scenarios it got reset to some fixed value [21:54:08] Ahhh [21:54:09] Yes' [21:54:56] PROPELLANTPRESSUREPSI [21:55:00] got reset to 185 [21:55:38] linked the convo in discord for you [21:55:50] I wonder if this is related. [21:57:35] Thymo I canot push to my Orbiter 2016 branch anymore [21:57:38] cannot* [21:58:18] https://www.dropbox.com/s/auw2p21o8kpygcq/Screenshot%202022-02-07%20145811.jpg?dl=0 [21:59:13] I also cannot rename or delete that checklist branch [22:00:25] you now have to pay $100 to a Nigerian prince call Thymo [22:00:28] called* [22:00:32] Lmao [22:01:40] and naturally I now can't reproduce the needle vanishing [22:01:45] You changed the course of history [22:01:46] after it happened twice [22:01:47] By that reset [22:01:50] git push --force [22:04:25] Still wont work in the gui after that] [22:04:41] same error [22:06:22] Close and reopen it? [22:06:32] My GUI knowledge is limited [22:06:46] It should get the same result though [22:07:23] Haha [22:07:39] Same error [22:08:28] I suppose learning how to use the CLI to make your problems go away forever is an unsatisfactory answer [22:09:05] Right now, for how I use git, yes [22:09:07] will that make the problem go away? [22:09:39] Seems things are worse now [22:10:00] is there now a change in the remote repo that Ryan doesn't have locally? [22:10:04] Well it surely helps you understand what is going on and understanding the context of the problem, effectively preventing the problem before it occurse. I'm gonna go with yes. [22:10:06] I don't really see how though [22:10:32] Did you do a force push? [22:10:37] Yes [22:11:18] Are you definitely on Orbiter2016 and did it say up to date? [22:11:29] Because on Github I see no change [22:11:40] was about to mention that [22:11:49] https://www.dropbox.com/s/71gtk8ohi0ur3dl/Screenshot%202022-02-07%20151142.jpg?dl=0 [22:11:59] Yes and yes according to that [22:12:28] doesn't that mean up to date compared to the main repo? [22:12:36] in its current local state [22:12:41] Its telling me to integrate remote changes but there are none that I am aware of [22:13:06] I feel like there is some confusion between the two remote repos you are using [22:13:20] Was all working fine before the cherry picking thing [22:13:33] Thymo, again, git push without specifying a remote [22:13:42] which one does that try to push to? [22:15:07] Whatever remote is set as remote tracking branch [22:15:13] As indicated by git branch -vv [22:15:39] and when it says "up to date" [22:15:44] what does that compare to [22:15:59] the local state of that remote tracking branch? [22:16:26] There is nothing to do because the remote is already up to date with your local stuff [22:17:54] rcflyinghokie, what were you trying to push to the Orbiter2016 branch? [22:18:12] isn't this update now in the checklist branch? [22:18:45] It is [22:18:56] Yeah but I just wanted to get my Orbiter 2016 branch up to date as well [22:19:25] Can you post a screenshot of `git reflog`? [22:19:34] That's basically git's blackbox [22:20:05] I mean, essentially it's the same error as when you try to push to a branch that already has updates you haven't merged yet, right? [22:20:37] Yes. Something happened on the remote and if you were to push it some stuff would be overwritten [22:21:54] I can't really help, I've never tried anything with rebase [22:22:07] and so far it doesn't sound very appealing to me haha [22:22:09] https://www.dropbox.com/sh/z2vqv6soq109dk8/AACaFxfAQbdXpvHmQq35E2ewa?dl=0 [22:23:50] Did you do a git push --force on Orbiter2016? [22:25:20] well I hope you figure it out [22:25:23] good night! [22:27:43] Lol Thymo yes [22:28:06] 4x now [22:28:38] *internal screaming* [22:30:04] not to confuse the issue if this is wrong but does that push force command need to specify origin [22:31:36] If you git pull does it pull from orbiternassp or your repo? [22:32:35] In the first case what Matt says is correct, in the latter case I'm going to sell all my electronics and live on a remote island [22:33:35] Only in the first case would it make sense why the GUI and CLI say different things [22:33:55] And the GUI does say it is trying to push to origin specifically [22:34:04] So your fix should be [22:34:08] git push --force origin [22:34:26] yep [22:34:28] that did it [22:35:22] Now as far as this checklist branch, I cannot seem to rename it [22:35:24] For everyone's sanity, everybody please don't create commits on Orbiter2016 to prevent another aneurism. [22:36:18] Rename it locally or remote? [22:36:30] Lol its funny as my setup stems from the contributor thread on the old forums :P [22:36:55] Both? I cannot stand the lowercase c first of all [22:37:09] Drives me nuts [22:37:17] What have you tried that makes you think it doesn't work [22:37:47] Says it already exists [22:37:56] I just made it plural instead [22:38:30] Guess it doesnt let you change capitalization alone :P [22:39:02] That's the fault of Windows and its designes deciding that it should be case insensitive [22:40:06] Damn microsoft [22:40:17] But seems all is well now [22:41:02] I will keep working on these 9 procedures and make a new PR later [22:41:09] ...from my Checklist branch [22:41:22] For your sanity :) [22:41:43] I don't think we won Niklas over to the rebase camp today [22:43:09] To be fair this was still collatoral damage from squashsing Max's commits after they were merged. It caused everyone's repos to get desynchronised. [22:43:25] Trying a rebase just made the underlying issue apparent. [22:43:39] Together with all those commits being added to PRs [22:45:10] Might need a new contribution thread [22:45:13] in the forums [22:45:26] And this is why knowing how git works is just as, if not more, important than knowing C++ when working on projects with multiple people. [22:46:29] Using the GUI is fun and all but it only really suffices when you just want to keep progress in a personal repo. It doesn't scale under these circumstances. [22:46:32] Personal opinion [22:48:01] Fair enough [22:48:18] at least we're not still using SVN [22:48:28] And to be frank, for what i do with pulling and pushing and contributing the gui is all I need [22:48:41] Been using it for a decade with no real issues [22:50:09] But seems things are all back to normal [22:51:45] True. But that's like saying you don't need to read the AOH to fly NASSP because you already have the Checklist MFD. Sure, you'll get to the moon but do you actually understand how you did it? [22:52:56] Good analogy, not against learning it I just havent had the reason to [03:52:14] One thing we might want to clarify in the keyboard commands is translation in the LM vs CM [03:52:41] FWD is +X in the CSM but +Z in the LM [14:42:47] hey [14:44:53] good morning [14:45:47] git all fixed? [14:48:48] yeah all good [14:49:37] git push --force origin is all I needed [14:50:57] Working on the 9 and 11 launch checklists now as I think they mostly followed copy paste haha [14:51:08] Small procedural changes so nothing major [14:57:15] yeah, I wouldn't expect huge differences [15:03:38] order of operations and technique mostly [15:05:25] "This email is to acknowledge receiving your request for material. The UHCL Archives staff will try to make it available to you within 10 business days." [15:05:50] have they stored away their PDF files somewhere inaccessible??? [15:06:11] I specifically said the documents have all already been scanned haha, can that really be so time consuming [15:12:09] Lol depends on the backlog and staffing on site I suppose? [15:12:22] Maybe a normal boilerplate [15:15:13] I guess. In my mind writing that email took as long as searching for those 3 PDF files, but they probably have their process [15:22:47] ok sep maneuver is mostly integrated into the deorbit targeting now. I'll fly one with my just launched Apollo 12 [15:22:52] with proper sep maneuver technique [15:23:37] definitely already the proper technique already for Apollo 12, but the first time that procedure appears in the checklists is Apollo 15 [15:24:28] again this is sep/deorbit in LEO with an SIVB attached? [15:24:46] correct, sep from the S-IVB [15:25:08] 5 ft/s burn to get away safely for the deorbit burn [15:25:19] and that 5 ft/s is taken into account for finding the deorbit TIG [15:25:41] sep is 20 minutes before deorbit [15:26:39] Apollo 15 and later have a "Pre-TLI Abort from Orbit" section in their Launch Checklist [15:27:31] covers the time from starting the preparations for this through having performed the sep [15:27:44] then you go to the deorbit maneuver checklists [15:27:50] either SPS, SM RCS or hybrid CM/SM [15:28:27] you take over manual control of the S-IVB and pitch down until the window line is on the horizon [15:28:38] so the sep maneuver is in the same LVLH attitude as the deorbit burn [15:29:15] ah no, you pitch up [15:29:32] I guess that's quicker, you have to cover about 180° to retrograde [15:29:47] and that makes you heads up [15:29:50] so no 180° roll required [15:33:19] you can also specifiy a shaping maneuver instead of a separation maneuver [15:33:23] that has a fixed TIG [15:33:29] and not X minutes before deorbit [15:33:36] that's probably what they did on Skylab [15:33:45] started out in a 220 circular orbit [15:33:49] shaping burn to 230 x 90 [15:33:52] and then deorbit [15:35:53] oh you command the sivb before hand [15:35:59] that makes sense [15:36:15] and you give it back control and it holds the new LVLH attitude [15:36:19] does the booster hold inertial attitude at sep? [15:36:55] I think it will keep on holding the new LVLH attitude until the next programmed attitude maneuver comes up in the LVDC [15:37:12] but I don't think this works right now in our Saturn IB LVDC [15:37:23] because I wasn't sure if it already worked like that on Apollo 7 [15:37:30] where you nominally take over control [15:38:03] I feel like on Apollo 7 it should be moving back to 0° LVLH pitch and yaw after you give it back control [15:38:24] but for the Saturn V I implemented the calculations from the Skylab Saturn IB EDD [15:38:32] it will hold the new LVLH attitude [15:39:09] if you do that and continue with TLI then it will go back to the old attitude at TB6 [15:45:37] Yeah I always assumed it would go back to LVLH orb rate after giving back control [15:47:08] well it kind of does haha [15:47:15] just not at 0° pitch/yaw LVLH [15:52:26] ahh just LVLH [15:52:31] and whatever attitude it was [15:54:36] yep [15:54:38] [5+3131.010001] Saturn control returned to LVDC [15:54:39] New local referenced attitude: R 1.89 P 232.13 Y 3.10 [15:57:12] Apollo 7 LVOT says [15:57:29] "End manual control of S-IVB attitude from the space­ [15:57:30] craft. The IU will return to its programmed [15:57:31] timeline whenever the spacecraft relinquishes atti­ [15:57:32] tude control. " [15:57:52] so that is definitely different from the Skylab Saturn IB LVDC [15:58:40] so if I ever implement it for our Saturn IB LVDC I need to add an option for either behavior [16:11:38] after all this time I am requesting documents wrong haha [16:11:48] "In the future, please include the Program Name and Location Code, from the Archives Search Index.. The documents have been scanned, but not as individual stored. They are stored in large bulk files numbering several hundred pages. Having the Program Number and the Location Code makes it much easier to locate and extract the documents." [16:12:22] I wasn't including the location on purpose, so that they don't accidentically scan the document again [16:12:29] I guess I overthought it haha [16:58:36] haha oh well, we liive and we learn [17:00:30] morning! [17:02:12] speaking of archives and scanning, Ryan and I collectively realized yesterday that we can probably get our hands on missing checklists from microfilm at NARA, if we ask them for the SKB number of the checklist instead of the name of it [17:04:12] ....whenever NARA is actually usable again [17:05:37] hey [17:06:00] well I knew they had all the checklists. So it's easier with the SKB number? [17:06:18] That would be a gold mine to fill in the blanks [17:06:29] stowage lists has those numbers [17:07:40] yep [17:08:01] at least, that's the theory lol [17:12:39] indy91, could we change the keyboard commands thread to clarify direction for LM/CSM translation? I know its minor but of course FWD in the LM is +Z where in the CSM it's +X [17:13:23] sure [17:14:42] changed [17:14:48] let me know what you think [17:20:11] Perfect [17:39:36] looks like the panel lighting got jarmonik's attention [18:02:55] yeah it looks quite impressive [18:28:42] I'm excited to see where that goes. [18:29:58] yeah me too :D [18:56:50] working through PCB layout for the test version of the board with only a small number of each type of circuit this week... [19:01:32] I would definitely be interested in that. [19:15:24] indy91 for Apollo 9, when is the SIVB commanded to start maneuvering to TDE attitude in our sim [19:15:34] Is that a fixed time? [19:20:01] n7275, forwarded you the initial email about it. there hasn't been anything nailed down yet [19:22:22] thank you! [19:31:22] rcflyinghokie, yes fixed time [19:31:27] 2:34h [19:31:29] GET [19:31:30] 2:34? [19:31:37] And thats when it starts maneuvering [19:33:29] inertial hold of local reference, -16° pitch, 15° yaw LVLH [19:33:47] which is immediately frozen inertially [19:34:09] not like Apollo 7 where it holds -20° pitch LVLH for a bit [19:34:16] and then gones into inertial attitude hold [19:34:29] goes* [19:35:22] the SCOT suggests using inertial angles from the start, but I tried those, they don't work so good [19:35:37] probably because the SCOT wasn't written for the actual launch day [19:37:28] I believe this doesn't always give the exact TD&E angles as in the flight plan, but fairly close [19:37:52] it used to be more off [19:38:33] Sounds good, just trying to null out this GDC align [19:38:44] in the flight plan its mentioned explicitly after the maneuver time [19:38:58] But in both the abbreviated and the incomplete CMP checklist, its done before the maneuver [19:39:20] I am just going to put it in both locations as I am 99% sure it needed to be done AFTER the SIVB maneuvered [19:39:43] Also, does MCC give any uplink before the maneuver by chance? [19:40:03] I think the actual mission got a SV [19:40:22] And in the abbreviated there is an uplink with pyro arm before the 2L34 time [19:40:24] 2:34 [19:40:45] L3-2 [19:40:50] pdf 29 [19:41:02] real GDC is good at drifting, more alignments don't hurt :D [19:41:35] Haha indeed [19:42:33] MCC does it like the flight plan [19:42:41] state vector at 3:15h [19:43:19] actual mission got one earlier it seems [19:43:21] but unscheduled [19:43:37] they had a fairly bad IMU accelerometer bias in one axis [19:45:10] so they got an uplink at about 1:40h [19:45:35] Ah ok, so maybe just an anticipated thing on the abbreviated checklist [19:46:05] Any idea what that line in parenthesis means under UP TLM - BLOCK [19:46:34] https://www.dropbox.com/s/o1g2qzssz1mhhw7/Screenshot%202022-02-08%20124625.jpg?dl=0 [19:46:52] maybe an attitude? [19:47:20] My guess was maybe pitch [19:47:56] yeah, that sounds likely [19:48:18] but that is before 2:34, so perhaps just inertial attitude due to orbital rate [19:48:25] in orb rate you have about 4°/min [19:48:39] that looks right then [19:48:46] sounds like a check that the LVDC knows what it is doing [19:55:44] interesting I dont think they latched the FC's for Apollo 9 TDE [20:07:18] Also I see corrections to use 0 on the EMS but looks like the crew used 100 [20:26:06] is there any info on how much vibration would be required for one to close? [20:29:07] Well Apollo 13 probably provided that data ;) [20:34:26] now the O2 tank pressure needles have vanished [20:35:03] oh and the SM RCS helium pressure one, that already did it before, vanished as well [20:57:58] indy91 are you sure you have absolute animations checked? [21:02:36] also indy91, does the LM ejection still not impart dV? [21:05:08] I thought we changed it so it would impart a DV [21:05:47] I havent done one in a while so I am just checking [21:06:29] well I just left my LM in Earth orbit [21:06:35] and am reentering haha [21:15:10] Poor LM [21:18:17] n7275, are you kidding me, I had it off [21:18:21] I always had it on... [21:18:45] I think we had experimented with absolute animations a few months ago, maybe I switched it off then haha [21:18:47] Thymo, done, and also forwarded it to the rest of you. sorry for the email spam if you're not interested :) [21:20:11] ok, just went through that whole procedure with S-IVB separation and deorbit targeting from the 100 NM orbit [21:20:20] worked really good [21:20:38] one thing that confused me was the long range [21:20:46] but I think it's because of the deorbit method [21:21:17] they weren't using the normal velocity vs. flight path angle targeting from the 100 NM orbit [21:21:29] because that gives you too little time between deorbit cutoff and reentry [21:21:36] so they used a fixed DV of 325 ft/s instead [21:21:45] which is shallowed than your normal deorbit trajectory [21:21:48] shallower* [21:22:13] the current EMS range calculation doesn't like it much, it was off by 25NM in the end [21:22:21] I bet also because of the shallow angle [21:22:37] and the CMC, lol, it had almost 200 NM too much range for the EMS [21:23:04] probably a mixture of the RTCC being 25NM off, the shallow angle and the wrong Earth shape [21:23:28] I thought I went through the checklist smoothly, but still too slow, when I was done with everything I was almost at 0.05g [21:24:44] so over all the procedures worked fine and the deorbit TIG iteration that takes the sep burn into account, too [21:27:29] the initial downrange error in P67 was 350NM, normally I've seen 250NM. That is also usually on the Earth Entry PADs. Must also be because of the shallow angle [21:34:51] what is the EI from a 100nm deorbit [21:35:06] not EI [21:35:09] Entry angle [21:35:58] I think it was a bit more than 1° [21:36:03] wow [21:36:25] I'll check what you get with the normal target line [21:36:32] also not very steep, but maybe like 1.5° [21:36:43] you won't get more than 2° from any low Earth orbit [21:37:45] ok so using the target line (which is already the shallow target line) you get -1.39° [21:38:43] only 7:28min to entry interface [21:39:35] and using the fixed DV of 325 ft/s, which they would have actually used from the 100NM parking orbit, it is -1.00° [21:39:42] and 10:02min from TIG to EI [21:40:21] for the 90NM orbit they had to change the technique [21:40:33] 15° line instead of 31.7° line [21:40:41] so point the SPS less downwards during deorbit [21:40:45] 250 ft/s [21:40:57] and all that still gives 1 minute less time from EPO [21:41:03] than the 100NM orbit I mean [21:41:07] good thing they had 3 people to run the flows [21:41:13] yeah [21:41:14] thats not much time [21:41:21] and good thing it wasn't required [21:41:34] indeed [21:41:42] much nicer to do it with a light CSM from 90x230 near apogee [21:42:18] this Apollo 15 sim data package has a SM RCS deorbit burn from 90NM parking orbit that takes 12 minutes [21:43:08] and that only gets you a 40NM perigee, the absolute maximum [21:45:11] that's the burn itself the 12 minutes [21:45:14] not TIG to EI :D [22:05:38] night! [22:32:39] Huh FC latching is also not in the Apollo 11 TDE procedures [22:33:05] unless I am blind haha [22:37:24] Maybe it was started on later missions? [22:38:57] Not on 8's that I can see [22:49:31] Apollo 16 AOH has it [22:56:19] Yeah and 15's launch checklist [22:56:45] 13 and 14 [22:57:04] And 12 [22:57:15] So perhaps started on 12 [22:57:51] Dont have a source for 7 or 10 [23:08:43] Thymo is that a better PR? ;) [23:11:32] Much :) [23:12:05] I will probably have to revisit Apollo 10's as well, but 9 and 11 match the procedures we have now [23:20:26] I went through the effort of cleaning up my telemetry branch last night [23:20:56] the commit history is way nicer now [23:21:45] ....but I somehow missed some merge conflict text in a file or two... [23:36:36] Thymo has us all spring cleaning early I guess :P [00:11:11] lol [00:11:35] This guy in Discord managed to get a countdown hold. [00:12:17] I did some digging and while looking at the ML code I noticed the saturn pointer is not initialized when the ignition sequence starts [00:13:52] It is done when prelaunch venting is stopped and this falls through to the ignition sequence. However if you save and reload the scenario between T-8.9s and T-2.0s it gives you a CTD on the first timestep [00:14:04] I'll PR tomorrow [00:14:07] good night [00:36:07] interesting [05:04:50] Thymo, not sure how meaningful this version number is, but maybe something we should consider too? https://github.com/orbiternassp/NASSP/blob/04bae9213d909b803557f91afd24444115717a39/Orbitersdk/samples/ProjectApollo/src_sys/PanelSDK/PanelSDK.h#L30 [15:34:20] good morning [15:37:43] morning [15:38:17] hey [15:47:51] I've decided to reopen the can of worms that is multithreading for the systems SDK. [15:49:41] oh fun [15:49:49] my only consolation is that it at the very least, can't break any scenarios [15:50:14] my fuel cell branch is a bit heavy on computation [15:50:40] I get a big dropoff in performance over 40x [15:51:43] whereas before I could do up to 60x or so [15:52:05] yeah a heavier CPU load is about the last thing we need [15:53:48] I'm sure even our users on the lower end of the performance spectrum have cpu cores sitting idle [15:54:20] definitely [15:54:39] I have one maxed out, one at 75%, and 22 others just along for the ride [15:56:35] that's what is converting me to a VC user right now [15:56:38] performance [15:56:54] because I am CPU limited apparently [15:58:06] in the VC, never a drop below 60 fps [16:01:10] we could probably multithread the the telemetry too as long as the digital words are protected by mutexes [18:54:26] hey [20:05:29] Afternoon! [20:16:24] Random question, say Apollo 16 they scrubbed the PDI and used the LM for RTE, would they burn a TEI from the descent orbit or would the DPS be used to circ first? [20:16:50] I am assuming burn TEI from the DO as the altitude at TEI burn position would still be approx 60nmi [20:17:00] But I cannot find anything explicitly stating it [20:47:18] good question [20:47:54] if the TEI was close to apogee then I bet they would burn it from the descent orbit [20:49:20] but then again maybe they wouldn't necessarily have burned TEI right away and maybe fly an alternate lunar orbit mission [20:58:45] unless the perilune altitude becomes unsafe they would probably do it in one burn [21:01:07] n7275: I do see the PanelSDK is used in one instance to read the scenario in one of two ways. Thanks for pointing it out, it might help us to version PanelSDK stuff seperately from the NASSP scenarios themself. [21:01:25] Maybe that's not a bad idea for checklists either [21:08:07] rcflyinghokie, the Apollo 16 RETRO calculated some DPS TEIs, pretty sure that would be from the descent orbit [21:16:07] good to know [21:17:32] makes sense that it would be [21:17:50] perilune is somewhat close to the Earth side of the Moon [21:18:03] so TEI is near apolune [21:18:17] I could imagine them having more of a problem if TEI happened near perilune [21:18:43] right which was my logic as well [21:56:03] night [22:09:50] ,ask indy91 From what document did you implement the ML stuff? I want to read up on it [22:15:38] Guenter! [22:15:48] .ask indy91 From what document did you implement the ML stuff? I want to read up on it [14:15:21] offers Socially Appropriate Greetings to all intelligent lifr [14:21:14] hello [14:21:45] howsit? [14:24:07] Welcome [14:27:33] is it my presence, or are you guys always exercising your fifth amendment rights? [14:27:59] I'm at work [14:32:32] ? [14:35:29] Peregreena, were not all American, so that doesn't really apply. but not sure what you mean. [14:37:46] good morning [14:37:53] is there any chat in this here erm ... chatroom? [14:39:49] This is a channel for development chat [14:41:02] we tend to focus on topics we are actively working on, so many times there will be a lack of direct conversation [14:41:10] Depending on the members present [14:49:19] so something interesting I was reading, the LES MOTOR FIRE SECS button actually fires the launch escape motors and not the tower jet motors [14:49:41] Moreover, it requires the frangible nuts to be detonated via the tower jett switches before it will function [14:49:48] I dont think we model that correctly do we? [14:50:09] it is used as a backup tower jettison in the event the TJM doesnt fire [14:50:11] The first we do, not the latter [14:50:33] As far as I'm aware anyway [14:50:57] I do know Niklas implemented both as part of his SECS overhaul a couple years ago [14:52:35] I guess I never looked which motors fired [14:55:08] maybe it is implemented because my SECS button doesnt do anything lol [14:55:56] n7275 what was up with that Pere person? [14:58:21] Thymo for your edification https://github.com/rcflyinghokie/NASSP/tree/Flightplans [16:06:18] rcflyinghokie no idea [16:11:23] lol came in here thinking it was just a chat room? [16:20:57] I have no idea. he joined, I said hi. he asked if we were "exercising our 5th amendment rights". it was at that point that things stopped making sense [16:24:51] morning! [16:24:57] y'all are clearly up to no good [16:35:35] We had a random person seemingly trolling the IRC [16:36:01] Seemed he wanted a chatroom I guess [16:41:52] good morning [16:45:07] hey [16:45:27] like, the sequence of events? [16:46:19] hey Niklas [16:46:39] rcflyinghokie, you can let the jettison motor fail via the PAMFD [16:47:20] you can then do the use the switch for it, which will only make the pyros fire that separate the tower [16:47:30] Ah so it is implemented as it should be [16:47:32] and then use LES Motor Fire [16:47:34] Awesome [16:47:54] Thymo, indy91, about chrivals FDAI textures, whats the best course or action? Should I close the old PR and start a new one or just amend the old one? [16:48:13] have we decided which ones to use? [16:48:30] I like the off white ones personally [16:49:55] Also, I amended the flight plans folder a little, but I am concerned with the extra size it adds [16:50:11] definitely no clearance issue when using LES Motor Fire [16:50:14] that tower is gone [16:50:22] Thymo was suggesting potentially we make a separate branch similar to padloads to store them [16:50:26] lol [16:51:28] I think we decided to use chrivals since we asked him first, but are we still considering Lupus's? [16:51:45] I don't know, I haven't really followed it much [16:52:07] I do think chrivals are slightly better quality [16:52:08] I don't think you need to close the PR, just add the updated FDAI [16:52:15] right [16:52:36] well we are lucky that there is actually competition about this and can choose the best one [16:52:40] I guess I will have to merge in all other NASSP changes into it too [16:52:53] true [16:53:07] any performance impact? [16:53:17] none on my system [16:53:52] I guess it's still the same number of pixels to blit in 2D [16:54:17] the VC would definitely have no impact, the 2D panel one is now double the resolution it was before [16:54:24] oh ok [16:54:29] I like chrivals as well [16:54:31] so if theres a bit of an impact it would be the 2D one [16:54:51] I'll try them [16:55:03] I am a bad test case for performance impact l;ol [16:55:09] my system is a good test case, I often can get 60 fps in 2D [16:55:16] but then it also can be randomly down to 40 [16:55:26] I wish I knew why that was inconstent... [16:56:04] ah right, it's a dds file even for the 2D panel [16:56:09] I forgot that it's a lot of special code [16:57:15] in what format does the VC FDAI come? [16:57:41] well, looks like I don't know much [16:58:21] so I just downloaded the latest FDAI dds file [16:58:26] VC is updated [16:58:31] 2D panel FDAI is white? [16:58:55] some setting I need to change? [16:59:56] there is two resolution versions [17:00:08] I think one is for 2d and one for VC [17:00:13] oh ok [17:00:19] so we need some code changes to use both [17:02:08] no performance impact [17:02:13] hmm actually don't need code change [17:02:28] so we are just going to use the lower resolution version? [17:02:38] looks great in 2D [17:02:42] I can put the high res one in the VC folder [17:02:50] and have the mesh use it [17:03:18] thats how I already have it set up in the PR [17:03:22] ah, that just requires a change in the mesh to use that texture? Is that how it works? [17:03:28] yep [17:03:32] ah ok [17:03:54] yeah looks great to me in both VC (high resolution) and 2D (low resolution). No performance change [17:05:36] yeah I think he did a pretty good job [17:07:45] yeah it is pretty sharp [17:14:21] Where do I even put the input page for the sep maneuver for deorbit... [17:14:48] always my favourite task, adding a new page and everything just for lots of input that nobdy ever changes haha [17:15:19] I guess you would need to change it for Apollo 15-17 as they wouldn't use the 31.7° line but 15° [17:16:17] hehehe [18:01:37] So I did a docked DPS TEI on my 16 scn the other day, what kind of TEI targeting would be used to reduce that dV [18:04:26] I burned around 102 hours I think my TZ was 165 [18:06:27] adding 24h to the TZ would reduce the DV [18:06:45] if you want to land at a specific longitude then there isn't much else you can do [18:07:00] as long as it isn't already running into a inclination constraint [18:07:35] there is also an option for the lunar search to find a fuel optimum solution [18:07:58] how did that get implemented... I think you just change the target point from MPL to FCUA [18:08:16] "Lunar Search: Site or FCUA" yes [18:11:12] you can continue adding 24h, with diminishing returns [18:11:24] at some point it gets too slow and the calculation will fail [18:27:47] you probably don't want more than 100 hours between TEI and TZ [19:18:52] Yeah i added 24, reduced by about 500 fps or so [19:19:15] I used the lunar search EOM though [19:19:56] yeah that's fine [19:20:02] the 24 hours is probably all you need [19:25:05] I would still be a little short using just the DPS though [19:25:16] 50 fps or so [19:25:30] hmm [19:26:55] I need to look at the numbers again but I believe when I compared by fuel exhaustion dV accumulated vs addint 24 hours I still was short [19:28:59] in fact I shall try that now [19:32:03] https://www.dropbox.com/s/1sc3jebrwo11dr0/Screenshot%202022-02-10%20123155.jpg?dl=0 [19:32:06] maybe in that case you would try the AOS [19:32:09] There are a few [19:32:10] AOL* [19:33:44] Indian Ocean could also be an option [19:33:46] FCUA would work [19:34:28] yeah, close to Indian Ocean [19:34:41] maybe you find an IOL solution that doesn't take so much time to reentry [19:34:55] but is still better than the EOM with 24h added [19:35:46] I think you would only really use the EOM if everything is nominal [19:36:33] A few more options https://www.dropbox.com/s/420n46h2mzm80ev/Screenshot%202022-02-10%20123620.jpg?dl=0 [19:37:24] Now let me see ho much dV I have to play with [19:37:45] Would the MPT give me that? [19:38:30] only if the propellant mass in the MPT is accurate [19:38:47] Well its a full DPS [19:39:57] Hmm AST not calculating with MPT active [19:42:19] Ah there we go [19:43:30] But now not sending to MPT [19:44:12] any error? [19:45:10] iteration failute [19:45:12] failure [19:45:20] might not like the long DPS burn [19:45:45] some parameters will probably have to be adjusted [19:45:55] is the top or bottom the most recent [19:46:04] "The RFO computed several DPS TEI options and advised the [19:46:05] Flight Director that TEI 18 at 108:58 was the last DPS TEI available [19:46:07] landing at 191 hours" [19:46:14] Ohh wait [19:46:19] RCS? :D [19:46:22] It computed the burn for about a minute ago [19:47:07] so let me compute it for the next rev [19:47:33] so they calculated a DPS TEI at 109h landing at 191h [19:47:46] Hmm [19:47:54] so not a FCUA [19:47:55] probably using the MPL instead of EOM [19:48:13] and 109h might have a lower DV than 101h [19:48:17] but still pretty close [19:48:23] I don't think you have more than 2900 ft/s [19:49:13] I did a MPL at 109h with landing of 191 [19:49:18] 3048 fps [19:49:25] huh [19:49:38] maybe they would have done staging and finishing the burn with the APS [19:49:51] Thats what i was thinking might happen [19:50:52] Haha MPT says I am 462 fps over [19:51:07] Which is on par with what I saw previously when I burned an EOM [19:51:19] I was about 600 short or so at fuel exhaustion [19:51:36] oh really, I thought you would have at least 2800 [19:51:49] Again this is MPT [19:51:53] I will test burn it though [19:52:39] https://www.dropbox.com/s/j33f2pjg9jq9021/Screenshot%202022-02-10%20125233.jpg?dl=0 [19:52:44] That is the maneuver [19:53:05] https://www.dropbox.com/s/s0opdn9e38cw7eq/Screenshot%202022-02-10%20125300.jpg?dl=0 [19:54:16] well you have to do some exciting procedures then [19:54:42] if the DPS isn't enough [19:55:42] Wonder what the difference is here [19:55:59] I guess just vehicle masses? [19:59:44] yeah, I'm not sure [20:01:01] fast forwarding to TIG and I will see what I get [20:04:06] wonder if they would have uplinked a new REFSMMAT [20:11:57] what is your CSM+LM weight? [20:12:40] Apollo 10 alternate mission plan says there would be 2800 ft/s DV, but of course that is different weights [20:13:44] CSM 40732 LM 34800 [20:14:44] According to MPT [20:15:33] seems quite high for the CSM [20:15:45] actual was 39298 [20:15:55] for CSM [20:16:21] Probably less RCS use [20:16:33] did that weight account for crew? [20:16:36] Or suits [20:16:42] getting some confusing data :D [20:17:24] I think we still don't use the correct J-mission weights [20:17:41] You are probably right [20:17:43] LM should be about 36500 [20:17:48] fully loaded [20:17:58] so CSM will naturally need a bit more propellant for LOI [20:18:25] it would be 76500 lbs CSM+LM at separation [20:18:30] but wouldnt my lower LM weight offset that right now though [20:18:54] yeah, it seems like total weight is smaller for you [20:18:58] 75532 [20:19:04] but maybe we also don't use correct DPS propellant mass? [20:19:20] Also a good question [20:20:09] hmm [20:20:12] the scenario has [20:20:15] LMDSCFUEL 8891.0 [20:20:36] that's pretty accurate [20:20:59] Apollo 16 had 7530.4 fuel 12028.9 ox [20:21:11] can you verify that number with the scenario editor? [20:21:16] one sec [20:21:24] Unlikely but possible that it isn't loading that correctly [20:21:47] DSCFUEL 8891.000000 [20:21:48] ASCFUEL 2345.000000 [20:22:06] kg? [20:22:30] yes [20:22:36] that's the scenario [20:22:42] I meant the scenario editor in sim [20:22:46] ohh [20:22:49] you can check the actual propellant in each tank there [20:22:54] yes [20:23:16] I think we had something with the LM ages ago where you put the right number in the scenario for LM ascent stage weight or so [20:23:24] but it didn't end up having the correct number [20:23:37] because of some bad code [20:23:58] if it says 8891 in the scenario editor, too, then that's all good [20:24:00] 8891.00 [20:24:03] good [20:24:06] hmm ok [20:24:31] but I guess what the scenario is still missing is changed empty weights [20:24:41] yeah [20:24:42] especially the LRV will make a difference there [20:24:59] but even so, I would think I should get more available dv as my stack has less mass [20:25:04] yeah [20:25:20] maybe DPS performance? They enhanced that with the nozzle extension didn't they [20:27:16] Yes [20:29:30] looking at the LM 10 AOH 9900 lbs thrust [20:30:53] LM-3 9870 [20:31:11] not much difference but over time of course it adds up [20:31:12] it's not so simple, the thrust increases and the specific impulse decreases with continued firing [20:31:24] right [20:31:39] I was just looking at the differences between the extended bell DPS and non [20:31:47] I think they kind of simulated that by assuming a negative amount of throat erosion for the initial state of the J-mission DPS [20:32:08] maybe that's how we could do that as well [20:33:56] ah yeah because of no DOI prior? [20:34:16] the nozzle extension [20:34:36] previous LMs, initial throat erosion: 0% [20:34:50] the Apollo 15 mission report supplement has an initial value of -1.21° there [20:34:54] percent [20:35:00] Oh I see [20:36:34] Ah damn my burn is gone after saving and loading [20:38:31] oh well easy to recreate [20:38:33] MPT burn vanished? [20:38:42] MPT is there [20:38:49] or just the RTE [20:38:50] the AST and RTE were cleared [20:39:29] Not sure if I will have the dv but here it is lol https://www.dropbox.com/s/k2f1jxridgh0okf/Screenshot%202022-02-10%20133912.jpg?dl=0 [20:39:52] definitely not [20:40:12] I doubt it even with any DPS performance change [20:40:52] so after ignition [20:40:57] yeah same [20:41:04] I am curious to compare the MPT prediction though [20:41:13] Apollo 12: Throat erosion 0%, 9790 lbf thrust, 304.8 seconds specific impulse [20:41:34] Apollo 15: -1.21%, 9905 lbf, 306.3 s [20:42:32] so both more thrust and specific impulse [20:43:49] what do we simulate [20:45:15] 9712.5 lbf without any erosion [20:46:22] hmm [20:46:30] something in the calculations is weird [20:46:45] I'm getting confused between 92.5% vs 100% thrust [20:48:18] could be that we use wrong specific impulse [20:48:59] isnt 92.5 max throttle? [20:49:41] yeah [20:49:54] 100% is really just one defined thrust value they defined early on [20:50:31] ah no [20:50:35] DPS_FCMAX [20:50:38] DPS_FMAX [20:50:44] not the same thing :D [20:52:40] our specific impulse at max throttle and no erosion is 303 seconds [20:54:46] so a little lower than 12 [20:55:40] yeah [20:55:44] but quite close still [20:56:01] I don't think that will make the difference [20:56:11] what about for a J mission LM [20:59:00] surely it makes a difference, but I don't think it's going to be more than 100 ft/s [20:59:32] hmm another note, the N86 doesnt seem to be computing correctly for dvz in the maneuver pad [20:59:42] unless I am missing something [20:59:59] take a look at the maneuver pad [21:00:26] dvt comes out correct but the vector values are off [21:01:22] Oh never mind, had to enter P40 [21:01:42] still not quite the same but close [21:02:01] https://www.dropbox.com/s/3bvx0sece6pslc7/Screenshot%202022-02-10%20140155.jpg?dl=0 [21:02:32] oh the AGS vector [21:02:37] uhh [21:03:02] did they change the thrust value in the computer for the DPS [21:03:09] that could make a difference [21:03:33] not sure [21:03:56] 9817.5 lbf [21:03:59] Luminary 1E [21:04:23] nah [21:04:28] didn't change that [21:04:44] probably am not calculating the AGS DV the same way as the LGC then [21:05:22] MCTDT9 = 43670.0; [21:05:53] well that's 9817.4066 lbf [21:06:45] ah, but in the actual Luminary code they have 43670 Newton loaded [21:07:42] need to check the Luminary calculation for N86 [21:08:14] although I do have the correct RTCC conversion function for the AGS [21:08:29] but I'm not using it [21:08:40] probably just that [21:08:46] I guess you only notice it with super long burns [21:08:57] Not sure if it would help debugging but v [21:08:59] https://www.dropbox.com/s/8kzdoi25yx2sh6q/Apollo%2016%20-%20DPS%20TEI.scn?dl=0 [21:09:08] Just prepped for the docked TEI [21:10:50] yeah might be a good example calculation for testing [21:11:12] I think it's the RTCC not calculating that quite correctly [21:11:37] can make a few updates to the LM Maneuver PAD calculation [21:14:41] ah great I made it worse [21:14:47] lol [21:15:05] In the mean time, lets see what my dv remaining is at fuel exhaustion [21:18:25] For this long of a burn though would it be normal to use full throttle [21:18:33] yes [21:18:37] Thought so [21:18:47] Otherwise it would push past the engine run limit of 1100s [21:18:57] yeah [21:19:09] erodes the nozzle too much [21:20:51] 4m15s 1000dv [21:21:06] lets see how much longer this goes [21:22:12] 1400dv at 50% fuel remaining [21:26:52] wow [21:27:04] 2899.8 dv burned at ECO [21:30:03] about what I would have expected [21:31:59] You sure that engine change wouldnt give me the extra 150 or so fps? [21:32:19] yeah, fairly sure [21:32:31] wonder what kind of numbers that 16 TEI computation got then [21:34:12] maybe they didn't get as far as checking the DV haha [21:37:09] cya [21:40:42] night [14:30:24] hey Ryan [14:39:38] good morning [14:40:09] I have discovered a docked APS burn with 1 person is a challenge [14:40:40] need a combination of TTCA and ACA to really keep it stable [14:42:01] but I was able to burn a TEI to depletion (2900fps) and then do a MCC an hour later of about 170fps with the APS [14:42:37] I am then using P99 to burn the LM to a new pacific site and keep the CSM on a MPL target via corridor control RCS [14:43:37] I would need to get myself a joystick that would work as a passable TTCA/THC if I want to try that [14:44:29] I need to finish my THC but its still packed in boxes [14:45:08] I did the APS using KBM, mostly in translation (my Apollo 13 skills came back with using TTCA for attitude control) [14:45:39] Followed the Docked APS contingency procedures and got within 5 fps of the target [14:45:52] Will save the rest for RCS corridor control [14:46:20] LM is shut down and cast off in burn attitude and I did a separation maneuver [16:25:12] I've been thinking about doing a long-term polar orbit mission using the LM for extra dv [16:25:38] Oh yeah? [16:26:46] Nik shared a 3-impulse LOI document from Belcomm, I think it's very doable [16:30:04] you lose a lot of redundancy though [16:38:54] Oh I bet [16:55:10] morning! [16:57:21] hey mike! [17:02:29] what's up? [17:09:50] reading through that document I sent you from ntrs [17:18:31] looks like there were a few wheels that I reïnvented [17:29:48] heh [17:47:26] hey [17:49:11] Morning [17:49:28] Tried my hand at a docked APS burn under AGS control yesterday, that's a workout lol [17:49:54] Its very much a 2 person job [17:51:21] wow I bet [17:52:09] do you have to help it out or can it maintain burn att on its own? [18:01:58] You have to constantly fly it [18:02:28] It will not maintain attitude on its own, which is why the procedure uses PGNS guidance with AGS control [18:02:49] ah interesting [18:02:50] Need the TTCA's and direct coils on ACA to maintain control [18:03:04] holy crap [18:03:26] sounds a bit like that scene in Apollo 13 [18:03:51] Well thats where the procedure was developed from [18:03:56] Apollo 13's manual burn [18:04:01] right [18:04:02] https://www.dropbox.com/s/ot06vskftavk5xz/Screenshot%202022-02-11%20110335.jpg?dl=0 [18:04:12] From LM contengency checklist [18:04:43] It was an interesting ride but I managed a 170 fps burn [18:04:52] Since I couldnt finish TEI with the DPS [18:05:07] I guess with the realistic CG we now have, this must be quite accurate in NASSP [18:05:18] Yeah it certainly is evident [18:05:45] One thing I noticed in my TEI attempt is I had a weird transient when throttling up [18:05:58] I havent noticed it before [18:06:11] I ended up doing 10-40-100 to reduce it [18:06:14] I guess having 2 joysticks would be ideal for this [18:06:16] instead of auto throttle [18:07:14] btw chrival's FDAI textures have been added to the PR and is back open for review [18:07:50] Oh excellent I will add them to my little fun flight and see what they look like [18:08:57] Git question, is there an easy way to merge this PR into a local repo? [18:12:57] Ah got it [18:18:47] that looks good [18:19:06] maybe a little too tanned but thats just nitpicking probably as I am not used to it [18:20:13] it looks really good [18:21:12] Just in time for a desired REFSMMAT [18:22:35] https://www.dropbox.com/s/bjr9cojz7q536zr/Screenshot%202022-02-11%20112227.jpg?dl=0 [18:24:11] yeah I think he based it on photos of the real FDAI, which does seem to have a bit of a brownish tint [18:24:12] https://www.orbiter-forum.com/attachments/fdai-jpg.27791/ [18:26:01] Probably faded [18:26:09] But I think the off white is correct [18:26:20] https://www.dropbox.com/s/bddezsjmfdmqt7a/Screenshot%202022-02-11%20112613.jpg?dl=0 [18:29:27] I am of course open to un fading it a bit [18:29:36] But other than that it looks good [18:42:42] no performance impact either [19:52:46] you mentioned cg [19:53:26] we dont simulate negative g cg location in the csm do we? [20:18:04] I think he meant the docked vehicle cg [20:18:13] I dont think the CSM has shifting cg yet [20:19:01] docked cg. yes. that's the term [20:19:57] yep combined cg is simulated [20:20:14] doesnt work in the stable orbiter though [20:20:31] We found the issue and Nik got orbiter fixed [20:25:19] oh I know that [20:26:16] I was referring to the sps propellant shifting forward under a docked DPS/APS burn [20:29:19] Oh slosh, no not yet [20:29:24] but I think that would actually make your DPS dv lower [22:35:55] rcflyinghokie, mission specific c/w lights seem like something we should add. [22:37:18] Agreed just need to get the wiring for them and the systems [22:52:30] I was pleasantly surprised by the number of telemetry words dedicated to sps sensors [04:04:57] Oh a lot of them [04:05:26] I need to see if the sensor for rough engine, flange temp, and PU remained even without CW [21:51:27] Welp. I have one CTD cause that I can reproduce [21:51:51] If you open up an external MFD and resize it to 0x0 pixels the D3D9 client crashes [00:21:33] it also seems to crash if you switch from one MFD to another but only in some cases [01:02:09] Oh great the LM has magically decided it wants to do something else and just undocked. I guess Orbiter doesn't like time accelerating when docked [02:30:43] I time accelerate all the time docked [03:02:24] tell me it doesn't respond to the ctrl-d command [03:11:06] I've never had orbiter undock anything of it's own accord in my 17 years of using it. I'm going to count that one squarely as our bug [12:39:23] hey Niklas [12:39:38] hey [12:52:47] I saw you had some question about the shifting CG in the CSM? [13:04:23] yes, so we don't simulate the cg shift that would happen under a docked dps burn do we? [13:05:28] correct [13:05:38] I'm not 100% sure what I based it on right now [13:05:54] but I think it's the data for propellant on bottom of tanks [13:05:59] so when under SPS thrusting [13:06:33] maybe it's zero g [13:09:00] I briefly considered that Ryan's dv that he was missing might have related to a difference in moment arm [13:11:15] but If it were further forward that would almost certainly make the situation worse [13:12:07] hmm, how would it influence the DV? [13:19:34] steering losses, but I have a hard time believing that those could account for more than 2-3ft/sec [13:30:23] yeah I think so too [13:34:12] you'd need an average pointing error of 2.5° on 2900 ft/s to get to 125 ft/s [13:35:53] indy91: See PR. Your downstream fork has diverged from NASSP and any commits you make are done one a different tree from the one upstream. You need to rebase onto the current Orbiter2016 to avoid that growing list of commits being added now and in the future. [13:36:01] I can walk you through it if you need help. [13:36:16] and I still don't really understand how that happened [13:36:29] and I do need help yes haha [13:36:57] is it all because of the one PR that I merged a bit too early and where you still wanted to change the title of one commit? [13:38:09] Yes [13:39:00] I essentially rewrote a part of the git history, and you are still using the old 'history'. I didn't anticipate the fallout would be this however.. [13:39:44] So even though the commits are the same, git thinks they are unique, because they stem from a different origin point in the commit history. [13:39:49] would it get worse every time? Like in the future it will have even more commits, all since the rebase? [13:40:03] or is it just messy in this one PR [13:40:10] and then it will be ok in future PRs? [13:40:17] I guess it won't be ok on its own... [13:40:20] It only gets worse if we don't fix it now [13:41:09] ok. I need to be really careful with anything like hard resets, I always have lots of additional files and uncommited stuff of some half-projects I had started [13:42:11] Do you have anything untracked or unstaged right now? It's best to do this with a clean working tree. [13:42:52] You could stash your changes, but there is a non-zero chance they won't apply without a merge conflict after you rebase. [13:43:44] I have a hundred of additional files that appear in the "Unstaged Changes" list in the Git GUI [13:43:46] How did you set up your remotes? Own fork as 'origin' and orbiternassp/NASSP as 'upstream'? [13:43:58] Hmm [13:44:06] Okay, let me test some things then [13:44:25] and I hadn't created a branch yet for my deorbit targeting update, but I can easily do that [13:44:38] then everything in "Unstaged Changes" would just be additional files [13:45:00] I guess just the files in folders that git is not ignoring [13:45:28] would git really delete those under any circumstances? [13:46:05] I have orbiternassp/NASSP as origin [13:46:09] and my own as indy91 [13:46:52] Untracked files will be fine. But anything that is unstaged needs to be committed or stashed [13:47:00] right [13:47:04] well that's the same with merging [13:47:09] if that file got changed [13:47:30] untracked is files that git sees but not commited, right? [13:47:39] unstaged is files that git tracks, but not commited [13:47:46] but not staged yet [13:47:49] Exactly. [13:48:01] And I am using the CLI mostly haha [13:48:09] I use Git GUI where it is useful for visualize things [13:48:14] That's what I like to hear. :) [13:48:22] I used it for staging and committing [13:48:26] GUI is nice for resolving merge conflicts [13:48:28] everything else the CLI [13:48:53] it's nice to see the changes to a file you are actually making [13:49:04] I'm sure the CLI can show you that too but GUI looks nicer there [13:49:26] best of both worlds. At least it works for me hehe [13:51:28] I'm trying what you need to do in a bit. I'm getting a conflict in saturnmesh.cpp. There are some differences there [13:52:26] the CM aerodynamics [13:53:00] ok, I put the retrofire stuff in a branch [13:53:15] lots of untracked, no unstaged files now in Orbiter2016 [13:53:18] It's conflicting with this commit: https://github.com/orbiternassp/NASSP/commit/724e5f6ef76faf225a034671759dc5501dd6b79a [13:54:44] how can there be a difference [13:55:10] Figuring that out right now [13:55:58] Ah [13:57:48] Okay, so what a rebase does is it rewinds your branch to the point it diverged (so temporarily removing those commits), then fast-forwards to what you want to rebase onto. That is the current tip of the upstream branch that includes your aero commits [13:58:40] It then tries to replay your changes on top of that. However since it thinks you also made the aero changes it will apply those again in a commit by commit manner [13:59:00] so basically unfortunate timing in the commit history vs. the rebase [13:59:39] well if I get conflicts I can resolve them I guess [14:00:26] Sort of. Like I mentioned git has two instances of your aero commits and it wants to first do the ones already merged and then this second instance on top. It thinks they both made changes and causes a conflict [14:00:42] hmm [14:00:53] Nothing that can't be fixed. Just need to tell git which to pick [14:01:22] so you got to veto direct pushing of updates to the Orbiter2016 branch. Can I veto anything to do with rebase for the future? :D [14:02:30] Hehe. Maybe it's better if neither of us does this willy nilly in the future... [14:02:58] ok, so how do I start [14:05:45] I think I have something [14:06:10] Start with a git fetch on orbiternassp so we're sure that's up to date [14:06:42] ok [14:07:00] up to date [14:07:18] Double check that you have everything you want committed and that you are on your Orbiter2016 branch [14:07:36] checked [14:07:39] Then: git rebase -i origin/Orbiter2016 [14:07:47] That will open an editor, probably vim. [14:07:56] prays that I don't loose any files [14:08:24] You'll get a list of all the commits that you made in this branch compared to upstream [14:08:52] Like this: https://puu.sh/IITO9/36740f796f.png [14:09:27] yes, I am there [14:09:48] GNU nano haha [14:09:54] Oh [14:09:59] That works too [14:10:27] yeah it shows the same 8 commits as in your picture [14:10:45] You want to remove all the lines that say "pick 123456 message" !Except! "pick a727eb055 MCC etc etc" [14:11:20] https://puu.sh/IITPv/09433a5ed8.png [14:11:37] ok, so just the one commit from the current PR [14:11:55] This will drop the commits that git thinks are duplicate and only add that commit onto what is already merged, yes [14:12:25] Once you've done that you can save and exit the file [14:13:40] hmm, what do you mean with save [14:13:47] or is it "save and exit" in one go [14:13:54] like merging usually for me I think [14:14:01] CTRL + X is all I do... I think [14:14:05] Ye [14:14:07] Yes [14:14:26] Now git should say that it has successfully rebased [14:14:27] ok [14:14:33] I thiiiiiiink it did it [14:14:39] Your git log output should look like this roughly: https://puu.sh/IITQN/8045c9ba8b.png [14:14:48] successfully rebased and updated refs/heads/Orbiter2016 [14:14:53] A merge commit by which is the latest upstream and then your commit [14:15:29] If all looks good to you you can force push your now fixed branch [14:16:01] hmm, it didn't show me that list of commits [14:16:27] but I still think it worked right [14:16:37] Only the topmost two matter [14:17:00] maybe it showed it in the separate window [14:17:10] but not in the Git Bash [14:17:23] git log [14:17:24] so now [14:17:25] is what I did [14:17:27] git push indy91 Orbiter2016 --force [14:17:29] oooh ok [14:17:47] And you are spot on with that push [14:18:21] yeah, I have those two commits there [14:18:34] Cool, you're good to go then [14:19:01] seems like it worked [14:19:16] that wasn't as painful as I thought it was going to be [14:19:19] Hooray [14:19:46] will branches cause any issues? [14:20:02] Git interactive rebasing (what we just did) is really useful in a pinch. [14:20:19] Branches you might have that still originate from the old parent might also have this issue yeah [14:20:35] like the branch I had just created before [14:20:43] I'm afraid so [14:21:07] Same procedure applies. git rebase -i origin/Orbiter2016 and remove the duplicate [14:21:30] ah great, let's say I have probably more than one branch that might still get merged at some point... [14:21:59] so I rebase on Orbiter2016 while in the branch [14:22:24] Yep [14:22:32] well, it won't take too long until that comes up, I'll create a PR then and we will see [14:22:45] so, when I rebased my telemetry branch I had to resolve merge conflicts on a bunch of commits (git thinking that an added line was a changed line). if I rebase it again, will I have to resolve those same conflicts again? [14:22:47] for now I'll just merge like usual [14:24:30] Rebasing and merging achieve the same thing in a different manner. Merging dumps everything in a merge commit and adds that to your branch. Rebasing will replay what you did onto the current upstream version. [14:25:28] That's why I prefer a rebase for branches that get worked on for a long time. It prevents all those merge commits from being added to the PR [14:26:09] n7275: I don't think so since you've resolved those commits now. [14:26:16] s/commits/conflicts [14:28:44] ahh okay. [14:30:32] I should probably go through the specific heat branch and do this too, I think there are like 2 real commits. the rest are merges. [14:33:41] Thymo, ok in the rebase for the branch. The lowest commit in that "pick X" list is now the one (and only one) I did for that branch [14:34:00] above that is the commit for the PR you just merged [14:34:08] what do I pick [14:35:26] What numbers are behind pick? That's the hash of the commit [14:37:05] I think you want to remove the lowest one as that is what you have locally. [14:37:14] it's exactly the same list as we had before with the 8 commits to pick. But the lowest one is now the one commit in the branch [14:37:45] Oh I get you [14:37:58] and it's 9 commits now of course [14:38:00] just one added [14:38:11] Yeah same thing, remove the duplicates and only keep what is not in upstream (generally the lowest) [14:38:51] ok, so NOT remove the lowest one [14:39:07] No do not do that. I though you were trying to do something else [14:39:27] I think I'm slowly getting it now [14:39:28] I was under the impression you had two commits for the block data 1 calculation [14:39:41] this branch already knows about the block data 1 commit [14:39:51] because it got created when that was already merged locally [14:39:58] and now rebasing it thinks it would do it again [14:40:18] so I'll just keep the one commit there that was actually done for this branch [14:41:26] 10 points :) [14:43:15] ok, worked [14:43:29] I'm letting it show me a potential PR on Github and it now only has the one commit [15:00:10] thanks for the help! Let's not do this again [15:54:16] morning [15:54:51] Looks like thermocalc's Apollo 10 sent him on a very low pericynthion https://www.orbiter-forum.com/threads/apollo-10-with-nassp-8-beta-rev-1822_issues.40350/#post-590766 [16:00:55] hmm [16:21:02] Seems odd considering the MCCs were small/scrubbed [16:21:10] Might need a scn [16:21:38] yeah [16:21:51] the MCC logic follows the mission rules [16:22:04] and 50 NM pericynthion would be acceptable [16:23:19] but the node would of course still be 60 or more in that case [16:23:21] and the final orbit, too [16:25:41] So that points to TLI or the separation maneuver being off? [16:41:25] I would say the decision logic in the MCC for MCC-3 and 4 [17:14:55] hmm [17:16:37] everything in the decision logic and calculations just happily accepts if the perilune altitude after LOI-1 becomes lower than desired lol [17:54:15] Do the new FDAI textures still need anything done to them? It looks good to me, chrival has asked if we could give the 2D FDAI and instrument needle rendering a look at some point to increase their resolution. I think we can merge in these textures in the meantime though. [17:58:49] I also have no idea if the 2D rendering can be improved on our end or if it's a limitation of the old bitblitting approach we're using. In the latter case we should ask ourselves if we want to redo the whole panel or keep it as is and let the VC be the primary supported panel [18:26:38] I think the new texture looks great and my vote is that they be merged [18:27:42] I don't think there is much we can do by way of the 2d panel, except for making it obsolete by improving the VC until it is no longer necessary [18:27:53] imho [18:53:09] Yeah if anything the tan part might be too tan but beyond that they are great [18:56:03] like the blue of the DSKY is too blue :D [18:56:08] but yeah, the FDAI has a go from me [18:56:35] and concerning the 2D panel, there is still a bunch of bugs and general issues like the Orbiter clickspot loading bug [18:57:02] and lacking feature like the blinking border from the Checklist MFD we have for 2D [18:57:14] so we aren't quite there yet to say that VC is our main cockpit [18:57:21] but in the long term that will be the case [19:01:04] also VC needs more viewpoints as well [19:01:13] Thymo was pointing out a lot of panels hard to access [19:08:01] really? [19:08:16] not in my experience. We have good support for "leaning" [19:08:22] CTRL + ALT + arrows [19:08:35] with that only a handful of things are slightly inconvenient to access [19:08:38] TIL [19:09:11] I just checked, the Orbiter manual also never learned that it seems [19:09:42] ahh [19:09:47] TIL as well [19:10:22] I didn't know about that keybind, I'll play around with that. Some panels I found hard to access was the one containing the SPS line heater breakers (229 I think) and the cooling panel since they are quite far up [19:10:56] yeah the leaning is actually shifting the viewpoint, too [19:10:57] The alternative I used was TrackIR which worked quite well for my case. [19:11:13] especially panel... [19:11:58] 325 and 326 [19:12:10] with cabin pressure relief [19:12:25] can't access it very well from the left seat [19:12:39] but when you do CTRL + ALT + Left it works nicely [19:14:03] trying to find where we even define those in our code [19:16:05] ah just SetCameraMovement [19:17:30] the Deltaglider uses it [19:17:33] and its manual mentions it [19:17:43] not sure when I learned about it though [19:17:59] as I said, Orbiter manual fails to mention that key combination [19:20:16] I think our system is pretty good right now. We have 11 view positions, it gets a bit too confusing to move around if we add more [19:20:25] as long as we can actually cover everything with leaning [19:20:53] when you look at the COAS in VC, is that viewpoint aligned with the COAS properly [19:23:27] I think it is [19:23:31] but it looks very weird [19:23:38] the mesh itself isn't properly aligned I think [19:23:56] but the view position and direction is [19:24:06] just check any docked scenario, I see the docking target [19:25:55] hmm [19:25:59] or maybe it is correct [19:26:53] and it even works, yay [19:26:56] hadn't seen that [19:27:11] you switch it on and off [19:27:14] you can* [19:27:29] but only works in the COAS view position [19:27:33] up from the left seat [19:27:41] normal up, so CTRL + left, not shift [19:32:46] Also I noticed the CM docking target just appears and floats when turned on, its humorous lol [19:59:13] haha [19:59:38] interesting, so technically no mission rule or technique was violated in thermocalc's case with Apollo 10 [20:01:09] perilune after LOI-1 of down to 50 NM is acceptable [20:01:19] but would they actually have done that, what am I missing [20:05:53] FIDOs didn't care as much about mission techniques as you might think [21:26:39] rcflyinghokie, we got one more FDAI update [22:01:53] night! [22:43:54] n7275: I just tested and you can in fact use Ctrl-D to undock the LM. [22:44:15] I don't know why I would press that combo but evidently I did. [23:09:30] PR open [03:27:29] I'll look at the FDAI tomorrow...also might be good to somehow disable CTRL-D lol [03:40:18] Ah I just checked PRs and commented :) [12:54:00] .tell Thymo I genuinely had no idea that Orbiter supported key remapping. It doesnt look like that was a recently added feature either. not sure how I never noticed [14:16:42] Yep [15:20:31] good morning [15:22:08] hey [15:23:45] was following those entry issues on the forums, I mentioned twice to do retrofire uplinks ;) [15:24:35] I wonder how he got 170° as the entry target [15:37:18] Good question [15:46:01] he probably did at least some retrofire external dv uplink during the mission [15:46:20] padloaded are the west Atlantic abort area coordinates [15:46:35] east [15:47:41] wonder if an MCC or the initial TEI was computed using the wrong coordinates [15:53:17] or no retrofire uplink lol [15:54:27] well there had to be at least one [15:54:29] or a P37 [15:55:29] Ah true [15:55:41] I dont remember a P37 on 15's flight plan though [16:09:32] just writing an update to the RTCC MFD for the deorbit targeting [16:09:37] for the manual I mean [16:09:47] then that update with the sep maneuver is done [16:10:08] what I really want to do now is add the reentry simulation to the Entry PAD calculations [16:10:25] and then slowly, finally add the missing numbers for the PAD [16:10:36] starting with the 0.2G time for Earth orbit [16:10:54] that's the time when you would decide if you trust the CMC or go with the SCS [16:11:13] so fairly important procedurally and I don't think there is another way to get that time [16:33:37] I assume a simulation is how it was achieved actually? [16:38:24] yeah [16:38:36] that was the last trajectory integrator I implemented for our RTCC [16:38:57] already gets used for the RTE Digitals and retrofire displays [16:39:19] but it doesn't provide all the information it could yet [16:39:29] blackout times, drogue opening time [16:39:45] EMS range [16:40:23] I'm always afraid to break a calculation like the Entry PAD by including something new [16:40:32] but it should be safe enough [16:41:40] Those are the items on the later Entry pads, did those start with 15? [16:42:43] hmm [16:42:53] I don't think the format changed much from Apollo 8 to 17 [16:43:09] just our Entry PAD in the RTCC MFD and from the MCC is incomplete [16:43:24] both types of Entry PADs [16:43:33] Ah I see that [16:43:37] I never noticed haha [16:44:38] all stuff that you can't simply predict with a state vector at entry interface [16:44:46] needs calculation of the trajectory with drag and all [17:00:20] So here is an interesting one, have someone completing Apollo 8 and did the P01 and recovery [17:00:37] After MCC5, calling V82 caused a 1302 error [17:03:42] something wrong with the state vector maybe? [17:03:52] or flag salad [17:04:11] Well it got a SV update before the burn [17:04:21] I am assuming flag salad [17:04:34] https://www.dropbox.com/s/2ewqtd84qbqjv47/Apollo_8_-_01_-_Pre-MCC5_TIG-2min.scn?dl=0 [17:04:43] Burn the MCC, and call V82 per the checklist [17:04:56] SV looked good [17:05:04] If you go to P00 after the burn V82 works [17:06:17] ah yeah, there is different logic [17:06:27] V82 with or without average g [17:07:12] So what would cause the with to 1302 [17:08:42] I'm sure we can find out with the alarm data [17:09:12] also, pretty big MCC5 burn [17:09:56] Yeah i noticed that, maybe due to P23s and extra maneuvering [17:10:41] I am asking for TEI pad data now to compare [17:11:28] maybe no trimming [17:11:31] or too much [17:12:59] https://www.dropbox.com/s/2l0phsuaml6xkuu/TEI%20PAD.png?dl=0 [17:13:09] V05 N08 is 3404, 64, 0 [17:13:34] Residuals -1.8 +0.5 -0.1 [17:13:42] did not trim per flight plan rules [17:13:43] oh wait I forgot [17:14:01] -1.8 for cvx residuals [17:14:03] MCC-5 is done with splashdown longitude control right now [17:14:05] dvx [17:14:10] Oh [17:14:15] I'll remove that eventually [17:14:21] so this isn't just corridor control [17:14:24] for that it's ok I think [17:14:28] Ok so 6.6 isnt out of the ordinary [17:14:33] How about the alarm [17:14:53] yeah with those residuals [17:14:56] pretty large in DVX [17:15:27] Yeah [17:15:37] definitely blaming the tailoff thrust in addition to some other factor [17:15:40] like framerate [17:15:42] or something [17:15:47] But within flight plan rules for trim [17:16:02] "Trim to 2.0 fps" [17:17:05] right [17:17:10] later missions do it differently [17:17:16] Apollo 11, trim DVX and DVZ to 0.2 [17:17:29] I'm not good at deciphering AGC alarm data [17:17:34] will need help from Thymo or Mike [17:18:51] oh interesting [17:18:55] in the GSOP for V82 [17:19:09] I see the different paths for Average G or not [17:19:20] but then I see another path for "Is P11 running" [17:19:37] or rather [17:19:45] "Is P11 or P00 running" [17:19:58] maybe that is a screwed up flag [17:22:36] and he did all the procedures in the transcript they used for recovery? [17:22:46] morning! [17:22:58] Yeah I believe so [17:23:36] hey Mike [17:23:50] V05 N08 is 3404, 64, 0 [17:23:57] Colossus 237 [17:24:01] alarm was 1302 [17:24:10] happens in V82 with average G running [17:25:57] I am trying to find out of he changed the flagword on the F37 after P52 or after going to P00 [17:27:27] He thinks he did it on F37 not not sure [17:28:39] indy91: program alarms from the interpreter aren't particularly useful... at least not in earlier ropes like this [17:28:42] that just points here http://www.ibiblio.org/apollo/listings/Colossus237/INTERPRETER.agc.html#5351525441425254 [17:28:44] hmm ok [17:29:25] someone recreated going to P01 on Apollo 8 during transearth coast [17:29:28] did all the recovery [17:29:33] but apparently not all haha [17:29:44] or they were told to avoid V82 in P40/P41 or something [17:31:38] Mike, it was Swag lol [17:31:40] probably will have to make a guess then [17:31:49] I'm sure it's a wrong flag [17:37:34] indy91 would doing the P01 accident way earlier influence this? [17:37:45] Like right after TEI instead of at 106h [17:38:06] hmm [17:38:14] maybe if it's Earth vs. Moon SOI [17:38:28] so, I uplinked a state vector and it got fixed actually [17:38:54] went to P00, uplinked [17:38:55] then P47 [17:38:57] and V82 [17:38:59] no alarm [17:40:08] it feels like a Earth vs. Moon problem [17:40:21] I could see that [17:44:54] I think CMOONFLG is in lunar SOI [17:45:00] and the SV itself, too, I think [17:45:12] but the scenario has passed back into Earth SOI already [17:45:17] MCC-5 is not in lunar SOI [17:45:52] 102:18:00 Collins: Okay. The purpose is to bring the LM and the CSM state vectors to Earth's sphere of influence. Step one: Verb 37 Enter, 23 Enter. Step two: At Noun 70, at Noun 70, load and register 1, 2, and 3 the following numbers. Register 1, 00002; register 2, five balls; register 3, 00210. Step 3: proceed on Noun 70, Noun 70. Step 4: proceed on Noun 25, 25. Step 5: do not proceed on Noun 18. Wait for 30 seconds; then do Verb 37 Enter, 00 [17:45:53] Enter. End of procedure. Over. [17:46:17] already that is more in reference to a P23 [17:46:58] I'm also not sure the burn will be good if the CMC still think it's in lunar SOI [17:49:37] nah [17:49:41] burn is perfect [17:51:47] and the flag gets fixed on its own actually when you exit P41 haha [17:51:59] so you can tell him, don't do the V82 at that particular moment [17:52:04] after the burn it has fixed itself [17:54:12] and the difference between corridor control vs. longitude control burn is tiny [17:54:35] corridor control only is 0.02 ft/s less [17:54:51] but I guess that's what 1.8 ft/s DVX residuals do [17:55:00] Ok so regarding the flag [17:55:41] It gets fixed when exiting P41, but what exactly is broken, and is it a result of doing the P01 in lunar SOI [17:56:16] could be [17:56:22] or P23 [17:56:45] I'm definitely sure the flag for Earth vs. Lunar SOI is wrong [17:56:54] but what's confusing is [17:57:06] V82 shows Earth relative data anyway [17:57:24] and the state vector itself and some flag for it, and also the P30 data, are all Earth SOI for MCC-5 [17:57:46] Well a SV and P30 were uplinked before the burn [17:57:55] So those were correct [17:59:02] I think something I said was contradictory [17:59:14] how could I replicate the issue with P41 -> P00 -> P47 [17:59:21] if exiting P41 already fixes it... [17:59:25] you couldnt [17:59:27] oh right [17:59:35] I exited P41 before Average G [17:59:50] then it's not fixed [17:59:59] Ah [18:00:31] P40/P41 convert a normal state vector to IMU coordinates [18:00:32] https://www.dropbox.com/s/7lujxhpr93mo3zz/Apollo_8_-_01_-_Post-TEI_0002.scn?dl=0 [18:00:39] If you want to try a P01 then [18:00:41] and then back after it ends [18:00:59] so the flag it checks at the end of Average G must be correct [18:01:19] So did we miss a step on the recovery or is it still based on doing it in lunar SOI [18:01:20] maybe [18:02:33] I mean there is this procedure I quoted earlier [18:02:51] Collins says it's due to doing a P23 too close to the switch point Earth/Lunar SOI [18:03:51] Exit P41 before Average G -> P00 -> P47 -> P00 also fixes the flag [18:03:57] so exiting Average G fixes it indeed [18:04:44] if he did that P23, too, maybe it wasn't the P01 [18:04:53] but the late exit from P23, like on the actual mission [18:05:06] that somehow prevents the switch to Earth SOI to work completely [18:05:10] Ahh yeah he did P23s [18:06:35] how was it fixed [18:10:08] on Apollo 8? I quoted the procedure earlier [18:10:30] Oh the SOI change [18:10:57] Was that what will prevent the 1302 in avg g? [18:11:21] fixing that flag prevents the 1302, yes [18:11:36] I don't know why they go through P23 [18:11:46] so maybe it's not entirely the same issue [18:12:52] wouldnt uploading a new SV fix that or is it not set that way [18:13:36] I would think so, too [18:13:41] I uplinked one and it got fixed [18:13:54] maybe uplinking to the LM slot and doing V47 does not fix it? [18:13:57] haven't tried that yet [18:14:02] Hmm [18:14:30] also [18:14:36] there is a program note for Artemis even [18:14:46] that V82 can produce 1302 alarms in some case during TLC and TEC [18:15:17] Ahh [18:15:43] if you do it far away from the current body [18:15:54] after MCC-5 would fall in that category [18:17:07] hmm [18:17:12] or is that for Luminary only [18:18:19] were you able to check the SOI flags by uplinking into LM slot and transferring vs CM slot? [18:18:29] nah, both [18:18:33] I'll check [18:18:59] because if that fixes the SOI then something else caused it [18:21:23] seems to get fixed [18:21:38] but [18:21:46] the SV uplink might have still been in Lunar SOI [18:21:58] switching the SOI could still be broken [18:22:09] uplinking right now gives an Earth SOI state vector [18:22:13] which just circumvents the problem [18:23:12] Any way to check which SOI the uplink was in? [18:23:50] not directly [18:23:54] only by the time of it [18:26:04] on that trajectory it was [18:26:13] about 100:35:30 GET [18:36:13] so that might have been the case [18:50:52] hey [18:52:03] have you guys tried the updated FDAI textures? [18:53:49] Ive only looked [18:53:56] They arent in the PR so I havent merged them [18:54:03] ah I see you added a message to the PR [18:54:23] Yeah [18:54:33] I was going to ask before adding them to the PR, but you guys are waiting on me haha so Ill do that now [18:54:43] Yeah might as well [18:56:23] thumbs up from me [18:56:36] although I have only ever looked at the CSM FDAI actually [18:56:46] but I'm sure LM is fine [18:57:47] done [18:58:06] building and testing shortly [18:58:11] yeah I looked at the LM ones and they look good I think [18:58:42] they looked great before, I just wanted to see them in the SC itself [18:58:54] With the color change [19:00:31] its still off white, but a bit less then before [19:00:50] I think that should be right though [19:02:40] well the FDAIs have definitely been used a lot in testing and training before launch [19:02:56] not sure if the color would be a sign of that or only age though [19:03:01] but I am fine with it now [19:08:16] looks good here [19:26:56] indy91 can you help me understand the P37s a bit? Like the -MA vs not, and the little erasable change on 8 [19:27:18] sure [19:28:39] Colossus 237 has a hardcoded "speed limit" for the reentry trajectories [19:29:09] indirectly, by giving a maximum major-axis [19:29:25] which is just twice the semi-major axis [19:29:58] Apollo 8 had two changes done to their trajectory in mission planning [19:30:08] they used the steeper contingency target line [19:30:15] for the flight path angle at EI [19:30:26] like, -6.5° instead of -6.3° or something [19:30:36] and then, because no LM and spare propellant [19:30:52] they decided to return home 24 hours faster than originally planned [19:31:02] gives a larger TEI DV, but they had enough [19:31:11] aaaaand now they run into the MA limit [19:31:15] Ahh [19:31:23] -MA is "without the limit"? [19:31:34] the limit is hardcoded [19:31:35] but [19:31:44] it gets copied into erasable by P37 and then used from there [19:31:58] the copying is done after you press PRO on the first N60 [19:32:04] right after [19:32:12] and what you do then is manipulate that limit in erasable [19:32:17] Ah i see [19:32:22] that's the -MA procedure [19:32:27] so you have to do it kind of quick [19:32:37] the procedure is necessary for returning from the Moon [19:32:45] and maybe late TLC aborts [19:33:04] but not early TLC because its orbit after the abort maneuver doesn't extend that far [19:33:07] its been a long time since I have done P37s haha [19:33:33] So I am doing 122 hours as my TIG I assume [19:33:45] sure [19:33:56] that's like MCC-6? [19:34:00] yeah [19:34:06] this P37 was done after MCC5 [19:34:12] ok [19:34:22] what is dT transfer [19:34:25] you are following the CMP Checklist, right? [19:34:27] yes [19:34:29] abort maneuver to EI [19:34:41] should be about 22 hours for you [19:34:43] Thats what i assumed [19:34:52] N60 can be confusing [19:34:57] 24:48:17 [19:35:14] these are the second iteration [19:35:17] ok [19:35:27] I assume thats what this is and why those 3 nouns come up twice? [19:35:39] Kind of like final passthrough [19:35:43] actually there is a conic calculation and a precision calculation [19:35:49] first time through is conic [19:35:53] ahh [19:36:05] I am on precision then [19:36:08] that's where it will iterate on the flight path angle [19:36:15] but it won't in the precision phase [19:36:19] N60 +36219 -00653 [19:36:23] that's why N60 pops up again [19:36:37] where it shows the flight path angle it will use in the precision calculation [19:36:59] right, that is velocity and angle at EI [19:37:05] the first N81 I had like 5fps [19:37:09] thins one is 0.1 [19:37:12] this* [19:37:19] sounds about right for MCC-6 [19:37:34] MCC-7 the difference between conic and precision will be near zero [19:38:00] because of my distance from earth? [19:38:04] yeah [19:38:10] ah this is all clicking now [19:38:21] MCC-6 Moon is pulling you back and Sun is pushing you sideways or whatever haha [19:38:40] but from MCC-7 to EI there is no time for that [19:38:55] and Earth gravity dominating [19:39:03] ah I see that makes sense [19:39:31] late TLC aborts, difference between conic vs precision is huge [19:39:31] So -MA is used for MCC5 and 6? [19:40:01] nah, the issue with the MA limit applies to both conic and precision [19:40:09] and is just a function of your trajectory [19:40:24] so you will always have to do it [19:40:41] you can actually check with the Orbit MFD [19:40:52] what does it say there for semi-major axis? [19:41:06] Hmm I am trying to figure out why some in the 8 checklist are -MA and some not [19:41:15] unless its a mistake [19:41:55] in the Checklist MFD? [19:42:08] all P37 during TEC have to use the procedure [19:42:42] Yeah [19:42:59] Not sure why I have some -MA and some not then [19:43:23] Dont know where that came from [19:43:30] hmm [19:43:49] I'll think about it, but I am fairly sure that it will give you a large DV if you don't do it [19:44:01] at any point in TEC [19:44:11] Yeah [19:44:20] unless the actual mission tested it [19:44:27] just to see [19:45:15] haha [19:45:19] 124:19:21 Lovell: Do you see that Program Alarm we got when we went through P37, 1302? [19:46:09] Interesting [19:47:00] just used a wrong TIG [19:47:22] but they did get a 1302 alarm on the actual Apollo 8, too :D [19:49:55] TLI plus 44 requires the procedure [19:50:22] TLI plus 35 didn't [19:50:55] So all the TEC M37s are with -MA [19:51:00] *37s [19:51:03] *P37s [19:51:27] I don't see a way around it [19:51:53] the major axis will change due to Moon and Sun pulling on the CSM [19:51:54] Makes sense [19:51:57] but not that much [19:52:09] I have fixed the checklist to reflect that [19:52:29] now I wonder [19:52:33] going to double check a few things before PR though [19:52:38] if the procedure is required for TLI+44 [19:52:46] oh, the steeper angle [19:52:58] so the 24h quicker return wasn't so significant [19:53:05] but using the steeper reentry angle is [19:53:41] major axis limit is 8e8 meters [19:54:01] in our Apollo 8 MCC-6 scenario the semi-major axis is 477.3M [19:54:21] would have to be below 400M (= 4e8) to be below the limit [19:55:23] whoever tested that code was probably more thinking about Mission E for Apollo 8 and not so much the Moon yet :D [19:55:54] Yeah and this 8 scn...107h, SMa 486.5M [19:59:37] so -MA for all [20:14:13] merged [20:17:18] cool [21:48:08] rcflyinghokie, "Change all Apollo 8 P37 procedures to include with -MA", what you meant there is all during TEC, right? [21:48:38] or did they not use P37 during TLC [21:48:42] only P23? [21:49:32] ah and P21 to determine the pericynthion [22:00:29] well answered my own question. night! [22:00:33] New FDAIs are merged [22:05:28] Awesome [22:08:06] I'm out of town for a few days, but I cant wait to use then when I get back [22:11:30] they look good [22:32:11] Only 20 more pull requests until we reach the 600th being merged [22:38:43] that's quite impressive [14:42:51] I think we can unpin the Mission Scenarios thread on OF now it's pretty outdated [15:06:08] oh wow. just looked at that one. [15:06:17] I agree. [15:09:03] unstickied lol [15:20:08] hey [15:20:13] good morning [15:28:47] done [15:28:48] https://github.com/orbiternassp/NASSP/pull/713 [15:29:51] I restructed the MFD pages a bit, too. Deorbit vs. Return to Earth pages [15:30:09] deorbit is now its own category instead of one page under RTE [15:30:31] the button for getting to the RTE calculations is still "ENT" [15:30:38] so Alex doesn't have to do 20 changes to the input guide :D [15:32:50] oh nice [15:33:58] now I'll see how far I can complete our Entry PADs [15:35:24] I am looking forward to that [15:35:43] Speaking of pads, whats the current status of the TLI pads and how they get computed [15:36:07] Also, can we make a template for 8 to remove the extraction attitude portion? [15:37:00] ah yeah, TLI PAD calculation in the MFD is still the old method [15:37:13] which is fine, but DVC can be up to 50 ft/s or so wrong [15:37:45] extraction attitude can be removed [15:37:59] are those attitudes computed or hardcoded [15:37:59] I have some PADs already with slightly different versions [15:38:10] computed [15:38:18] even in the MCC TLI pad? [15:38:35] roll still seems to be off [15:38:54] must be a flaw of the calculation method [15:39:09] or the LVDC? [15:39:17] How is it compared to the actual PAD [15:39:34] One sec I will get an Apollo 8 example [15:40:24] For Apollo 8 MCC, the extraction attitude is already not computed [15:40:29] so PAD shows 0 [15:40:37] Right this is sep I am referring to [15:41:24] the MCC uses the MPT and the full procedures from the Apollo 11 audio for the TLI PAD [15:41:32] in this example the sep is 357 81 02, N20 at sep attitude 01, 80, 02 [15:41:49] Roll is off 4 degrees [15:42:22] actual TLI PAD was 10° off in pitch [15:42:27] pitch and yaw tend to be very close but roll seems to be consistently off [15:42:28] I already knew that [15:42:41] I think they get a correction [15:42:50] their roll on the PAD is 357° [15:43:04] yep [15:43:51] Any idea what accounts for the difference [15:44:41] not really [15:44:56] but in the case of Apollo 8 our PAD is consistent with their PAD [15:45:01] need to check another mission [15:46:40] like Apollo 11. Not only do I know the exact FIDO inputs to the RTCC, but I also have the exact calculations the RTCC does. [15:48:27] in case of Apollo 11 we have the exact same sep attitude as on the historical PAD [15:48:37] so maybe the issue is actually the LVDC [15:49:11] Ah [15:49:28] Also, looks like 10 didnt get an extraction attitude in their TLI pad either [15:51:32] hard mode [15:52:11] need to have the slide rules on the ground double check the arithmetic [15:56:26] so the LVDC just keeps 180° roll in its inertial reference system [15:56:47] while pitch and yaw have a bunch of conversions from LVLH to inertial [15:58:31] I guess first I need to check if it actually tracks 180° roll [15:58:40] and if it does, why that could be wrong [16:01:08] Yeah pitch and yaw are usually quite close but roll is typically 3-4 degrees off consistantly [16:01:17] yeah [16:01:34] Apollo 8 geometry should be simpler [16:01:40] not even a yaw... [16:04:36] seems like CSM IMU and LV IMU roll attitudes are basically exactly 180° apart [16:05:02] makes sense, the LV IMU alignment is basically the same as the launch REFSMMAT [16:05:36] so 0° in the CSM is exactly 180° in the LV [16:06:07] if you get 1° that is just the deadband [16:06:39] Right, which I do see [16:06:48] But 3-4 off seems higher [16:06:51] so it will go up to 1° and then slowly drift back [16:07:06] I feel like the 180° roll used in RTCC calculations is in an LVLH attitude [16:07:09] and not inertial roll [16:07:38] the difference would probably be the TLI burn plane change [16:08:09] liftoff alignment of the LV IMU is in the direction of launch [16:08:27] so inertial = LVLH roll, at least in parking orbit [16:08:29] ideally [16:08:45] maybe it's also the shape of the Earth being wrong again [16:08:55] but 3° is a bit much for that I would think [16:09:04] yeah [16:09:13] the latitude difference caused by that isn't that big [16:09:39] I could get a few TLI missions flown and get you the data on pad vs N20 if it would help at all [16:10:10] nah [16:10:28] what I could try is do a bunch of calculations to see if it is the shape of the Earth [16:11:33] launch REFSMMAT is calculated taking the right shape into account [16:11:49] that's why we get a larger IMU error in the P52 during EPO [16:12:03] Ah right [16:14:21] I wish we could fix those haha [16:16:46] hmm [16:17:09] I wonder if all the TLI PADs could be wrong [16:17:33] because it looks to me like the roll should be 0° [16:17:38] basically exactly [16:17:47] but that's not what the PADs say, ours or real [16:18:16] but that would be mentioned in the transcripts [16:22:17] Huh [16:25:42] yeah i dont recall a mention of that [16:28:07] for missions where is very little plan change during TLI the issue is probably less [16:28:15] I know Apollo 15 had very little [16:28:21] Apollo 8 and 12 the most [16:29:51] I mean, it's possible that the calculation for the sep attitude in the LVDC would use LVLH roll [16:30:02] but none of the documents we have does it that way. [16:30:16] But we have no document directly with the sep attitude [16:30:50] just the Skylab Saturn IB one with the detailed calculations for LVLH attitudes [16:31:06] and the Boeing document, with very little about post TLI at all [16:33:33] oh [16:33:56] I should be able to check this in the Saturn V flight evaluation reports [16:37:42] commanded attitude exactly 180° [16:37:43] inertially [16:38:02] but does this mean it's different from the CSM IMU... [16:38:12] or from the PAD angle [16:54:25] at least I can conclude that our TLI PAD calculations agree with the actual PADs [16:54:32] so if there is an issue it's in the LVDC [16:56:08] our LVDC or actual or both [16:56:30] well [16:56:46] our LVDC could be working different from the actual one in this case [16:56:50] but I am not so sure about that [16:57:19] if it works correctly then nobody never noticed the difference somehow [16:57:34] attitude timelines also have the ca. 357° [17:01:14] sadly I only know in the case of Apollo 8 that the inertial LV IMU roll angle was 180° [17:01:22] for the other missions they didn't include the same graph [17:04:07] The LV eval reports done have them? [17:04:10] dont [17:05:28] yeah. Only Apollo 8 [17:05:41] although I haven't checked them all yet [17:05:45] just 10, 11 and 17 [17:05:59] if something slightly unusual happened at sep they might have included it for some mission [17:06:23] but Apollo 8 already points to the LVDC working slightly different than they all assumed [17:07:06] maybe some compensation was done [17:08:11] I know there tends to be a azimuth misalignment between LVDC and CMC [17:08:43] which would be mostly roll [17:08:46] but it's not large enough [17:08:51] 000:20:34 Collins: Roger, Jim. When you do your P52, you can expect a torquing angle of 0.25 degrees. Over. [17:09:13] that's the difference between CMC and LVDC launch azimuth mostly, I think. In terms of alignment [17:12:31] not much at all [17:12:48] even that error plus deadband is smaller than I am seeing [17:19:43] we could use some actual IMU attitudes at sep [17:33:56] morning! [17:39:19] hey Mike [17:39:55] what's up? [17:42:35] we have a bit of a riddle with the roll angle on the TLI PAD, for the separation attitude [17:43:03] it's possible that all TLI PADs (actual and ours) and attitude timelines are wrong [17:43:58] hahahahaha [17:44:00] oh boy [17:44:51] alternatively it's our LVDC that is wrong [17:44:57] well [17:45:15] the Apollo 8 flight evaluation report supports the theory that our LVDC is NOT wrong [17:46:49] but we aren't sure yet [17:47:04] sounds like quite the rabbit hole [17:47:08] The inconsistancy seems to be about 3-4 degrees in roll across the board [19:46:01] indy91 are there any good docs on SCS and beta entry techniques [19:47:12] beta? [19:47:39] flying the CMC generated beta on the RSI [19:48:47] aaah [19:51:41] well AOH has a bit [19:51:53] Apollo 7 Entry Summary Document is pretty good [19:54:48] I dont have that one [19:55:58] https://ntrs.nasa.gov/citations/19700025002 [19:56:20] the other entry summary documents seem to lack separate backup procedures [19:56:50] ah [19:59:03] for general techniques (not so much procedures) the retrofire and reentry mission techniques are good [19:59:45] https://web.archive.org/web/20100520071924/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19750065849_1975065849.pdf [20:00:50] but for that specific techniques it's fairly simple [20:00:56] like the entry checklists say [20:01:13] if DAP nogo [20:01:19] SC CONT - SCS [20:01:22] Fly Beta [20:01:27] that's it [20:02:21] if CMC is no go, downgrade to EMS [20:02:33] if EMS is no go, fly bank angle [20:02:43] at least from Earth orbit [20:03:06] right [20:03:15] same for a lunar return pretty much [20:03:37] hmm, there is also the constant G technique [20:03:55] oh I forgot about that one [20:05:38] https://ntrs.nasa.gov/citations/19700024999 [20:06:41] that has stuff on constant g [20:06:50] usually 4 Gs on a lunar entry [20:08:11] and that's a lunar entry only technique [20:08:25] I need to fly some manual entries with the new aerodynamics [20:12:04] they are fun [20:12:30] in the 2D panel you can use the hatch window to fly [20:12:35] with the window markings [20:18:16] more relevant for Earth orbit reentry [20:18:27] For an EMS entry I guess I am trying to determine when to roll [20:18:46] I have a basic understanding of it all but I am trying to refine the techniques [20:20:00] the 180° roll coming from the Moon? [20:20:11] there are some lines there guiding you [20:20:31] yeah [20:20:42] i know to follow the slope [20:21:40] but as far as when to roll [20:21:51] Just trying to internalize it [20:24:15] before the trace becomes parallel to the skip out lines [20:24:49] G off-set lines I mean [20:26:56] Ahhh [20:27:19] how do i save my scroll [20:27:28] PAMFD has a button [20:27:42] GNC page [20:27:45] thanks [20:30:00] RTCC can simulate the constant G technique, too [20:30:11] they took a little chunk of CMC code for that, pretty interesting [20:53:36] rcflyinghokie, would you mind having a look at my PR? I added you and Thymo as reviewers. Of course neither of you is going to understand too much of this code haha. [20:53:45] But it's harmless, the MCC doesn't use this targeting yet [20:54:03] so it can be merged without potentially breaking stuff [20:55:15] Yeah absolutely [20:56:00] On the entry stuff, if I am flying EMS, am I still relying on the beta from the CMC? I see a lot of close to 90 angles being flown by the CMC [20:56:42] no, the EMS technique works completely without CMC [20:57:15] So how would I fly those [20:57:35] what would make me use a non 0/180 RSI angle [20:58:03] you will fly somewhere in between for most of the time [20:58:15] to modulate lift [20:58:37] using EMS ranging you would fly a fairly constant G level [20:59:31] Ahh so lift down if my range is decreasing too fast and up if too slow sort of? [20:59:51] yeah [21:00:05] once you are past the initial entry (on lunar entry), you will start modulating [21:00:08] like the CMC would [21:00:13] 0°, 180°, then in between [21:00:24] That makes sense [21:00:55] and I think you don't reverse the bank angle [21:01:09] so only lifting towards north [21:04:46] so watching the CMC fly and now analyzing the scroll [21:04:47] hmm, I have a broken RTE digitals [21:05:56] I see when the line becomes parallel with the off set line it rotates 180, then the next 180 I am trying to figure out the indication [21:05:58] Uh oh [21:09:01] don't know if it's my local changes [21:09:04] probably [21:09:06] can't be the PR [21:11:21] yeah haha [21:11:25] I'm on Orbiter2016 [21:11:29] oops [21:11:39] so I don't even have the PR in my local copy right now [21:11:47] only the local changes for the Earth Entry PAD [21:12:01] made some changes to the reentry sim, but only really to store more data... [21:14:52] oh [21:15:02] it's because no REFSMMAT is available haha [21:15:20] I guess that could happen in old MCC scenarios [21:15:25] just need to downlink a new one [21:15:35] there should be an error message for that somewhere... [21:16:19] indy91: Any chance you can also add the TeX sources for the manual to your PR? :) [21:17:06] I can, but it won't work without the pictures [21:18:48] I don't know how large those are [21:19:41] oh [21:19:43] very small [21:19:53] but I need to move them to another folder still [21:25:21] I'll make a separate PR for that, I'm getting confused what I have changed where [21:26:39] Thanks. That'll make it easier to see what has changed going forward. In time we can also add it to the build so it automatically builds the pdf. [21:27:03] right [21:27:15] yeah luckily it's not a lot of pictures [21:27:21] and they are all tiny MFD screenshots [21:27:30] Yeah, that's not too bad. [21:27:49] I have one minor comment on the PR. Looks good to me otherwise. [21:28:26] I am about to throw up some minor checklist changes, mostly just fixing a position of a valve being incorrect as well as spelling (missed the fact that "02" was used instead of "O2" [21:29:17] Also, is there any way to ignore EMS scrolls when checking for changes [21:30:22] Try adding /*.bmp to the .gitignore [21:31:07] or better .png [21:31:12] as these pics are png hehe [21:31:39] Oh lol [21:32:08] I'm not at my desktop right now. Made the wrong guess haha [21:32:44] good comment on the PR, I had already merged it, but I have similar logic in a few more places. If that works it's a nice simplification [21:33:21] thought I needed to make that a void pointer [21:33:31] its a bmp [21:34:17] oh, I got confused, I thought Thymo was talking about my pics in the RTCC MFD manual haha [21:34:40] would make no sense to ignore those, so... no idea why I thought that [21:34:53] So my memory isn't failing me :P [21:35:03] Haha not today [21:35:10] Got your coffee in I see ;) [21:35:13] no, just my lack of reading comprehension [21:35:16] or rather [21:35:19] lack of reading [21:35:20] in this case [21:35:29] Regarding the void pointers. Pointers can be type casted so even then you wouldn't need the temporary variable [21:39:24] ah right [21:39:48] well it's not a very pretty tex file, but I moved the pics and linked to the them with a relative path [21:40:50] That's fine. The latex for my thesis doesn't deserve a beauty award either. [21:45:24] only 4 pictures, I thought there were more [21:45:29] probably because there should be more [21:59:08] night! [15:13:44] hey [15:37:41] morning [15:45:07] I know I am getting ahead of myself but how difficult would making mission specific system test meter readings be [15:45:26] That and removing the placard from the LEB panel (which I think is from skylab?) [15:48:07] difficult [15:48:47] thats what I thought [15:49:04] either difficult or extremely messy code [15:49:09] pick one :D [15:49:42] Well at some point we have to cross the bridge of systems/panels for different missions [15:53:11] just dont know how to do it or approach it [16:03:36] I don't think it's a priority just yet [16:03:50] we don't need it too much for Apollo 7-11 [16:10:14] I was thinking things like the CW panel in the CM or the LM changes between 9 and 10 [16:10:23] Fall within the realm of our support [16:11:57] right [16:23:18] ok, I could add 5 items to pre and postburn section of the Earth Entry PAD each [16:23:35] right now tracking a bit of an issue with the 0.05g time [16:23:48] current calculation and reentry sim are 3.5 seconds off [16:23:58] current calculation seems to be the accurate one [16:24:49] hmm thats a big difference [16:25:25] one thing is that the simulation has a fixed step time of 2 seconds [16:25:44] so right now if it just barely missed 0.05g the time could be up to 2 seconds late due to that [16:30:00] oh [16:30:33] that needs to be made accurate, too, but I don't think it causes this lateness alone [16:36:31] why the fixed timestep of 2 seconds [16:37:19] I think that would be the normal step length for the maneuver and reentry simulations [16:37:27] also is identical to CMC guidance cycle [16:37:32] ah that makes sense [16:37:59] but, the maneuver simulation had some logic in it to stop at a next important event [16:38:26] maybe that's how the reentry simulation worked, too [16:38:44] but then it would have to predict somehow when a specific G level will occur... [17:38:04] I have an idea what it could be [17:48:38] rcflyinghokie, we could have a NASSP testmeter that's accurate to our wiring until we make a more robust [17:49:56] you mean to replace the placard? [17:50:41] yeah. at least then its accurate to what the meter shows [17:58:04] I mean I am all for that, or at the very least removing the one thats in there [18:12:16] always difficult to make bitmaps look consistent after all this time with someone new editing it [18:16:20] but yeah, it's annoying to have this Skylab stuff in there [18:17:33] annoying and confuses many [18:22:59] morning! [18:25:34] good morning [18:37:23] oh man indy91 I like your V5N9 theory [18:37:43] haha [18:37:50] it seems so obvious [18:39:13] 5 and 9 would also appear in the first digit [18:39:25] and it somehow inserts a 0 instead of blank somewhere [18:40:06] yeah that is almost certainly it [15:01:09] good morning [15:08:08] morning [15:13:11] hey [15:13:57] good morning [15:15:19] What are your thoughts on moving the pdf flight plans out of the main repo and into another like the padload worksheets etc [15:15:57] I think that would not only free up some size, but also allow more docs to be included without bogging down the NASSP main [15:18:56] hmmm [15:19:37] yeah, a separate "flight data file" package would be good [15:20:07] at least we shouldn't include original documents without being cleaned up etc. [15:20:43] I can agree with that [15:22:28] I generated a PR with some of them just for the files [15:22:34] I will say though, there are projects I've run across in the past that I gave up on trying to figure out, simply because the documentation was hard to find. so we should definitely lead people in the right direction [15:23:14] Yeah [15:24:02] I see there is a documentation one on there [15:24:07] https://github.com/orbiternassp/documentation [15:24:15] I think thats what Thymo intended to use for these [15:25:21] ahh okay [15:28:56] I am going to start adding a few [15:43:43] I'm tempted again to throw money at NARA [15:44:17] the hardest part is to get any answer, they never replied to my (rather generic) request if they had any IBM RTCC documents [15:44:37] So this might be ambitious but I would like to set up a mission to one of the other Apollo landing site locations, but frankly have no idea where to start haha [15:44:57] Isnt NARA still severely delayed? [15:45:34] yeah [15:45:39] well, I guess so [15:46:08] but I sent that IBM RTCC documents request in April :D [15:46:29] maybe they reply if I know that they have a certain document [15:47:02] the biggest problem with other landing sites is that we have no LVDC launch targeting tool [15:47:39] if you find a rough launch time in some document then you can at least launch to 72° [15:49:42] but then TLI is the issue [15:50:35] Ahh [15:54:04] wish there was a way to compute those launch windows [15:55:07] yeah I never got too far into developing something like that [15:55:31] Did a bunch of reading but eventually I managed to reverse engineer the right numbers for the flown TLIs instead of calculating them from scratch [15:56:46] Ah I see [15:58:02] we have scenarios for Apollo 11 July 18 and 21 launch [15:58:07] those do land somewhere else [15:58:39] we have an Apollo 12 LVOT for a September launch [15:58:45] not sure where those are supposed to land [15:59:27] UHCL has some more documents about launch vehicle targeting [16:00:05] if we have launch time and some LVDC parameters then we can create everything else [16:00:12] CMC and LGC are no problem to create from scratch [16:00:23] although we should try to develop a better process for that [16:00:35] I always wanted to develop some padload generator [16:00:45] I get the basics of it but not the computation [16:02:38] Like the math to be able to plug in a landing site and get launch windows :P [16:03:32] There are lots of documents that at least have a preliminary launch day for some landing sites [16:03:37] are you thinking about a specific one? [16:04:47] Copernicus or Tycho [16:05:08] No rhyme or reason, just curiosity [16:05:31] well Tycho will be difficult to achieve without some stunts like three impulse LOI [16:05:54] Copernicus on the other hand should be doable [16:06:03] and I am pretty sure it was the backup site for some mission [16:06:24] maybe 15 with its higher inclination? [16:07:44] I got to Tycho with Apollo 14 by burning a 4000 ft/s LOI-1 [16:07:52] took me a while to get it to calculate [16:10:05] https://www.hq.nasa.gov/office/pao/History/SP-4214/ch12-5.html [16:10:16] Has launch opportunity dates [16:10:41] Not sure if that helps at all [16:12:15] Tycho as a prime for 7 FEB 1973 [16:12:25] With Copernicus as alternate [16:16:32] and Feb. 19, 1972 for Copernicus itself [16:16:56] Yep [16:17:01] Its a start [16:29:19] TLI targeting sounds like a complicated boundry value problem [16:38:07] indy91 do you have a link to that bellcomm 3 impulse document. I thought I had it... [16:40:10] https://web.archive.org/web/20100520034726/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19790072409_1979072409.pdf [16:41:40] thank you! [17:28:31] morning! [17:32:13] good morning [17:32:44] what's up? [17:32:46] I started pushing Niklas to figure out alternate landing sites :P Not sure how well it was received ;) [17:32:51] heheh [17:32:56] I did find some launch window openings though [17:33:57] well I am looking at all my documents about launch and TLI targeting right now, so at the very least you managed to distract me haha [17:34:08] :D [17:35:29] when I a was already struggling with the reentry sim a bit and wanted to throw money at NARA for some documents [17:36:01] oh man [17:36:06] I wonder if they're on site or not [17:36:40] well they never answered my question about IBM documents from April [17:37:01] but in this case I would be able to ask for a specific document that I know they have [17:37:12] yeah that will definitely be easier to get a response [17:37:46] Well I am happy to offer a distraction! [17:55:16] launch time and TLI parameter calculations are definitely a topic I want to revisit [17:57:26] I'll make a separate MFD for it :D [18:08:39] Awesome [18:09:29] but there are a few projects I want to get out of the way first [18:11:22] for now we only have a process for creating launch scenarios when we already know launch time and TLI parameters [18:12:43] so in terms of alternate missions we can only do Apollo 11 July 18 and 21 launches and Apollo 12 September launch window [18:12:58] we don't have scenarios yet for the September launch window [18:13:50] need to find more LVOTs :D [18:58:29] Ugh ny internet connection is so frustrating it keeps "hanging up" when i try uploading the flightplans and such to git [19:30:03] git is a very bad way to store big binary files like PDFs for what it's worth [19:30:06] so that is probably not helping [19:32:19] Yeah, I am open to suggestions on how to better do it [19:38:50] I mean I happen to co-administrate a website that is dedicated to serving Apollo PDFs lol [19:39:02] Ron will be happy to hear that :P [19:39:21] yeah if there's stuff we don't have, just email them to Ron and ask him to add them to the website [19:40:11] in this case it's all stuff available on the Internet, but we want it as a nice package for NASSP users [19:40:27] could be distributed from anywhere, might as well be Github [19:40:40] gotcha [19:55:43] Yeah something organized and clear [20:46:55] the wiki is another option if Thymo is okay with that. [20:53:49] cya! [22:05:40] Lol n7275 you overestimate my upload speed [22:06:13] I host the wiki at home. Have 5 people downloading PDFs and it gets bogged down. [22:07:06] I maybe be upgrading to a 1gbit/s connection soon but then storage becomes a concern. I always use Ron's document library as my go to source for docs [22:07:56] I created the documentation repo the other day, that's my inteded spot to separate mission documents from the main repo into [22:55:30] Yeah I linked to it and messed up my origin for it but I have it fixed now [22:55:42] However, I cannot seem to get the larger stuff uploaded because of my connection [23:08:28] I am getting the missing 0.05g light in VC now [23:48:35] thewonderidiot, n7275, have you guys thought about the way to once again adjust the EL displays? [23:49:48] no, I haven't thought too much about it [00:56:56] I will side with whatever you all decide based on the evidence :) [01:06:43] Thymo, I didn't mean hosting them haha, I just ment a page with links to documentation. No reason not to have the repo and a links page though [01:10:18] I think hosting them in an organized library with proper naming might be handy [01:10:31] links can be a little confusing for some files with original names [01:12:10] sometimes original names are also terrible [01:12:23] my favorite example Symbolic Listing Information for Block II [01:12:35] which is a fantastic AGC programming resource but you would never guess that :P [01:13:32] rcflyinghokie, I'm searching through my logs for where we left off on that [01:19:32] thewonderidiot haha yeah exactly! I was thinking like a folder called "Flightplans" then inside "Apollo XX" then "ApolloXX Flightplan"...same idea for procedures and checklists [03:41:52] thewonderidiot, just watched Marc's latest video. it would be kind of interesting to send some of our telemetry over that link [03:42:05] yes it would! [14:46:00] good morning [14:47:10] hey [14:48:37] making a bunch more changes to the reentry sim and now the EMS range on the Earth Entry PAD comes from an integrated range for the first time [14:49:01] instead of using the CMC method of predicting it [14:49:25] not perfect yet, but in the Apollo 9 deorbit that I have been testing a bunch it gives slightly better results already [15:01:19] good morning [15:03:08] Oh great [15:03:20] And I assume it should be analogous to a lunar entry as well as far as predictions? [15:04:05] yeah, just have to add the reentry simulation to the Lunar Entry PAD calculation as well [15:04:42] I can add blackout begin, end and drogue opening times to the Lunar Entry PAD [15:04:49] and EMS range will have a better calculation [15:05:25] and I guess the time of V circ [15:05:30] whichever velocity that is [15:06:01] indy91, how familiar are you with NASA's GMAT? https://software.nasa.gov/software/GSC-17177-1 [15:06:18] probably the 25500 ft/s line on the EMS scroll [15:06:41] a little bit, I've tested some LEO trajectory stuff with it [15:06:49] but not too much [15:11:22] this might be more of an Alex question, but which setting(s) would cause the text to be blurry on the 2d panel? would using a higher screen resolution cause it? [15:13:20] no idea [15:13:38] the optimization tools are very powerful. I'm thinking about setting up a mission to target a high-latitude site. what information would we need to be able to set LVDC parameters for TLI? [15:14:21] maybe 8 vs. 24 bits or something [15:15:00] n7275, a state vector at cutoff would already work [15:15:20] although not for the full presettings, that is basically a family of trajectories, not one particular one [15:16:57] but a cutoff state vector is a good start [15:17:37] https://www.ibiblio.org/apollo/Documents/SaturnVLaunchVehicleGuidanceEquations.pdf [15:17:48] this has more details on that [15:19:01] somewhere in there at least [15:22:29] indy91 where is that selected any idea? [15:24:43] hmm, I'm sure it's a setting in Paint or whatever [15:24:59] oh btw, I had a bit of trouble in the latest CM/SM sep [15:25:04] auto checklist running [15:25:13] jettison controller fired but not sep [15:25:18] so started spinning out of control [15:25:27] hmm [15:25:34] what would cause that [15:25:37] we might have to change the checklists to hold the switch [15:25:44] there is a 0.1 seconds time delay for sep [15:25:54] same kind of issue we had with LV sep [15:26:23] I thought SetDelayTime in saturnpanel could deals with that [15:26:26] but maybe not [15:26:38] -could [15:27:22] I'll test it some more times before you have to make any changes though [15:30:16] yDid you verify that switch has it? [15:30:59] CmSmSep1Switch.SetDelayTime(1); [15:31:07] yeah [15:31:39] There is also some logic to prevents the pyro firing signal from being on all the time [15:31:54] maybe if you had a huge lag spike of 1.7 seconds it wouldn't do the CM/SM sep [15:31:58] but I doubt that is what happened [15:33:50] ill try it on my end [15:35:00] well I have been doing a few deorbits in the last days and it only happened once [15:35:13] so it must be bad luck with timing somehow [15:36:15] yeah it worked fine for me [15:37:04] this would only be in cases where the auto checklist does it and there is no holding commands [15:41:21] right [15:41:44] I can add a hold if needed for a failsafe of course [15:42:22] right, I'll let you know if I figure out what happened [15:42:33] then we might need the hold [15:46:24] sure, I can add it on all switches needing a hold to be safe [15:49:10] looking at the code the delay time should apply to the auto checklist [15:49:20] all switches have a timestep function that normally doesn't do much [15:49:41] for springloaded switches it causes the switch to return to the default position [15:49:55] unless there is a delay time, then it doesn't reset for that duration [15:50:01] and also not if the switch is held [15:50:29] the "held" variable is used when you Shift + click on a switch [15:50:40] or with the Checklist MFD [15:51:21] so I am a bit confused why it happened. There isn't a 1 second delay of something [15:51:33] then the 1 second delay might randomly be long enough or not [15:52:00] but there is only a 0.1 second delay from switch to CM/SM sep... [15:53:02] I'll call it a fluke. Don't have to change checklists just for that. I'll look for it, if it happens again I might have a better idea why [15:54:00] Sounds good [17:17:53] morning! [17:26:46] hello [17:27:17] what's up? [17:43:18] hey Mike [17:44:07] hey hey [17:46:08] doing a bunch of deorbit + reentries to test the new Earth Entry PAD calculations [17:46:57] nice :D [18:29:21] Good evening [18:29:30] yo [18:29:58] How goes it? [18:30:39] pretty good! I managed to order all of the chips/transistors I want to use in my rope reader this morning, after a lot of watching for stock [18:31:08] still probably need to order all of the inductors and bigger caps sooner rather than later, but I think I'm mostly covered at this point [18:36:37] Cool [18:37:38] I'm gonna do some more Apollo 9 in a bit. Was supposed to be out this evening but there's a pretty big storm so it got cancelled. [18:59:39] awesome, did you ever get that terrain sorted? [19:05:51] Good one. I haven't solved that yet. [19:06:11] I'll go up now and nuke my Orbiter install [19:07:56] Good luck [19:29:47] Can someone check [19:29:50] Is SVN dead? [19:57:52] uhh [19:57:54] in general? [19:58:07] I fixed it [19:58:23] ah good [19:58:24] At some point the repo moved from orbiter-forum.com to svn.orbiter-forum.com [19:58:27] I had the former still [19:58:33] ah right, I remember that issue [19:58:53] I haven't touched my Orbiter install like this since 2018. It shows. [20:01:13] I remember that issue from other people, I haven't set up from scratch for even longer haha [20:02:44] With the texture glitches and CTDs I've been having I figured it's time for a clean install [20:03:05] right [20:03:18] one issue I got when my install became old is too many quicksaves [20:03:31] and when saving Orbiter for some reason goes through all save files [20:03:40] so saving too more than a second at that point [20:03:51] needed to move most of the scenario files [20:04:02] took* [20:04:11] Quicksaves is dangerous [20:04:25] Only takes one accidental "Clear quicksaves" to know that [20:04:32] I speak from experience [20:05:14] also an issue I have only heard from other people. I guess I just have my Orbiter window sized differently so that I never get close to that button [20:05:45] I do become afraid of clicking it though when I hear that [20:09:10] I periodically back mine up [20:09:48] I have a directory called 'NASSP Saves' with whatever I want to keep. [20:18:58] get your magnifying glasses ready, the Earth Entry PAD fits on an RTCC MFD page [20:26:49] with the added lines [20:27:27] there is two more lines for a chart update, I'm not thinking about adding those right now haha [20:27:46] first I have to research how those actually work, I believe it's for under or overburns on the deorbit or so [20:31:25] Oh wow it fits? [20:32:45] used a smaller font [20:33:00] basically the smallest font I usually use for displays [20:33:17] aside from the vector comparison display, I use an even smaller one there [20:33:36] Only really usable with External MFD [20:33:54] but the Earth Entry PAD fits exactly and is readable as is in the 2D panel [20:45:33] Just finished reinstalling [20:45:41] FPS in the virtual cockpit is now 4... [20:45:46] Something is not right still [20:46:06] debug mode? [20:46:50] Ah [20:46:54] I think so [20:47:13] I was wondering why I was suddenly seeing build warnings [20:47:52] right [20:48:26] I think we also have exactly 1 build warning in release mode [20:48:59] unless that finally got fixed, something in the Systems SDK [20:49:26] Yep that was the issue [20:50:01] Reinstall saves me some space too. I'm running beta without Orbiter2016 now. [20:50:11] Only copied the textures and didn't install the rest [20:50:42] ah nice [21:04:35] Thats how I have mine running [21:21:03] night! [21:53:23] Should the CMC be driving the rate needles while the IMU is in coarse align? [22:05:05] I think they can run [22:05:11] But thats a Nik/Mike question [22:15:21] Hmm I think rate is always supplied by the BMAGS [22:19:16] Not the PIPAs [22:19:42] PIPAs are for XYZ acceleration, they don't measure rate. [22:19:48] That's what the IRIGs do [22:20:08] But they are not hooked up to anything outside the IMU from what I can see [22:32:18] Ah right [22:37:17] Thymo, my PR will fix that build warning [23:18:23] there is definitely an appropriate amount of coffee that will allow me to finish this multithreading project...and I did not have that amount today [23:26:22] multithreading project? is the amount of coffee measured in metric tons? [23:31:53] Who'se been reading you the forbidden teachings :p [23:32:47] lol [23:34:42] our systems call their refresh functions in sequence by stepping through a linked list, one at a time [23:35:50] my fuel cell update will impact performance with the added systems, and I know there are many more things we want to add [23:36:42] How are you distributing the work? [23:41:00] I would like to create a thread pool that runs its own subset of the refresh functions. these would get saved into a vector of function pointers that would be split up equally at simulation start [23:42:29] Sounds like it would work [13:12:49] Hey [13:15:30] hey Thymo [13:18:55] Got 9 running in the background and doing a burn every now and then. Next up SPS-4 [13:19:15] I disabled gravity gradient-torque to see if that stops the CTDs I've been having [13:22:37] hmm, right [13:23:47] I'm not sure how it would affect it but Alex' install guide mentioned it might cause a CTD, we'll see [13:24:40] yeah, we had some CTDs [13:24:52] it was some leftover objects in the scenario basically [13:25:00] optics cover [13:25:09] or some Saturn stage that didn't get deleted for some reason [13:25:29] any vessel that is only defined with a config file [13:25:35] and not a dll [13:25:36] The only vessels I have are the CSM, LEM, S4B and MCC [13:27:19] iirc the gravity gradient torque cdt was at lunar impact of the SIVb [13:27:41] I remember it being S-II impact on the Earth [13:27:44] but it could be both [13:28:35] Atleast it was somekind of impact then [13:28:37] sounds like a singularity that orbiter doesnt have any provisions for handling [13:30:03] I have another issue My s4b never did the second burn to a heliocentric orbit. [13:30:29] Does MCC not uplink that burn or did it just run out of power? [13:30:42] it should uplink the removal of an inhibit [13:30:51] two actually [13:30:59] first the attitude maneuver back to orb rate [13:31:23] oh wait [13:31:26] second burn [13:31:42] Yeah, it did the first one [13:31:45] in my LVDC terminology second burn is the "TLI" [13:32:00] yeah no provision yet for that third burn [13:32:05] Second restart* [13:33:50] Well.. gravity gradient torque is not my issue. CTD again switching from the s4b to csm [13:34:09] oh you get CTDs when switching, weird [13:34:25] Not always [13:34:40] Sometimes it's pressing an MFD button under time acceleration [13:34:51] Sometimes it happens when I change viewpoints [13:35:10] I didn't have these issues on 8 [13:36:59] the second restart needs a lot of Apollo 9 only LVDC code, main reason why I didn't implement it yet [13:37:15] and in reality they already knew something wasn't quite working right so they uplinked a lot of commands [13:38:08] and when you try debugging the CTD it's leading nowhere? [13:38:22] There is a known issue with the External MFD in the VC [13:38:42] It's always in OrbiterSound or D3D9 code. I don't have symbols for that. [13:38:45] which I was able to replicate with Orbiters own MFDs, so it's not NASSPs fault (for once) [13:39:11] I didn't know about that known issue [13:39:20] But it is what I'm using [13:39:35] I think it happens when you switch around between different MFDs [13:39:45] STS mentioned it when he flew Apollo 7 in real time [13:40:02] and then I tried around and managed to replicate it without any NASSP MFD [13:42:54] easiest way to replicate it is [13:42:59] go to Orbit MFD [13:43:05] and then to Checklist MFD [13:43:12] CTD every time [13:43:25] lol [13:43:40] just tried it. You're right [13:43:46] that is how we found out about it [13:44:08] well actually works with most MFDs [13:44:15] Orbit -> Align Plane [13:44:19] does it as well [13:44:37] I guess something doesn't like loading a new MFD type [13:45:01] are you using the standard External MFD or the DX9 one [13:45:07] dx9 [13:46:10] same [13:48:27] can't replicate it with the standard one [13:48:41] I also just tried it in a scenario with only a DG [13:48:51] so not any NASSP code messing things up somehow [13:48:53] Does the dx9 mfd have any advantage over the old one? [13:50:13] I'm not sure [13:50:57] I don't know if the DX9 client developers know about it, but it seems like something that can be fixed in the next releases of it [13:51:44] Whoa [13:51:58] Two program alarms on P52 option 1 coarse align [13:52:03] 211 and 217 [13:52:18] Coarse align error - drive > 2 degrees [13:52:24] Bad return from stall routines [13:52:48] goddamn not that one [13:53:07] Ryan got it near the end of his Apollo 9 mission and we were never able to figure out what caused it [13:54:12] Made an erasable dump [13:54:25] Time for some digging... [13:58:44] https://nassp.space/irclogs/2021/2021-03-16-12%3A36_Log.log [13:58:57] that's when we were talking about it [14:00:07] I bet when you switch to optics CMC mode then it already wants to drive the optics somewhere even in P00 [14:00:49] I think the bug is somehow caused by the last SPS maneuver with the TVC using the OCDUs [14:02:06] the CMC still partially thinks it should be doing TVC [14:04:27] OCDU error counter is on indeed... [14:12:58] it seems like something bad happens when you exit P40 [14:13:03] but I have no idea what [14:13:09] Yeah okay you say it only happens when you have optics mode in CMC [14:13:11] Mine are in manual [14:13:22] ah right haha [14:13:36] CMC mode is more of a suggestion [14:13:39] However it does happen when the OCDU error counters are enabled [14:14:02] CMC mode just sets an input bit to the CMC, software can still decide it is in control [14:14:05] Not controlled by that switch but you usually are in that mode when the counters are on [14:14:10] Indeed [14:14:15] which is useful for P24 in Artemis [14:14:33] So this goes back to that forum post form a few months ago [14:14:35] switch in manual, CMC tries tracking the landmark and you just have to do corrections manually and mark [14:14:41] Why does OPTMODES get set incorrectly... [14:15:06] This also happens in Colossus237 but no one reported program alarms there so far [14:15:16] Only the counter being wrongfully enabled [14:17:52] I've not read anything about it from the actual missions [14:18:07] so maybe it's some NASSP code with input/output bits [14:19:28] Maybe [14:25:55] Hmm [14:26:07] Went back to an earlier save [14:26:21] As soon as I take optics zero - off the OCDU counters are enabled [14:26:26] I don't think that's right [14:29:12] And now they don't.. [14:29:49] Oh wait [14:29:52] zero and mode [14:30:13] OPTIND goes form 77776 to 0 [14:31:41] OPTMODES goes 1520 to 1510 when I dod that [14:55:19] yeah such a weird issue [18:59:04] I just did the exact same thing as this afternoon. No alarms this time [18:59:07] So weird [20:39:27] .tell rcflyinghokie Another checklist item for you. G&N power down checklist. cb SCS LOGIC BUS x/y are wrong. Should be 1/2, 3/4, 1/4, 2/3 respectively. [23:42:34] .tell rcflyinghokie initial switch position checklist has cabin repress - close twice [00:21:46] .tell rcflyinghokie MFD has mnvr to AOT attitude an hour early [00:23:54] Setting the crew in PA MFD also doesn't work properly. 0 crew is 1, 1 is 2, 2 is 3. Dialog got broken somehow [00:41:56] .tell AlexB_88 In the LM VC Press Reg A is labeled close instead of cabin [13:07:38] Thymo, setting the crew in the LM? That can be a bit confusing, but I don't think it's broken. The number it shows is crew in the cabin, not including in the suits [13:55:28] morning! [14:08:25] hey Matt [14:09:51] so there is one annoying thing with the reentry simulation in the RTCC [14:10:00] 0.05g time is usually spot on [14:10:09] but 0.2g time is a few seconds too early [14:10:18] and it's only about 40 seconds between those times [14:10:33] but it doesn't look like a serious flaw in the reentry sim [14:10:53] one main cause seems to be the atmosphere model [14:11:13] RTCC uses 1962 US standard atmosphere, Orbiter uses later, better models. [14:11:34] At the altitude of 0.05g there is a 5% difference between the models in density. At 0.2g altitude it's nearly 9% [14:11:57] which model are you using? [14:13:02] J71C [14:13:06] I think that is the standard one? [14:13:26] but at these altitudes, 80-86km, there isn't too much of a difference [14:13:31] between any newer model [14:13:35] yes, I believe that's the default [14:13:47] 1976 US standard atmosphere also agrees pretty closely with Orbirer [14:13:48] Orbiter* [14:14:41] it's really above 90km where newer models can differ [14:14:52] 1962 one just seems to be a bit off at about 80km [14:15:08] I don't know how long they used the 1962 one in the RTCC [14:16:08] if I compare PAD data with actual from Apollo 7 and 9 then Apollo 7 seems to be pretty close to the predicted time between 0.05g and 0.2g [14:16:20] for Apollo 9 it was 4-5 seconds longer than predicted [14:16:23] I'm getting up to 8 [14:17:39] the exact time of 0.2g isn't critical for any G&N go/no go check, but that is the time when the CMC switch to P67 and you would then check the downrange error against a PAD value. If 0.2g happens later then there is a larger difference to the PAD [14:19:00] I have been using the NRLMSISE-00 model for a while because I think it's a bit more nuanced, but I think probably the biggest thing affecting both of these models is that Orbiter uses (iirc) a mean solar flux for all years, as the input to these models. [14:19:13] right [14:19:38] I'll check with that model [14:19:46] but I don't expect any difference at lower altitudes [14:20:20] oh one thing I need to check [14:20:32] our Orbiter Earth is of spherical, with launchpad radius [14:20:46] and that's what I am using as reference radius in the density calculations [14:21:29] maybe some parts of Orbiter atmosphere models don't use actual altitude for calculations [14:22:08] I think there is a drastic improvement in accuracy with NRLMSISE at high altitudes over long peroids of time, but below 125km or so they should all be fairly similar [14:23:30] Orbiter's spherical earth is a very annoying problem to have to contend with [14:23:32] I agree [14:23:42] just not for the 1962 model which is 9% off at 80km haha [14:24:31] and the G-level still increases quite slowly at that altitudre [14:25:15] so that difference can cause a few seconds difference in 0.2g time I guess [14:32:48] hmmm [14:33:05] J71C does this for the geopotential height [14:33:06] h = Z*6369.0/(Z+6369.0); [14:33:27] I'm using the actual radius that we have in Orbiter [14:34:06] ah I miscalculated [14:34:17] only is 1 meter difference, not more than a kilometer :D [14:45:10] yeah NRLMSISE-00 makes no difference compared to J71C [14:46:02] now I wonder if I should update our model in the RTCC. It would be closer to Orbiter, but I am pretty sure that until maybe 1970 they did use the 1962 model in the RTCC [15:00:58] well I'll keep working on this topic. Otherwise the update is done [15:18:00] I'm trying to add a new resource script to a project (.rc). If you guys go to File > New > File... > Visual C++ do you see an option there? [15:18:11] It's missing on mine. Not sure if my VS is broken [15:23:35] I see 4 options there [15:23:40] .h .cpp [15:23:45] .clang [15:23:52] and something I don't know [15:23:58] Yeah same [15:24:38] Microsoft is telling me that their should be another option ¯\_(ツ)_/¯ [15:25:47] Oh d'oh [15:25:55] Project -> Add new item [15:26:29] can't read [15:31:34] well neither can I aparently haha [15:33:33] I'm hacking together an Orbiter module and made the amazing decision to use CLion. One thing I've learned that if you need to use a resource file you're screwed and forced to use VS to create one. [15:33:54] Not just that, VS needs to recognise it as a VS project before it will even show you the option. [15:56:58] what are you making :) [15:57:32] A plugin that just runs in the background and calls oapiSaveState every 10 minutes [15:58:08] All I want to add is a simple dialog to allow you to change the interval and file name... [16:07:42] ahh nice [16:48:38] morning! [17:31:55] hey Mike [17:45:51] what's up? [17:47:05] finished adding some numbers to the Earth Entry PAD [17:47:08] now the Lunar Entry PAD [17:47:33] ncie :D [17:47:36] *nice [17:49:46] and you? [18:00:30] working on the PCB layout for my rope reader test board [18:00:38] getting pretty close to being able to send this out for fab [18:03:07] great [18:04:46] one step closer to having that important device :D [18:13:30] getting there! [21:33:34] night! [16:24:55] good morning [16:27:59] hey [16:42:52] Hello [16:49:02] hey Thymo [17:01:25] morning! [17:07:03] hey hey [20:45:50] found a nice and simple solution for a problem [20:46:05] the reentry simulation in the RTCC has a fixed integration step length of 1 second [20:46:16] but I would like to find the time when 0.05g happens exactly [20:46:19] and integrate to it [20:46:44] and 1 second is a bit too inaccurate. It's ok, but not ideal [20:47:18] all solutions that I had come up with for that were complex [20:47:57] But my simple solution is, if the 0.05g time is to be predicted to happen within the next second (linear interpolation), set integration step length to 0.1 seconds [20:48:11] and reset it to 1 second when 0.05g is detected [20:48:48] very simple, doesn't need any status bools, and doesn't have to deal with the fact that it won't integrate to exactly 0.05g [20:50:21] because if you try to calculate the time exactly and integrate to it then you might actually have 0.049g and then you need to introduce tolerances and all that [20:50:38] but 0.1 seconds is accurate enough. And at most it's doing 9 extra integration steps [20:52:25] nice! yeah that sounds like a nice easy solution :D [20:57:43] it's not very linear (time vs. acceleration), so if I would try to find the exact time then linear interpolation wouldn't even be good enough [20:58:40] and then I would need a tolerance if it's slightly below 0.05g and the CMC guidance uses a slightly different acceleration so at worst CMC detects 0.05g 2 seconds later than it should [20:58:41] etc etc [20:59:32] maybe one day I'll find out how they actually implemented that... [21:03:05] RTCC Apollo Programming System - Mission System - Reentry Computation, in the MSC corporate index. So, some chance at least that NARA has it? hahah [21:03:47] I'm not sure I even want to know, I would just stare at a list of documents I want like I am staring at the first pages of MSC memos that Ron has scanned... [21:11:11] hahaha yeah I know that feeling [21:14:47] I was just thinking about poking the smithsonian bear again [21:15:32] https://airandspace.si.edu/collection-archive-item/level-three-volumes-lm-10-and-subsequent-grummanpsd-led-267-57-february-3-1970-4-folders/sova-nasm-xxxx-0093-ref868 [21:15:58] now that I know what "level three" means, this is a much more interesting entry in the bellcomm technical collection [21:17:04] what does level 3 mean? [21:18:02] drawings like this https://www.ibiblio.org/apollo/Documents/LDW370-54001.pdf (the one we first found AGC pin numbers in) [21:18:18] 4 folders is super thick so presumably it would have all of the level 3 drawings for LM-10+ and also other stuff?? [21:19:01] that sounds pretty good [21:31:28] I ran across the acronym MOPS (Mission Operations Planning Systems) while reading through the version of Philco's display format manual that we have. Other than a brief sentence describing the acronym, I have not found any more info on the subject. [21:42:00] UHCL has a couple of documents with that in the title, but they're all very late [21:42:02] 1972 or later [21:42:11] and seemingly only in reference to skylab? [21:51:11] odd. maybe it was a later thing? [21:57:43] yeah I think so [21:57:51] but I dont know much about it either [22:22:35] night! [02:06:04] I may have written the worst implimentation of a thread pool ever [04:08:39] https://gist.github.com/n7275/d2372c974aa7f6ab25ca69511c987462 [17:09:52] morning! [17:31:18] hey Mike [17:32:50] my IRC app is being a pain today, so we're doing weechat over SSH :) [17:48:46] hey guys [17:54:10] hey Nik [17:57:59] I discovered last night that i can eliminate one of my 5th order polynomials in my fuel cell code with this new version [17:58:21] that should save some cpu cycles [18:02:31] ah nice [18:05:08] heating had to take into account all sorts of stuff like evaporation of water and heating of reactants [18:06:43] now that we have a good model for that its just heat of combustion * flow rate - electrical [18:07:10] right [18:09:27] I need to look at the deorbit targeting again [18:09:35] it has problems with RCS deorbits [18:10:11] in the first step it assumes an impulsive burn, Kepler orbits and curve fits for reentry to get an initial guess for the TIG [18:10:29] and after that it integrates through everything and converges the actual solution [18:10:42] but RCS deorbit burns can be 4 minutes long [18:11:01] and you specify the attitude at ignition in LVLH coordinates [18:11:18] so the thrust vector is far off for impulsive vs. finite burn [18:11:40] there probably needs to be some logic that compensates for that, in the initial guess calculation [18:12:28] yeah impulsive would be pretty far off [18:14:22] There is maneuver calculation in the RTCC called "perigee adjust" [18:14:35] I think it just calculates some maneuver that gets you a safe perigee [18:14:45] and the attitude is always with the 31.7° window line on the horizon [18:14:57] and it does have a compensation in pitch for impulsive vs. finite [18:15:06] so I'll probably use the same logic [18:17:10] that makes sense [18:18:11] in terms of inputs it will still be a bit annoying [18:18:36] to get a fixed attitude, retrograde maneuver for the RCS you will have to specify the LVLH pitch at ignition instead of 0° [18:19:08] so like in one Apollo 9 document example, the burn would start at +6.9° pitch and end at -6.9° pitch [18:19:16] and you have to input +6.9° [18:19:38] and internally, for the impulsive burn, it will compensate the 6.9° to ideally 0° [18:19:56] probably not unrealistically annoying for inputs though :) [18:20:15] but I think that's how it works. Have to check again, but the input attitude would be at ignition I believe [18:20:57] it's mainly meant for SPS deorbits of course where you want the window line on the horizon at TIG [18:23:19] RCS deorbit burn is supposed to be 100 ft/s, and so far I haven't been able to converge any solution [18:24:02] it will always get into a situation where that isn't enough to reach the atmosphere [18:28:24] the trajectory is probably not ideal, but it should be better with the right impulsive burn attitude [18:28:38] was trying with out Apollo 9 mission scenarios [18:28:41] our* [18:28:44] with the impulsive method or the new one? [18:29:49] previously [18:30:02] ahh okay. [18:30:19] usually the initial guess with impulsive burn doesn't reach entry interface at some point in the iteration [18:30:47] if the initial guess finds a TIG then the first time it does the integrated solution it is far off from what it had previously predicted [18:31:06] and then the first attempt at the integrated solution doesn't reach the atmosphere :D [18:31:20] i'm following now [18:33:41] so making the impulsive burn use an "average" attitude should help both of those issues [21:33:23] I made a bit more progress on the "Finding OS/360 related stuff" front [21:33:30] http://mwhume.space/Files/OS360TAPES/ [21:41:29] I need to add some sort of attribution there, it came from Rick Fochtman originally [21:42:21] this is some of the operating system code for the IBM 360? [21:42:30] the kind of stuff they then modified to create RTOS? [21:43:46] yes [21:45:10] this is the source code for the 21.8F (I believe) release of OS/360 [21:46:15] good stuff [21:46:33] I believe RTOS was "forked" around version 11, but there is a note in a document I saw at one point that said it had been "updated to OS/360 bersion 16" around the time that 16 released [21:46:50] *version [21:50:08] git merge OS360_V16 [21:52:12] haha [21:53:31] git is fairly painless compared with a deck of 20000 insert/update cards [22:07:14] night! [01:17:28] .tell indy91 you might find this interesting: http://home.kpn.nl/panhu001/Mission_Management/JSC/MCC/RTCC/RTCC_V3_40.jpg don't think I've ever seen a floorplan that included the computers