[14:08:32] NASSP Logging has been started by n7275 [14:08:34] good morning [14:09:59] Guenter! [15:37:09] good morning [15:38:46] hey Alex [15:49:58] if you join Discord, you probably have a whole lot of messages :D [15:50:08] asking for something in the virtual cockpit [15:50:42] ah yes I will take a look [15:51:09] ah is it about the new cross-pointer mesh [15:51:48] I think MaxQ already did the code changes for that [15:51:59] the update is in the pipline, so to speak [15:52:44] we need to figure out something for a pending pull request first [15:52:57] and then Jordan can do VC updates [16:19:40] hi Nik, Alex [16:22:13] hey Matt [16:22:37] repairing Open Orbiter 64bit builds? :D [16:24:40] trying to :) [16:27:14] I know virtually nothing about CMake syntax, that's the only thing keeping me from finishing that. [16:29:02] that one time I tried it, I was proud that I remembered how to use standard Orbiter MFDs to fly to Mars(?) [16:29:19] except that Mars was moving out of the way [16:29:23] to avoid me [16:32:12] hows the QRTP stuff going? [16:33:29] I implemented a bunch of stuff from the original documentation for it, but had to take it apart again for that. [16:33:55] before that I could generate LVDC presettings and RTCC files that got me a good TLI to a Tycho mission. [16:34:10] now I still need to repair it again to get back to that [16:34:26] still a bunch of bugs and issues I would like to get sorted before a release [16:34:39] but I will release it soon, even if it not everything is perfect yet [16:35:49] some better error messages [16:35:57] free return has issues [16:36:14] but I guess that is not the top priority [16:36:27] we will mainly use non-free return to get to new, fun landing sites [16:40:36] ah nice [16:42:48] looking forward to playing around with that [16:44:06] maybe Ill finally give one of those pending PRs a test, hows the "S-IVB propulsive LH2 venting" going is it just waiting for a positive review so it can be merged? [16:44:51] it's essentially ready. it should get a bit more testing before being merged. [16:45:16] launch through LOX dump after TLI on a random mission. Looking at tank pressures, making sure the S-IVB trajectory makes sense, too. [16:45:20] But also smaller things [16:45:25] Apollo 7 through LOX dump [16:45:35] Apollo 9 TD&E was done while the venting was enabled [16:45:49] so the S-IVB is coming towards you [16:45:53] a bit [16:45:57] that's a fun thing to test [16:46:06] can be done loading the mission scenario before it [16:55:27] so are the pressures now correctly displayed on panel 1? [16:55:53] yes [16:55:56] except for prelaunch [16:56:00] I believe it just shows quantity precent before [16:56:04] ah [16:56:06] during S-IVB burns they are basically fixed [16:56:16] not a super detailed simulation yet overall [16:56:28] but during coasting phases they are pretty realistic [16:56:41] would they show S1C & SII or was that not the case? [16:57:18] before S-II/S-IVB staging one of the meters showed S-II fuel pressure [16:57:31] that is still quantity percentage [16:58:08] in reality, not long before launch, you would be able to see the pressures go up to flight pressurization [16:58:23] for us it already starts there [16:59:20] from launch on the S-IVB pressures should be pretty realistic [16:59:54] there are some limitations, like, after orbit insertion the pressure goes up enough to need a bit of H2 gas venting [17:02:35] I've done by best, actual behavior of liquid hydrogen and oxygen is pretty complex :D [17:02:38] my best* [17:23:19] morning! [17:28:45] hey Mike [17:33:20] what's up? and how are you feeling? [17:33:52] pretty good. Yesterday I lost energy by noon, didn't want to move at all by evening :D [17:34:06] definitely an improvement today [17:35:49] excellent :D [17:50:16] understand CDUs yet? [17:58:07] not quite :D [17:58:34] I'm probably going to pull a couple modules in the next week or so and do some bench testing to measure some actual behavior [19:51:32] indy91, I'm combining my two systems PRs into one. They're really too interrelated at this point, and everyone that has been testing them has been doing so together. [19:52:07] good call [20:28:37] n7275, I'm going through some special DX9 features with Jordan and I stumbled upon SetupCustomCamera again. I think we had the idea to use that for CSM optics, right? [20:29:57] how would we implement that. Would it be: zoom in heavily on the eyepiece until you see only through it [20:30:28] or, click on the eyepiece and the camera view pops up over the whole screen [20:30:54] second solution is basically as if you switch to the 2D optics panel [20:34:45] a solution that doesn't even need special DX9 client camera solutions would be to make the full view a special camera [20:34:51] like, just a different view position really [20:38:17] My idea was something like this: [20:39:14] Have a hole where the eyepiece is that looks at a circular surface, upon which is projected the "camera" output [20:40:39] and you would zoom in to make it the full view? [20:40:55] or could even be a clickspot and that sets the coordinates to use the eyepiece [20:43:02] something like that, I think you'd want it sized to roughly fill the vertical FOV with Orbiters FOV (vertical?) set to 30ish [20:51:46] well, I'm sure there is an actual aparent image size that we could calculate [21:06:11] I'm imagining some geometry shaped roughly like the inside of an Erlenmeyer flask, behind the optics pannels. Image gets projected onto the "bottom" [21:11:38] well at first I would just try to render what we have on the 2D panel essentially [21:46:50] night! [17:36:42] hey [17:39:39] hello [17:44:06] morning! [17:54:44] hey guys [17:57:24] what's up? [18:00:10] some odds and ends with NASSP, giving Turry some tips with the Shuttle FDO MFD [18:00:14] and you? [18:03:40] web CDU is basically alive, but I was too tired last night so I just punch-card-ified a bunch of Sunburst pages [18:04:39] as usual lots of things to do. need to bring up the spare rope reader board [18:06:41] the flight spare for the January+ rope reading window :D [18:07:42] I feel like I have asked this question before, do we have any checkout procedures for DAP Aurora? [18:07:55] specifically I was looking for any checkout procedure involving the tapemeter [18:08:37] no, but we have the real Aurora 88 and lots of checkout procedures for that [18:09:12] hmm wasn't a special thing in DAP Aurora that it talks to the analog displays [18:09:19] so Aurora 88 doesn't have that yet? [18:09:43] Aurora 88 should have that [18:10:11] oh that would be good to find [18:10:18] I think I saw the Aurora 88 procedures [18:10:26] interesting colors... [18:10:38] in the engineering drawing library, 1002xxx are procedures [18:11:00] https://archive.org/details/1002323Images [18:11:02] ? [18:11:03] there might be relevant JDCs too [18:11:26] lol yeah, that's Ron's original bad scan [18:11:42] https://virtualagc.github.io/virtualagc/AgcDrawingIndexBox433.html#gsc.tab=0 [18:11:50] and https://virtualagc.github.io/virtualagc/AgcDrawingIndexBox434.html#gsc.tab=0 [18:11:56] are better scans [18:12:03] ah good [18:12:49] we also have these Grumman test procedures for LTA-8 and LM-2: [18:12:51] https://www.ibiblio.org/apollo/Documents/ocp-b-90000-b-1_lta-8_manrating_test.pdf [18:12:52] https://www.ibiblio.org/apollo/Documents/ocp-b-90008-lm-2_landing.pdf [18:14:48] "flight displays checkout" could be interesting [18:26:39] Grumman procedures sadly don't give the behavior when you just push in the tapemeter CBs [18:26:52] they do have procedures involving it at least [18:28:30] I think there should be two different MIT procedures. 1002323 is post-installation, and then I think there is another one for general testing at the cape [18:28:44] that latter one rewritten for Luminary but I think early on it was for Aurora [18:29:42] yeah, 1002349 [18:30:24] and then 1002380 is testing with Luminary [18:31:39] I don't see anything in those post-installation procedures with the tapemeter [18:31:48] just lots of IMU and some AOT stuff [18:32:21] ah maybe in 1002349 [18:36:58] the semi-automatic moding test should do things with the tapemeter [18:37:28] er, no. semi-automatic interface test [18:37:44] test option 11 [18:38:48] I've been scrolling since you posted the links, but I never find this stuff as fast as you :D [18:39:32] I have boxes 435 and 436 open. Did you already found the semi-automatic interface test specifically? [18:39:52] no not yet [18:41:31] there is never a good inventory and endlessly repeating pages. So all you can is scroll, scroll, scroll... [18:43:48] hmm [18:44:06] I think I am going to send an email to NARA and see how big LSC 350-307 is [18:48:39] what is that again? [18:48:48] also, how can I tell apart JDCs for the CSM vs LM [18:49:08] Grumman's procurement specification for the tape meter [18:50:06] simplest way, open them up and see which vehicle they're talking about lol [18:51:27] ah yes, ingenious technique :D [18:51:44] we have this https://www.ibiblio.org/apollo/Documents/apollo_jdc_index.pdf [18:51:47] which may or may not help [18:55:19] I think I found a crosspointer test [18:55:22] progress lol [18:55:27] hehehe [18:55:28] it calls it "velocity meter" [18:55:44] which might as well have been the 10th name I have seen for the tapemeter [18:55:59] the Aurora code calls the tape meter the "altitude meter" [18:57:55] yeah it always depends on what data is being sent to it [18:58:04] altitude and altitude rate from the computers [18:58:11] also called range meter for RR data [18:58:30] and all variations of range meter + range/range rate meter [19:01:07] but yeah, semi-automatic interface test is the best I would be able to find for a PGNS only procedure [19:02:57] or LGC output test [19:03:06] aha! [19:03:08] found a JDC for that [19:03:17] https://archive.org/details/apertureCardBox475Part2NARASW_images/page/n428/mode/1up?view=theater [19:04:41] at least I see the output bits there [19:31:05] AlexB_88, I might have to change something about your VC debug string that shows data for lunar landing [19:31:15] your LMP replacement basically [19:31:22] altitude and altitude rate [19:31:32] right now it takes LGC data from the tapemeter [19:31:41] but that data doesn't actually exist in that format [19:32:03] I can make it show the tapemeter values though [19:32:13] like, whichever source for it is selected [19:32:42] or did you specifically want to try and replicate DSKY values and getting it from the tapemeter class was just a workaround? [19:34:15] ah yeah I think I made it show DSKY values [19:34:28] but tapemeter value no matter the source makes more sense [19:35:07] I can't remember why I did it that way [19:35:16] DSKY class could be accessed as well potentially [19:35:28] the problem in the tapemeter, PGNS and AGS share a register for their data [19:35:46] so the way I am setting it up, there is no uniquely PGNS data variable anymore [19:35:53] unique* [19:36:05] right makes sense [19:36:21] I'll use the general tapemeter data then and give it a test [19:54:33] one problem with that, if you still are somehow on RR data [19:54:46] then the debug string would show tapemeter RR data [19:54:55] and not altitude (rate) at all [19:59:51] right [20:00:36] maybe that is why I opted for getting the DSKY values all the time [20:18:32] just that you didn't get it from the DSKY but the tapemeter :D [20:19:04] but the same LGC data [20:25:01] I think it's still ok though [20:25:14] every checklist has you go to altitude and altitude rate data [15:33:49] hello [16:23:16] hey Matt [17:51:19] morning! [17:58:40] hey [18:06:25] what's up? [18:08:12] helping Jordan make some virtual cockpit magic :D [18:10:25] and checking what the state of the OCDU output channel bit is [18:11:52] haha nice :D [18:12:02] the videos he's been posting look awesome [19:31:35] still getting tired easily. Night! [16:04:12] hello [16:12:32] hey [16:15:09] I seem to have picked up the flu over the weekend [16:17:49] oh no! [16:17:53] sorry for sending it your way [16:19:22] I thought SASL would protect me lol [17:05:17] ITAR is only protecting you from me, I am trafficking all my viruses as much as I want! [17:05:27] me from you* [17:29:54] morning! [17:30:40] boo, sorry to hear that Matt [17:32:53] hey Mike [17:47:24] it's been less than fun. I seem to be getting better though [17:49:14] I've got a weird thing now. I never lost my sense to taste, but now that I am almost through with Covid, everything smells and tastes really weird [17:49:23] sense of* [17:49:42] apparently some people have that in their recovery phase from not tasking anything?! [17:49:47] tasting* [17:51:41] I had the same thing when I got it [17:51:45] was kind of interesting drinking/eating different things and seeing how the taste had changed [17:54:56] right now I am constantly smelling something that isn't even there [18:27:10] when I had it in January 2022, I lost my sense of taste and smell. most of it came back, except the ability to taste garlic. [19:22:13] hey [19:22:55] hey Alex! [20:21:31] @n7275, I have a bit more time for NAASP so I think ill be flying a mission soon...maybe ill test some of the pending PRs like the SIVB venting and your Systems Update [20:21:45] anything in particular to look for for the systems update PR? [20:23:59] yay time for NASSP \o/ [20:25:51] AlexB_88 I think LM cabin temps are probably the last piece that we need to build some confidence in. [20:27:59] the Fuel cells and cryo systems have been pretty thoroughly tested, but obviously if anything weird happens, that would be cause for concern. [20:30:04] ok I will probably fly Apollo 17 and give it a good test [20:30:39] along with the SIVB venting branch, those 2 should be compatible I guess? [20:35:59] they should be [15:54:13] hey [16:25:47] hello [16:26:13] hey Alex [16:59:19] going to be flying 17 again soon [16:59:42] and ill test a few of the pending branches at the same time [17:05:18] fun [17:18:32] I want to fly 12 [17:18:37] never gave the MCC a test [17:18:43] will make some tweaks to it, likely [17:20:10] yeah its been neglected for a while :D [17:22:12] Turry will need it in half a year :D [17:22:42] ah yes [17:23:04] people have flown full missions with it. I think it's pretty reliable. [17:23:06] we might as well get him a proper surveyor mesh as well [17:24:46] btw, would it be possible to build a full SFP manually? [17:25:00] like using a scenario with full presettings and calculating a TLI+MCC from before launch for every possible azimuth [17:26:12] my mission planning and TLI targeting tool, that is under development, is outputting a SFP [17:26:24] with all that data [17:28:15] with the new format of the SFP file manual editing is a bit difficult [17:28:35] if there is any need to do that instead of calculating it automatically I can always add an editor for it or so [17:29:28] yeah I am eager to try this new tool out :D [17:29:38] added a local git repo for it today [17:29:44] sounds very powerful [17:29:46] it's not far away from an initial release [17:29:48] ohh [17:29:55] free return support is buggy [17:30:13] and I implement the writing of 32 plots by the QRTP [17:30:15] using gnuplot [17:30:21] but you need to have that installed for that to work [17:30:25] need to better set that up [17:31:20] with the launch azimuths, the workflow is basically that you adjust some input parameters until you are happy and then save the data [17:31:27] for 1 TLI opportunity and 1 azimuth [17:31:38] typical azimuths would be: 72, 81, 90, 99, 108 [17:32:02] just need to slightly tweak your inputs and save that [17:32:10] for both opportunities [17:32:45] SFP is derived from that [17:32:57] as well as the targeting objectives for the TLI targeting stage of the planning [17:36:22] ah ok [17:39:08] I wonder if it makes it out in time for my Apollo 17 run I could maybe re-create the full SFP for it...I might try a late launch and see how the MCC handles it [17:41:45] I am currently fixing up my Apollo 17 MCC branch to the latest NASSP state [17:42:29] hmm, did we have issues with the SFP on Apollo 17? [17:42:45] something not working right for late in the launch window? [17:42:55] no issues when I did it [17:44:13] it should work even better due to the constant arrival time TLI targeting [17:44:29] so the initial guess for GMT of pericynthion is basically valid for all launch times [17:44:37] ah right [17:45:09] I remember that it had trouble handling the alternate mission plan for a MCC-1 with CSM alone, getting back to free return [17:45:30] my tool can't do that yet, but there are separate parameters on the SFP for flybys [17:45:50] as a totally non-free return mission those flyby values would be optimized for that in the future [17:46:03] for hybrid missions they have the normal TLI trajectory flyby numbers [17:49:26] so for hybrid missions, it calculates both free and non free I guess? [17:54:07] it would, yes. Can't do that yet [17:54:25] it's really mainly useful so for for non-free return trajectories with no special LOI/DOI geometry [17:54:35] so far* [17:55:25] the QRTP part would be able to handle all trajectories already [17:55:39] it just needs to know the altitude above the Moon to fly by [17:55:52] and free vs. non-free [17:58:36] well I guess if it supports non-free then you can already make custom missions to a wide range of landing sites [17:58:43] just have to plan a LOI-2 :D [18:00:09] morning! [18:00:20] hey Mike [18:47:50] hey [18:53:04] indy91, when doing F62 to select a different opportunity/azimuth, do the interpolated numbers get saved in the RTCC, or does one have to do a F62 every time they reload a scenario to get the interpolated SFP? (thinking ahead for when we will have a full SFP and flying a late launch) [18:53:55] saved in the scenario [18:54:01] ah ok [18:54:07] so you just do the F62 once [18:54:12] per mission, yes [18:54:22] well, it was done in prelaunch I believe [18:54:38] if you then launch delayed or use the 2nd TLI opportunity you would have to run it again [18:55:04] the interpolated data gets saved in table 1 of the SFP [18:55:31] previously we only had one set of SFP data which was saved/loaded directly in SFP table 1 [18:55:55] that's why all old scenarios are compatible with my update [18:56:05] it simply had the 72° launch data in there already [19:02:37] right [19:35:57] also, if one has to do a 2nd opportunity TLI, can you just do "F62,,2,;" or must you also re-enter the launch azi? [19:46:25] also launch azimuth [19:48:01] ah ok [19:57:06] I just made the day of year optional [19:57:13] I think that is already not quite right haha [19:57:22] but the day of year already is saved in the RTCC anyway [19:57:27] might as well make use of it [19:58:19] yeah [19:58:32] alright my Apollo 17 branch is up to date [19:58:54] gave it the F62 calls after insertion like you did for the others [20:12:01] fun [20:12:13] I have to test that branch some time as well haha, like Apollo 12 [20:16:42] I am now creating a Frankenstein branch consisting of your Apollo 17 MCC, SIVB venting, Systems update and Jordan's VC branch [20:17:03] your SIVB venting branch* [20:17:48] and I will fly Apollo 17 with that :D If all goes well I can approve a few of those PRs [20:19:22] Jordan's VC branch will need a bunch more code cleanup [20:19:33] but you can find functional issues of course [20:19:54] right [20:20:46] I already noticed a few issues in the CSM lighting, a few panels in the back are still not tied to the lighting controls [21:05:28] good afternoon [21:06:13] I probably updated the commented-out J-mission cryo tank state... [21:07:33] but its been so long I can't remember [21:08:29] easy fix if it isnt [21:09:06] right [21:26:39] cya! [21:44:19] night! [16:29:22] hey [16:35:44] hey Alex [16:45:38] I don't know exactly why, but I have started to overhaul our failure code :D [16:50:09] ah fun [16:50:21] add more features? [16:50:58] well I was thinking about adding more [16:51:10] but I didn't like the current process for that in our code [16:51:33] so instead of adding new ones I am rewriting everything [16:55:10] good afternoon [16:55:39] that sounds cool [17:00:10] hey, yeah I hope this makes adding new failures easier [17:00:19] for now I have many build errors :D [17:36:38] morning! [17:53:43] hey Mike [17:54:30] what's up? [17:55:19] messing around with our failure code [18:21:28] will it still be done through the PAMFD? [18:21:35] yep [18:21:43] I'm not changing that for now [18:21:51] although there will be new saving/loading [18:22:17] should be a bit easier again to schedule failures in scenarios [18:24:38] with my new system I can also have a few more time references [18:24:56] like, S-IVB engine failures weren't implemented because J-2 ignition time is variable [18:25:19] oh nice :D [18:25:23] but now you could select e.g. engine fails 30 seconds after S-II/S-IVB staging [18:25:34] as we track those events already for the Checklist MFD [18:25:48] it was theoretically possible, but the timing code for failures was all over the place [18:25:51] now in one class [18:27:33] ah and we also have "TLI begun", starts at TB6 [18:27:44] we can have one of these failures that causes an alternate time base [18:27:51] O2/H2 burner failure [18:28:03] my S-IVB venting PR implements the burner [18:29:35] or J-2 engine failures at a specific time in TB6 [18:38:11] cool [19:07:02] that sounds awesome [19:45:14] I think I basically already have a version that adds no additional features yet, but works as before [19:45:57] AlexB_88, something for you to review: https://github.com/orbiternassp/NASSP/pull/1118/files [19:56:53] approved [19:59:01] effort break-down of me just approving the PR: Getting through the multiple security layers to login to my git account: 95% Actually approving the PR: 5% [19:59:41] :D [20:00:06] haha oh no [21:27:33] night! [16:44:21] hey [16:46:45] hey Matt [16:48:10] I haven't even made a draft PR yet, but I already pushed my branch for the failures. FailureOverhaul on my Github. Just in case you wanted to see it. [16:48:25] When it's being released I will add something to our wiki describing how it works [16:48:55] I should probably not go much further with it, already running into the danger of feature creep [16:49:02] I added support for generic switch failures [16:49:13] that was basically already supported before [16:49:23] all switches have a GetState() function [16:49:38] which normally returns to the "state" variable [16:49:42] returns the* [16:49:52] but you can set the switch failed [16:49:59] and then it returns FailedState instead [16:50:54] I had to make a few changes to the circuit breaker class so that it calls GetState instead of using state directly [16:51:05] but now you can set up timed switch failures of any switch [16:51:19] e.g. CMC circuit breakers popping open at T+ 1 minutes or so [16:55:14] For now I will probably just test that all our old failures still work in the branch [16:55:23] and clean it up and make a PR [17:14:09] morning! [17:16:22] hey Mike [17:17:46] how's it going? [17:20:49] playing around with failure simulation still [17:20:55] making progress with the CDU? [17:21:12] yep! [17:21:29] what kind of CDU did you try to simulate a few years ago? :D [17:21:44] that is an excellent question :D [17:21:49] definitely an earlier one lol [17:22:22] I'm going through the NOR logic now and I definitely used an earlier revision of the schematics [17:23:17] haven't found anything yet that will impact behavior [17:25:11] going to wire up the MSA&QR module again shortly and answer the gain question once and for all haha [17:26:25] reminds me of the ACA proportional control with the AGS. The Apollo 9 crew found the LM nearly uncontrollable with it, way too high attitude rates. They made a change to it afterwards. And we simulate that, too, with a variable gain in mission files. [17:26:40] We have one good source for the exact behavior of this... LM-1 Systems Handbook [17:26:51] so it's the version of it that most LMs didn't fly... [17:27:00] But I think my adjustments get us pretty close [17:27:17] oh interesting [17:28:12]