[20:52:54] NASSP Logging has been started by thewonderidiot [20:52:58] Guenter! [21:50:17] night! [22:52:37] Finished the report. Time to look at that issue. :) [02:49:38] oof, just pushed a commit to fix the mission scenarios. >104 files changed [02:51:49] going to have to load each and every one now and make sure I didn't break anything [14:56:41] good morning [14:59:13] hey [16:06:57] finally pushed that general purpose maneuver update [17:03:32] nice [17:24:10] I'll do one little side project and then I will go back to the long and boring task of preparing the coordinate system change in the RTCC [17:26:22] morning! [17:26:45] n7275 and you got your script for the ECS scenario editing all working? [17:26:47] hey Mike [17:26:55] yes [17:27:05] hi mike [17:27:53] one day I want a tool that can create the scenarios entirely from scratc [17:28:06] equivalent to loading the mission simulators into a specific state [17:28:51] we have some documents with data for that [17:29:14] like the exact state vector and P30 data for the Apollo 10 maneuver sims [17:30:56] I tested it against my fuel cell branch and it does what I want. [17:32:24] I think a scenario generator would be doable. would only want to target a released version where the scenario format isnt changing [17:33:25] I want Ryan to test my changes and then we can merge it. [17:34:56] and I want to test what happens in unedited scenarios :D [17:36:13] I can give you the script if you want to upgrade some of them. [17:37:43] might be useful for the public, too [17:38:07] https://gist.github.com/n7275/8cab7e348507ff4bce4749d09e2c3894 [17:38:49] it does all scenarios in the directory of the script. [17:42:30] it also doesnt know if the scenarios its upgrading have already been upgraded, so make backups and use with caution [17:44:00] in unedited scenarios the most notable error will be the cryo tank pressures being very wrong [17:44:43] cabin temps will be a bit high but it wont kill the crew and will be okay within 20 minutes [17:49:00] ah nice [17:49:19] at least the crew isn't getting killed, so old scenarios are still somewhat usable [18:46:14] hmm [18:46:25] I've been reading in our favourite MSC memo again [18:46:32] there are two constants, for Earth and Moon [18:46:38] basically integration step lengths [18:47:05] 0.03125 and 0.0625 [18:47:18] but in the IBM RTCC document they are [18:47:22] 0.3125 and 0.625 [18:47:24] that is weird [18:48:33] hmmmm [18:48:49] at least they're both different by the same factor... [18:50:09] I do find the 10x version has a bit too long steps [18:50:15] I like the 1x better [18:50:37] it's possible that it is intentional [18:50:50] the RTCC has this function twice [18:51:00] once stripped down, used for iterating on trajectories [18:51:17] and maybe they are ok with the longer integration steps there [18:52:05] but 10 times is a big difference [18:53:39] could also be a typo [18:55:16] MSC memo is actual Fortran code [18:55:24] the IBM documents are just flowcharts [18:56:59] when trying to find a specific radius or flight path angle, and not time, there is another difference between the two [18:57:26] linear interpolation in the MSC memo, quadratic interpolation in the IBM one [18:57:49] if the step length is really 10 times as large, maybe they needed to implement the quadratic interpolation then [19:11:12] I am glad that EQUIVALENCE isn't in modern programming language as much [19:11:18] it makes code very difficult to read [19:16:10] heh yeah [19:17:59] especially if it's misused like in this MSC memo [19:18:11] mainly used for convenient variable naming [19:18:30] not a lot for e.g. accessing a value in an array more easily [19:21:09] I guess it's not too dissimilar from the Comanche 44 -> 45 problem [19:21:20] same location, same value, referred to in two different places by different names [19:21:28] yep [19:21:32] easy to miss something :) [19:21:33] that's how you get bugs like that :D [19:21:37] hahaha yeah [19:24:27] https://media.discordapp.net/attachments/735589860131340368/912760832927080538/fullcycle.gif [19:25:05] rope visualizer can show full memory cycles now, given an address that you give it. getting close to having everything I want implemented :D [19:28:10] oh that looks fancy :D [19:34:55] it's so nice to have something that shows me what's happening visually now [19:35:04] I understand ropes so much better [21:25:02] oh wow. that's very nice [21:29:50] thanks :D [21:30:19] it's also very interactive -- you can have it simulate a cycle automatically, but also you can click on all of the wires to activate/deactivate them and see what happens to the cores as a result [21:30:42] or, tonight's feature, click on a core to see its current polarization and the amount of current flowing through it [22:02:59] Hello [23:39:09] hey Thymo [23:40:10] Been reworking interrupt stuff in ApolloGuidance [23:40:27] That GenerateHANDRUPT function wasn't even being used... [23:52:31] good to know... [23:57:43] I'll need to dive into it further. PR is up with some fixes though. [00:01:58] I'll give it a look [00:02:18] so wait, was it just ignoring interrupts in standby? [00:08:41] The opposite. It should ignore them but it didn't, causing the AGC to break. [00:08:54] So the new function discards any interrupt requests during standby. [00:11:07] oooooh [00:14:29] oh that looks much cleaner [00:15:41] It's a bit more verbose with the whole ApolloGuidance::Interrupt:RUPT going on but it's easily outweighed by that enum yeah [00:33:15] are we waiting on anything to merge the update to platform toolseet 142? I cant remember [00:34:02] s/toolseet/toolset [08:41:23] Morning. [08:42:15] n7275: Good point. I'm not sure if there was an impediment there. I'll browse through my logs, if it's all good I'll make a PR. [08:42:57] It does require people updating their tools though, so it will need to be communicated. [15:03:47] Hey Nik [15:05:02] hey guys [15:08:08] hey [15:10:06] googles "final" specifier [15:10:48] lol [15:12:29] are any interrupts being generated in a way right now where the functions would have to be virtual? [15:14:07] the Interrupt enum is only internal to the ApolloGuidance class, right? [15:14:24] Otherwise it should be called AGCInterrupt or so as we have other computers with interrupts [15:15:07] It is defined inside ApolloGuidance but can and is used outside of it too. [15:15:34] But you need to access it throught ApolloGuidance's namespace [15:15:58] ok, then that is fine [15:16:33] this code doesn't handle the AGC being completely off yet, right? [15:16:47] AGC off, PCM on. That would still generate some interrupts [15:17:01] well, any external system [15:17:14] or is the standby mode flag set when the AGC is off [15:18:36] It doesn't actively prevent you from raising an interrupt as pulling the breaker does not set the standby flag (nor should it). However when the breakers are pulled we reset the AGC to a GOJAM state on each timestep. [15:19:05] So even if it does happen the interrupt is cleared at the start of the next AGC timestep. [15:20:11] Eventually I'd like to move the GOJAM code away from NASSP and make it available in yaAGC but it would introduce a new interface so Ron probably has a say about that. [15:20:25] ah ok [15:20:34] right, our code for the AGC being off is then handling it [15:21:35] About them being virtual -- The orignal functions were virtual, so I kept that intact. Although they probably don't need to be, same goes for other functions in that class. [15:22:52] ah right [15:22:54] yeah it's fine [15:24:07] I should probably remove it as marking a function virtual final in a base class is kind of pointless coming to think about it. [15:24:35] well the functions could be called externally [15:25:14] quick tangent before I run off: I'm going to create an issue for the HBR telemetry desync issue that we see on the client side of things. im convinced it's the pcm class doing it not the client. [15:26:33] yeah, didn't we have some idea what it could be? [15:26:55] I missed that discussion. [15:27:19] was a while ago [15:31:00] Is it a quick fix? [15:32:17] I think the fix is something getting reset to zero when we switch from LBR to hbr [15:32:46] I can look into it [15:34:53] I want to do a rewrite of the telemetry code so if it requires major rework its probably best to integrate it in the new solution instead of patching the current one. [15:37:09] okay. if it's more than the one line fix I think it is then I will leave it. [15:40:27] you were planning on running telemetry in it's own thread right? [15:43:42] That's part of it. I want to expand the capabilities and make it into a proper API so we can support external applications doing mission control tasks. [15:44:17] ahh okay. I like it. [15:45:15] It's gonna be a little while before I start work on it though. Just know that I will be ripping all of the current telemetry code out at some point. :P [16:00:07] good morning [16:06:19] hey Ryan [16:11:54] Heading home. Back in a bit. [16:17:13] This week has been killing me with work lol [16:17:39] Saw the ullage reply, that does provoke an interesting question on using 2 vs 4 jet ullage [16:17:52] I imagine it is based on burn time and propellant remaining [16:45:45] I also read that time critical burns use 4 jets because the ullage burn will still be successful if a jet fails