[14:51:35] NASSP Logging has been started by n7275 [14:51:37] hello [14:52:57] hey Matt [14:59:12] any reason why we can't close the cabin fan GitHub issue? it seems to be resolved [15:00:45] I think so. What got implemented isn't exactly what Thymo was suggesting, but the solution does the same, more acceptable volume. [15:09:23] okay. I think we are going to need to revisit sound in general if we want to consider migrating to the next version of Orbiter [15:11:39] yes [15:23:04] ok, put all my current RTCC work on Github [15:23:19] just needs testing and maybe more documentation [16:04:40] on the subject of countdown holds, would it be easier to just add a new time variable, rather than trying to change/remove all the instances of mission time? [16:29:27] yeah I think that is the way to go. in a lot of places the mission time is mostly used as a regular time interval even with saving/loading [16:29:53] the main challenge will be the prelaunch sequence of events in satsystems, mostly for the ECS [16:30:08] a lot of that codes belongs in the mobile launcher somewhere [16:30:11] code* [16:34:06] speaking of plans that haven't come to fruition yet, a while ago I wanted to write an Apollo 12 specific RTCC MFD guide, but I guess you need to fly without that for now... [16:35:29] morning! [16:36:50] hey Mike [16:37:03] how is the CDU doing [16:37:25] I'm down to only 12 nets with errors for tray X in the backplane viewer [16:37:37] although resolving the nets has raised a lot of questions that need to be beeped out [16:38:14] ....and this is only for LM backplanes. I'm sure it will be a disaster again if I try to generate a CSM one [16:38:58] yeah this CSM/LM mixture seems to get in the way a bit :D [16:40:00] it wouldn't be so bad if they annotated their schematics consistently [16:41:07] like two pins almost right next to each other in the schematic. one of them is clearly marked as only connected in the LM, the other is not [16:41:17] but they're both only connected in the LM, and they are separated by a pin that's connected in both vehicles [16:41:20] not helpful, MIT [16:44:43] yeah that's quite annoying [16:50:06] the one I'm stuck on now is the IMU cage signal, which is put out on pins 109 and 110 [16:50:29] both unmarked implying always connected for all axes, which is clearly false [16:50:46] but also both are explicitly marked as going to the mode module [16:50:59] but it seems like only the pin 109 signal ever actually makes it there [16:51:11] so I don't know if pin 110 is just unwired or what [16:56:41] CDU outputs IMU cage command? [16:57:25] something like that [16:57:38] at least it's a signal called CAGE [17:00:06] I'm seeing some signal going to the IMU, looks like 1x sine and cosine input from IMU is send back to the IMU to drive it to zero when you cage it [17:00:20] oh, not sure if it's useful at all to you, but I have the SA-502 version of https://www.ibiblio.org/apollo/Documents/UAH-19671205-InterfaceControlDocumentDefinitionOfSaturnSA507FlightSequenceProgram.pdf arriving today [17:00:23] ah yeah that'll be it [17:00:48] oh nice, Apollo 6, yes that could be useful [17:02:06] I do already have the S-IVB stage flight test plan for that mission [17:02:42] nice :D [17:02:58] which has most if the flight sequence program, but there are a bunch of TBDs [17:03:03] so might be an early version [17:03:07] of* [17:03:35] so good to have something more official :D [17:04:37] oh and the S-IVB flight evaluation report also has all of the events [17:04:54] but still, it's good to cross check. And there might some sequences not used on the actual mission [17:07:25] and what mode module is that? Also part of the CDU, right? [17:08:08] just from the Systems Handbook the CAGE signal is always connected to the three gyro servo amplifier relay module, part of the IMU [17:08:15] and that has cage and coarse align relays [17:08:23] which would allow that cage signal to do something [17:10:21] oh god the IMU wiring there is complex :D [17:10:25] hahahaha [17:10:30] yeah the mode module is part of the CDU [17:10:55] but it's mostly the IMU cage switch that gives the cage signal to the IMU [17:11:25] there is a second path, looks maybe like during IMU turn-on it also has it caged still [17:11:47] and also my sleepy brain was conflating the CAGE signals, which I also had problems with, with the other signals that I actually got stuck on: _CSRFH and _CSRFL [17:12:15] which are the cosine(theta-psi) reference from the quadrant select modules and definitely CDU-internal [17:29:55] yeah the CSM CDU backplane is going to be a complete bloodbath when I delete the optics coarse modules [17:30:35] it's almost too bad that I don't have access to a CSM CDU tray X to see if they still had any wires connected there at all [17:43:20] what's better than owning one CDU. Owning two CDUs! [17:44:10] just steal a whole CM from some museum, how hard can it be [18:06:55] hahahaha [18:07:21] I don't know if I want two CDUs [18:07:30] one is radioactive enough [18:13:53] haha right [18:15:04] and what's the rope reader doing? Getting as much attention as the CDU? [18:17:45] aluminum parts are in https://photos.app.goo.gl/BD72o1X51yZqBgKw6 [18:17:55] the test backplane board is allegedly being delivered today [18:18:04] and I started doing the layout for the full driver board last night [18:18:32] it hasn't been getting as much, but I'm going to start focusing on it almost exclusively again until the driver board layout is done [18:19:42] if the backplane fits I'm going to take over the rear aluminum plate to Marc's so we can install all of the female Samtec/Malco pins [18:29:04] they are already experts at AGC pins [18:31:46] yep! [19:51:45] ah! backplane boards are here [19:51:50] let's see if this all fits together [20:03:08] yesss it works :D [20:08:49] :D [20:11:08] I don't think any changes are necessary outside of actually routing all of the connections on it [20:11:20] the driver board plugs into it just fine [20:11:38] malco pin holes are well-aligned with the mounting holes on the rear plate [20:12:24] the orientation of the rope module pins is correct [20:18:26] https://photos.app.goo.gl/71LVreEXaLUGbwD5A [20:18:50] https://photos.app.goo.gl/g3T1sivEngcQNQwL6 [20:19:59] beautiful [21:04:16] night! [14:21:38] good afternoon [14:40:24] hey [14:43:24] what's the latest on your CSM exterior lighting PR? Was there anything left to do? [15:45:08] I think it can be merged [15:45:21] I was just waiting on feedback in the visuals [16:03:31] there are more lights to add (running and eva) but that requires mesh work and I have no idea what I'm doing there [16:19:34] hmm [16:19:41] RndzLightSwitch.refresh(simdt); [16:19:47] I feel like this shouldn't be necessary [16:28:10] I guess switches are e_object but not registered via AddSystem so their refresh isn't called? [16:30:29] okay now I'm doubting my code [16:31:41] they *should* be registered they won't draw power otherwise [16:31:52] I'll dig into it later [16:33:48] I can quickly check if the refresh function is already called [16:39:01] I am not seeing yet though how the switch itself is registered with the electrical system [16:41:20] it is though [16:41:31] if I comment out the refresh call, it still gets called [16:41:39] so it seems like it is redundant [16:41:47] just need to figure out how haha [16:52:56] or not [16:53:12] I had added a debug string to UpdateSourceState() [16:53:17] but that also gets called during loading [16:54:20] in the past we have handled these switches differently [16:55:02] we would have added a line in [16:55:06] Saturn::PanelSwitchToggled [16:55:15] instead of a refresh that gets called every timestep [16:55:41] which should be fine as long as you do the re-wiring at scenario loading [16:55:51] and then only when the switch state is changed [16:57:04] interesting [16:57:11] I get an error when loading in debug mode [16:57:19] in E_system::Create_ElectricLight [16:57:27] Run-Time Check Failure #2 - Stack around the variable 'flashing' was corrupted. [17:15:54] no idea what causes that yet [17:32:16] that doesn't sound good [17:36:57] sounds like a buffer overflow [19:34:08] it seems to be your sscanf line for the config file [19:38:12] but it only fails at the end of the function [19:38:48] maybe it doesn't like loading the bool flashing with %d [19:39:19] if I make flashing an int, let it load it with %d, and then in the ElectricLight constructor I use (flashing != 0) [19:39:23] then I don't get that error [19:44:51] ok, now I am seeing really weird things during debugging, I need to rebuild :D [19:51:30] it loads from scenario [19:51:34] first line for the switches is [19:51:35] ASCPYawSwitch 0.000000 0.000000 [19:51:59] it calls that LoadState function, but it somehow calls ThreeSourceSwitch::LoadState ??? [19:52:12] and from there it calls ThreeSourceTwoDestSwitch::UpdateSourceState ???? [19:52:24] nothing of that makes any sense [19:55:02] hmm [19:55:22] so, if a line from the scenario is loaded, it literally calls the LoadState function of every single switch [19:55:37] and in the LoadState function it decides if it even is the correct switch [19:56:04] but some LoadState functions also call UpdateSourceState [19:56:35] and that seems to be called for every single switch in the scenario [19:56:50] I don't think that does any harm, but it's very inefficient [19:57:58] n7275, and you didn't cause this haha, that was there before [20:03:49] and my original reason for checking all this, the refresh function for the rendezvous light does need to be called [20:51:30] night! [23:35:50] .tell indy91 whoops was afk the whole afternoon. I'm glad it wasn't me this time haha [13:17:32] I thought it was a good idea to make some of my little tools available that I have created over the years [13:17:41] started with this one: https://github.com/indy91/RTCC-TLI-Presettings-Card-Format [14:14:06] hello [14:14:21] that looks cool [14:20:47] I made that when I didn't want anymore that the RTCC needs to access the Saturn class directly to get LVDC parameters to simulate TLI [14:21:31] the RTCC files this creates (with TLI in the name under Config\ProjectApollo\RTCC) aren't really human readable [14:21:45] but they follow the punch card format that was used to read the data into the RTCC computers [14:53:01] ooo that document even defines what the card identification numbers should look like [14:58:13] yeah, has the full format of everything [14:58:37] MSFC sends the data via tape, it gets converted to card at MSC and that gets loaded into the RTCC [14:59:10] and in our RTCC config file it is 1 line = 1 card [15:05:13] as a proper tool this could probably use some work, maybe have you enter the three input variables via command line or so [15:05:36] this is just how I used it, with 5 minutes of looking over it today [15:06:24] I had it as a VS project, but to be more platform independent I only added this file for now, as it is the only file [15:06:29] and no sprinf_s :D [15:06:34] sprintf_s* [15:07:38] haha, I tried building on linux and rather quickly discovered those [15:09:53] should be all snprintf [15:10:01] that should be compatible, right? [15:14:09] my mistake. it is [15:14:21] it was the scanf_s [15:15:26] *sscanf_s that is [15:15:51] oh right, I overlooked that [15:15:53] I can change that [15:17:46] if there is a good function that VS doesn't complain about but also works in Linux [15:17:53] VS doesn't like sscanf anymore [15:20:19] what a pain [15:21:22] Thymo may have a better idea, but I found this https://docs.microsoft.com/en-us/cpp/c-runtime-library/secure-template-overloads?view=msvc-170&viewFallbackFrom=vs-2019 [15:22:13] All those _s functions are Windows only special sauce [15:22:16] it does suggest that I use _CRT_SECURE_NO_WARNINGS if I want to still use it [15:22:24] sscanf I mean [15:22:26] or sprintf [15:22:28] Both Windows and Linux support the POSIX variants [15:23:12] I'm not really finding a good equivalent to snprintf for sscanf [15:23:35] any suggestions? [15:25:29] I don't see any problems with snprintf. Sscanf could only be problematic if your format string is bad and the output ends up larger than the place you're storing it in [15:25:36] Is VS complaining about those too? [15:27:32] error C4996 'sscanf': This function or variable may be unsafe. Consider using sscanf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. [15:28:27] I can just do _CRT_SECURE_NO_WARNINGS I guess [15:29:08] Maybe we should do a #ifdef WIN32; #define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES; #endif [15:29:21] or #define _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES 1 [15:29:33] Then MSBuild will replace anything it is not happy with with the _s variant on Windows [15:30:39] haha we're frequency and phase locked today [15:31:46] OVERLOAD_SECURE_NAMES requires you to replace the functions with the _s variant and it will automagically insert the size. However the _s variants don't exist on *nix so OVERLOAD_STANDARD_NAMES is probably more portable. [15:35:29] or [15:35:30] #ifdef _WIN32 [15:35:31] #define _CRT_SECURE_NO_WARNINGS 1 [15:35:31] #endif [15:36:04] that actually builds for me, your two variants don't for some reason. [15:37:21] But does it solve, or hide the problem? :p [15:37:45] it hides the not-a-problem of using sscanf safely :D [15:38:53] i think _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES doesn't work with sscanf [15:39:02] it seems to work for sprintf though [15:41:06] Maybe we can just disable it for sscanf then. [15:41:23] Anyway, need to pop off again. Having dinner at a friend's place. [16:47:05] by the looks of the forum, Jordan appears to be working on linux-orbiter [16:49:48] ah interesting, some NASSP screenshots [16:50:08] oh I saw you did a bit more with the Fortran code [16:50:45] the atmospheric density function it has uses the 1962 US standard atmosphere [16:50:49] and that's what I am using, too [16:50:51] in our RTCC [16:51:26] but I came across a document from December 1967, Apollo Missions and Navigation Systems Characteristics [16:51:47] and it suggests to use, for below 90km, a supplement to the 1962 atmosphere [16:52:16] the biggest discrepencies I found were at 80km, between the 1962 atmosphere and the realistic models that Orbiter uses [16:52:35] the IBM RTCC document does also say to use the 1962 atmosphere, but it's from May 1967 [16:52:53] so maybe I would get a bit better results if I use the modified atmosphere below 90km [16:53:17] the supplemental document has several versions, for January and July, at 15° latitude increments [16:55:19] these errors cause some differences on the Earth Entry PAD [16:55:29] the entry guidance switches to P67 at 0.2g [16:55:40] but the entry angle there is very shallow [16:55:55] so the 0.2g time is up to 20 seconds in error [16:56:06] and you would check the downrange error at that time [16:56:30] so the difference is large enough that you would almost have to declare the PGNS no go for the reentry [17:00:01] oh wow [17:00:11] that is significant [17:00:28] I also found this document http://mwhume.space/Files/TranscribeMe/todo/19680023890.pdf [17:01:12] and http://mwhume.space/Files/TranscribeMe/todo/19680023891.pdf [17:01:17] right, I think I have seen this [17:05:17] I'll need to make some comparisons [17:05:49] if the modified atmosphere model will actually be better [17:11:21] I wonder if we could add another earth atmospher model, that took historical F10.7 values rather than a static a erage [17:11:39] *average [17:13:46] oh yeah, we likely could [17:13:53] atmosphere models seem to be rather flexible [17:14:06] if they can call the Orbiter API [17:14:13] to get the MJD or so [17:14:16] and then interpolate [17:16:51] would be useful for Skylab [17:20:02] also in general, there are differences between the 1962 model and what Orbiter does by 50% at orbital altitudes, too [17:26:07] and yes [17:26:10] EarthAtmosphere_J71G [17:26:16] it calls oapiGetSimMJD [17:26:29] so we could have a database of flux numbers [17:39:33] but for now I am just happy that I manage to finish more projects than I am starting haha [18:33:36] I would like to do that at some point haha [19:03:22] I'm back [19:09:29] hey [19:16:22] I had a really nice spinach pesto pasta for dinner :D [19:29:38] oooo nice [20:13:57] indy91: I'm working on the DSKY wiring again. You mentioned that wiring the DSKY might not be a good idea last time. Why did you think that? [20:13:58] https://github.com/orbiternassp/NASSP/tree/agc [20:16:39] hmm I don't really remember. Was this about differences between CSM and LM that I was worried about maybe? [20:17:23] You were worried about introducing CSM/LM specific code into the currently agnostic DSKY [20:17:40] Convo was in 5-16 in the logs [20:18:50] ah right, it was about the LCA [20:19:21] The differences between the LM and CSM wiring is to such an extent that I need some glue somewhere. I don't think doing it in the DSKY causes too much trouble, besides maybe having to be linked against the vessels now. [20:19:54] But the DSKY is already so NASSP/Orbiter specific that I don't really see it being used for another purpose anyway. [20:20:11] Unless you want to use it for DIGFLY if we ever find itor something [20:22:12] yeah I guess you would have to add some common class in both CSM and LM that does the lighting controls [20:22:37] sounds complicated [20:23:55] I think the way I chose is minimally invasive [20:24:17] It will get some small additions when we add integral lighting for the keyboard. [20:24:37] minimally invasive sounds fine [20:26:24] looking at the Systems Handbook, there isn't really an LCA equivalent in the CSM, it's probably just a bunch of wiring and some equipment built into panel 100 [20:28:23] No instead of the LCA it has that one transformer [20:28:38] Between the DSKY and the dimmer. T4. [20:29:20] yeah [20:30:02] and some more associated with the control knobs [21:04:16] night! [11:34:30] Good morning! [11:34:46] STC, this is Apollo 9, T -53 minutes [11:36:27] morning where? :D [11:36:43] In Spain and in Florida :) [11:37:06] *In Spain (RL) and in Florida (sim) [11:37:18] ah afternoon in Spain begins after the siesta, I understand haha [11:37:25] Exactly [11:37:28] Remember [11:37:34] Spain in 2 hours late in summer [11:37:39] 1 hour late in winter [11:39:41] *is [11:40:03] So, things that will go wrong on this training: I will fail the docking, I will be unable to pressurize the LM. I will fail the extraction of the LM [11:40:14] and something else ;D [11:40:27] I'm not sure you will be able to fail then extraction haha, it's easy [11:40:48] pressurizing the LM properly takes a little bit of experience, but not difficult [11:40:54] docking takes a bunch of practice to do well [11:40:56] Last time I did it was like 12 years ago :) [11:41:17] I don´t undesrand some parts on the flightplan that say "Decal" [11:41:26] In reality that is my biggest concern [11:41:42] What is the meaning of "Decal"? [11:44:51] uhh [11:44:54] good question [11:46:12] maybe ask one of our English speaking folk [11:47:10] Habrá que recurrir a eso [11:50:02] Oh, by the way: [11:50:04] https://prnt.sc/78zv6dhhHmDe [11:50:27] Why do this text overlaps? Is this a known issue? [11:51:18] font size is weird in External MFD. Does it also overlap on the 2D panel? I have this problem constantly in the RTCC MFD, I wonder if there is something I can do [11:52:22] On 2D panel also overlaps [11:53:11] Even if I change the size of the external MFD. Font resizes accordingly... [11:53:23] Then two of the texts need to be shortened a bit [11:54:25] And... what does the text say? I think that I will need some of these controls on 9, right? [11:54:54] to the right it is just coolant loop tests [11:55:01] I don't think you ever normally would use them [11:55:05] more a debugging thing [11:55:14] on the left it just says back [11:55:16] And the hose? [11:55:29] and CRW to set the number of crew in CSM or LM [11:55:43] the hose is for better air circularization [11:55:57] we get the same issue but for different reasons, a CO2 buildup in the LM [11:56:05] the hose helps with that [11:56:20] Aha [11:56:36] they basically connected a hose to the CSM suit loop, and let it push air into the LM cabin [11:56:55] which slightly overpressurizes the LM cabin, pushes air back to the CSM, which removes the CO2 [11:56:59] when the LM is unpowered [11:57:33] I understand [11:57:58] you can kill the crew when you first activate the LM ECS and open some valves [11:58:01] too much CO2 :D [11:58:29] if you have the LM crew already in their suits [11:58:53] ^Added to the list of things that can go wrong today :D [11:58:54] I am practising up to GET 6 hours. [11:59:17] nah, won't go wrong today, no entry into the LM on the first day I think [12:02:15] By the way, what happened with 1885? [12:03:57] the release? No idea [12:04:01] was there a 1885? [12:05:20] That is why I ask, because it´s 1884, 1889, 1890, 1891,1892.. etc [12:25:40] Quick question; is the tape stopped after SECO on Apollo 9? [12:52:10] not sure [13:24:09] hey [13:24:33] "Decal" https://en.wikipedia.org/wiki/Decal [13:25:26] hey Matt [13:25:28] no idea why that particular word is used in the checklist [13:25:44] yeah, I don't get it either [13:25:53] CM/LM Pressure Equalization (Decal) [13:26:00] Tunnel Hatch Removal (Decal) [13:26:09] Docking Latch Verification (Decal) [13:26:21] as the heading for these parts of the launch operations checklist [13:26:54] maybe it means "click the texture" [13:27:10] Hey n7275 [13:27:18] Yeah, I though the same... [13:27:32] the lines I am quoting are from the actual launch checklist [13:27:34] I knew the decal word from my plastic models [13:27:37] not ours [13:27:53] so the word decal is taken from the actual checklists [13:27:57] no texture to click there :D [13:28:32] So... what to do there? Just Imagine yourself checking the things? [13:29:52] well I have no idea then lol [13:31:20] clearly there are some dialect differences between 60's Texas and 2020's Maine, American English.... [13:32:11] :D [13:33:42] or the Britsh English as taught in German schools of the 00s [13:35:09] Houston, Apollo 9 [13:35:23] 5 balls on the first P52 [13:36:52] soon you will learn that you have a docking probe on the CM and that you can extend it [13:38:38] Exactly [14:20:57] The time has come [14:38:26] https://prnt.sc/rGeclgXPUJDL [14:38:39] Go to P00, I guess... [14:39:15] That is after doing the V25N17E and V25 N22E [14:40:37] if you want to, it's not strictly necessary [14:41:17] Went to P00; 'DON HELMET AND GLOVES'. Do I do something with PAMFD? [14:42:42] nah [14:42:45] not in the CSM [14:42:52] Oukay [14:42:53] in the LM you have some options there [14:43:01] either suited or in cabin [15:41:53] https://prnt.sc/UGZC1MIYlilO [15:48:15] catch that spider [15:54:52] https://prnt.sc/-7XbCL68PdKn [15:55:01] https://prnt.sc/WyLVQVN4G-E8 [15:55:08] Houston, Docking is complete [15:55:11] :D [15:56:34] hopefully without spending half of the RCS :D [15:56:59] Yep [15:57:03] 380ish [15:57:16] lbs [15:59:36] morning! [16:01:12] hey Mike [16:01:24] what's up? [16:01:35] Hey good morning [16:01:38] I say AS-502 flight sequence program, what say you :D [16:01:46] Training apollo 9 here [16:02:24] I say, USPS may have delivered it to the wrong mailbox :/ [16:02:30] ouch [16:03:22] so, will you even get it? Or has it been properly delivered and USPS can't do anything? [16:03:49] Cago en Satán! (as we say here when something goes bad...) [16:08:30] not sure yet [16:08:47] we'll see [16:09:38] ah damn, I'll be hoping for the best [16:12:38] Jordan and gondos have been talking on the Orbiter Forum about running Orbiter and NASSP on Linux. They have been having some success after modified some code and files. [16:12:59] the least I can do is incorporate those changes, some of them are simply bugs or oversights [16:13:05] like this: https://github.com/orbiternassp/NASSP/pull/790 [16:14:45] oh sweet, that would be awesome :D [16:18:00] we should probably take the spaces out of some filenames [16:32:05] Question, my Systems Test 4D shows 0 [16:32:19] On checklist it should read 0.5-3.2 [16:32:23] Normal? [16:35:49] I always forget, is that LM power? [16:35:55] Yep [16:36:26] LM power switch is on CSM, LM power breakers are closed [16:36:35] hmm, at the very least it should be jittering a bit [16:36:44] it should be powering some heaters in the LM [16:36:53] but they might have enough heat right now [16:36:56] Yeah, I see the jutter now [16:37:01] *jitter [16:37:06] then it's fine [16:37:43] Ok [16:39:20] it means it is connected which is the important part [16:41:50] Go for LM extraction [16:42:03] Las time done in 2009 I think :D [16:45:26]