[16:18:54] NASSP Logging has been started by thewonderidiot [16:18:56] morning! [16:19:01] oh hi Guenter [16:19:16] oh hi Mike [16:19:55] Guenter should reply like that [16:20:02] not very smart AI [16:20:21] back up to the white room, he is much better there [16:23:00] hahaha [17:09:09] n7275, could you have a look at my "Add Apollo 9 DAP PAD for MCC..." PR? It's a lot less scary than git makes it. I only squeezed in one MCC update, but for that I have to slightly change the numbers for each update on that day [17:10:17] Also, I still think this concept of being forced to have someone approve your work is not good. At least not for me and the RTCC: [17:10:23] I'm the only one doing that coding [17:10:54] so nobody is jumping on the opportunity to check my PRs for that. I always have to beg for it or else nobody checks anything. [17:12:04] This doesn't result in much better code. It just wastes my time because my RTCC updates are often incremental in nature. [17:12:24] And I don't want to work on Project Y, that depends on Project X, if Project X still might have a bunch of changes done to it [17:14:01] For any bigger projects I am glad to get help with testing and I will do PRs for whenever I think it's best if something needs extended testing. [17:14:46] But the current concept almost requires twice as much manpower for any project than before, because of the PR code reading and testing. [17:14:52] and we just don't have that [17:15:48] I think it's totally fine if people become specialized. Any update from Ryan for the LM ECS for example I can approve immediately, because he knows what he is doing and has tested it a lot [17:18:04] the gravity model PR on the other hand, that is something I would always have done a PR for. I know n7275 has done similar things working on an update for Orbiter, so the second pair of eyes on that is important. [17:50:16] for what it's worth, I agree with you -- but I agreed with you back when this was enabled the first time too lol [17:54:31] I keep getting into this trap of not creating branches for everything [17:55:01] create a small update, think it will be merged within hours, so do it in Orbiter2016 [17:55:45] nobody looks at it for days, I would like to create a testing branch for this clock drift fix that actually could use people testing it [17:55:54] but now I can't branch off from my local Orbiter2016 [17:58:05] I guess I could checkout a few commits back and branch from there. But what an annoying effort just because other people don't have time or don't look at pending PRs all that often, without me having to scream into the world "I made a PR!" [17:58:54] To be fair, with this review system you automatically start thinking "I should actually review, not just rubber stamp" [18:02:12] and that's always a time investment [18:08:18] > You’re not authorized to merge this pull request. [18:08:26] unfortunately I'm not authorized to help lol [18:09:55] because I didn't add you as a review I guess [18:10:02] which I have now done [18:10:20] reviewer* [18:10:33] nope, still not authorized [18:11:28] oh to merge [18:11:35] you would need to do a review [18:11:46] go to files changed [18:11:54] green review changes button [18:11:58] and I can then merge it [18:12:06] oh wait [18:12:09] I think only Thymo and I can actually do the merging [18:12:17] yeah I'm used to gitlab [18:12:51] the best person to review would actually be Turry, but I don't think he wants to go back 24 hours of mission :D [18:13:25] hahahaha [18:13:33] okay I tried [18:13:46] yeah I could merge it now [18:14:23] I guess you didn't run this update in NASSP so let me have one last look if it's actually good :D [18:14:28] but I did test it [18:15:28] I'm already seeing something I want to change, but not in this PR haha [18:15:42] merged it. Thanks for the help! [18:25:04] hooray for defeating the system lol [18:27:20] haha [18:28:18] better than changing the settings on Github without talking it over with Thymo... [19:18:51] hey guys [19:19:21] sorry I haven't been as active. still pretty busy [19:24:07] ah no problem [19:24:32] the one PR is merged, and the other is pretty independent from any other RTCC work. I'll leave that up until you could have a look. [19:24:39] the gravity model one [19:44:36] okay [20:39:17] your PR might fix part of my multithreading issue. will have to test. [20:41:56] haha nice [21:04:38] night! [13:59:56] good morning [14:01:31] hey [14:21:31] n7275, did you ever look much into how data was stored for MOCR displays? [14:22:01] not talking about dynamic displays, but rather some RTCC calculations leading to a static set of numbers being displayed [14:22:59] often there is one function doing all the actual calculations [14:23:07] and then another one converting to display units [14:23:22] but where does that data go then and in what format is it stored for display... [14:26:40] good question [14:27:33] I'm kind of tired to add 100s of structs to the RTCC for each display [14:28:03] I know a lot of "glass terminals" at the time stored their data in acoustic delay lines [14:28:16] so no actual buffered memory [14:28:32] hmm [14:28:44] but you could look at these displays on several screens [14:28:49] it worked like TV channels [14:29:02] maybe there was a data buffer for each channel [14:29:15] probably preformatted as text... maybe [14:29:43] so maybe what I should do is add an array of strings for each display [14:30:06] which is normally empty (not bloating the RTCC object), but gets filled once the calculation was done [14:31:44] previously I have often done the conversion to display units in the MFD function itself, so every time the MFD display refreshes it would run that code [14:32:28] in the few display formats we have examples of, display formats appear to be defined on a character grid. I believe that plots were done with analogue video composition [14:34:34] yeah [14:34:45] and for telemetry display you specifiy the telemetry ID [14:34:58] telemetry measurement number [14:36:50] I have looked through the RTCC mfd code before. that looks like a lot of work to impliment a new one [14:38:08] yeah, quite tedious for just one display [14:38:22] even more if there are a bunch of buttons that need to be used [14:39:12] that's why I was thinking, I finally need a more general system, at least for the actual MOCR displays [14:39:21] not so much for the pages with input data [14:39:53] sounds like we need an RTCC++ API [14:41:18] display formatting language [14:41:22] whatever that was :D [14:53:29] it's really two separate questions [14:53:37] how I want to handle the background "slide" vs the actual data [14:57:37] https://ntrs.nasa.gov/api/citations/19730010501/downloads/19730010501.pdf#page=16 [14:58:17] well aparently the formats for both were on two seperate tapes in real life, so seperating them sort of makes sense [14:59:25] we need this DRAFT program... [14:59:53] yeah, this data was used to generate the background slide [15:00:24] which was all analog then, so very different from the digital data of telemetry and such [15:06:20] I have a suspicion that the format language is very similar to some other IBM or Philco thing of the era and NASA just had their own name for it...not that I've had any luck finding alternatives, though [16:27:57] morning! [17:31:04] hey Mike [17:31:14] hey hey [18:05:53] hey [18:07:30] feeling very motivated to wrap up the rope reader design this weekend. if I pull it off, we're probably ~1 month away from reading some ropes [18:11:14] nice! [18:14:04] fantastic [18:14:44] assuming I don't fuck it up :D [18:15:50] failure is not an option [18:22:11] in the long term, no [18:22:25] in the short term, it's an undesirable and expensive possibility that I'm going to do my best to avoid lol [18:22:56] mostly worried about getting all of the connector pin mappings correct throughout all of their turns [18:24:29] then I'll use an actual Apollo 13 quote: "Let's solve the problem but let's not make it any worse by guessing." [18:24:32] :D [18:32:44] indy91, just pulled your gravity model branch [18:33:58] there's no guessing, just a lot of careful thought when thinking about how connectors get mirrored in 3D [18:34:01] ah nice [18:34:39] thewonderidiot, was just listening to Apollo 13 audio and apparently when the accident happened the CMC clock had a 3.5-4 centisecond jump [18:34:42] that hits a nerve... [18:34:53] could that be caused by the voltage drop or anything? [18:34:54] hahahaha [18:35:32] depending on the severity of the voltage drop, sure [18:35:41] the computer can't keep track of time when it's "off" [18:35:58] GUIDO said it was fast [18:36:42] maybe the sudden voltage change messing with the clock, I guess it depends on how the power supply handles it [18:36:48] either STRT1 or STRT2 were probably triggered [18:37:03] power supply failure and oscillator failure, respectively [18:37:26] GUIDO asked RETRO to look at it while he is checking the restart. Was listening to the RETRO audio for some note taking. [18:37:27] but those both have some hysteresis -- mostly for the bootup scenario (everything has to be stable for X milliseconds before we let the computer actually start running) [18:39:08] looking at the mission report [18:39:25] I think I just found the actually worst anomaly on Apollo 13 [18:39:37] "Improper Nasal Spray Operation" [18:39:51] oh shit [18:40:11] "On previous flights, there had been a tendency for the spray to be re [18:40:12] leased too fast, therefore a piece of cotton was inserted in the 9-cc [18:40:13] bottle to hold the 3 cc of medication. " [18:40:14] can't make it up [18:40:55] SURGEON didn't have enough to do on the Apollo 13 review board I guess [18:41:28] https://i.imgur.com/jMUKAPi.png [18:42:05] lol [18:42:13] it's an assembly, must have been in the LM [18:42:21] hehehehe [18:42:40] Where did you find that so quick? [18:42:57] you triggered a memory [18:43:17] back when we didn't know what all was in NARA's apollo drawings collection, I spent a lot of time googling trying to figure it out [18:43:35] https://facebook.com/nationalarchivesfortworth/photos/archives-and-allergies-whether-you-are-residing-in-one-of-the-highest-ragweed-ar/2074360405918430/ [18:43:48] they made a post about digitizing them, with this drawing as an example [18:45:42] nice, where is the rest :D [18:45:59] nowhere to be seen haha [18:49:42] had to go back and spend a year writing guidelines for researchers, no time to do scanning for the public [20:08:21] Hey hey [20:09:15] Guess who gets to attend the graduation ceremony in two weeks? [20:18:54] yay! congratulations [20:18:58] congrats, very nice :D [20:26:05] It was fun but I'm glad to finally be finished. [20:55:47] wooo! [21:23:41] night! [12:56:15] hey Niklas [12:59:17] does Orbiter's default moon only have spherical gravity? I think I just noticed this. [13:07:32] yeah I think so [13:40:29] from what I can see with my Apollo 10 scenerios, I think we're good to merge your update. the tesseral stuff will need a bunch of testing when I get my branch merged with Orbiter [13:53:08] oh yeah, obviously a change like that to Orbiter itself needs a lot more scrutiny [13:54:40] I let it print a big debug block with data from 1 day of coasting integration of all 3 integrators I am currently using [13:54:58] And I like it, so I think it works right [13:58:38] Hey! [13:58:46] n7275 Good morning! [13:59:23] I maybe use for the first time the lights on the Rendezvous of Apollo 9, wich I will hopefully do tomorrow [13:59:30] *practise, not do [13:59:31] :D [13:59:51] I will record the run [19:56:46] hello. I'm back. [20:24:21] hello back! [20:34:04] haha [20:36:17] my wife and I spent a few days up in northern Maine. I expected a little bit of cell service, but there wasn't even a bit [20:38:51] https://photos.app.goo.gl/qCQr8P6qsNKSHk6c7 [20:39:06] Earth is still turning as you may have noticed. No additional global crisis as far as I can tell :D [20:39:32] gorgeous [20:41:28] yeah I think this is a picture that you couldn't take anywhere in Germany haha [20:42:36] at least not with the forest + lake + elevation like that [20:43:54] the lake is 1400 feet above sea level [20:44:17] https://en.m.wikipedia.org/wiki/Mooselookmeguntic_Lake [20:45:02] we don't have names like that either [20:46:31] I think "lake" is the only part of that name with any European origin, haha [20:46:40] so the word moose is of indigenous American origin, didn't know that [20:49:52] yes, it comes from Algonquin apparently. [20:51:18] "Elk" would be the more generic term, except that in North American English we use that word for something completely different [20:52:08] Elch for me [20:53:11] not that we have any [20:54:05] ah but you are right, that is a different species [20:57:39] our PRs got merged. I don't expect that PR with the fix for the clock drift to need too much testing [20:57:49] scenarios load and don't look broken with it [20:57:51] so it works lol [21:02:41] that's always a good sign [21:03:27] it must have been some restrictions in Orbiter 2006, maybe still 2010 that caused bad things on the first timestep [21:04:22] too bad we don't have the Orbiter code for those. [21:04:56] still need to test a bit more how our accelerometers like it [21:05:07] maybe they get bad data on the first timestep [21:05:12] or it's actually the opposite [21:05:22] now that they run on the first timestep there is no e.g. jump in the EMS [21:09:26] ok, bedtime. Good night! [16:29:10] morning! [16:37:51] hey Mike [16:40:01] what's up? [16:40:18] maintaining mission scenarios is no fun haha [16:40:37] you either get to do a lot of text editing or have to fly full missions again [16:41:44] hah yeah [16:41:52] no real good way around that [16:43:11] well, only support the T-4h scenarios :D [16:43:33] But I guess it makes sense that people at least want to try the "10 minutes before PDI" scenario [15:55:51] hey [15:57:21] hey Matt [17:01:59] morning! [18:10:53] hey [18:19:57] what's up? [18:27:56] seems like that fix for the AGC clock drift has no side effects as far as I can see [18:28:09] Hello! [18:28:17] hey Thymo [18:28:28] the issue was just that on the first timestep after loading Orbiter none of the systems were updated [18:28:43] because of some (hopefully long gone) Orbiter restriction [18:29:01] and the first (actually first three) timesteps in Orbiter are 0.01 seconds long [18:29:02] I saw your PR yesterday. Let me take a look at Orbiter to see when the first timestep is started. [18:29:26] so every time you load Orbiter the AGCs (and any other timekeeping thing) lost 0.01 seconds [18:29:53] someone like MrResiduals on Discord seems to reload a lot more times than the usual NASSP user, he lost more than a second [18:30:52] I need to understand the Orbiter code for all that a bit better [18:30:56] Yeah, he does that a lot instead of just rectifying something. Don't know where he gets the time to redo so much stuff over and over. [18:31:42] actually, when I was reading through the Orbiter code I got the impression that, if anything, Orbiter might slightly drift from real time [18:32:26] As long as the drift is consistent through Orbiter that is not a terribly big problem [18:32:33] yeah [18:32:51] What I was looking at was simulated MJD versus the simdt variable that Orbiter supplies to the timestep functions [18:33:06] and those actually seem consistent [18:33:32] What Daniel and I long had suspected was, the simdt was only an estimate, so any desync in timing could come from that [18:34:00] but I don't think that is the case. Still, need to understand that Orbiter code better. [18:34:11] But that's when I thought "if this doesn't cause the drift, what does..." [18:35:19] in Orbiter 2016 the clbkPreStep function changed, it's possible that this theory was still true in Orbiter 2010 [18:36:07] or, I think PostStep was what mostly changed when it is done in any update cycle [18:36:40] 000000.010: simt 0.010000 simdt 0.010000 mjd 40419.668162 [18:36:41] 000000.020: simt 0.020000 simdt 0.010000 mjd 40419.668162 [18:36:42] 000000.030: simt 0.030000 simdt 0.044927 mjd 40419.668162 [18:36:43] 000000.075: simt 0.074927 simdt 0.051731 mjd 40419.668163 [18:36:49] this is how it starts up for me [18:37:36] interesting that even in the first PreStep call simt is already 0.01 and not 0 [18:38:14] ah no it isn't [18:38:20] it's further up in the log of course [18:38:21] 000000.000: simt 0.000000 simdt 0.010000 mjd 40419.668162 [18:38:47] It makes sense though. If simt is 0 you would have a 0 length timestep, that may cause issues for modules assuming that time isn't stationary. [18:38:55] huh [18:49:52] I assume ggalfi is still working on that PR? [18:52:13] for the VC viewpoint bug? Yeah the latest I heard was that he wanted to spend some time on accelerometers in general [18:53:01] Gotcha [19:00:14] What are your thoughts on the subsystem failures PR that is still open? I commented that if we want to add the feature it should be done more like a extendable framework so we can easily add more systems when support for them is ready. [19:15:27] yeah I agree. The PR itself is ok, but a more wholistic approach would be better [19:57:52] anything I can do to help mine along. the one from November. [20:28:10] Are there any blockers beside my version check feature? I'll reduce the scope to just the notification that I already demonstrated. I've been having less time than I'd like to work on NASSP lately. [20:47:23] version check is the only thing. I also haven't had much time to work on NASSP, so I understand. I wasn't trying to bug you too much. [20:59:40] I don't mind if you bug me every now and then if you need something from me. I'll get on my "things people are actively bugging me about" list instead of the "Do this whenever I finish the things people are bugging me about" list. :P [21:05:22] :) [16:10:56] hey Nik [16:27:07] hey hey [16:36:25] hmm, that's strange. Your PR from November has some code that was part of my CM aero update [16:37:22] otherwise it's actually a pretty harmless change, of course with old scenarios affected [17:05:19] oh that's odd. [19:54:58] those scenarios are probably very out of date now. hopefully git knows what it's doing or I'm going to have to run my script on all of them again [19:58:10] nah I don't think there were many complete changes of those scenarios [16:42:12] hey [18:34:09] hey Matt [18:15:47] we really need to have some bad weather here so I can justify sitting inside in front of my computer a little better. [18:22:25] hahaha [19:00:12] thewonderidiot, that's an interesting collection of documents that Ron recently uploaded, about the IMCC [19:01:00] oh yes! I meant to ask you about those [19:01:05] anything good? [19:02:18] hmm, not really. All very early and unspecific. Of course I haven't read every page of every document yet. [19:03:17] yeah you usually complain about 1965-1966, which is like my sweet spot for AGC [19:03:22] and this all looked like 62-63 :P [19:03:37] 65-66 might be decent for Gemini [19:04:05] but there are definitely good sources of this type, from Philco etc. [19:07:32] so annoying that PHO-TR170A from UHCL only had changes. The original, full document would have had so many display formats