[15:37:05] NASSP Logging has been started by n7275 [15:37:07] good morning [15:38:22] hey [15:44:50] I see a new PR for review [15:48:41] two even :D [15:49:00] one just a few font adjustments for the RTCC MFD so that there aren't as many text overlaps [15:49:11] the other are the AGOP options I had already fully implemented [15:49:24] so not the "Point AOT with CSM" stuff yet [15:50:09] the other options were already pretty well tested, so, I thought I'd make a PR now before I get distracted by another project and never even finish the options that fully work already... [16:39:20] I'll review and approve later today [16:40:07] great thanks [16:40:18] both of them are quite harmless [16:40:37] the font size change is small so that it's at worst 1 pixel difference on the 2D panel [16:40:55] and the AGOP isn't being used by the MCC or anything yet, so nothing that can critically fail for a mission [16:43:27] morning! [16:51:23] hey Mike [16:53:27] what's up? [16:54:45] I think I'm finally going to implement that RTCC MFD feature to uplink EMPs from text files. Not a super important features, but, I've been talking about it for too long and it would have been useful for a bunch of people already. [16:55:04] ooooh, exciting! [16:56:52] should be better than manually inputting them haha [16:57:23] I want one file = one EMP, so, I just need to come up with a way to have a text file format that has multiple loads [17:04:39] we do have a lot of fun EMPs to put into it. maybe not useful for NASSP, but fun to mess with :D [17:07:22] some definitely useful [17:07:24] shortened P23 [17:07:40] SPS gimbal trim check without P40 is one I have tried [20:20:01] there's an ongoing discussion on the forum about Lua. I know we have a simple implimentation. but I wonder if there is any benefit to expanding that further. I keep thinking there is, but never come up with any good ideas [20:20:35] scripting for tutorials and demonstrations [20:27:47] oh that's a great idea [20:29:55] and I have done a challenge with it [20:30:06] for the least amount of propellant spent during TD&E [20:30:11] half a year ago [20:30:34] I see I have a "SPSTutorial.lua" file from middle of 2022, but, I did not get far at all [20:32:21] oh I remember that one [20:47:34] we have a way to cheat in that scenario now [20:47:45] you just have to do a 180° and 60° roll [20:47:50] ... and enable LH2 venting :D [20:57:50] night! [16:02:07] good morning [16:18:33] hello [16:19:30] hey [16:56:23] do we need a naming system for EMP files? [16:56:37] right now I just have P99 LUM210.txt and Short P23 ART072.txt [16:56:45] but when we have lots of files it can get confusing [16:57:02] on the other side, just naming it "EMP 99" is also not very good [16:57:46] well, I could include the GSOP list of EMP names in the RTCC MFD manual [16:57:54] then it could be numeric [16:58:06] seeems like they started CMC EMPs with the number 500 [17:01:24] We probably should have a naming or numbering scheme [17:01:56] maybe the files need a metadata header? [17:02:39] CMC/LGC, software version, name/description [17:04:30] yeah that makes sense [17:04:43] the MFD page could display that data [17:47:49] morning! [17:57:22] hi Mike [17:59:31] everything is booked for the trip :D and I'm making good progress bringing up the backup reader board [18:07:49] hey Mike [18:07:54] awesome [18:08:28] I think a week before I will create the branch to add it to NASSP. I still have some tests to do with the 1950 coordinate system. [18:08:53] but at worst our Skylab MCC support fails and I have to go all CMC :D [18:09:18] hehehe [18:11:05] I think my artemis branch is as ready as I can make it, with code removal and new flags added [18:16:57] fun [18:27:32] really the only thing I need to check before merging it into NASSP would be a RTCC state vector uplink and then a P21 test if it gives the right coordinates. [18:27:52] then just in terms of pure AGC coordinate system Skylark is supported [18:31:31] I should create a launch scenario for 2024 [18:31:47] because there is no reason to not launch there [18:32:48] oh man that would be great haha [18:33:00] I'm using the Orbiter ephemerides for the padload generator, so, no restriction there either [18:33:09] works at all times [18:34:29] I am very excited :D [18:34:46] it's going to be fun to disassemble a new rope that's so different, but that we have the Norton document for [18:35:17] yeah, it's really like halfway to discovering a new type of AGC software besides CMC and LGC [18:55:19] n7275, I think I will just add two lines at the top of EMP files [18:55:26] Name/Description and rope [18:55:39] EMP 99: Guided RCS Translation Maneuver [18:55:41] Luminary 210 [18:55:46] in the case of P99 [19:08:47] there could be EMPs that apply to all CMCs. Or even CMC and LGC. Then we could say that instead of the rope name [19:09:15] I don't want to deprive people from uplinking LGC EMPs to the CMC, so, I will not directly prevent that :D [19:31:42] that sounds good [22:12:06] night! [15:23:42] hey [15:24:32] hey Nik [15:27:13] I wasn't sure if I needed a manual uplink editing capability for the new displays [15:27:19] but some EMPs need it [15:27:38] there is one for a failed DSKY button [15:27:50] and you have to adjust one value in the uplink to the failed button code [15:28:57] so I guess for us, you load the specific EMP load that needs one thing edited. And then you use the MFD button to do the edit. Should be simple enough, give it line and value to change. [15:31:49] there are also some fun Skylark EMPs... [15:41:59] maybe we need an intermediate stage between uplink creation and the actual uplinking [15:42:13] some kind of "load editor" [15:42:18] oh I definitely have that already [15:42:32] the load button gets an uplink load from the file to the display [15:42:43] then you could edit it, which I now need to implement [15:42:49] and then you press UPL [15:43:16] I'm sticking pretty closely to how the real inputs and displays worked [16:07:41] hey [16:30:37] hi Alex [16:31:13] hey Alex [16:50:43] uplink editing works. I guess I can already make a draft PR today [16:53:34] ah nice [16:53:43] is that for custom EMPs? [16:55:12] yeah, we can then put EMPs in text files that a new uplink page in the RTCC MFD can load and then uplink [16:55:26] and editing the uplinks can also be done [16:55:29] in some cases has to be done [17:02:57] AlexB_88, how did the rest of your mission go? [17:05:38] morning! [17:09:09] hey Mike [17:19:38] n7275, went well other then the CO2 in the LM suit circuit went way up after my final EVA so I had to leave the astronauts in cabin for liftoff and rendezvous [17:19:53] but I think that I had that happen also before your update [18:40:41] draft PR is up [18:42:29] I wonder how hard it would be to get yaYUL to assemble EMPs [18:42:47] it would be nice if we could transcribe the code and then just assemble it for whatever rope we want [18:43:10] instead of having to transcribe octals for each different rope, and then have to manually massage the octals if we want to run the EMPs with different ropes [18:46:47] oh yeah that would be interesting [18:47:50] I guess EMPs mainly became a thing because the development of the software got frozen? [18:47:59] but they started appearing with P99 already a bit earlier [18:48:18] but we then could have the same EMPs for earlier ropes without too much trouble [18:50:12] there were all sorts of EMPs used for testing on the ground too, much earlier [18:50:14] but yeah [18:50:34] if I find time soon I'll mess with that [18:50:53] lots of stuff going on at the moment :D [18:53:19] when my PR is done I can at least transcribe all the EMPs we already know about [18:53:35] even the Skylark ones :D [18:55:11] :D [18:55:29] I was looking for a weird Skylark EMP the other night [18:55:46] I thought we had one that was used to test IRIGs or the IMU somehow on the ground, published in some testing memo [18:55:49] but I'm having a hard time finding it [18:56:54] we have GSOP section 7 rev 0 and rev 2 for Skylark I think [18:56:58] rev 2 is for ASTP [18:57:02] yeah, it's not in those [18:57:24] sadly there is at least one EMP they removed from the ASTP document which had an update in rev 1 [18:57:37] oh that sucks [18:57:43] so we don't have that updated version [18:57:57] which one is that? [18:58:48] Generalized Rotational Rate Generator [18:58:55] a pretty substantial EMP, requires 10 uplinks [18:59:18] "This EMP provides a means of imparting a rotational rate to the Orbital Assembly." [18:59:38] boo [18:59:42] do you have any idea what they changed? [18:59:45] "This capability can be of use in conjunction with docked +X translation maneuvers, CMG desaturation and the initiation of "Wide Deadband Attitude Hold"" [19:00:06] no it just says in the changelog in rev 2 that there was an update to that EMP in rev 1 [19:00:25] rev 2 has an "IMU slip ring program", but that's probably not what you mean [19:01:02] oh actually it might be [19:01:14] "This EMP provides a means of simultaneously rotating all [19:01:20] three gimbals about their axes at a 35° per second rate to [19:01:20] clean the Slip Rings" [19:01:34] yeeaah you got it :D [19:01:41] this is the memo I was thinking of: https://www.ibiblio.org/apollo/Documents/slipring_program_and_kstart_tape.pdf [19:05:20] that sounds like something that is fun to watch [19:40:11] lol [19:40:35] well in searching for a copy of Rev 1, I've discovered that NARA has Rev 3 [19:44:12] haha wow [19:44:19] rev 2 is from October 1974 [19:44:26] they didn't want to let go :D [19:46:07] this rev 3 is from June 1975 [19:46:11] right before ASTP launch [19:46:38] an interestingly it has an instrumentation laboratory cover again instead of the CSDL cover of rev 2 [19:48:04] Skylab + ASTP, using spare parts as much as possible for everything :D [19:48:32] hehehe [19:53:53] the two ASTP exclusive EMPs also look quite fun [20:42:14] yeah they do! especially the raster scan [21:37:56] night! [15:20:50] good morning [15:21:12] hey Matt [15:43:17] hey [15:46:09] hey Alex [15:47:17] will the new EMP uplink functions be already accessible by the MCC? [15:47:39] oh [15:47:40] hmm [15:47:45] didn't think of that actually [15:47:51] definitely no at the moment [15:47:59] the function to load the file is in MFD code [15:48:02] ah ok just curious [15:52:59] I guess you would like to include the P99 uplink for the Apollo 17 MCC [15:53:50] I might move the EMP file load function to RTCC code then [16:10:17] I'll create a nice wrapper function so that you can do this pretty easily [16:10:38] it's not just one mission with scheduled EMP uplinks, so, it should be possible [16:11:57] I don't know though if it isn't safer to just hardcode EMPs in the MCC [16:12:10] people can mess with their EMP files :D [16:25:52] hmm yeah [16:26:00] do you really need to load from EMP files? [16:27:36] but at least something better than hardcoding should be available in the RTCC... [16:31:07] I am fine with keeping the MCC with hardcoded EMPs if its safer [16:39:17] I would also have to change the current code quite a bit [16:39:37] I have no good way of testing that code either. Let us maybe do that at some later point. [16:43:10] sure [17:04:10] btw I launched a new mission yesterday, now up to MCC-4. MCC-2 DV was 12 ft/s so I guess that is quite good with the SIVB venting [17:34:34] was that with your usual, unsupported TLMCC mode 4 shenanigans? :D [17:34:46] but yeah in general we will get a slightly higher DV with the venting [17:34:54] just because of more state vector uncertainties [17:46:19] 4 impulse LOI with a far side landing [17:46:25] just kidding :D [17:46:36] but yeah I am doing a CSM DOI so mode 4 [18:12:45] morning! [18:14:50] hey Mike [18:16:01] what's up? [18:18:25] about to LOI [18:19:41] target is near Stevinus crater [18:19:46] nice :D [18:19:54] and you? [18:20:50] not much, just feeling simultaneously excited and anxious about rope reading :D [18:25:29] haha [18:25:50] well following the private chat, seems like your well prepared [18:27:11] you're* [18:36:16] yeah, getting there :D [18:37:17] I did find one suspect Malco/Samtec pin on the Block II reader -- it must have gotten damaged by the Colossus 236 scrap unit that I last read [18:45:23] got plenty of spare pins? [18:51:01] oh yeah [18:51:29] Samtec made like 2000 of these female contacts for us and we used essentially 0 during the AGC restoration. that needed almost exclusively male contacts [18:51:45] Carl's DSKY display setup and my rope reader are the first things we've needed the female contacts for [18:55:41] oh yeah that is plenty of spare :D [15:49:16] hey [16:05:18] hey Nik [16:24:19] What's the plan for XRSound? [16:39:53] I think we are switching to it sooner rather than later! [16:40:10] awesome [17:13:08] hey [17:23:12] hey Alex [17:48:54] morning! [17:57:48] hey [18:24:40] what's up? [18:25:54] EMP PR is basically done, just has to have people test and approve it [18:26:01] nice :D [18:26:16] now I am looking (for the xth time) into improving resolution of AGC RCS commands... [18:26:21] I did quick review pass of the Luminary 210 EMPs last night and didn't spot any typos [18:26:37] ah great, thanks! [22:00:17] ah awesome, just discovered a big flaw in my AGC RCS code [22:00:21] and that is the time to say [22:00:23] night! [22:00:25] :D [16:02:36] hey [16:05:41] hey Alex [16:08:31] the RCS min impulse update is really nice, I can use 10x now during maneuvering with the CSM. Is something similar planned for the LM? [16:09:12] yeah I am working on it. A bit of a different approach though. [16:09:21] Trying to properly resolve PGNS RCS commands [16:09:24] without timestep issues [16:09:41] the thing about the CSM update is, it's a bit cheaty for time acceleration [16:10:05] I don't really expect my new solution to be as good for time accel [16:10:15] the issue is, the DAP runs 10x per second [16:10:32] so if you get 2 (or more) DAP runs per timestep the AGC is a bit confused why the attitude hasn't changed at all [16:11:31] it only works for the CSM because the thrust is increasing slowly, artificially [16:12:03] so I am not sure yet how well it will work in the LM [16:12:09] At least at 1x it should become really nice [16:12:17] no matter your framerate [16:12:29] well, you need above 10 fps with the DAP running that fast :D [16:14:57] right [16:21:45] it would likely still be a vast improvement to before [16:22:04] no huge RCS spikes [16:26:48] that will be nice to have [16:28:25] I had some code nearly ready for testing, but I overlooked something [16:28:36] I think I know what to do though [16:29:02] would this update be for both CMC and LGC at once? [16:29:40] doesn't have to be. The core of the code is in ApolloGuidance, so it will eventually apply to both. But I can put it in the LGC timestep only at first. [16:30:01] ah [16:30:07] it would require a bit of rewriting the RJEC timestep in the SCS code [16:30:31] I've already done the same for the ATCA [16:31:11] and I have tried to give the AGS the same behavior as we currently get in the CSM [16:31:34] haven't test anything yet though [16:31:36] tested* [16:32:39] that would be the same in the CSM. Trying to retain this improved behavior that the CSM in general currently has [16:35:41] for the SCS [17:57:22] n7275, I simply merged it because it looks right, but, what did your fuel cell fix PR do? [18:18:28] the fuel cell constructor expexts a pointer to the N2 tanks. I forgot to add those [18:19:43] I don't check any N2 pressures in the FC code yet, but they were technically uninitialized pointers [18:19:46] that's all [18:22:22] ah ok, yeah I wasn't expecting anything major [18:23:21] morning! [18:24:04] hey Mike [18:24:34] what's up? [18:24:45] I created a branch starting with S today. Has a changed mission file, RTCC file and padload in the scenario. Just in case it is needed :D [18:24:59] hehehe [18:25:39] I made a new similarly named repo last night. gathering symbol addresses from EMPs, Norton, etc. to start putting together a rough memory map [18:26:12] yeah that sounds useful. Will this be the best support source code reconstruction so far? [18:26:18] supported* [18:26:23] supported with documentation etc. [18:27:20] hmmm, that title probably belongs to Luminary 69R2 or something where we didn't have to come up with any custom names for anything [18:27:48] but as far as recent rope dumps yeah, this will be the best by far. Norton should be able to give us an incredible number of names [18:28:09] ah true. Difficult comparison as some reconstructions were a lot smaller in changes. [18:28:25] yep [18:28:46] but for Sundial E, Aurora 88, Corona 261, Sunspot, etc.... there is no comparison :D [18:29:04] all of those have huge chunks of total mystery code that needed a lot of modern naming haha [18:29:11] I just need to read Corona and think of, no not a virus, a square root of mu. [18:29:41] hahaha AS-202 has firmly supplanted the virus in my mind now when I hear "corona" [18:29:50] I spent too much time on that source reconstruction :D [18:31:03] the Discord will probably be a pool of sharks with the rope being the prey. Who knows at what time of day you will be done with it (timezones are fun), so, I'll have the branch ready on Github if people want it. [18:37:49] yeah I don't even know the exact day yet, much less the time of day lol [18:38:22] haha [18:39:13] and of course with anything we do, it's not certain until it's already happened [18:41:00] yeah [21:48:24] night! [13:55:45] good morning [13:59:39] hello hello [14:03:30] I finished up my Airfoil4 project last night [14:04:55] oh nice! [14:08:06] I think I had one other small Orbiter project I wanted to add, but I have no idea what it was now [14:08:28] I should probably finish up the IMU project next though [14:10:04] hmm yeah I don't remember what project you had in mind haha [14:30:01] I remember [14:30:35] I wanted to give thrusters an optional second propellant handle [14:35:42] I'm not sure I want to jump directly into that though [14:46:50] also don't forget I added this debug thing to the RTCC MFD that shows the current IMU misalignment. Maybe it's helpful. [14:49:28] I think that will be very helpful. [14:52:32] I think most of the work I have left to do is just collecting all of the data from each mission and getting it into our mission files/scenerios [14:52:52] I guess I also have a part in this [14:52:57] with the padload generator [14:58:36] ok so in a script my new method to resolve LGC RCS commands works now. Let's see if that also translates to NASSP. [15:01:55] this is the type of project where I need to run my monitor in 60 Hz (instead of 144) to simulate the "average NASSP experience" :D [15:02:44] there's also the "fixed timesteps" option if you want to test a spcific timestep length [15:03:04] hmm but the simulation then runs at variable speed [15:03:15] pretty sure I've tried it [15:03:36] yeah, its kinda weird to interact with [15:03:58] could still be useful for testing very specific framerates [15:04:49] with this new system we should get very realistic behavior down to 10 fps. Or 100 fps at 10x etc. [15:05:23] below that the DAP runs twice on an Orbiter timestep and would command two short RCS commands instead of one. [15:05:28] For the LM ascent stage [15:05:36] that one is mainly the problem [15:06:11] so with 144 Hz I should be able to run a powered ascent at 10x without any changed behavior at all [15:06:28] changed as in, too much (or too little) RCS [15:07:39] the big oversight I had a few days ago was that, for a min imp command, the RCS is already being commanded off again before the thrust even develops [15:08:00] in that case my logic didn't give any thrust at all [15:08:22] so the very thing I wanted to improve, very small RCS commands, didn't do anything haha [15:27:51] I find one of the things that makes my missions take so long to complete (other that getting lost in systems updates for a year), is the time I have to spend at 1x for attitude holds [15:31:04] with the last CSM update that should have improved a lot [15:31:13] you can even do V49 with 10x [15:31:55] so you can play with that on your next mission [15:33:04] do you have any difficulty with S-IVB attitude control? [15:33:09] on 144 Hz it's no problem [15:33:22] but I could use the solution I had for the CSM for it as well [15:34:59] S-IVb attitude is generally no issue for me, even at 10x. Sometimes if I get a long timestep at 10x it'll mess it up though [15:35:03] yeah [15:35:13] and a light S-IVB is more of a problem, like, Apollo 7 [15:35:18] no LM, too [15:35:55] I believe so, based on my memory [15:43:04] "the minimum engine firing pulse duration is approximately 70 milliseconds" pretty long, comparatively [15:43:59] I can implement the same logic as for the CSM, you would run into this during time accel only [15:44:34] the concept being: thrust can only increase by a minimum impulse firing during a timestep [15:57:58] what sort of framerates do you get with vsync off, just out of curiosity [16:00:43] not that much more [16:02:14] Apollo 11 MCC-2 scenario [16:02:22] 2d panel, one MFD open, 178 fps [16:02:36] hmm, not it's settling at 200 [16:02:40] now* [16:02:52] 244 in the VC [16:03:05] 400 fps external view [16:03:43] nice coil whine from my GPU at 400 fps :D [16:08:09] oh wow [16:08:25] I think I need a better GPU [16:11:05] I have a GTX 970 [16:12:27] I have a 1050, and I can only hit like 120 fps in external [16:12:53] maybe it's just full of cat hair again... [16:13:22] oh yeah, mine needs a good dedusting [16:19:19] I've been mostly CPU limited probably, that's why I hated the 2D panel with its inefficient meters [16:19:28] not anymore :D [16:24:56] yeah, that was a pretty incredible performance boost [16:26:18] I have quite a bit of CPU capacity, it just happens to be paralell rather than speed, capacity [16:31:51] I think I will fly an Apollo 12 mission. I want to see how it is in general now with the latest updates. I want to see how the MCC behaves, as Alex implemented it. I want to add a few things the Checklist MFD currently doesn't have access to. [16:32:03] and the RCS behavior [16:32:31] let's see how far I get before I find something I don't like that distracts me from continuing with the mission... [16:35:50] hopefully it isn't fuel cells or LM temperatures :) [16:36:04] 100% not [16:36:17] for those I'd rather use malfunction procedures than try and fix code :D [16:45:59] morning! [16:56:24] hey Mike [17:00:57] what's up? [17:05:06] hey [17:05:18] just launched Apollo 12, just wanted to see how everything is with the latest updates [17:05:26] nice :D [17:32:28] ah found the first thing I need to implement for checklists [17:32:36] set the ORDEAL to a specific altitude [17:53:07] for TLI? [17:53:30] yeah [18:33:37] although thinking long term, I wanted to implement a generic rotational switch class that doesn't have just the few discrete switch positions [18:35:31] see, this is how it happens and I get off track :D [18:46:09] it was inevitable :D [18:47:25] this is why I never make it much further than TLI :) [18:48:40] yeah now I am stopped before TLI, thinking if implementing a dummy switch for the Checklist MFD is a good idea :D [18:48:58] for the rotational switch, it would be nice if it actually worked like a potentiometer: power source input, voltage output [18:49:19] yeah [19:03:33] I think I will implement that new rotational switch class at some point, but for now I will skip implementing the dummy switch. Otherwise Ryan will have to adjust a bunch of checklists twice [19:03:58] so only non-rotational dummy switches on this mission :D [19:12:28] Are we considering Apollo 12 part of our 8.0 eventual "Release" now? [19:14:29] more as a bonus, but, there isn't that much different between 11 and 12 [19:14:40] so wouldn't be a problem [19:17:30] it seems like we have it fairly well suported at this point. it'll be nice to have, especially when we have the CMC software for it [19:20:14] Alex's method for getting the LOI-1 TIG right with the MCC-2 calculation is a bit overkill haha, it takes a while [19:20:47] but I haven't heard complaints about it not converging reliably, so, that's not really a problem [20:25:24] is the plan still to wait for some form of an official OpenOrbiter "release" before NASSP 8.0? [20:32:20] sort of. I can't say have much of a plan... I was more enthusiastic about OpenOrbiter a few years ago. Hopefully it becomes more stable and such. Then we can think about a release. [20:33:37] has it already been a few years? holy cow [20:37:34] I think it went open source in 2021 [21:17:14] https://www.orbiter-forum.com/threads/orbiter-startup-issues.41517/post-614603 [21:19:46] Maybe I should stop sending in new PRs haha [21:22:21] hahaha [21:22:24] As far as I can tell from Jarmo's forum posts and github messages, the "plan" is an early 2024 release, then starting work on a replacement for DX9 [21:39:05] night! [15:06:39] n7275, filling the repress tank is quite slow now. [15:18:38] it might need to be tuned a bit to make it more realistic [15:21:17] I think it's due to the surge tank also dropping in pressure quite a bit [15:21:41] they are both still recovering basically [15:21:49] both tanks [15:22:18]