[15:24:17] NASSP Logging has been started by indy91 [15:24:19] hey [16:16:39] morning! [16:17:18] hey [16:17:40] I made my decision [16:18:22] the stuff I am working on is divided into launch window calculation, so mostly the time of launch, and launch targeting, calculating the insertion parameters [16:18:45] brb [17:00:25] back [17:00:57] what I wanted to say was, the generic launch window stuff is calculated anyway, but we can't do much about it, changing launch time and all. [17:01:15] So in terms of inputs and displays I will only put the launch targeting stuff in the RTCC MFD [17:01:23] and I am mostly done with that anyway [17:01:49] for launch window, that is more mission specific. Like one set of inputs and displays for Skylab launches, but that doesn't apply to other missions etc. [17:02:39] that makes sense [17:05:40] it's pretty neat, it calculates two other launch times automatically anyway [17:05:48] the time when the target in orbit is exactly in-plane [17:06:00] passing over the cape [17:06:16] nice :D [17:06:29] and another time, when you launch, that you will have zero phase angle at insertion [17:06:35] so directly above you [17:06:39] yeah that's cool [17:06:54] not useful for any rendezvous directly, but I think for e.g. Gemini they launched at that time plus a bias [17:07:15] to get a specific phase angle setting up for rendezvous [17:07:36] those options are also there, I just won't immediately add input buttons for that [17:08:37] So basically you need to have a target in orbit that is set up correctly for your launch [17:08:48] but then you can get there [17:09:03] or, what should also work, is you start the RTCC MFD from the initial prelaunch scenario [17:09:06] calculate the launch time [17:09:16] exit the sim, change the mission time in the initial scenario [17:09:25] and then you can get the ideal launch time, too [17:09:41] good enough for now I think :D [17:10:26] haha yeah seems reasonable enough :D [17:11:25] for the Skylab rendezvous displays I would next need to get a better version of the targeting for the maneuvers, the ground solutions, not Skylark onboard [17:11:36] and then that gets used in the launch window calculations [17:11:46] which is somewhat required to adjust the insertion velocity [17:15:19] but that is details, they didn't want to have some of the maneuvers become lower than 30 ft/s, so that they could do them with the SPS [17:15:45] And that is somewhat relevant for when you launch or probably more the apogee height, so insertion velocity [17:20:04] right [17:20:27] kind of funny to intentionally make things need more delta-v :P [17:26:11] well almost all the maneuvers are horizontal, so in the sum the DV is basically the same [17:26:29] they just didn't want one maneuver having 200 ft/s and then the next one 10 ft/s [17:26:47] but with the right phasing at insertion (and velocity) that could become e.g. 100 and 110 ft/s [17:27:20] ahhhh gotcha [17:27:53] that's basically the phasing launch window. The last of the horizontal maneuvers is small (30 ft/s), all previous maneuvers are large, because the phasing angle is small [17:28:05] and then end of the window is when the very first maneuver is only 30 ft/s [17:28:17] which normally is up to 200 ft/s [17:28:37] I can work out the details on all that later haha [17:28:54] I actually haven't found any good state vectors for Skylab [17:29:12] So in the end we will just have to fly it [17:30:05] Or do the launch in-sim and then propagate that state vector to the launch time of one of the Skylab 2-4 missions [17:31:53] They had planned to launch Skylab 2 just one day after the Skylab itself. So maybe we should set up two scenarios. One for the Skylab 1 launch, but it already has Skylab 2 in the scenario and you can actually launch it [17:32:23] But they ended up launching a few days later, so for the actual Skylab 2 launch, that would be another launch scenario [17:53:56] unrelated, but the ETA for that countdown procedure is Friday, so I should definitely be able to have a scan ready this weekend [17:55:07] awesome :D [17:55:49] all I have been talking about is stuff happening during countdowns, it's very related :D [17:56:04] hehehe [17:58:14] for that, if it should contain additional procedures we could implement, there needs be a certain level of interaction between what the user does and which commands are sent from the LCC for the EDS test [17:58:36] I don't know if it's good enough to do everything on a timer [17:59:17] the test is split in many parts which are started manually I believe, everything in a part is automatic [17:59:29] like switching on 1, 2, 3, 4, 5 then 0 LV lights [18:00:08] they even tested the liftoff and abort circuits which is somewhat scary [18:00:34] I'll need to figure out if it would be possible to have switches and circuit breakers in the wrong state during the test [18:00:44] which lead to an unrecoverable state of the spacecraft [18:03:48] oh boy [18:06:05] looking at my notes, probably not. Only if you do the wrong switches in the CM, but I will have to see [18:09:02] as long as the CM is in the right state 45 minutes after the test [18:09:09] that's when pad aborts are enabled [19:15:02] speaking of Skylab [19:15:24] just found an interesting old file [19:15:26] "Apollo 15 - P34 issue with Artemis.scn" [19:22:48] hmm, what's that? [19:24:29] we would like to use Artemis until we get Skylark [19:24:37] but Artemis has an issue in Earth orbit with P34 [19:24:53] I think a long, long time ago Thymo wanted to take a look at that and create a fixed version [19:24:57] ahh right right [19:25:55] maybe I know enough interpreter by now to see the issue myself [19:26:46] it might be easier to spot it by doing a side-by-side comparison of the relevant sections of the two Norton documents [19:26:53] since we have both [19:27:14] my first guess is scaling issue with RTARG [19:29:41] time doesn't really have differing scales in the AGC [19:29:45] but position vectors do [19:30:27] need to slightly repair the old scenario because there was no standby mode then. And the AGC STATE variable in NASSP is a bit incompatible there [19:35:54] I could set up a better scenario that can be better tested in the standalone Virtual AGC [19:36:12] just need to get rid of the program alarm and save [19:39:38] I mean they completely removed the lunar capability in Skylark [19:39:48] the better comparison might be Comanche vs. Artemis [19:40:04] do we have a complete Norton manual pre Artemis? [19:41:46] mmmmmmmm [19:41:50] I don't think so... [19:41:54] we have several for Luminary [19:42:18] yeah, doesn't look like it [19:43:00] Luminary might be good enough actually [19:46:29] in that case, yeah we have full Norton docs for 116, 131, LM131r1, and 173 [19:48:35] hmm, this is weird [19:48:41] E7,1414 is EMEM3414, right? [19:48:53] pretty sure it's double precision [19:48:55] this is what I get [19:49:01] EMEM3414 252 [19:49:03] EMEM3415 22600 [19:49:04] EMEM3416 77623 [19:49:05] EMEM3417 32100 [19:49:06] EMEM3420 16 [19:49:07] EMEM3421 65577 [19:49:21] I don't think it should mix plus and minus like that... [19:50:50] E7,1414, yeah [19:50:58] are those decimal or octal numbers? [19:51:03] they look octal [19:51:37] but if octal, >=40000 would be negative. 252 and 22600 are both positive [19:52:05] yeah, but the other two aren't [19:52:08] er, yes on it being 3414 [19:52:09] this is a vector [19:52:14] double precision [19:52:16] ohhh [19:52:20] gotcha [19:52:31] so the 2nd and 3rd value are mixed [19:52:38] more often than not the AGC can deal with it [19:53:11] even when they got that weird TEPHEM (triple precision) on Apollo 14 after the liftoff time update they changed it mostly to be careful I think [19:53:21] yeah [19:53:22] or what do you think with it being able to deal with it [19:53:43] usually it's fine, and if it matters they'll call a sign agreement enforcing function before using the number [19:54:04] SGNAGREE [19:54:20] or in the case of a vector like this, VECSGNAG [19:58:26] too bad the Artemis Norton manual isn't searchable [19:58:41] would have liked to checked every instance of RTRARG, maybe there would be a comment on it [19:59:55] I can run OCR on it later :) [20:02:07] actually, I think RTARG is fairly "contained". So you don't need to OCR it just for me :) [20:05:06] another good candidate would be that the AGC looses track if it needs to use the RTARG as lunar or Earth orbit target [20:05:18] because INITVEL works correctly in P34 [20:05:26] in that scenario I had 20 ft/s [20:05:39] when you start P40 it does INITVEL once, I think [20:05:46] and then later during the burn itself, too [20:05:57] that initial calculation in P40 had 78 ft/s or something [20:05:58] do we not have a program note for this issue? or does it just say, "it doesn't work" [20:06:03] so there it already went wrong [20:06:23] hmm, suspicious [20:06:25] "there is also a known problem [20:06:26] with the aim-point transfer between P34/F35 and P40/P41 when in [20:06:27] earth sphere." [20:06:30] lol love it [20:06:50] oh the two sentences before are even better [20:08:00] https://i.imgur.com/gqJVnmt.png [20:09:22] hah, wow [20:10:31] dropped requirement I guess, no more CSM+LM rendezvous tests in Earth orbit should TLI fail [20:16:31] hey guys [20:22:07] hey Matt [20:27:11] I'm failing pretty hard at having any free time to work on stuff haha [20:29:38] ah that's fine haha [20:34:21] how dare you! [20:38:39] lol [21:07:34] night! [04:04:32] I accidentally clicked on "recent changes" on Wikipedia, rather than nassp.space..."Oh no! The Spambots are back--wait..." [15:31:05] Hey Nik [15:32:27] what's up? [15:32:48] Covid has you left long behind I hope? [15:50:20] I'm looking at Artemis again, you know, the issue where its rendezvous programs don't work in Earth orbit. The thing you wanted to look at ages ago :D [15:52:44] Yep, I could come in to the office on the 10th. Doing fine. [15:53:01] I still cough every so often so we'll see how long that lasts. [15:53:39] Oh I remember looking at it years ago, no idea what I did or found out. [15:54:14] Anyway, I defended my thesis today and it got graded at an 8/10. I'm pretty happy. :D [15:54:22] that's really good, congrats! [15:55:59] Yeah, if you get atleast an 8 my university allows you to publish it in the national knowledge base for everyone to see. [15:56:07] Thanks! [15:56:21] if you get a 10 they replace the professor with you [15:56:33] which is why you never would get the highest grade in such a presentation... [15:57:44] Hehe, exactly. I never expected to get one because of that. Although they were naming excuses as to why they could not rate it with a 9 or 10, which is another sign they think it's good I guess? [15:57:56] yeah [15:58:03] in my thesis defense the professor criticised that I put my hand in my pocket once, something he did all the time during lectures haha [15:58:13] In either case I was more than happy with my grade so I just waved away their excuses to celebrate :p [15:58:32] Oof, talk about excuses lol [15:59:20] One of the panel members complimented me on my English usage, which confused me. The presentation was in Dutch. [15:59:56] Took me a minute to realize he was talking about my thesis and that I didn't accidentally present in English [16:00:01] clearly asleep [16:00:09] ah haha [16:01:16] What was your thesis on? I always forget what degree you studied. Aerospace? [16:03:56] Yeah. It was about the Eurofighter, I wrote it for Airbus Defense and Space. [16:04:16] Which was also a problem during the presentation. I had to speak in general terms about a bunch of stuff [16:04:26] the juicy stuff was classified [16:05:18] The only reason the institute at the university liked me doing that thesis was so that they could get more connections with the industry [16:05:36] otherwise they didn't really benefit from any research I did [16:05:42] Yeah, I was in the same situation during my internship at Thales. Bunch of things had to be generalised. Wasn't a thesis though, so not as juicy as yours. [16:06:48] Anyhow, I need to fetch some dinner and head of to the Red Cross. I have to program a bunch of radios for this weekends marathon. See ya! [16:07:04] see ya! I'll go back to my Artemis... [16:07:15] I misspelled nemesis... [16:12:54] hey [16:15:36] hey hey [16:20:55] morning! [16:22:04] hey Mike [16:22:24] I've gone into the business of mass conversion of octals [16:22:39] uh oh [16:22:42] I can replicate the Lambert calculations Artemis does in my test scenario [16:22:49] hahaha [16:22:57] awesome [16:23:14] P34 does the calculations once for TIG [16:23:29] when you start up P40 it does it twice, once for TIG-2 seconds and then TIG [16:23:34] to set up some variables [16:23:48] I guess for the change in DV between the first guidance cycles (2 seconds) [16:24:03] And if I track down what changes it's not RTARG, the target position vector [16:24:14] it's RINIT and VINIT, the state vector at TIG [16:24:28] and I don't think it's a wrong time P40 uses or so [16:24:45] oh I didn't mention, I can replicate the P34 calculation of 20 ft/s (which is correct) [16:24:53] and P40 then comes up with nearly 80 ft/s [16:24:58] that is the bug I guess [16:25:13] and it seems be because RINIT/VINIT are wrong, somehow [16:25:21] that's weird [16:25:33] I didn't see TIG changing [16:25:45] it's just using CSMPREC to get the state vector to that time [16:25:52] and then stores it in RINIT/VINT for INITVEL routine [16:26:19] also thinking about it, the problem can't really be with P40 itself [16:26:26] it must be the data fed to it [16:26:37] because P37 also uses Lambert aimpoint guidance [16:26:46] and that clearyl works in Earth orbit, it only works in Earth orbit [16:27:05] so P40, in general, can handle Earth reference Lambert aimpoint [16:27:42] that's as much as I know [16:28:00] no idea if it maybe propagates using lunar gravity or something [16:28:05] very weird [16:28:08] yeah that could be [16:28:32] but RINIT/VINIT is off and it doesn't seem to be a time tag issue, I can't just let those vectors coast forwards/backwards in time and get to the correct value [16:29:13] and I just cross checked in Colossus 237. As I said, it's three INITVEL calculations, once in P34, twice in P40. [16:29:18] the first and last use the same time [16:29:29] so RINIT/VINIT should be identical [16:29:36] and it is with my Apollo 7 scenario [16:29:59] after P34 vs. after the initial P40 calculations [16:30:38] those coasting integration routines use the push down list a lot [16:30:52] so a bit harder to debug, as I don't exactly know the erasable addresses [16:31:35] ahhh yeah that can get hard to follow [16:35:28] ooooh, countdown procedure is being delivered early, in a few hours :D [16:36:44] that's great [16:52:56] maybe I need to look more at P34 [16:53:18] P34 using a wrong state vector at TIG [16:53:33] and not P40 [16:53:47] nah, the DV P34 comes up with makes sense [17:12:42] hmmmmmmmm [17:15:11] we have all of the Artemis anomaly titles [17:15:15] have you looked at those for clues? [17:15:46] https://www.ibiblio.org/apollo/Documents/apollo_16_fsrr_slides.pdf#page=18 [17:16:40] I haven't [17:22:41] it's not in there [17:22:51] it's just a program note [17:22:56] laaame [17:23:03] And the GSOP mentioning that it hasn't been verified for Earth orbit [17:23:11] GSOP doesn't mention that it's broken though [21:39:11] I'm back [23:48:21] hey [23:58:55] yo [00:09:37] hows the scanning going? [00:12:07] not started yet, in the middle of an auction :D [00:12:29] also need to cook dinner first [00:12:33] I'll get to it though lol [02:54:34] Thymo, should we have a wiki thread on the forum? [04:22:25] dumb C++ question [04:23:06] in the function void PanelSDK::AddElectrical(e_object *e, bool can_delete), PanelSDK.cpp [04:24:01] I would like to add a std::function refreshPointer, that is a pointer to the function e->refresh(); [04:24:36] how do I do that [05:21:16] I *think* this is the right incantation: [05:21:18] std::function refreshPointer = std::bind(&e_object::refresh,e,std::placeholders::_1); [05:29:24] oh man I am way too out of C++ practice for that [05:35:11] well as it turns out, that is *not* the right incantation... [05:36:24] ooooooor [05:36:52] I'm just calling a function that I wrote, with the argument in the wrong order [05:48:56] Yeah, there should be a thread. Just wanted to be sure CAPTCHA and other stuff was working before publicly announcing it [05:52:53] I'm not familair with that C++ mechanic. I only know the C way of passing function pointers [06:00:59] .tell indy91 https://drive.google.com/file/d/1CQLX5m4Tkq1xoXhsxQEIU1F43JPyCL99/view?usp=sharing [06:01:15] .tell indy91 unfortunately the EDS test is one of the few things that gets called out to a different procedure... [13:10:08] . [13:44:38] good morning [14:12:56] I tried adding my thread pool to the systems SDK last night [14:13:25] does not work as expected [14:16:31] hey [14:16:38] hmm, that's unfortunate [14:22:26] I'm done with the launch targeting stuff, but I want to set up a better scenario for everyone to try it [14:22:39] setting up padloads is still a pain [14:22:50] so I decided to finally work on a padload generator [14:23:06] that automatically does it, not like the Excel worksheet [14:24:34] in the process I found a bug in a function converting to the fixed precision values [14:25:16] which might affect some of our current padloads actually [14:25:35] not a lot, only for triple precision values [16:33:42] pad load generator sounds like a good step toward a mission generator :) [16:48:44] morning! [16:49:35] hey Mike [16:49:45] the document is really great [16:49:58] of course unfortunate that the EDS test and some CMC procedures are outsourced [16:50:31] but it really is cold and dark to liftoff procedures [16:50:51] exact confirmation when the backup crew checklist is done [16:51:04] :D [16:51:16] yeah we'll have to keep our eyes peeled for the other referenced procedures [16:51:18] and procedures for a countdown hold even [16:51:28] and scrub [16:51:30] but yeah overall I'm very happy with it [16:51:34] same [16:51:38] and it even starts out with a weird little EMP lol [16:51:56] I think you asked on Discord, we did always have backup and prime crew prelaunch procedures [16:52:17] right, but no pre-backup crew procedures [16:52:33] yeah, we came up with a short startup checklist for that [16:52:56] even this document doesn't give the procedures for starting P01 though :D [16:53:23] hah yeah, I think that's just the "start gyrocompassing" callout at T-23h right? [16:53:27] yeah [16:53:34] oh speaking of documents, I also have new [16:53:35] news [16:53:47] from NASA STI [16:53:57] "Unfortunately, after further review Basic equations and logic for the real-time ground navigation program for the Apollo lunar landing mission - Project Apollo has been determined to not be publicly available for distribution by NASA and we were unable to locate a copy elsewhere. We were able to find a metadata entry for this title in another repository - https://ntrl.ntis.gov/NTRL/dashboard/searchResults/titleDetail/N7034528.xhtml" [16:55:29] boooooooo [16:58:38] so all egs are in this basket [16:58:42] eggs* [16:58:43] https://archive.org/details/NARASWSelectedApolloBoxes/page/n147/mode/2up?view=theater [17:00:21] hmmm [17:00:34] I'll have to ask Ron about the status of NARA [17:00:41] apparently their research room is open again [17:00:44] finally [17:01:25] a few weeks ago I had read it was partially open [17:01:56] but I think the text on their website has changed again [17:02:20] More open than before [17:11:51] I would like to have a list of all the four letter call sign acronyms in that countdown document [17:12:02] especially the ones with M as the first letter I have rarely seen before [17:14:29] yeah I wasn't able to find much there [17:16:21] there are partial lists in other documents [17:16:27] mostly having the ones with C [17:16:35] which I think stands for control center (LCC) [17:16:39] S is spacecraft [17:16:46] so SCDR is the commander (or backup) [17:16:52] SPAD is Günther [17:17:04] I think [17:25:25] ahhh [17:25:38] hmm [17:25:46] so this copy belonged to MACE [17:25:52] who had reports RACE and ACE [17:29:31] M wouldn't be MCC would it? [17:29:39] no that's H [17:29:42] for Houston [17:29:47] gotcha [17:29:49] HFLT or so was the flight director [17:30:17] during the abort light test (which I had procedures for from other countdown document) several people are switching on/off the abort lgiht [17:30:45] oh, I also found it funny that these procedures in at least one place do V33E when they could have done PRO [17:46:40] are they typing into the K-START there? [17:46:47] I don't think K-START can transmit a PRO key [17:47:23] ah possible [17:58:53] I think K148 is the K-START keypad? [18:35:20] sounds like it [18:42:36] indy91, I'm looking into implementing the J-mission workarounds in a slightly more official capacity, do you have any suggestions on what would be a good way to do so? In theory I would like to specify the mission type in the scenario file and then switch the Saturn/LM systems hardware based on that, during the initialization, but I don't know how I would go about doing such a thing. [18:43:07] oh, no no no [18:43:12] we already have such a thing [18:43:17] oh you do? [18:43:27] https://github.com/orbiternassp/NASSP/blob/Orbiter2016/Missions/ProjectApollo/Apollo%2015.cfg [18:43:35] mission specific config files [18:43:38] hiya [18:43:45] ah neat [18:43:46] hey Thymo [18:44:00] I guess what the J-type mission need is load a different Saturn config file maybe? [18:44:43] What do you all have to do right now to fly the J-type missions [18:44:54] change the size of the cryo tanks in the config [18:44:56] anything in code? [18:45:02] I would rather not load a separate file, because that would require extra maintenance if systems need to be updated that are shared between mission types. Ideally I'd like to just have a separate field in the same config file that is loaded instead [18:45:30] Last I checked, there are code changes required as well, you have to comment out a couple lines and uncomment their J-mission equivalents [18:45:39] that in particular is what I want to eliminate [18:45:55] I want to have a solution that doesn't require building NASSP from source [18:46:36] but the first thing I need to know is, how would I access this mission-specific data within the code? [18:46:37] right [18:46:51] Saturn and LEM classes have a pointer [18:46:52] it could be as simple as an "if-else" statement [18:46:54] I think called pMission [18:47:09] and that can call functions for every mission specific thing [18:48:14] I added the "J-type mission" variable early on [18:48:22] in reality a lot of changes were done after Apollo 13 [18:48:28] like adding additional tanks I think [18:48:50] Right, IIRC the third Oxygen tank was present on Apollo 14 which wasn't a J mission per se [18:49:41] I can't find the places in code right now that you need to rebuild [18:50:03] In reality, we may want to have some sort of enumeration for mission type that is more extensible [18:50:19] let me take a look for those code points, I have the workaround list pulled up [18:50:50] sure, it can be an int instead of a bool [18:50:59] and then every type of config has a number [18:51:56] precisely [18:52:07] ah okay, the changes are in the #define section of "nasspdefs.h" [18:52:48] I'm going to alter those to use different names so that they can all be defined at once, and the code will use the proper value for the mission [18:53:39] ah right [18:53:49] I think those are even only used for meters [18:54:08] maybe [18:55:34] interesting [18:55:37] yeah, to convert to percent [18:55:43] of tank content for a display [18:55:51] huh, why are the defaults 76%? [19:01:15] not sure, ask Ryan haha [19:01:45] dang, I don't know if I can query pMission from lmswitches.cpp [19:02:35] aha, yes I can [19:02:40] this->lem [19:08:02] what would be nice, is if our system configs and parser could support including other config files [19:12:53] oh that's a great idea [19:13:26] true, the main thing is that so many systems and values are shared between all missions, so if anything we would want to "patch" or "append" a generic spacecraft config file with mission-specific values [19:13:59] for the time being, I've converted IsJMission() to GetMissionType() and I'm using an enum class to define any of the potential mission types, A through J [19:14:38] Apollo 14 is a special case since it's still called an H-type mission, but I have added a second value called "H_POSTA13" to account for it [19:15:13] 8 is also a special one, as C prime :P [19:15:24] I think Apollo 7 was just regular C [19:15:28] yep, I included that one too [19:15:48] n7275: I'm gonna merge your wiki accounts. Do you want to keep n72.75 or n7275? [19:16:17] let's keep the "N72.75" one [19:16:20] thank you [19:17:55] I started working on a page for the systems simulation the other night [19:20:17] CaptainSwag101, I also had kind of moved away from using the JMission variable and made new variables for specific things [19:21:16] I think that is better. Not even using GetMissionType(), but more specific for a subsystem [19:21:22] like "HasSIMBay" or so [19:22:27] yeah I just noticed that, I suppose that might be a more extensible way of doing things [19:23:14] hmmm [19:28:04]