[16:24:11] NASSP Logging has been started by rcflyinghokie [16:24:13] running through it all again [16:26:44] https://www.dropbox.com/s/y0n5wpnlbk66sfb/Screenshot%202021-03-19%20122628.jpg?dl=0 [16:26:46] 30x [16:27:10] looks bad [16:27:12] yeah [16:27:20] any idea what framerate that was? [16:27:23] that last GDC align before launch is what saves it [16:27:35] I can find out [16:28:01] would be helpful. If it drops below 60 it might become unstable after all with longer steplength [16:29:05] 27 [16:29:20] I normally get 50 in the CM [16:29:37] that's why I don't use time acceleration on the main panel haha [16:29:44] lol I do often [16:29:53] but usually during non critical things [16:30:01] but yeah I see what you mean [16:31:03] I think that is more a performance issue than something in GDC code that should be fixed [16:31:09] would be quite difficult to fix [16:31:40] that rate signal is the same as the rate that gets integrated by the GDC to determine attitude in normal operation mode (non GDC align) [16:32:08] wouldn't want to limit that rate in normal operation mode [16:32:18] or else the GDC really starts to drift :D [16:32:35] the only possible place to fix would then be in the ASCP, limit the output voltage [16:32:50] GDC attitude minus ASCP attitude [16:33:03] morning! [16:33:10] hey [16:33:48] at least we know its not a procedural thing [16:33:57] yeah [16:34:09] with that this run through of 9 is complete [16:34:18] well, I still want to check if that procedure to get the RSI pointing up is really right [16:34:22] quite annoying [16:34:37] well I think its supposed to be already from launch [16:35:13] so you shouldnt have to move it that much [16:35:45] but there could be lift vector down reentry [16:35:56] if you come in too shallow from the Moon [16:36:03] highly unlikely of course [16:36:47] true [16:36:48] or not haha [16:36:53] procedure for that is [16:37:02] roll 180° at 0.05G [16:37:03] yeah everything I see has it up [16:37:10] just after EMS roll switched on [16:37:14] haha [16:37:18] that will bring it down [16:37:23] assumign its up to begin with [16:37:26] assuming* [16:37:28] I prefer that to doing the RSI alignment [16:38:54] yeah super easy [16:40:26] also not good procedurally to have to do everything 180° rolled [16:40:29] pre EI [16:44:03] Ok that checklist is done for now [16:44:32] I guess I will dive back into the LM ECS haha [16:57:38] im starting to look at how to add a VC to the MCC vessel [16:58:05] should that be part of mccvessel.cpp? [17:05:22] hmm yeah, I guess [17:07:34] or maybe adding a mccvc.cpp for it? [17:08:01] oh you mean the file mccvessel.cpp. Yes better make it separate [17:08:17] ok [17:09:52] what I have in mind right now is quite simplistic, maybe a room with the correct size, but just with one "console" for now with 4 MFDs on it side by side [17:11:14] and can definitely be expanded on later [17:13:22] sure [17:13:34] also keep in mind that MFDs have the wrong aspect ratio [17:14:21] in the future we might want to just draw the MCC screens on a display with the right aspect ratio, if that is possible [17:14:32] so without it being an MFD [17:15:11] right [17:15:44] what I can do is just give it the frame of an MFD for now and I can revisit it later [17:16:36] but I can still try and make the console around it have the look/feel of the Apollo-era console [17:17:14] yeah [17:17:34] just don't make it difficult for yourself in the future if we want to do it differently [17:19:03] shouldnt be hard to change in the future, its only a simple thing right now anyway, just a VC with 4 MFDs [17:19:21] everything else in the VC will be static [17:19:23] for now [17:19:47] yeah [17:22:25] this will be nice when your flying a mission from the virtual cockpit, since there are no MFDs in the VC, you can easily switch to the MCC vessel [17:22:35] you're* [17:22:56] I guess uplinks still need to be worked out [17:23:08] right [17:23:12] that was the other thing [17:24:06] what if we somehow could give the RTCC MFD access TAB menu uplinks queue [17:24:55] yes that's possible now that the RTCC MFD uses the same instance of the RTCC [17:25:10] that way you could calculate your burn from the MFD in the MCC vessel, then back in the CSM/LM VC you can use TAB to do the uplink [17:51:39] my conclusion after trying to understand how Orbiter calculates gravity for an hour: I don't understand how Orbiter calculations gravity [17:52:03] whats the best way to add a new c++ file, can I just right-click on the MCC project->Add->New Item...->C++ file ? [17:53:33] I mean I guess that looks quite obvious but it somehow looks to simple to me :D [17:54:22] @indy91, I can't remember exactly, but I thought there was something in the Doc/technotes folder [18:23:27] the technotes are somewhat useful, but they are more general and not specifically about how it's exactly implemented in Orbiter [18:24:20] AlexB_88, make sure you add them to the header or source files [18:24:41] and also that the files are created in the correct folder [18:24:54] right [18:25:14] I think by default it wants to add them under Build/VS2017 or so [18:30:59] the Orbiter API doesn't really help me to understand how gravity is calculated [18:31:21] The best I can get seems to be GetWeightVector, which is a force in local vessel coordinates [18:31:38] I disabled nonspherical gravity. Put a spacecraft in a circular orbit [18:32:07] Moon and Sun gravity are still being considered in Earth LEO, but should be very small... I think [18:32:20] but the gravity force is still changing a lot [18:32:27] not really understanding that... [18:39:25] ok, going to play git dummy again...how do i create a new branch for testing that I can check out, I honestly cannot remember all the steps [18:44:18] git checkout -b branchname [18:44:49] so if I wanted to start a new one with the current NASSP snapshot to edit? [18:51:26] oh I think I got it [18:54:38] n7275 we had a discussion a while back regarding substances, and looking into how the sdk handles substances going from a cryo/liquid state to gas...did you look into any of that or change any of that for your fuel cell work? [18:56:28] I was going to, but I was worried that it would become too big of a project. [18:57:01] when I get this one merged I want to breadboard the tank class in matlab [19:04:46] I gave multithreading some more thought too. I have no intention of working on that any time soon. but I think the way to do it would be to split up what the refresh functions calculate. and the parameters that get updated by them into two distinct steps. [19:05:11] all the threads of one would need to finish before the other started. [19:10:23] yeah it will be a big project [19:11:17] I think probably the most straightforward thing to do right now, would be to add things like liquid vs vapor specific heat, etc [19:12:53] and maybe add some sort of enum phase or something [19:13:55] yeah you see what we have so far as far as properties [19:14:04] liquid, gas, supercritical, nuclear fusion plasma for those large timesteps... [19:22:33] hehehe [19:23:06] speaking of big projects.... I've been thinking a lot about the counter overhaul again [19:24:31] and found myself wondering how I would make an AGC emulator today if I didn't have to worry about backwards compatibility with yaAGC [19:25:33] so, both as sort of a refresher on the hardware design and as something that didn't take a lot of mental effort to write over the past couple of busy weeks, I have a new mostly-working emulator [19:25:52] oh that's why you were so quiet lately :P [19:26:05] I was moving, which is most of why I've been quiet haha [19:26:10] but am now mostly settled into the new plcae [19:26:12] *place [19:26:14] haha I know I know [19:26:23] great [19:26:27] i am starting that process in July [19:26:41] anyways, it's modeled after the hardware so it's more accurate (it executes subinstructions instead of instructions)... and also initial tests show it being about 4 times faster than yaAGC [19:27:22] that sounds nice [19:29:01] it passes all of the Retread 50 instruction tests, so now I'm working on fleshing out all of the I/O channels and counters [19:29:32] What I was thinking about with telemetry and all is timing requirements and synchronization between systems [19:30:30] hmm, how does that impact telemetry? [19:30:36] is it mostly a sample time thing? [19:30:38] well the PCM timestep [19:30:54] for AGC sync it gets called in the AGC timestep 6400 times per second [19:31:16] I'm not sure AEA telemetry can be done without it also having a certain amount of synchronization with the PCM [19:31:40] right [19:31:44] the timing requirements sound ambitious for just being called once per timestep [19:32:26] and the way it works right now is, the PCM timestep gets called 6400 times per second, in sync with the AGC, only when the AGC is powered [19:32:46] otherwise it just runs once per timestep [19:33:08] so to keep all these systems in synch, there should probably be a central place from which things are timed [19:33:15] yep definitely [19:33:24] of course there are seperate clocks. PCM uses AGC clock if it's powered, otherwise it has its own [19:33:28] also mission timers etc. [19:33:46] how does that work in your new emulator? Same as in the Virtual AGC? [19:34:08] how does what work? the timing? [19:34:26] well how does the simulation of it run [19:34:34] one call of the function equals one cycle? [19:35:03] like calling agc_engine [19:35:31] we call that function every 0.00001171875 seconds [19:35:49] yeah, I haven't set up any higher level timing logic but right now I have a function that corresponds to 1 MCT, which is that number [19:35:59] right, so the same [19:36:02] yup [19:36:09] it's annoying with the AEA, it works differently [19:36:27] so putting both AGC and AEA in a timestep together would be a bit annoying [19:37:26] we could refactor the AEA to provide a better interface [19:37:54] aea_engine returns the number of cycles it ran [19:38:22] heh that's annoying [19:38:29] I think I'll keep thinking about this for a while [19:38:40] how to best set it up [19:39:01] I don't think it would be too hard to change it to have an interface similar to the AGC, where each call takes a certain amount of time [19:39:07] right [19:39:23] I basically want a class that handles all things that need fixed timing [19:39:29] the timestep would be different from 0.00001171875 though [19:39:33] it has to be able to deal with different timing sources [19:39:37] yeah that sounds like the right way to go [19:39:39] yeah, that would be no problem [19:40:18] for now my main concern with the AGC is still that coarse align error [19:40:52] but your new emulator sounds fun, can't wait to test it a bit myself [19:40:56] yeah. I'm wondering if it's because of the way yaAGC fakes the counter operations [19:41:38] just weird that we haven't really seen this before [19:41:48] yeah definitely [19:41:54] I was testing with our Apollo 9 mission scenario pre SPS-7 [19:41:57] from 2018 [19:42:07] and I did go back to the commit that added that scenario [19:42:13] felt weird using such an old NASSP build [19:42:18] haha [19:42:29] and I did manage to get the same problems there as well [19:42:42] so it's not something we recently(ish) broke in NASSP [19:42:51] oh that's very interesting [19:43:29] and we've flown so many missions and never really saw this issue [19:44:10] so weird [19:45:26] https://github.com/thewonderidiot/magc [19:46:35] thanks! [19:48:27] the goal for this weekend is to be able to talk to it through a DSKY haha [19:48:29] not quite there yet [19:48:54] already build myself an exe file [19:49:33] hah, that was fast! [19:49:48] next step would probably be harder haha [19:49:55] it takes hardware-formatted ropes, not virtualagc binary files [19:50:05] of course [19:50:33] well before you have to teach me how to use a 0.0.1 version of a software, I'll let you work on it a bit more [19:50:56] I'm curious if it mostly works for you though! [19:51:03] since you bothered to build it haha [19:51:28] I bothered to type make and hope it did something [19:51:57] https://drive.google.com/file/d/1q3xU35QFFJywzetBH7jh-da-WNYnmv2b/view?usp=sharing [19:52:14] you should be able to run it with "magc Retread50.rope" [19:52:29] at least I have updated my Git for Windows so that it uses main as the default branch instead of master... [19:52:36] and it'll spit out a whole bunch of subinstruction names and state after executing them [19:54:00] I see lots of A, L, Q, Z, FB, EB, B, G, S, EXT, INH [19:54:11] and then it stopped after 10 seconds or so [19:54:15] cool [19:54:26] reproducable results [19:54:26] sounds like it works :) [19:54:36] other than most our current NASSP issues... [19:54:42] hehehe [19:56:02] I can't even reproduce Orbiter's gravity and state propagation methods [19:57:35] :( [20:09:34] you develop your emulator I'll build my Orbiter competitor [20:09:42] hahaha [20:09:55] I suspect that I might finish just slightly before you do [20:09:58] :P [20:10:08] very likely [20:10:51] my plan was to provide a simulation for the standalone LVDC emulator. Lacking a DSKY the LVDC emulator would be a bit boring otherwise [20:11:10] Sadly the LVDC emulator is even more boring, it doesn't have any software [20:11:41] yeah [20:11:47] maybe someday... [20:13:29] I wonder how hard making an Orbiter clone really would be.... [20:15:25] hard [20:17:01] so in your current commit [20:17:09] where did the fuel cell clogging go? [20:21:10] I'm still a bit skeptical about your power_load logic, but you are the expert on it. The code is probably ok as it is. If you think it's correct I'm willing to merge it [20:25:30] going to impliment clogging in a separate commit. trying to make these projects smaller in the future when possible. I'm going to play around with the branch as is this weekend a bit, and then I'll message you to merge it [20:25:43] sure no problem [20:33:26] oooh one other thing. is the FC disconnect current different in earlier CSMs than later ones? [20:34:02] the document I've been referencing is the rev 3 databook, from 1970 [20:37:55] ours trip at 75 amps, but if I'm reading the databook right, that was the spec, but even at 112 it took 80 seconds to disconnect [20:39:08] 100 ampere minimum...no I'm not reading it correctly [20:43:37] indy91, this might be a bit hacky but... [20:43:55] I found a way to not have that long pause at CSM/LV sep [20:44:27] I found it by accident while testing the MCC VC mesh by loading the LM VC for it [20:45:21] if the LM VC is already loaded in the session, it reduces the pause significantly at CSM/LV sep [20:46:16] n7275, we also have revision 2, not sure if you downloaded that one. If not and you don't want to download a 500MB file, I can check if it's the same. Just tell me where I should look. [20:46:57] AlexB_88, I guess we can do that in the SaturnV class only? [20:47:12] yeah [20:48:24] I'd be fine with that. Even better if we can disable the loading of it somehow, after CSM sep [20:48:30] maybe we can have it loaded in SaturnV class and then deleted after CSM LV sep [20:48:40] yeah [20:49:01] maybe we can hide in the VAB or something :D [20:49:19] ah well I guess not if it part of SaturnV class [20:49:42] oh by loaded you mean actually loaded [20:49:48] oh well just need to flag it invisible [20:50:01] well thats what I did in my test [20:50:20] I had it loaded in the place of the MCC VC mesh [20:50:24] haha [20:50:43] flight controller positions: CDR and LMP [20:51:23] isn't it possible to globally load a mesh without having to actually display it already, even if invisible? [20:52:03] ah, right [20:52:28] ill try just loading it [20:52:34] not Adding it [20:52:43] oapiLoadMeshGlobal? [20:52:50] does that something good for us? [20:53:03] that is what I am trying [20:53:19] rcflyinghokie1, I just remembered, did you land that second time with the main chutes not releasing? [20:53:24] without the AddMesh after [20:54:05] the second time they released and the CM stayed at its orientation upon release [20:54:41] ah ok [20:54:51] so yes [20:54:53] have to fly a few reentries to try that again [20:55:16] just having it loaded with oapiLoadMeshGlobal in a separate vessel from the LM before CSM/LV sep works [20:56:17] great! [20:56:31] I guess we can do that in Sat5mesh or something [20:56:40] yeah [20:57:03] as part of loading the S-IVB stuff [20:57:08] then it doesn't get loaded the next time [20:57:16] after CSM sep I mean [20:57:36] right [20:58:09] I can add that right now to my MCCVC branch and it will be part of the 1st commit [20:58:37] sure [21:04:40] are all the saturn5 meshes deleted at CSM/LV sep? [21:05:07] like the ones loaded by LoadSat5Meshes() [21:05:16] I downloaded rev 2. looks to be the same. I'll change it to 100 amps. [21:06:19] hmm [21:06:49] I believe LoadSat5Meshes always gets called [21:07:04] gets called in the Saturn5 module initialization [21:08:02] Once a mesh is globally loaded it remains in memory until the user closes [21:08:02] the simulation window [21:10:32] and it notes below exactly what were trying to do [21:10:35] "* \note This function can be used to pre-load meshes to avoid load delays during [21:10:36] * the simulation. For example, parent objects may pre-load meshes for any [21:10:37] * child objects they may create later." [21:11:14] * \note Do NOT delete any meshes obtained by this function with oapiDeleteMesh() [21:11:15] * Orbiter takes care of deleting globally managed meshes. [21:11:57] child object LM wants a pre load from parent object Saturn V [21:12:00] may Orbiter already takes casre of it then, when the LM_VC mesh is loaded again by the LM itself [21:12:58] Every further request for the same mesh directly returns [21:12:59] * a handle to the stored mesh without additional file I/O. [21:13:39] right [21:14:59] so it looks like the only thing needed is the oapiLoadMeshGlobal and we dont have to worry about deleting it from Saturn5 class [21:15:31] yep [21:15:40] so Ill add that to LoadSat5Meshes() [21:17:18] I guess. Ah you were thinking about the case of loading a scenario after CSM sep [21:17:29] where both Saturn V class and LM class are calling that [21:18:06] we can maybe see in the DX9 Client log if that actually works, so the LM module not having to load the mesh again [21:21:14] whoa, I just got in a little Apollo 9 booklet from AC Electronics [21:21:39] the LM Computer Programs page actually lists P10, P11, and P63-P67 [21:22:16] sure [21:23:58] I can confirm Apollo 9 had P10, P11 and P63-P67 [21:24:55] fun that something actually acknowledges that :D [21:24:58] it calls P10 and P11 "Predicted Launch Time (CFP)" and "Predicted Launch Time (DT)", respectively [21:25:48] yeah I think this is the first thing we've found that does haha [21:26:09] yep those names are the same as the early GSOP [21:26:33] the log shows Storing a mesh 0x21719D98 (ProjectApollo/LM_VC) twice [21:26:47] oh shit, I wonder if it also has descriptions for the option codes I had to make up names for [21:27:38] AlexB_88, look at how long that took each time though [21:27:57] if it mentions 0x21719D98 twice that is probably good [21:27:59] same ID [21:28:12] 1st: (204: 20.8s 01.76ms)(0xAF8) Storing a mesh 0x21719D98 (ProjectApollo/LM_VC) [21:28:23] 2nd: (519: 52.9s 05.42ms)(0xAF8) Storing a mesh 0x21719D98 (ProjectApollo/LM_VC) [21:29:39] hmm [21:29:53] that's probably not the process of loading the mesh [21:30:09] when does the next task start after those two [21:30:21] next lines in the log [21:31:08] 1st (205: 20.8s 59.72ms)(0xAF8) Texture 0x21F2E280 (Contrail2.dds) added in repository [21:31:19] 2nd (520: 52.9s 01.49ms)(0xAF8) Texture 0x4EF42398 (ProjectApollo/dust.dds) added in repository [21:31:21] hmm [21:31:45] does it prevent the long load in that case? [21:31:52] yes [21:32:05] there is almost no pause now [21:32:14] maybe 1/2 a second [21:32:22] but it was like that before too [21:32:37] well however that works... it works :D [21:32:42] *before the VC was added [21:32:46] yeah [21:33:13] definitely [21:35:50] I just tested again without it and its about 5 seconds [21:36:01] so big difference [21:36:30] as long as we don't add 10 seconds instead of 5 to every LM load now, that's great [21:36:35] since its kind of important and such a small change I think I will commit it right now [21:36:52] yeah [21:49:21] ugh [21:49:51] why does GIT keep refusing my password only on my laptop [21:50:18] when I try to do git push from the command prompt [21:52:58] says the username password are incorrect, but they ARE! :D [21:53:03] only happens on my laptob [21:53:04] no idea, I let git store the password, so I never have to enter it [21:53:38] I have it set that way on my main PC, but my laptop keeps asking for it [21:55:53] make sure your remote is git@github.com:org/repo, not https://github.com/org/repo [21:56:06] if you go through https I'm pretty sure it always prompts [21:56:07] Github is more annoying [21:56:40] wants me to confirm my identiy every so often [22:00:35] rcflyinghokie1, upon further investigation, I think the trajectory propagation isn't so bad. I set all drag of the CSM to 0 and it stays quite close. [22:00:47] so it might actually be drag after all [22:00:58] maybe not only drag, but it's definitely part of it [22:02:24] without drag it's still 30 meters off at most from what was predicted 1.5 hours ago for the position at deorbit TIG [22:02:44] I used your deorbit day scenario, I think about 6 hours before deorbit [22:06:34] yeah the dragless solution is perfectly fine. Why was I even doubt that as a whole [22:06:44] doubting* [22:08:02] haha so its orbiters fault? [22:08:23] I think it's mostly drag that the RTCC isn't compensating for [22:08:46] I always thought that the drag of all our spacecraft are super small, but apparently not [22:08:58] and this orbit has a perilune of 94NM [22:10:14] perigee [22:11:00] should the remote "origin" have the address of my only repo? [22:11:07] online* [22:12:13] I think the way we usually set things up is upstream for the main repo and origin for our own NASSP one [22:13:03] I decided to delete my origin with GIT GUI and trying to re-create it [22:13:45] git@github.com:org/jalexb88 for the address? [22:14:00] git@github.com:jalexb88/NASSP [22:14:13] oh lol [22:14:16] thanks [22:17:39] so I added that address as to the remote "origin" [22:17:54] but now when I push ie. git push origin Orbiter2016 [22:18:05] |Warning: Permanently added the RSA host key for IP address '140.82.114.3' to the list of known hosts.| [22:18:16] git@github.com: Permission denied (publickey). [22:18:16] fatal: Could not read from remote repository. [22:18:40] https://docs.github.com/en/github/authenticating-to-github/adding-a-new-ssh-key-to-your-github-account [22:18:41] try [22:18:43] git remote -v [22:19:29] I get a list of the repos now [22:20:03] origin: git@github.com:jalexb88/NASSP [22:20:19] upstream: https://github.com/dseagrav/NASSP.git [22:20:45] hmm, does using deagrav there still work? I guess it does [22:21:05] orbiternassp/NASSP is the actual link now [22:21:20] looks right otherwise [22:21:49] oh but wait [22:21:57] that origin link looks weird [22:22:01] Does that work? [22:22:53] For Mike's new repo I did [22:22:53] git remote add origin https://github.com/thewonderidiot/magc.git [22:22:56] earlier [22:23:30] both formats work -- they're different protocols. git@github.com lets you set up a public key so you never have to authenticate [22:24:40] ah ok [22:26:08] ok so its the fatal: Authentication failed for 'https://github.com/jalexb88/NASSP.git/' [22:26:19] so I guess Ill have to check the link Mike posted [22:30:22] night! [22:34:53] ok so I still cannot find the physical location of the LM fan on LM-8 [22:35:09] I think part of the reason we arent getting cabin circulation is the fan positioning [22:36:57] I am wondering if its positioned in the loop like the cabin gas return to help circulate [22:39:13] ok it works finally [22:39:41] thewonderidiot, thanks for the link, a bit of a hassle to go through but it works :D [22:39:53] yeah it's worth it though [22:40:03] now that you've set it up you won't have to again until you switch computers [22:40:24] even if you change your password or whatever, that key will keep working [22:40:39] right makes sense [22:40:57] is that key tied to my laptop though? [22:41:33] no, you could easily copy that private key you generated to a new computer [22:41:42] I usually have one per computer though [22:41:56] ok [22:44:56] .tell indy91, PR sent [23:18:40] thewonderidiot: Are you writing a new AGC emulator? [23:33:21] yup [23:46:16] Nice. Because of the counters? [23:48:02] What kind of API do you have in mind for peripherals? Same as yaAGC? [23:49:46] nope, this is clean slate, how I would design something now if I didn't have to worry about compatibility with yaAGC [23:50:07] I'm not going to provide much of an API -- probably just DSKY [23:50:21] otherwise it will be optimized for being included in simulations [00:00:08] I think I'd do the same. While compatabilty is nice there have been discussions that limited function in for better compatability. [00:00:32]