[09:50:31] NASSP Logging has been started by thymo_ [12:36:48] morning [12:37:51] hey [13:17:36] I've reached the second sleep period of Apollo 9, soon I can continue the work on the MCC. I've gotten to this point the last time already. [13:17:49] then without a LM ECS [13:18:43] nice [13:21:41] and I'm looking at the SCS logic buses a bit [13:22:08] there actually needs an ullage signal to be present, or else the Thrust On button doesn't start the SPS [13:22:20] either from the Direct Ullage button or +X with the THC [13:22:27] a little bit like the AGS I guess [13:23:31] oh really? [13:24:29] doesn't work for us like that yet [13:25:25] how was TD&E with the new docking target? [13:25:50] a bit more challening, but not too bad [13:26:01] you can still easily see where the docking target is from a distance [13:26:12] just not the exact alignment of it [13:26:35] but that becomes visible when you are closer [13:28:14] yeah [13:56:14] just tested the PDI+X fix, its good [13:56:56] at 1st I was like, wait its not fixed... Then I realized I hadn't calculated the PDI pad itself lol [14:26:15] haha, yeah, that is still required [15:34:27] wow [15:34:39] just find the Apollo 7 SCOT on the archived NTRS [15:34:42] found* [15:34:56] even in a section I had previously searched through [15:35:10] it's the same date as the one I requested from UHCL a while ago [15:39:05] great [15:39:13] wonder if theyre adding more docs to it [15:39:52] nah, this is an old document [15:39:59] among those removed from NTRS in 2013 [15:40:05] right [15:40:18] there are two main archives that have saved NTRS data [15:40:44] archive.org and archive-it.org [15:41:00] and sometimes it just fails to find a document [15:41:12] that is usually fixed by adjusting the date you are searching for [15:41:23] I usually use 2010 and if that doesn't work I try a date in 2011 [15:41:36] so I guess this was one of those random times when it didn't find the document [15:41:39] just bad luck [16:07:39] also, someone uploaded LM-4, LTA-8 and S-IVB blueprints [16:07:41] https://archive.org/details/Apollo_blueprint_archive [16:21:02] nice [16:40:58] back later [16:46:26] morning! [16:47:07] hooooly cow that is a treasure trove of drawing numbers [16:49:04] hey [16:49:09] yeah [16:49:33] for us it's especially useful as a reference for certain dimensions I guess [16:49:59] yep [16:50:27] but yeah as with the level three diagrams, pretty much every drawing referenced here is probably at NARA, and can be requested if you need more detail on a part [16:50:53] great [16:50:57] .logging [16:51:04] hmm [16:51:09] it wasn't on earlier [16:51:30] Thymo started it ~7 hours ago [16:51:36] yeah, looks like it [16:52:21] also you had me extremely excited when I saw an archive.org link and the word "uploaded", thinking that one of the new manuals was up [16:52:23] :P [16:53:19] haha [16:53:21] patience [16:53:53] as I said earlier, I found the Apollo 7 SCOT Volume I - Mission Profile on the archived NTRS earlier [16:54:00] among documents I had already searched [16:54:17] so that is 160 pages that UHCL didn't really needed to scan :D [16:54:35] haha [16:54:41] nice [16:55:06] when I searched through NTRS in 2016 and 2017 I never properly wrote down which sections I had already searched [16:55:17] I am doing that now and am careful to not overlook anything [16:55:26] and I won't ever search those sections again then [16:55:31] excellent [16:56:22] I want to have that full collection of MPAD documents, haha [16:56:49] not going to be possible without NARA [16:57:58] which is weird in a way [16:58:07] NTRS had sooo many of these documents [16:58:21] I really wonder if they didn't have them all and we just haven't found them yet [16:58:43] main reason why I keep on searching [16:58:54] to make a possible NARA trip not quite so lengthy [17:00:30] I fully support all such efforts :P [17:00:37] haha [17:00:52] I'm not finding much useful stuff for you. And rarely for me as well [17:01:06] the old script is kind of working [17:01:14] it doesn't download working PDFs [17:01:18] and they are all really small [17:01:34] but at least I know which NTRS ID is valid and I can manually access it then [17:01:55] they're HTML pages -- one of the archive websites changed how they display PDFs, to have a toolbar overlaying it [17:02:03] ah [17:02:07] I fixed the script a while back to break through the toolbar and actually download the PDF [17:02:14] I can get that to you tomorrow, if you'd like [17:02:19] sure [17:02:36] although I kind of like that it doesn't download random 300MB files I don't need [17:02:42] hehehe [17:02:53] that is fair [17:04:42] also I hope you guys didn't have anything in with UHCL -- I requested 5 new (small) documents last night [17:05:33] all from right around the time this AGC would have been made... and all probably relevant as to its functionality [17:05:43] BLOCK II COMPUTER DESIGN DEFICIENCY [17:05:47] AGC ( APOLLO GUIDANCE COMPUTER ) PROBLEM COMPUTER RANDOM FAILURES [17:05:54] GENERAL LOW QUALITY LEVEL IN BLOCK II AND LM ( LUNAR MODULE ) COMPUTERS AND DSKY'S ( DISPLAYS AND KEYBOARDS ) [17:05:59] fun memos like that :P [17:06:55] yeah, they sound related [17:07:12] I haven't anything in the works at UHCL [17:08:43] also I found some interesting rework on the AGC this morning [17:09:27] https://imgur.com/a/r4eL6pC [17:09:45] there's three wires that have been added to the Tray B backplane in thick loose yellow sleeves [17:10:08] connecting the three CLEAR ROPE signals to the rope modules directly to filtered +14V rails [17:10:26] which, if they were actually just wires, would short out the clear circuits and make them nonfunctional [17:10:33] hmm [17:10:49] why would that have been done? [17:11:03] but according to ND-1021042, there's supposed to be a resistor and diode in parallel with the rope modules, between the clear rope signals and +14V [17:11:10] CKT 40524 in the second image [17:11:30] what does "clear rope" mean? [17:11:32] and the rope driver modules don't have anything attached to pins 131 and 135, where that circuit is supposed to be [17:11:48] so I think they've patched a resistor and diode across the backplane to fix a problem with rope memory [17:12:05] "clear rope" happens during an aborted rope read cycle [17:12:34] ah [17:12:45] basically "bad rope" [17:12:46] certain things can cause a read cycle to be aborted... including, I think, the DV instruction [17:13:00] it's necessary to get the cores back into the proper state before the next read cycle, or you'll get corrupted data [17:13:29] I think [17:14:07] corrupted data in the rope memory? [17:14:23] I thought that was only a thing with the erasable memory [17:16:18] well, normally only a single core in fixed memory is supposed to be switched, on a read [17:16:31] and all sixteen sense lines either thread through it or not, for the 1s and 0s of a word [17:17:00] right [17:17:10] so if you start a read cycle by setting one of the fixed cores [17:17:15] and then abort the read [17:17:26] and then start another read cycle by setting a different core [17:17:33] uhh [17:17:36] you get bad reads [17:17:36] then reset the ropes and look at the sense lines [17:17:46] you get data from two cores overlayed on top of each other [17:17:58] so the abort needs to reset the cores to make sure none of them are set [17:18:05] makes sense [17:18:37] so basically the same procedure you would need with the magnetic cores, minus the destructive read [17:18:43] yep [17:19:00] GOJAM also causes a clear rope, so you know when you start that all of the cores are ready [17:19:30] also! there is a paragraph in ND-1021042 that explains this resistor and diode that have been patched across the backplane :D [17:19:43] oh great [17:20:40] "The clear lines in the fixed memory module run parallel to the set and inhibit lines. Mutual coupling could occur and cause a voltage to be induced on the clear lines when the selection lines are switched. To eliminate this possibility, a series resistor and diode are placed across each clear line in fixed memory. The polarity of the diode causes the induced voltage to be dissipated in the resistor, eliminating any coupling." [17:21:17] so basically, due to the way rope memory was woven, they were having trouble with things becoming cleared when they shouldn't [17:21:26] and this diode+resistor was the fix [17:23:58] and in "your" AGC? [17:24:42] those yellow sleeves must be hiding that resistor and diode inside, because they hadn't yet been added to the rope driver modules themselves [17:25:06] AGC C1 and later would have had those in the modules instead of patched across the backplane [17:25:21] so basically the temporary fix version of what was properly fixed in later AGCs [17:25:28] yep [17:25:48] the weird thing is that the compatibility chart suggests that this AGC shouldn't have gotten the fix [17:26:08] there's two ECPs related to the clear rope circuits, 402 and 404, and neither should have been applied to a 2003100-017 AGC [17:26:10] from when is that chart? [17:26:20] like '72 [17:26:32] hmm [17:26:37] and this was a Raytheon AGC? [17:26:43] unclear [17:27:04] I'm really, really hoping now that the new copy of ND-1021042 is revision G or earlier, because revision H is what incorporated all of the changes to C1 [17:27:07] I would bet on that chart being outdated for this AGC [17:27:21] well I wouldn't necessarily say that [17:27:28] or whoever had this one never told the people who made the chart [17:27:43] there is a whole branch of the tree dedicated to this part number [17:28:49] https://ia800609.us.archive.org/BookReader/BookReaderImages.php?zip=/1/items/acelectroniclmma00acel/acelectroniclmma00acel_jp2.zip&file=acelectroniclmma00acel_jp2/acelectroniclmma00acel_0199.jp2&scale=1&rotate=90 [17:29:03] this is part number 2003100-071 [17:29:59] it has a test connector cover, which is ECP 474, and it has thermistors in its erasable driver modules not shown in ND-1021042 that I assume are part of ECP 301 [17:30:48] looks like they would have kept track of this modification [17:31:04] yeah [17:31:11] so I'm curious if this is 402 or 440 [17:31:17] I really wish we had better descriptions for ECPs [17:31:45] I mean then again [17:32:06] I'm like 99% sure this AGC has multilayer boards in its logic modules, which was ECP 254 [17:32:13] and that's only listed for C1 and later [17:41:03] ugh I wish I knew what the revision of the ND-1021042 is [17:41:24] I'm hoping that the ND-1021041 being all original revision means that ND-1021042 will be similarly early [17:43:31] possible [20:19:11] night! [20:30:45] thewonderidiot: Are you around? [20:31:00] yup [20:31:56] Thymo: what's up? [20:32:23] I'm trying to wire yaAGC into my own project but I'm not quite sure I've got everything right. In yaAGC.h UnblockSocket is declared but never implemented. Should I do that myself? [20:33:20] If I don't do anything with it it fails to build. I added some braces to it so it'll do nothing but that's probably not the right solution. [20:33:41] looks like that's in agc_utilities.c [20:33:47] how does nassp handle that file? [20:35:17] https://github.com/dseagrav/NASSP/blob/master/Orbitersdk/samples/ProjectApollo/src_sys/yaAGC/agc_utilities.c [20:35:52] That doesn't have UnblockSocket though. [20:36:24] But I haven't included agc_utilities.c either. [20:38:53] Looks like NASSP also doesn't implement it. [20:39:50] Ah, it doesn't need to. [20:40:14] In NASSP WIN32 is defined (obviously) so that call is never executed. [20:41:03] The associated comment talks about making getchar not halting the program. I don't plan on using the CLI so I should be fine leaving that as is right? [20:41:24] uh [20:41:38] yeah should be fine [20:41:51] most of this stuff probably doesn't really matter [20:44:35] Okay, so I've made my call to agc_engine_init. Assuming that completes successfully all I need to do is call agc_engine every 11.7 microseconds right? [20:47:01] yep [20:47:12] and provide your own implementation of the I/O functions in SocketAPI.c [20:47:16] to get data in and out [20:48:27] Is there an easy way to verify the AGC is executing without yet fully implementing the I/O functions? [20:49:20] just watch the program counter I guess [21:09:36] Looks like it's working. Log is being absolutely spammed with cyclecount increments. [21:11:41] :D [21:14:54] Probably not the most beautiful solution. I just started an infinite loop in a new thread that calls agc_engine, logs the cyclecounter and does a usleep(11.7); [21:15:52] Next challenge: Getting my peripheral to talk to the AGC. [21:17:34] After that, clean a lot of stuff up. Boy have I hacked this stuff together to get the AGC to run. [21:19:13] yeah, you're going to be a bit slow with that. that assumes agc_engine() takes no time at all [21:20:42] It's probably a good first guess. The logging is quite expensive too. I'd probably have to profile in order to get the right value. [21:42:28] or do it like NASSP and yaAGC do it, batching it so the right number of cycles run in roughly the right amount of time [21:43:08] there is no right value to use in a usleep() between cycles because the amount of time agc_engine() actually takes will be very variable [22:49:05] thewonderidiot: Alright. This is what I've been silently working on the past few weeks. It's not done yet, take a peek: https://github.com/Thymo-/AndroidAGC [22:52:21] Thymo: nice! [22:53:43] So far I can control the DSKY elements from Java by directly turning them on and off. Eventually this will need to be done by the AGC through some channel decoding stuff. [22:54:22] For now it just runs a little test (DSKYTest class) that walks every element and cycles it on/off. [22:55:05] I borrowed all the graphics from yaDSKY for now until I draw them programmatically. [22:55:39] that's awesome :D [22:58:11] I've been wanting to build something like this pretty much since I started to learn more about VirtualAGC a couple years back. Only a couple of months back I've learned enough at college to actually make an effort to build it. [22:59:45] For now I've hardcoded Aurora12 into it but I plan on making it user selectable in the future. [23:00:00] very cool! [23:00:05] also great choice of program :D [23:05:41] Well what rope would be more fitting for some experimental platform than a rope that still has all the tests? :) [23:07:33] Newspeak and/or Lamesh [23:07:36] but we don't have those :P [23:08:21] Duh :p [23:08:54] Also as it stands the way the rope gets loaded is super hacky. [23:11:00] Because you can't easily access embedded application resources from JNI context I extract the binary on startup by opening the packaged file and the new file as two streams and copy it over. :P [23:11:06] https://github.com/Thymo-/AndroidAGC/blob/master/app/src/main/java/nl/thymo/androidagc/AGCController.java#L86 [23:12:38] And in my implementation of rfopen I just pray the binary is in the hardcoded location and return it to yaAGC. [23:13:03] Bad things happen if you don't give the app storage permission. [23:23:24] lol [23:24:20] so is the plan to be able to select the rope from some sort of menu? [23:25:49] Yeah, ropes will go into the AndroidAGC directory on the device's internal storage and from there all that would be required is to tell agc_engine_init what file to look for. [23:26:08] That would also allow for user provided ropes. [23:26:26] nice [23:26:29] But we'll need AndroidYUL or something like that for that to happen. :P [23:26:44] or just a clever enough user [23:27:12] I think anybody that has a custom rope that they want to load in can probably figure out where to put the file [23:29:28] There's lots of possibilities with this. I can think of yaAGC running on one computer and the app connecting to it over the network. [23:29:57] Maybe even plug in the phones accelerometer for orientation and the like. [23:30:11] Camera as a sextant. :P [23:34:40] If you've got an Android phone you can try take a peek at the interface already. I need people to test it to see if the interface is any good. [23:34:49] https://vanbeersweb.nl/share/AndroidAGC.apk [23:39:34] welp [23:39:41] I can briefly see the interface [23:39:45] but then it crashes :P [23:44:39] it didn't ask me for any permissions or anything [23:45:40] It's not asking me for permissions on startup either. I'm not sure why, can you enable them manually? [23:46:20] What version on Android are you on btw? I built it for Lollipop and up. [23:48:15] oh man I don't even know [23:48:19] my phone is getting old [23:49:02] What phone do you have? [23:49:06] marshmallow, apparently [23:49:08] galaxy note 4 [23:49:32] Marshmallow should be able to run it. [23:50:10] fwiw my phone crashes and reboots all the time [23:50:26] I really need to do a factory reset and switch to a new phone if that doesn't work [23:50:56] giving it storage permissions didn't change the crashiness [23:55:31] Hmm, weird. I can't be of much help without taking a look at your logs. Thing is that those a not so easy to capture. We can try it sometime. For now I'm off to bed, gotta be well rested for my birthday. :) [23:56:40] goodnight, and happy birthday! [23:56:53] Thanks! [08:16:40] .tell thewonderidiot If you've got the time. Could you try capturing a logcat for me when you run the app? https://android.stackexchange.com/questions/33216/how-can-i-get-a-logcat [12:20:28] hi indy [12:47:36] morning [12:51:52] Hey all [12:51:57] hey [14:05:00] working on some new RTCC stuff I need to add for Apollo 9 [14:05:10] Thymo, did I read the IRC log right that today is your birthday? Or was it yesterday? [14:52:19] indy91, nice [14:52:42] more orbital maneuvers functionality? [14:52:44] yep [14:53:31] I believe that almost all those out-of-plane maneuvers of Apollo 9 were calculated to only rotate the longitude of the ascending node, not change the inclination [14:53:42] which happens close to the maximum latitude [14:55:38] in the general maneuver processor that would be the option "optimum node shift maneuver" [14:57:54] morning! [14:59:08] it's been a while since I've seen you guys talk about this stuff, so it might not be useful anymore [14:59:13] https://cds.cern.ch/record/1338950/files/978-0-387-37624-0_BookBackMatter.pdf [14:59:34] but this document has dry and wet stage masses for 7-17 on page 37 [15:01:07] hey Mike [15:01:16] that document uses the Saturn Flight Evaluation Reports as its source [15:01:23] which is also the source we are usually using [15:01:33] yeah, just wasn't sure if we were missing any [15:01:42] I don't think we do [15:04:21] we even have lots of S-IVB specific flight evaluation reports [15:04:44] and some for S-IB [15:06:32] nice [15:07:04] also I'm narrowing in on where this AGC was used -- it is almost certainly 602, and it turns out that 601 was used in LTA-1 for early systems tests [15:08:29] LTA-1, wow [15:09:24] which still has a round hatch :D [15:09:45] hehehe [15:09:52] the AGC does not care about your hatch shapes :D [15:38:14] hmmm [15:38:22] AGC serial number 10 was in LM-2 [15:51:40] later! [16:24:40] indy91: My birthday is today, yes. :) [16:28:33] Then Happy Birthday! [16:30:27] Thanks. 18 years old, quite a special occasion. We're about to head out for dinner [16:30:35] So I'll be back in a couple of hours. :P [16:30:50] have fun [17:02:37] indy91: it is Tuesday :D [17:02:43] it today the Tuesday? [17:04:32] hmm [17:04:34] maybe [17:17:09] wooo [17:17:34] also some more impatient ramblings [17:17:48] I still have no idea about ND-1021042, which is killing me [17:18:10] but I did figure out that the new copy of ND-1021043 is either the original revision, A, or B [17:18:39] because I have a picture of one of the pages that was changed in Rev C, and it has no revision mark [17:18:48] so that is really promising [17:18:58] I really really want ND-1021042 to be rev E or earlier [17:20:58] it turns out there were some pretty serious changes to modules B16/B17 between AGC versions [17:21:04] far more significant than any other modules [17:31:13] I've always imagined the AGC as a fixed design by the time they flew into space. I guess that is still true though. [17:32:10] yeah it definitely was [17:32:17] and from a software point of view nothing changed [17:53:18] also Lauren got back to me with those documents, if you want to read about early Block II problems :D [17:53:18] https://www.dropbox.com/sh/7zoebljz7trvm81/AABhsdFhNnpdp-om0Qwwt3JGa?dl=0 [17:56:41] huh, one of them has procedures for running self-tests on Block I AGCs [17:59:58] I need to try that with Solarium later [18:59:00] I'm back! [19:34:38] welcome back [19:38:50] heya [19:39:29] I don't know if it was actually your birthday when I said it last night, so happy birthday! [19:39:46] Thanks again! [19:40:04] It just was, by like half an hour. [19:49:12] I'll try to get you logs sometime tonight [19:58:26] Thanks [20:49:37] night! [21:00:36] uuuuuuuuuuuuuuuuuuuuuuuuuugh waiting for these scans is killing me [21:04:07] Hehe, can imagine. [21:15:35] I would be so much happier if I knew which revision of ND-1021042 we are getting [21:17:36] never before have I wanted somebody to not be on the ball with updates so badly [01:03:20] Great. I just fell asleep for 4 hours. Suppose I'm a little tired. :p [01:03:21] .t [11:50:28] hey [11:51:06] morning [11:51:15] whats up? [11:51:53] found a document in my collection for a LM descent simulator [11:52:06] for mission analysis at MSC [11:52:24] and it has a lot of equations for LR geometry [11:52:33] so I can check and maybe find an issue with our LR [11:53:01] and it also has calculations for DPS nozzle throat erosion [11:53:04] ah nice [12:26:01] I guess its figuring out how much to increase the thrust throughout the burn [12:28:32] it has equations for that as well [12:34:19] the only issues are that the calculations are more complicated than necessary for us and partially it's not easy to decipher the equations [12:41:40] Hi [12:44:35] hey [12:46:08] hey [12:46:31] any clues for the LR equations yet? [12:47:04] not yet [12:51:07] Good morning [12:52:59] Thymo, how old is the scn? There were a few changes to the tank itself done that are probably saved in the scn file itself. I could give you parameters to put in place of the old ones in the scn that would work [12:53:22] .tell Thymo, how old is the scn? There were a few changes to the tank itself done that are probably saved in the scn file itself. I could give you parameters to put in place of the old ones in the scn that would work [12:58:18] hey Ryan [12:59:44] Morning [13:04:58] hey [13:09:39] Hows it going? [13:11:33] working on Apollo 9 MCC [13:11:38] slow progress, haha [13:11:44] I bet! [13:11:58] A little more involved than 10? [13:12:37] for 10 I was able to recycle stuff I had already implemented for 8 [13:12:45] but 9 needs a bunch of new things [13:13:05] Apollo 11 on the other hand will be easy then [13:14:14] Let me know if you find more checklist issues :) [13:14:32] 9 is probably the most hybridized with the software differences [13:14:52] yeah [13:36:25] I am resuming 10 now with the MCC [13:36:37] I did find one potential discrepancy [13:36:59] The 1h40m pad with a SV update, the MCC says CSM & LM but the FP calls for CSM SV and a V66 [13:37:37] right [13:37:41] I'll fix that [13:37:45] the V66 is done in other places [13:38:09] Also, the evasive pad does not have a LM weight [13:38:29] I assume that is because when it is calculated, it is still not created? [13:38:53] should the evasive PAD have a LM weight? [13:39:28] doesn't look like it in the transcript [13:39:37] so the padloaded LM weight is used [13:39:40] Because it is so small? [13:39:44] Ok [13:39:52] is the padloaded LM weight off? [13:39:56] that would need to be fixed [13:40:40] Actually both are I think [13:40:50] easy fix [13:40:51] Let me check [13:42:01] Weights are 63634 and 33528 in the cmc [13:43:38] LM weight should be 33863 [13:43:59] significant enough to change it [13:44:42] And csm is 65396 right after LV sep [13:45:38] ah, you added custom CSM weights as well [13:45:58] Yeah way back when i did the saturn masses [13:46:18] yep [13:46:30] I'll fix it in the padload worksheet and the launch scenarios [13:46:36] Awesome [13:49:25] are you sure about that LM weight? [13:50:03] isn't LM-4 lighter? [13:51:25] is the 33863 from your scenario? [13:53:29] Yeah [13:53:41] Its what the RTCC calculated in a maneuver pad [13:54:16] I will verify the masses though [13:54:36] pretty sure that's wrong [13:54:44] did you recently use the T-4h scenario? [13:54:58] Yes [13:55:02] hmm [13:55:22] I think thats the default mass for some reason that number is famillar [13:55:24] because there was this thing with the LM masses having the wrong variable name in the scenario [13:56:17] Yeah I remember that [13:56:23] but it's certainly fixed [13:56:35] it has the right masses in my Apollo 9 scenario [13:56:56] LMDSCFUEL 8263.863311 [13:56:56] LMASCFUEL 1193.401525 [13:56:57] LMDSCEMPTY 2133.244916 [13:56:57] LMASCEMPTY 2446.223651 [13:57:36] that's in the launch scenario [13:57:40] Yes [13:57:43] is it in your current scenario with the LM? [13:58:31] just wondering what your guys frame rates are at? [13:58:41] Yeah its in my saved file [13:59:00] same numbers? [13:59:15] Yes [13:59:18] hmm, ok [13:59:20] Pre lm ejection [13:59:35] astronauthen_96 I get about 45 in the csm and 60 external [13:59:36] well that doesn't prove anything yet [13:59:48] And post ejection I will have shortly [13:59:56] ah, so you didn't have post ejection yet [14:00:04] mine are at 9 in the csm [14:00:32] that's far too low [14:00:41] DSCFUEL 8263.863281 [14:00:42] ASCFUEL 1193.401489 [14:00:42] DSCEMPTYMASS 2133.244873 [14:00:43] ASCEMPTYMASS 2446.223633 [14:00:45] post ejection [14:00:53] maybe its my graphics card its a different one [14:01:03] and what does the RTCC MFD say about the LM mass now? [14:01:20] Oh i got that number by ejecting early [14:01:26] 33863 [14:02:09] Oh wow [14:02:14] its different [14:02:20] 31532 [14:02:26] yeah, I just found the issue [14:02:28] That was odd [14:02:33] it's in the S-IVB code [14:02:45] the RTCC is asking for the mass, but it's returning the wrong variable [14:03:34] there is a general payload mass saved in the S-IVB, for payloads that aren't the LM [14:03:49] is that where that 33863 comes from [14:04:26] probably [14:04:41] So now RTCC shows the lower mass for the LM [14:04:43] might be hardcoded in some way in then Saturn code, for when the S-IVB is created [14:05:15] Does that effect the MCC maneuver pad calculation? [14:06:27] it will get the same mass as the RTCC MFD [14:07:23] And it is computed before the ejection [14:07:28] So potentially wrong right now [14:07:33] yes [14:08:08] Do I recompute with reset state? (its been a while) [14:08:22] yes, that should work [14:09:16] Not too far off [14:10:43] 31532.4969 [14:10:52] that's what I calculated for the LM mass [14:10:59] and I'll use that for the CMC padload [14:11:35] Yep that looks right [14:12:04] Are the apollo 9 padloads good for the sc masses? [14:12:56] I recently fixed them [14:13:08] https://github.com/dseagrav/NASSP/commit/ab9b6b847e6cd78c737845b291868e7e46f9cc2a [14:13:37] ok, here is what is going wrong [14:13:44] S-IVB uses the general payload mass [14:14:00] S4PL_Mass [14:14:16] that mass gets given to it from the Saturn class, when the S-IVB is created [14:14:30] the Saturn class calculates that mass with the LM mass parameters [14:14:46] but it looks like it's doing that at the wrong place in the code [14:14:56] when it still has the default masses [14:14:59] and also in the sextant and telescope i am getting a purple ring around the optics is that normal? [14:15:53] No that isn't normal [14:16:12] Sounds like a graphic isnt loading properly, could you take a screenshot? [14:16:34] sure [14:19:43] https://www.dropbox.com/s/2pllbkzqu6m0ukf/Untitled1234.png?dl=0 [14:20:22] Looks like a problem with the graphic and the resolution, what display resolution are you running [14:20:48] 1280 x 1024 [14:21:59] Yeah that isnt a 16:9 or 16:10 which I think our graphics are made for [14:22:48] we also should support 4:3 [14:22:48] i was running this resolution before with no problems and this is the graphics card i am using right now https://www.cnet.com/products/sapphire-radeon-x550-advantage-graphics-card-radeon-x550-256-mb/specs/ [14:23:05] ah [14:23:11] that's 5:4 [14:23:14] not 4:3 [14:23:16] Yep [14:23:45] I would try a different resolution in orbiter [14:25:38] yeah, 16:9, 16:10 or 4:3 [14:26:00] do you think it might be a crappy graphics card [14:26:10] if you get 9 fps, ye [14:26:11] yes [14:27:18] rcflyinghokie, I need a number from your pre ejection scenario [14:27:27] Sure one moment [14:27:31] PMASS [14:27:44] because, for me it calculates that correctly [14:29:14] PMASS 14036.733403 [14:30:00] that's 30945.7 pounds [14:30:10] it doesn't have the RCS mass [14:30:27] but still, that's what the S-IVB should be returning to the RTCC [14:30:34] so maybe the issue is somewhere else [14:30:52] RTCC is returning that value [14:31:00] pre ejection? [14:31:01] Yes [14:31:05] uhh [14:31:09] 30946 [14:31:11] and why am I searching for a bug? :D [14:31:25] Well I had 33863 returned [14:31:39] And I am trying to duplicate it [14:31:42] hmm [14:31:58] Ah [14:32:03] I just ejected from the lm [14:32:06] recalculated [14:32:09] 33863 [14:32:42] when now, pre or post ejection? [14:32:48] Immediately post [14:33:22] so no S-IVB involved at all in this [14:33:27] No [14:33:37] hmm [14:33:38] weird [14:33:51] maybe only a LM just ejected? As in, no scenario reloaded? [14:33:58] Yeah [14:34:03] a reload has the proper mass [14:34:07] interesting [14:34:35] but easily debugged [14:34:39] https://www.dropbox.com/s/bvwarzsk8ojl1an/Apollo%2010%20MCC%20-%20Pre%20LM%20Ejection.scn?dl=0 [14:34:46] If it helps [14:35:43] I found my Apollo 9 scenario for this, thanks [14:35:50] and I can reproduce it [14:36:16] oh [14:36:22] is the LM mass itself wrong? [14:36:25] probably [14:36:38] so not the RTCC at all [14:37:43] Where is the 33863 coming from [14:37:46] for apollo 8 scenario mcc1 the frame rates are up to 18 do you think its the video card or the cpu? [14:38:07] 33863 is default masses [14:38:27] the LM doesn't calculate it's own mass correctly [14:38:34] only when loaded from a scenario I think [14:38:40] but not when just created [14:40:15] Which is why the reload works [14:40:29] yeah [14:40:37] with just the csm [14:40:45] astronauthen_96 thats probably mostly gpu bottlenecking [14:41:17] what does that mean? [14:42:08] Means it cannot keep up with the demands [14:42:15] Try turning the graphics settings in orbiter down? [14:42:28] they are on the lowest settings [14:42:41] Orbiter 2016 itself is pretty demanding [14:43:08] even without NASSP [14:51:21] I think I found a solution for the mass problem [14:51:59] Something not too complicated I hope haha [14:53:40] no, fairly easy [14:53:58] the function SetLmVesselDockStage() is called by the LM when it is created [14:54:12] and also, if the gear hasn't been deployed yet, after loading [14:54:16] so it's called twice anyway [14:54:28] now I added it to the SetupPayload function as well [14:54:42] that function gives the mission specific masses from the S-IVB to the newly created LM [14:54:58] so, basically the same as if it was loading from a scenario now [14:55:06] Oh nice [14:55:19] so it creates the LM with the default masses [14:55:24] then updates the mass variables [14:55:36] What about pre ejection? [14:55:58] I added the LM RCS mass to the S-IVB payload mass calculation [14:56:21] only works for pre CSM separation scenarios, but now the pre and post LM ejection masses should be identical [14:56:24] and correct [14:56:35] Great [14:59:40] 65395.5 for the CSM? [14:59:54] yes [15:00:03] Yeah looks right [15:00:13] that's quite heavy [15:00:28] 800kg more than our default CSM weight [15:02:11] I can double check the numbers, of course [15:03:08] But Apollo 10 I did have a lot of data available so I would think that is more accurate [15:04:25] consumables analysis even has a launch weight of 65887 [15:04:47] so it's about right [15:04:53] I'll use the 65396 number [15:04:54] Ok [15:05:53] lol [15:06:10] I think I never commited the padload worksheet for the modified Comanche055 version [15:06:41] At least you have it locally, I assume :P [15:07:12] Oh, do you now the default RCS mass for the CM by chance? [15:07:18] know* [15:07:47] Somewhere around 110kg? [15:07:49] 55.5 [15:07:54] per system [15:08:06] Ok cool [15:08:21] 110.9 is the actual for 10 [15:08:29] So very close [15:09:32] rcflyinghokie: The scenario is roughly from June last year. [15:09:46] Ah yeah [15:09:49] bunch of updates pushed [15:10:08] The tank sizes and handling were changed as well as using gaseous versus liquid o2 for them [15:10:28] Thats a dangerous scn to be using given the age haha [15:13:15] outdated plumbing [15:13:55] Quite [15:21:40] Oh something else, is there a reason some CM's are named and some are using the AS designation still?? [15:23:40] some CMs never had names [15:23:46] but it's not 100% consistent [15:24:17] yeah, our Apollo 9 and 10 CMs use the AS-50X [15:24:45] Right [15:24:53] I always reused old scenarios, so it's always been like that [15:25:02] Just seems inconsistent haha [15:25:32] But 11 and later I think have the right names [15:25:38] Might as well do 9 and 10 [15:26:55] I might need to change a few things in RTCC and MCC if I do that [15:27:16] but it can be done, sure [15:34:53] So I see new padloads for 12 & 13 [15:35:11] good find :D [15:35:22] I updated it with parameters from the CSM Data Book [15:35:27] mostly the pitch polynomials [15:35:35] oh cool [15:35:43] also some small differences in the Saturn steering rate [15:37:08] Question about the PTC REFSMMAT with respect to MCC1 for 10: I know I added the little pro/fail based on if PTC REFSMMAT can be used for MCC1, but there is no indication if this can be used at the 7hr mark [15:37:19] I imagine that would have been radioed up? [15:38:07] yeah, they would have calculated the MCC-1, and checked the attitude [15:38:16] I don't think I've implemented that yet [15:38:27] Ah that was my question [15:39:02] Basically if it can use PTC REFSMMAT, the REFSMMAT was uplinked then, is that correct? [15:39:11] yep [15:39:18] If not, the launch REFSMMAT was maintained until after MCC-1 [15:39:24] yeah [15:39:27] Ok [15:39:31] or even a P30 REFSMMAT if necessary [15:39:34] Right [15:40:00] I guess the MCC just needs a check there to uplink a PTC REFSMMAT or not [15:40:38] yeah, when I had progressed further than the PTC REFSMMAT uplink I implemented some MCC features that make such decisions easier [15:40:47] but I didn't go back yet and used it everywhere [15:41:27] Ok [15:42:03] Do we have a good comm basic checklist for Pre J missions? or should they be basically the same? [15:42:40] I know it doesnt impact much, but I omitted that in the 10 checklist when I made it originally [15:46:40] Ah that basic should be fine [15:47:00] So for the first PTC uplink, it uplinks it no matter what right now? [15:47:27] I think so, yes [15:47:33] Ok [15:47:34] don't change the Checklist MFD though [15:47:40] it will be implemented eventually [15:47:40] Oh I am not [15:48:17] I do want to set the time of that decision to uplink to match the MCC though [15:48:31] Looks like you used the transcript time 7:14 or so? [15:49:15] rtcc->calcParams.TLI + 4.0*3600.0 + 30.0*60.0 [15:49:25] TLI time + 4:30 [15:49:47] I use relative times as often as possible with the MCC [15:50:00] Ok [15:50:06] so that late liftoffs and 2nd TLI opportunities can be support [15:50:07] ed [15:50:41] I will leave that choice at 7 hours then [15:51:23] Or I could always use TLI DONE + [15:51:50] But that could start digressing from the actual flight plan [15:52:34] Checklist MFD should be like the flight plan, yeah [15:52:49] Sure [15:53:29] The only problem I ran into with the way it is is the LM pressurization kind of steps on the maneuver to view the SIVB [15:53:45] But of course LM PRESS is not in the right spot for obvious reasons [15:56:37] cya! [16:12:22] And time for PTC and rest period one [16:12:47] No MCC1 [16:14:40] scrub [16:15:18] also something I changed after the fact. [16:15:39] Just following the mission rules, then MCC-1 would have been done almost always [16:16:46] but they didn't really want to do MCC-1, so there is an additional check on the DV, 50 ft/s [16:46:19] Was it actually scrubbed? [16:47:15] Ah it was [16:47:26] Only 1 MCC [16:52:11] morning! [17:10:04] hey [17:11:58] still no Block I schematics? [17:12:14] nooooo [17:12:16] >_< [17:12:53] nor new Block II schematics, which I am now equally excited for [17:13:46] or even any of the other 4 things lol [17:14:07] I am kinda curious what their scanning order is going to be -- there's 8 things to be scanned [17:14:31] with Don we only ever had 2 or 3 at a time [17:34:07] I was right, it turns out -- nobody every found the Opollo document, I was the only bid [17:34:14] or maybe I was just the only one who wanted it [17:37:16] The Opollo program is not as well known [18:48:25] Hmm I have a hung thread in MCC [18:48:56] I assume it is MCC2 [18:49:52] But not certain its about 25 hours [18:51:00] could be one of my many changes since I did MCC-2 [18:53:21] I might need a scenario from you, but I'll check my own first [18:53:32] Sure [18:54:05] yeah, in my own I did MCC-1 and MCC-2 just gets scrubbed [18:54:11] so I need your scenario [18:54:25] Interesting I reloaded it and I get a P30 maneuver with all zeros [18:54:49] https://www.dropbox.com/s/nle38nonj3y8kix/Apollo%2010%20MCC%20-%20Launch%200001%200003%200002%200001%200001%200003%200002.scn?dl=0 [18:57:25] yep, hung thread [18:58:11] let's see where... [18:58:35] Even if I reset the state it hangs again [18:58:44] it might operate under the assumption that MCC-1 gets executed [18:58:52] so I might have overlooked something with that [18:59:30] ok, it checks on the MCC-3 DV [18:59:36] too large, so MCC-2 has to be done [18:59:54] oh noo [19:00:05] the MCC calculation itself has issues... [19:00:09] uh oh [19:02:12] it fails on the first integrated solution [19:02:52] Now I dont have any trajectory issues do I? [19:03:00] don't think so [19:03:18] the MCC-3 solution it calculates first to determine if it should execute MCC-2 was not very large [19:03:33] Is that solution what is failing? [19:04:01] MCC-3 calculates fine [19:04:30] ah, the optimized, conic solution returns NaN for the pericynthion latitude [19:04:48] I shudder at the word.... [19:04:51] haha [19:04:54] Damn NaN's [19:05:00] probably just didn't iterate right [19:06:43] So should I just calculate this using RTCC for now? [19:08:47] it will have the same issue [19:08:53] but it might be a luck thing [19:09:09] Also that seemed early compared to the flight plan [19:10:15] TLI + 22:30 is what I use [19:10:18] might be wrong [19:10:30] I'm closing in on the issue [19:10:50] the iterator iterating on the optimal peri latitude is what fails [19:11:02] Flight plan is about 25:50 or so [19:11:32] Transcript is 25:41 [19:12:53] I can add 10 minutes to the time [19:13:03] or 5 or whatever [19:13:33] yeah, so it looks like no complicated orbital mechanics issue is happening, but it's just an small issue with the iteration [19:13:36] Well it calculated about 25:10 [19:14:08] ah right [19:14:24] TLI+22:30 would be about 25:10, indeed [19:14:26] so maybe TLI+23h? [19:14:33] yep, I'll use that [19:14:39] That should be close enough [19:16:22] So for my case, should I wait for a solution and then reload and reset state? [19:18:18] hmm [19:18:25] I'm not sure it's a quick fix [19:18:36] but if you wait until there is a fix, then yes, that's the procedure [19:19:12] I suppose I can scrub it and use a little more fuel for MCC3 [19:19:35] Lets me press on debugging [19:20:28] I'm not sure that will work, there won't be a nodal target for MCC-3 [19:21:15] which is an issue in itself. It probably wouldn't be able to deal with the situation right now, if MCC-1 and 2 are both scrubbed [19:21:25] Oh thats right [19:33:33] the real RTCC got a large array of nodal targets on tape [19:33:43] for the whole launch window and both TLI opportunities [19:33:49] as a starting point for an iteration [19:33:59] but it could also be directly targeted [19:34:08] the MCC doesn't have any initial nodal target right now [19:39:18] although that could be easily implemented [19:47:37] Is the lack of one why the calculation fails? [19:47:53] no [19:48:03] it's the optimization function [19:48:24] somehow it ends up with the exact same peri latitude on successive calculations [19:48:34] and that destroys the calculation, haha [19:49:52] oh I see [19:50:07] it's just me implementing terrible optimization algorithms [20:02:03] I think I have a temporary fix [20:02:19] and I'll use some better algorithm in the future [20:05:18] rcflyinghokie, update pushed [20:05:54] it even ran into the issue with the MCC-3 calculation for the DV check for MCC-2 [20:06:02] but by luck it didn't cause the NaN [20:30:33] hey @indy91 [20:31:03] i just got a new video card a MSI GEFORCE 710 and the frame rates are extremely smooth [20:31:38] very excited [20:47:01] great! [20:47:19] also, good night! [23:03:11] hi @thewonderidiot [23:03:21] hey [23:03:29] very excited about my new video card [23:05:49] nice [13:01:44] Hmm with Niklas' MCC2 fix for Apollo 10, it has a tig an hour later than the FP [13:04:47] .tell indy91 I have just tried your fix for MCC2 on Apollo 10, the pad comes up at a much better time (TLI+23h works well) but the TIG is an hour later than the flight plan MCC2. [14:57:40] morning! [14:58:56] Hey Mike [15:00:05] there's an Apollo 16 LM Timeline Change D on ebay: https://www.ebay.com/itm/302733469539?ul_noapp=true [15:00:14] it looks like we have Change C currently [15:04:58] Nice, appears that it was only used for training for Apollo 17. [15:08:20] yeah, I guess it's fair bit after 16, heh [15:10:14] also it turns out that the rope modules are less different between AGC versions than I thought [15:10:26] the schematics in ND-1021042 are just incredibly misleading [15:14:23] hi Ryan [15:15:37] Hi @Thymo [15:19:33] seriously, it took me until last night to realize this: https://imgur.com/a/W2L6wtf [15:20:03] all three of those pages are drawing the same circuit... but only portions of it [15:20:21] there's duplicated components across all of them, but they don't show connections to the pieces that they left out [15:20:29] you have to merge them all together to get what the circuit actually is [15:24:52] Hi Mike [15:24:59] hey [15:25:09] are you building anything? [15:25:47] no, just trying to fully pin out these modules in the AGC [15:25:54] nice [15:25:59] i wish i had a dsky [15:26:17] heh, me too [15:26:39] actually i wish i had a command module and a lem [15:26:43] probably will build one some time in the next year... [15:27:01] a csm? [15:27:05] DSKY [15:27:23] would it work with nassp? [15:27:26] no [15:27:46] also wow, it is totally impossible to tell even knowing that those are all the same circuit that the bases and emitters of Q2 and Q4 are tied together [15:28:22] well, the emitters at least [15:32:43] aaaand the connections for R2, R3, and R4 appear to be wrong in a lot of them [15:32:52] they really dropped the ball on these pages [18:02:03] good evening [18:02:53] hey! [18:03:03] weird [18:03:17] Apollo 10 mission rules says MCC-2 is at TLI+25 hours [18:03:24] flight plan says TLI+24 hours [18:03:45] haha [18:04:16] actual MCC-2 is consistent with the flight plan [18:05:30] so there's an interesting LM timeline change document on ebay, with scans of some pages [18:05:56] it's Change D to the Apollo 16 LM timeline, made a couple months after 16 flew [18:06:05] incorporating changes for Apollo 17 for training [18:06:20] https://www.ebay.com/itm/302733469539?ul_noapp=true [18:07:16] I think I've seen that one [18:07:32] wow, Apollo 11 has the same issue. Mission Rules say TLI+25, flight plan TLI+24 [18:07:39] hah [18:08:03] ah, we have an Apollo 16 LM Data Card Book with the same note [18:08:08] that it's for Apollo 17 training [18:09:03] and we have "normal" Apollo 16 and 17 LM Timeline Books. [18:09:20] which both might be closer to the flown version than this pseudo Apollo 16 one, haha [18:09:28] heh [18:09:39] yeah [18:09:55] so, not useful then :D [18:11:25] should be interesting to compare the pages to the documents we have [18:12:06] ok, for Apollo 8 MCC-2 was actually at TLI+25 [18:12:10] including the flight plan [18:12:18] so, maybe the mission rules are outdated or so :D [18:13:29] that sounds totally reasonable [18:21:32] can't quite decipher the time in the Apollo 12 Mission Rules [18:22:12] we are missing the Apollo 13 one [18:23:14] and starting with Apollo 14 there seems to be no fixed time in the mission rules [18:23:15] great [18:27:09] I guess at some point they noticed the discrepancy and decided "why do we even have this in the mission rules anyways" [18:30:25] maybe it also has to do with the clock updated they planned from Apollo 14 on [18:30:38] and had to use right on the first mission with it, Apollo 14 [18:30:44] use it* [18:31:00] then TLI+X becomes a bit confusing [18:31:17] actually TLI+X hours, or with the updated clock, or... [18:32:21] so having an actual mission rule with "fixed" times for it didn't make sense anymore [18:32:31] there still are nominal execution points [18:33:01] Apollo 14 MCC-2 is TLI+28 [19:13:40] Good afternoon [19:13:44] hey! [19:14:44] Hows it going [19:14:53] pretty good, what about you? [19:15:13] Actually flying a mission for a change [19:15:19] nice :D [19:15:24] Running Apollo 10 though with the MCC [19:15:30] through [19:16:07] ran into some computational trouble with MCC2 [19:16:08] how far in are you? [19:16:16] Stuck on MCC2, 25 hours or so [19:16:17] right, Niklas was talking about that earlier [19:16:43] He pushed a quick fix that worked, but it computed a TIG an hour later than it is supposed to be [19:16:58] because the Apollo 10 mission rules document is wrong! [19:17:02] which was my source [19:17:08] it has TLI+25 for MCC-2 [19:17:15] flight plan has TLI+24 [19:17:27] Nik's Vulcan ears must have been burning :P [19:17:32] lol [19:17:45] TLI+24 is correct [19:17:52] easy change [19:18:02] Haha ok, I figured seeing how the time was almost exactly an hour off, that it was a TLI+ time [19:18:41] Now are any other mission rule times different than the FP? [19:18:47] good question [19:18:49] I'll check [19:18:52] pushed the fix for now [19:19:16] MCC-3 is right [19:19:18] LOI-22 [19:19:43] MCC-4 is right as well [19:19:46] LOI-5 hours [19:20:53] So just the one? [19:20:59] probably, yeah [19:21:07] weird thing is, Apollo 11 has the same issue [19:21:14] mission rules TLI+25, flight plan TLI+24 [19:21:24] but for Apollo 8 it was actually TLI+25 that is correct [19:21:32] so my theory is, the mission rules didn't get fixed [19:21:52] despite there being change dates on the page in the mission rules [19:22:02] April for Apollo 10, June for Apollo 11 [19:22:11] so you would think they had changed it [19:22:13] Yeah [19:22:33] That is weird, I was thinking maybe a typo, but if its continuously there, maybe something overlooked? [19:24:03] yeah, I guess [19:24:21] at least I now don't trust the mission rules documents as much anymore :D [19:25:23] Not sure how I feel about the mission rules of all things not being adhered to [19:25:44] lol [19:26:06] Flight plan I understand, as things are more fluid, but mission rules? [19:26:54] I mean, it's just nominal execution points [19:27:06] I know I am just being obtuse [19:27:08] if they have to, they can plan a course correction for any time [19:27:27] and starting with Apollo 14 there isn't even any specified time anymore [19:27:36] MCC2 calculates at the proper time and for the proper time it seems [19:28:07] great [19:28:27] Roll 270 [19:28:33] Interesting [19:28:49] The actual was 99 though, so compensation for the PTC attitude? [19:28:58] hmm [19:29:18] RPY 270 166 003 [19:29:21] in our cases, the roll angle is always constrainted to heads up or down [19:29:27] constraint* [19:29:38] for MCC-2 that is still relative to the Earth [19:30:10] So probably why the actual R was 99 [19:30:14] so I probably should use the other option [19:30:28] Yeah, probably for communications? [19:31:03] Velocities look normal, -27.8 +9.4 -19.7 [19:31:03] right now it's heads down [19:31:35] Heads up would give the HGA better position WRT I think [19:31:43] WRT Earth [19:31:54] sure, easy change as well [19:32:22] Actually, the pad in the transcript says its in the moon SOI [19:32:29] RPY 089 167 006 [19:32:35] can't be [19:32:38] the burn? [19:32:38] Change in velocity (Noun 81), fps (m/s): x, -39.8 (12.1); y, +10.9 (3.3); z, -25.8 (7.8). The change in velocity is resolved into three components expressed relative to the LVLH (Local Vertical/Local Horizontal). As they are now in the Moon's sphere, the LVLH is with respect to the Moon; that is, relative to a vertical drawn between the spacecraft and the Moon's centre and the horizontal plane directly below the [19:32:39] spacecraft. [19:32:46] That cant be right [19:32:49] MCC-2 is 100% in Earth SOI [19:32:58] Yeah very much [19:33:27] Wonder if that is a copy paste error in the transcript description [19:33:58] could be [19:34:02] But yeah the actual RPY was 099 184 359 [19:34:03] maybe from another mission or so [19:34:51] So pretty close [19:35:39] Looks like I am burning about 10fps less than actual [19:36:48] nominal is 0 [19:36:50] hmm [19:36:51] no [19:36:55] not quite [19:37:00] due to the plane change [19:37:15] so, this is weird [19:37:34] if I use the TIG and DV from the transcript I get a very different burn attitude [19:38:37] that might mean the REFSMMAT we are using is not right [19:39:28] Well i just did it in RTCC [19:39:35] Using my current REFSMMAT [19:39:43] 088 165 004 [19:39:47] yeah, same [19:40:02] RPY 099, 184, 359 [19:40:05] from the transcript [19:40:09] So wrong PTC REFSMMAT, or different one rather [19:40:21] I'm using the one from the SCOT [19:40:28] which I thought was right [19:41:14] Unless the spacecraft isn't on the same course [19:41:31] But my sep burn was almost identical to the actual [19:43:11] yeah, I doubt it's the trajectory [19:45:12] Lets see what my P40 wants me at [19:47:47] 088 167 006 [19:47:54] Not surprised [19:50:08] Interesting transcript tid bit about MCC2 targeting [19:50:09] [The targeting for this midcourse correction was based on a preflight consideration to have the orbit inclination such that the Lunar Module approach azimuth to the landing site would be very close to that for the first lunar landing. The translunar injection targeting, however, was still optimum for the Earth-Moon geometry and launch-window constraints imposed by the May 18th launch date. A resulting pericynthion [19:50:10] altitude of 60.9 miles (112.8km) was indicated for the executed 49.2 ft/sec (15 m/sec) firing. The maneuver results indicate that an adjustment of 0.39 ft/sec (0.12 m/sec) would have been required to attain the desired nodal position at the Moon and 0.14 ft/sec (0.04 m/sec) to correct the perilune altitude error.] [19:50:39] yeah, I knew about that [19:50:48] that was the plane change I mentioned earlier [19:50:53] Ah right [19:50:56] at the MCC point it's mostly a plane change [19:51:40] trajectory wise Apollo 10 then simulates a mission to the same landing site as Apollo 11 [19:52:13] Ah I see [19:52:36] TLI was based on earth moon and the MCC was to alter course to simulate the trajectory 11 would have in July [19:52:50] Something like that? [19:58:06] yep [19:58:47] the exact same conditions aren't really possible to replicate with just TLI [19:58:57] Right that makes sense [19:58:59] at least you would get a different approach azimuth [19:59:28] I am going to burn this as the MCC tells me to [19:59:40] Hopefully the trajectory is good after [20:01:13] They do make a comment about the roll angle and the sun [20:01:41] 025:40:38 Duke: Roger. 013 and 018. And you're going to be - In the burn attitude you're going to be looking at the Sun. The Sun is 4 degrees off from the X-axis, and we think with this roll angle that the LM will block it out completely, though. [20:04:40] clever [20:06:11] but that still doesn't explain pitch and yaw being different [20:06:11] But with 10 degrees extra roll, does the P and Y change that much? [20:06:17] Yeah [20:08:07] Any good way to tell if that burn put me on the right path? [20:08:12] nah, it wouldn't change that much [20:08:25] it would change a bit, due to the SPS gimbal trim angles [20:09:28] hmm, calculating a flyby or MCC an checking the DV [20:09:46] I think I also wanted to add something so that you can look at your pericynthion state [20:09:50] for the RTCC MFD [20:09:59] That would be a quick easy reference [20:10:31] So an option 6/7? [20:11:10] yeah [20:11:44] same page could have the current reentry conditions [20:11:52] For 27h, PC is 76:02:38 [20:11:54] for free return trajectories [20:12:20] 9.1fps [20:12:38] and that to the nominal peri latitude [20:13:14] nodal target is stored in the MCC section of the scenario [20:13:16] Interesting that my dv is almost the difference between my MCC and the actual [20:13:36] coincidence [20:13:48] Ok [20:13:57] But does that sound right? [20:14:19] you can probably get the DV to close to 0, if you change the latitude [20:14:41] MCC-2 will have reoptimized the latitude [20:15:07] so it's not the same as a flyby calculation would use [20:15:28] ideally, that is the only difference, so you should be able to get a DV close to 0 [20:15:51] So that calculation should be good even though different than the actual [20:15:58] MCC2 calc [20:16:49] if you do an option 2 calculation with the RTCC MFD right now, it should give you close to 0 DV [20:17:01] if you do an option 6/7, then you have to manually adjust the latitude [20:17:09] but still should be able to get a DV close to 0 [20:18:20] 2.5 [20:18:21] 9 ft/s from option 2 would be too much [20:18:29] from option 2 [20:18:43] not great, but should be good enough [20:18:47] Ok [20:18:56] So something still isnt perfect with that burn calculation [20:18:59] you'll see, maybe you will have to do MCC-3 or 4 [20:19:07] or the burn execution ;) [20:19:14] Haha could be! [20:19:29] what it could be is this [20:19:33] Residuals were -.1 -.1 0 [20:19:38] it moves DV from LOI to the MCC [20:19:51] that is in the nature of the optimization for MCC+LOI [20:20:03] which is why option 2 isn't used for MCC-3 and 4 [20:20:20] it would try to shift too much DV from LOI to the MCC [20:20:30] and that changes the trajectory more than desired [20:20:32] That makes sense [20:20:35] you want lots of tracking before LOI [20:21:16] so, very small residuals might already lead to this 2.5 ft/s [20:21:40] and I would expect the LOI-1 DV to be smaller by the same amount [20:21:57] Maybe I should have nulled them [20:22:25] Even though I was told not to in the FP [20:22:44] I still find it unlikely that you will have to do MCC-3 or 4 [20:22:47] even I didn't have to dit [20:22:52] do it* [20:22:59] and I executed MCC-1 and not 2 [20:23:00] And you did an MCC1 right? [20:23:03] yep [20:23:04] Ok [20:23:17] Lets hope the error doesn't propogate enough [20:24:31] this shifting DV from LOI to the MCC [20:24:43] that's the whole concept behind the hybrid trajectories [20:25:38] high pericynthion altitude plus non-free return MCC to 60NM pericynthion altitude leads to a lot of DV saved for LOI [20:26:38] because you are going much slower at pericynthion [20:26:52] I never thought about that [20:26:55] But yeah you are [20:27:32] Well time for PTC and some coasting to MCC3 [20:27:38] which is hopefully scrubbed [20:28:25] likely something to fix for me, if it isn't scrubbed [20:30:10] let me know how it goes. good night! [20:30:13] I shall [20:30:14] night [20:30:16] night! [20:31:10] you know, it is probably in archive.org's best interest to finish scanning these things ASAP [20:31:25] to save them the bandwidth cost of me refreshing our page over and over again :P [20:33:04] Haha I never thought about that as a reason [20:36:02] Hmm would a V66 be done after any docked or csm only SV uplink? [20:36:14] Or just before and after maneuver SV's [20:36:53] you are asking the wrong person :D [20:37:22] Haha fair enough [20:37:30] Hmm this flyby pad troubles me [20:38:24] .tell indy91 here is my flyby pad, note the height of PC at 962NM... https://www.dropbox.com/s/k7forjsae00he7d/Screenshot%202018-05-10%2016.34.24.png?dl=0 [20:38:57] I thought MCC2 was supposed to drop the PC back to 60 or so [20:39:37] Oh never mind [20:39:49] Actual was 886 [21:06:46] .tell indy91 MCC3 was scrubbed, but the message came up around 52:40 instead of 52:15, another time discrepancy perhaps? [21:43:18] .tell indy91 and MCC4 is also scrubbed, however the call comes up at 69:40 instead of 69:15, same lag as MCC3 [21:44:05] .tell indy91 and I got no PC+2 pad with that [09:09:26] . [09:35:36] Hey indy [09:36:14] so i have an mcc2 scenario from March would that be recent enough to start a mission? [09:38:48] also found a potential bug [09:41:08] @indy91 [09:41:20] hey [09:41:25] which mission? [09:41:29] 11 [09:41:46] probably recent enough, yeah [09:42:05] and what bug? [09:42:19] right after earth orbit insertion if i use 10x time acceleration i get an orbiter.exe ctd [09:42:34] it happened on my old computer as well [09:43:09] oh, I think I know what this is [09:43:19] but for the redundant component check for time acel everything is fine [09:43:35] do you have wind enabled in the Orbiter settings? [09:43:37] so i dont know at which point the ctd's stop [09:43:58] nope [09:45:02] we had a really weird CTD at that point [09:45:08] and it only happened at 10x [09:45:21] it actually was caused by the interstage [09:45:23] was it orbiter.exe? [09:45:29] some aerodynamics issue [09:45:41] at about the time when it impacts the Earth [09:46:07] I'm checking what we did to fix that one [09:47:01] it's orbiter.exe crashing, because the crash happens in the aerodynamics simulation of Orbiter [09:48:09] also is the fdai supposed to move very quickly? [09:48:37] oh I remember what we did [09:48:41] we filed a bug report [09:48:41] https://www.orbiter-forum.com/project.php?issueid=1362 [09:48:59] and what will probably prevent the CTD is disable gravity gradient torque [09:49:18] FDAI moving quickly? when? [09:49:27] usually that means the spacecraft is moving quickly as well, lol [09:49:46] like for gdc align [09:50:24] if you press GDC align the BMAGs instantly have a new attitude [09:50:34] and the FDAI will move quickly to show the new attitude [09:50:49] maybe its my faster video card i am used to it moving slowly [09:52:25] hmm [09:52:45] the FDAI itself should have a fixed maximum rate of movement [09:52:55] shouldn't be dependant on frame rate [09:52:57] I'll check [09:54:46] another setting to check [09:54:52] in the NASSP settings [09:54:57] on the "Visuals" page [09:55:08] do you have Smooth Scrolling enabled for the FDAI? [09:55:14] yes [09:55:28] for me that makes the frame rate a looooot worse [09:55:40] so I really would recommend not having it on [09:55:42] my frames are 35 [09:55:50] it should be 60 [09:55:59] it might even be with smooth scrolling disabled [09:55:59] its smooth for me [09:56:09] 35 is ok, but not ideal [09:56:25] so unless you get 60 fps, I wouldn't have smooth scrolling enabled [09:56:44] the fdai is smooth as well [09:56:54] yes, that's the problem, haha [09:56:56] no lags at all [09:57:06] making the FDAI smooth costs a lot of performance [09:58:22] some setting must be wrong on my system, I probably should get a better frame rate in general [09:58:30] but if I have smooth scrolling enabled, I get 25 fps [09:58:54] 45 without it [09:59:03] i will try that [09:59:11] I have a quite powerful GPU, so it shouldn't be that [09:59:20] probably need to change some CPU settings [09:59:57] now its at 51 [10:00:09] but i cant really notice a difference [10:00:57] if you scroll around on the CSM main panel [10:01:10] I can easily see a difference between 25 vs. 45 vs. 60 fps [10:01:11] yes [10:01:23] i cant for some reason [10:02:00] there are no lags at all [10:02:03] ah, I have the panel scroll speed [10:02:08] scroll speed turned up [10:02:12] so that it's faster [10:02:18] I have it at 50 [10:02:23] then you should be able to see it [10:02:40] how do i change that? [10:02:50] under Parameters on the Orbiter Launchpad [10:03:22] got it mine is at 30 [10:04:12] when i scroll its at 36 now [10:05:15] the frame rate on the main panel always seems so random to me [10:05:21] sometimes it's a smooth 60fps [10:05:24] and sometimes not [10:05:33] and my gpu is low profile [10:08:58] ok, so with the FDAI, it actually might be different depending on frame rate [10:09:11] how much it moves during GDC Align or IMU coarse align [10:09:20] so higher framerate might make it faster [10:09:48] for most panel elements it's not depending on frame rate [10:09:53] like e.g. gauges [10:10:39] and my cpu is 3.70 ghz [10:11:07] mine as well [10:11:27] pretty sure that's the bottleneck on the CSM main panel [10:11:38] and again, it seems super random if I get 45 or 60 fps there [10:11:41] is that good or bad? [10:11:47] bad [10:11:52] wait [10:11:55] what do you mean? [10:11:59] the CPU frequency? [10:12:04] yeah [10:12:11] oh, I think that's pretty good actually [10:12:20] what's not so good is that NASSP actually needs it [10:12:33] so the panel could use some improvements [10:12:43] there are just so many interactive elements [10:13:09] not sure why i cant tell the different between 35 and 51 [10:14:14] panel scrolling should give it away [10:14:28] maybe you need to check your eyes, lol [10:14:31] just kidding of course [10:14:35] its still smooth at 50 [10:14:44] the panel scroll speed [10:14:45] oh, it's decently smooth at 50, sure [10:14:55] maybe you are just used to even worse frame rates [10:15:11] for me it usually 45 vs. 60 fps [10:15:20] and after a while I can see the difference [10:17:33] and you were using obs studio right? [10:17:45] to record videos, yes [10:18:21] might do a docking video [10:18:56] i lost all my saves except for mcc2 on dropbox [10:19:08] did you click the wrong button again? [10:19:47] no [10:20:03] i got a new computer and i forgot to tell my dad that i had saves on the harddrive and he formatted it [10:32:09] https://youtu.be/nO4INJ2a_J4 [10:35:04] so, I can see in that video that it's 30fps [10:35:19] because there is some "tearing" on the panel [10:35:26] that doesn't happen at 60fps [10:35:35] what do you mean tearing? [10:35:42] difficult to explain [10:36:09] like, the labels and such are slightly more difficult to read while scrolling [10:36:22] that is smoother at 60fps [10:36:52] would you consider the video "smooth"? [10:37:14] yeah, decently smooth [10:37:19] was it recorded in 30fps? [10:37:35] yes but its 35-36 without recording [10:38:31] in any case, when it comes to frame rate, then development happens with 60fps in mind as ideal, but it always should still work at 30fps as well [10:38:55] some things are worse with a lower framerate [10:39:12] like the accuracy of the IU state vector in the LVDC [10:39:20] so TLI is a bit less accuracy with a lower framerate [10:39:36] mostly caused by the new touchdown point calculations in Orbiter 2016 [10:39:40] so not much we can do about it [12:28:53] morning [12:29:44] hi Alex [12:30:39] hey [12:31:03] whats up? [12:31:30] not much [12:33:53] "AOT star check calculation" whats that? [12:48:32] on Apollo 9 they had a PAD for an AOT star visibility check [12:48:37] and that's a bit of geometry for that [12:49:05] you would specifiy REFSMMAT, IMU angles and detent and it should give you the most visible star [12:49:21] ah ok [12:49:23] or, as the RTACF requirements for Apollo 9 say, the 10 most visible stars [12:49:34] the PAD just has one per detent or so [12:51:24] it's the same calculation as for the sextant star check on the CSM Maneuver PAD [12:52:07] just a bit different geometry [12:58:28] right [12:59:03] im testing the new Apollo CMC pitch polynomials for Apollo 13 right now [13:04:16] the LVDC will still not have the right one [13:04:21] but it should be much closer [13:06:45] it has the 11 one I think [13:43:22] Good morning [13:47:46] hey [13:50:30] hey Ryan [13:50:35] I got your list [13:51:20] Ah great [13:51:41] Never mind the PC comment, I realized that was after a flyby maneuver [13:52:05] first, the flyby is targeted with the RTE processor, not TLMCC processor [13:52:15] so to a specific splashdown longitude, not 60NM flyby [13:52:55] 886NM was the altitude on the historical Flyby PAD [13:52:58] so not too far off [13:53:14] then, you get the PC+2 Maneuver PAD 5 minutes after the MCC-4 one [13:53:24] to give you time to write down the MCC-4 Maneuver PAD [13:53:33] doesn't really matter of course if MCC-4 was scrubbed [13:54:25] So if MCC4 is scrubbed no PC+2 pad [13:54:58] no [13:55:11] if MCC-4 scrubbed it will still wait 5 minutes until you get the PC+2 PAD [13:55:29] despite there being no reason to wait for you to have copied the MCC-4 Maneuver PAD [13:56:18] Well i never got a PC+2 pad [13:56:44] you sure you waited more than 5 minutes after the MCC-4 update? [13:57:25] Very much so [13:57:29] hmm, weird [13:57:34] I am at 69:03 [13:57:50] Already got my SV and REFSMMAT with the scrubbed message [13:57:51] did you get a Thread Started? [13:58:21] No [13:58:46] I got one for MCC scrubbed [13:58:55] and thread stopped I hope [13:58:56] Where it gives me an uplink [13:59:00] or ended [13:59:01] Yes [13:59:08] Completed [13:59:12] the logic for the PC+2 update is [13:59:13] SubStateTime > 5.0*60.0 [13:59:26] so 5 minutes after the MCC-4 update [13:59:35] I reset the state to the MCC4 [14:00:17] Should the state vector be updated for the MCC4 scrubbed call? [14:00:34] Or should it be waiting for the PC+2 with the REFSMMAT [14:00:40] no [14:00:51] you'll get an uplink with the MCC-4 update in any case [14:01:05] what kind of uplink depends on scrubbed/not scrubbed [14:01:08] Just the state vector? [14:01:16] If scrubbed [14:01:30] "CSM state vector, Landing Site REFSMMAT" [14:01:41] It just says CSM State Vector for my uplink [14:01:47] hmm [14:01:51] something is wrong then [14:02:03] Oh hold on [14:02:13] It says MCC3 is scrubbed [14:02:25] Let me reload a quicksave and see if I goofed [14:02:44] yeah, I just checked, only the CSM state vector update would be MCC-3 [14:03:31] Ok I reverted back to 68:37 [14:03:37] What state should it be in [14:03:39] what's the MCC state? [14:03:59] state 32 [14:04:02] 32 [14:04:03] before the MCC-4 update [14:04:07] Yes [14:04:19] Ok let me see what happened [14:04:43] and I have a theory about the timing being off [14:04:56] I was about to ask as I wait for the MCC call [14:05:00] your Apollo 10 mission might be 25 minutes behind the flight plan [14:05:18] so, the real Apollo 10 mission was behind schedule by 10 minutes [14:05:33] it was explained to the astronauts with the decision to not burn MCC-1 [14:05:37] but MCC-2 instead [14:05:42] that would account for 10 minutes [14:06:03] Interesting [14:06:04] I did MCC-1 and was 15 minutes behind the flight plan anyway [14:06:09] 15+10=25 [14:06:23] I blame TLI [14:08:15] Ok got MCC4 scrubbed at almost 69:40 as expected [14:08:37] And CSM SV and LLS2 REFSMMAT [14:08:44] That worked [14:09:01] Now lets see if PC+2 works [14:09:08] And in the mean time I have a V66 question [14:09:14] sure [14:09:27] Should this be done after every docked/csm alone SV update [14:09:46] csm alone as in the LM is no longer a player [14:10:58] if no V66 was uplinked as well, yes [14:11:05] two small exceptions [14:11:14] Apollo 8 got the uplinked SV to the LM slot [14:11:29] I think Jim Lovell liked being "in control" of the CSM state vector [14:11:44] and in Earth orbit there usually is a Nav Check PAD coming with a SV uplink [14:11:52] that would be tested first with P21 [14:12:01] and if the SV is good, then you would do the V66 [14:12:10] Makes sense [14:12:11] otherwise V47 to "repair" the SV I guess [14:12:25] So what about these in 10 [14:12:46] And if a REFSMMAT is uplinked as well, does a V66 break anything? [14:13:51] I have to check the documentation again, later flight plans are more clear about when a V66 was uplinked [14:13:57] I got my PC+2 pad too so it was just a state issue [14:14:09] and I don't think a V66 breaks the uplinked REFSMMAT [14:14:15] I have changed the checklist a bit to make it more clear when to expect them [14:14:23] it's just an issue with temporary memory for an uplink [14:14:26] Ok [14:14:44] So for 10 should I add V66's in for the SV updates? [14:14:45] a SV update isn't directly to the CSM or LM slot [14:15:19] it completes the uplink, does a check on some of the uplinked data and then copies it to the CSM or LM slot [14:16:03] yeah, I don't think they always uplinked the V66 [14:16:08] so it has to be done manually [14:16:13] Ok [14:16:29] I added them to all SV uplinks other than when the LM SV is needed for the LM [14:23:45] Hmm got a really bad angle after my REFSMMAT uplink and P52 option 1 [14:25:35] V32 and did it again and its fine, maybe user error then [14:36:50] Does the MCC do map updates? [14:39:42] yep [14:39:49] for Apollo 10 at least [14:39:57] still have to add them to Apollo 8 [14:40:01] Ah I guess I will expect it 25 minutes late :P [14:40:11] it wasn't giving consistent results as you will remember [14:40:16] on the RTCC MFD [14:40:25] confused sunset vs. sunrise [14:40:30] but that has been fixed [14:40:39] so it's good to go for the MCC [14:40:50] Yeah [14:41:11] Ok and something I missed with PTC with 10 is the different configurations earlier on [14:41:21] and about the 25 minutes delay, I'll look at the Apollo 10 TLI targeting parameters again [14:41:38] I know we did deadband changes in LPO [14:41:50] But looks like the first 2 PTC's had different configurations [14:42:09] yeah [14:42:17] flight plan experimented a bit with it [14:42:23] the real mission had some major trouble with PTC [14:43:22] https://www.youtube.com/watch?v=4Vf6Y98ZjwQ [14:43:33] here a talk partially about the Apollo 10 PTC issue [14:43:47] how they solved it from a mathematical point of view [14:48:38] Interesting, I am watching it [14:48:58] So should I go ahead and mimic the db changes for these PTC attitudes? [14:52:14] Our default PTC procedure is SCS controlled [14:52:21] These are G&N [14:53:41] yeah, they should be G&N [14:54:47] I will add a group for G&N PTC then [14:59:01] What dap settings were used for it? [15:00:43] the same? [15:04:34] Same as? [15:11:56] same as during the sleep period in LPO [15:12:03] max deadband, then manual change of deadband [15:12:08] max deadband in V48* [15:14:43] And disable the quads with the switches? [15:15:23] hmm [15:15:29] I think so, yeah [15:16:27] I dont see anything about disabling pitch and yaw for this PTC [15:16:30] Just roll [15:16:54] I think that was their issue [15:17:04] pitch and yaw thrusters stayed enabled [15:17:12] Ok [15:17:13] at the beginning of the sleep period [15:17:22] it reached the deadband [15:17:40] and then it just kept firing the thrusters a lot, keeping the astronauts up over night [15:19:34] if you wanted to use time acceleration, then you probably want to disable all the thrusters [15:19:44] but that's up to the user [15:20:14] For time accel I just use CMC free [15:21:30] ah right [15:28:05] And the db tests in lunar orbit were also under CMC control, correct? [15:30:09] yeah, anything that mentions a specific number in degrees for the deadband [15:30:23] the SCS is not reliable over time to hold a deadband at a specific attitude [15:30:47] Yeah I realized the first db change i added in LPO still was in SCS haha [15:30:53] That has been fixed as well [15:31:19] haha, that would be a waste of that manual deadband change procedure [15:31:36] Yep! [15:46:29] Wow LOI is almost exactly the same attitude as actual [15:46:43] just 1 deg difference in P and Y [15:47:16] I guess MCC2 targeting was pretty good [15:49:45] and I guess the TIG is way late [15:50:00] 76:04:59 [15:50:29] Kind of makes holding attitude until 76h obsolete haha [15:51:01] everything in lunar orbit will be late by that amount [15:51:08] about 20 minutes [15:51:22] Might confuse people later [15:52:30] it happened during the actual mission sooo... people just need to adjust [15:52:45] not a problem from Apollo 12 on, with the hybrid missions [15:53:01] actual Apollo 11 mission was about 5 minutes later than the flight plan [15:54:00] I like that argument :) [15:54:07] As real as we can make it ;) [15:54:18] well, I'll still work on that TLI targeting [15:54:31] I am still tryign to grasp these PTC procedures, was P20 used? [15:54:42] not until Artemis [15:54:57] Artemis had a bunch of features added to its P20 [15:55:18] including for PTC and sleep period attitude holds [15:55:25] simple custom deadbands etc. [15:55:42] Apollo 14 basically had the same functionality, but not integrated into P20 yet [15:55:48] So once again the comments in the transcript are incorrect [15:55:50] it was an extended verb for that mission, V79 [15:56:01] copy pasted from Apollo 15 or later than [15:56:04] Yeah [15:56:11] because before that there was no special support for PTC [15:56:26] Now I need to see what was used for the other PTC's in the mission [15:56:28] also, these are of course not actual comments from the transcript [15:56:33] Oh I know [15:56:34] these are from AFJ contributors [15:56:44] it gets even more confusing in the ALSJ [15:57:10] there are comments from the technical debriefing at the time, interviews with the astronauts and then comments from the editors and contributors [15:57:30] interviews with the astronauts mostly in the 90s or early 2000s or so [15:57:54] So easy to forget details [15:58:01] or get them wrong [15:58:14] both by astronauts and the contributors [15:58:29] most PTCs on Apollo 10 should be G&N [15:58:39] but they experimented with deadbands and roll rates [15:58:43] in the flight plan [15:58:52] Yeah [15:58:54] real time differed as well [15:59:10] I am mostly concerned getting them switched to G&N [15:59:31] Just need to know what DB they used for the PTC's after the first 2 [16:00:12] should be all in the flight plan [16:00:35] Just says PTC after the first 2 [16:00:38] hmm [16:00:47] They were going to decide which to use [16:01:00] I have the revised procedure from the transcript as well [16:01:11] after TEI has details [16:01:14] 20° once, then 30° [16:01:15] Yeah [16:01:20] But before LOI [16:01:32] I have a 20 and a 30 and then it would be decided real time I believe [16:01:39] yeah, probably [16:01:46] I will use the transcript [16:02:34] I will use the normal G&N procedure for the first PTC and the revised for the subsequent [16:02:44] I think that is reasonable [16:04:10] sure, whatever you think works the best for the Checklist MFD [16:05:26] Yeah I think that will work [16:05:32] Just need to add groups [16:11:04] Were all roll jets turned off? [16:11:27] It reads like they were [16:12:09] yeah, they were [16:12:23] after the roll rate has been established they aren't needed anymore [16:12:39] And were all P Y jets left on? [16:15:45] probably [16:15:47] not [16:15:50] probably not :D [16:15:59] pressed enter too quickly... [16:16:11] one for each direction is the usual procedure I would think [16:16:15] so 4 jets [16:16:38] although I am not sure that is healthy for the trajectory over night [16:16:52] I wish i had a non P20, G&N PTC procedure [16:17:47] which is why another G&C Checklist would be good [16:17:54] Apollo 10 to 13 somewhere [16:19:12] although [16:19:15] even with P20 [16:19:21] didn't they disable all jets eventually? [16:19:38] ah, but that's different [16:22:39] Yeah [16:23:30] Looks like this is the revision [16:23:31] 026:56:18 McCandless: Roger. After you get through the Enter at the end of flashing [Verb] 50 [Noun] 18 in the checklist, we'd like you to disable all jets on quads Charlie and Delta using the Auto RCS Select switches. Wait 20 minutes; then switch Manual Attitude Pitch and Yaw Acceleration Command mode, and enable all jets using the Auto RCS switches. Initiate your desired roll rate, which we show as three-tenths of a [16:23:31] degree per second, and then, when roll rate is attained, go to Accel Command in roll. Increase the deadband to the desired value; Manual Attitude Pitch and Yaw Rate Command of 30 degrees deadband. Over. [16:24:10] Thats for initiating the 30 deg DB PTC [16:25:29] good description [16:25:32] Now for the DAP do I choose AC or BD roll [16:26:35] I don't think it matters [16:26:38] ok [16:26:40] in each case only 1 quad will be active [16:26:56] because only C and D are on with the Auto RCS switches [16:30:07] Ok so all C and D quad jets disabled after the PTC attitude maneuver [16:30:24] Interesting that they are adjacent not opposite quads [16:39:51] And after that procedure, would all roll jets be disabled again? [16:40:11] And then 4 PY quads [16:43:20] hmm, maybe [16:43:29] morning! [16:43:51] They disable them all for a P20 powered PTC [16:43:57] Hey Mike [16:44:46] hey [16:44:48] what's up? [16:46:18] Ryan is working on PTC procedures [16:46:28] I am working on giving bad advice about PTC procedures [16:46:43] Hmm later on they are still clearing it up [16:47:09] They start the roll rate with a V21 N01E V24E? [16:47:21] 029:05:33 Duke: That's negative, John. You - you wait 20 minutes - all that down to "wait 20 minutes" is good. Then you go to Manual Attitude Pitch and Yaw to Accel Command. You enable all the jets, and then you let the DAP start - stop - start the roll rate by doing the Verb 21 Noun 01 Enter and the Verb 24 Enter, and on the last Enter, the thing ought to take off and roll, and when the roll is attained, the Manual [16:47:21] Attitude Roll goes to Accel Command. Then you increase the deadband to the desired value and the Manual Attitude pitch and yaw to the Rate Command. Over. [16:47:43] lol [16:48:55] Now I am confused haha [16:49:33] Looks like they arent manually starting a roll [16:49:39] huh [16:49:53] There is a rate procedure in the AOH [16:50:09] probably for a way later CMC version [16:50:17] Right [16:50:38] So I am wondering to what end they are referencing the DAP roll [16:50:58] "Then initiate the desired roll rate via the Verb 24, Noun 01, and the Verb 24 Enter." [16:51:12] V24 on what though [16:51:55] I have no clue [16:52:29] hidden feature in Comanche? :D [16:53:33] Well V24N01 is the rate change [16:53:40] At least in the AOH [16:53:46] where is that? [16:53:48] on the AOH [16:53:48] So maybe it was in Comanche [16:53:54] in* [16:54:04] 4-282 [16:54:23] pdf 296 [16:54:30] this is Comanche 45? [16:54:31] oh, interesting [16:54:37] it doesn't use V79 or P20 [16:54:51] Nope [16:54:57] I am wondering if this is the procedure [16:55:01] this looks like a manual command to the DAP [16:55:13] I'll check the addresses [16:55:22] Also this procedure uses a hold flag [16:55:27] That isnt mentioned for 10 [16:55:41] But it could be in their checklist [16:55:48] yep, was about to say that [16:56:43] Margaret does have that copy of Comanche 44 that you guys could ask her about ;) [16:59:24] I very much doubt this is a special Comanche 44 feature [16:59:35] it will work with all CMCs [16:59:42] just some addresses could be different [17:00:48] hmm [17:00:54] If it does work I will use the procedure verbatim [17:01:03] V21 N01E, 1013E, E [17:01:05] Because it looks like it is what is hatched out during 10 [17:01:09] would 1013 be octal? [17:01:13] because of V21 [17:01:15] Mike? [17:01:52] yeah, must be [17:01:55] N01 [17:01:59] that is what determines it [17:04:01] I just had a good LOI, now I am going to go back and play with this PTC [17:04:05] the address 1013 confuses me though [17:07:54] the addresses are why I was thinking having Comanche 44 might make this easier, heh [17:08:11] V21 N01E, 1013E, E [17:08:15] is this octal 1013? [17:08:19] also [17:08:20] yeah [17:08:27] where are the flagwords in the erasable? [17:10:21] address 074 is the first flagword in comanche 55 [17:11:11] REQRET ERASE # RETURN REGISTER FOR LOAD [17:11:13] 1013 == REQRET? [17:11:15] really [17:11:25] I think during this procedure you are in V49 [17:11:29] and have the V50 N18 up [17:11:33] Yes [17:11:53] guess we have to just try this procedure [17:11:57] I am right now [17:12:45] REQRET is an internal PINBALL thing [17:12:56] so the procedure zeros it... [17:13:04] here's a potentially relevant comment [17:13:15] CAF ZERO # ZERO REQRET SO THAT PASTED VERBS CAN [17:13:16] TS REQRET # BE EXECUTED BY OPERATOR. [17:13:28] the 3125 in the procedure looks correct [17:13:59] 3175 as well [17:14:10] hmm [17:14:21] is displaying something to the operator considered "pasting"? [17:14:30] and those are identical in Colossus249 and Comanchr055 [17:14:31] # NOUN. GO TO NVSUB AGAIN WITH THE :PLEASE PERFORM: VERB AND ZEROS IN THE [17:14:32] # LOW 7 BITS. THIS :PASTES UP: THE :PLEASE PERFORM: VERB INTO THE VERB [17:14:33] # LIGHTS. [17:14:50] 1013 is the same in C249 and C055 as well [17:15:26] if that is the case then it sounds like zeroing 1013 might allow the operator to press "ENTER" to execute a VERB/NOUN display that the AGC itself has put up [17:17:11] maybe. [17:18:59] Hm when I get to the 2E the display clears [17:19:11] I am doing +0.3 [17:19:29] so it works? [17:19:43] I dont think it is supposed to clear there [17:19:58] Unless I messed up somewhere [17:20:00] I am trying again [17:20:03] but it started the 0.3°/s rate? [17:20:17] No the dsky blanked before I got to that step [17:20:46] ah, that what you meant [17:21:43] But the step right before the V24 [17:21:48] It fires a roll jet [17:22:02] And then nulls the roll [17:22:17] Now I am back to the v24 step still on F50 18 [17:23:31] So i am wondering if something is amiss here [17:23:37] Same result [17:23:47] worked for me [17:23:56] I have a 0.3°/s rate [17:24:04] The DSKY didnt blank when you typed 2E? [17:24:09] never blanked [17:24:15] It has twice for me now [17:24:34] I did a V24 N01E on the middle step [17:24:37] instead of V24E [17:24:39] Oh [17:25:01] this might have been a feature that was added later, not sure [17:25:07] that you can do V24 and then enter [17:25:19] That would make more sense because the V24 during the F50 18 just enters R1 and R2 [17:25:29] And after R2 there is no more and it terminates F50 18 [17:25:40] Ok so this works as advertised [17:26:28] awesome [17:27:01] I bet this would be in the G&C Checklist, but from Apollo 14 on, where we have the checklist, they had easier ways to do this [17:27:39] Glad they kept it in the AOH! [17:27:59] I will make a group for it [17:28:17] glad they didn't update the AOH often enough [17:28:34] this Apollo "16" AOH mentions V79 sometimes [17:28:38] which only Apollo 14 had [17:28:53] the page for this rate procedure is from July 1970 [17:29:00] pretty old for Apollo 16 [17:34:12] thewonderidiot, and what does V21 N01E, 1013E, 70000E do? [17:34:23] maybe a proceed if 0 was enter? [17:34:55] 0 wasn't an enter, in that one instance it would have allowed the astronaut to press enter [17:35:04] You got the roll rate after the 27303E didnt you? [17:35:27] uhh, not sure [17:35:28] maybe [17:36:11] Did you do the step you just mentioned? [17:36:30] yes [17:36:39] That should be what starts the roll [17:36:50] I get jet firing before that though [17:36:51] hmm [17:36:58] so that procedure with 1013 might not be right [17:37:17] it should prevent it from starting the maneuver immediately [17:37:32] 1013 in Artemis is way different [17:38:15] Maybe the 1013 before and after the rate arent needed? [17:38:57] yeah, I really don't think futzing with REQRET is going to be useful... that is pretty PINBALL-internal [17:39:52] Well its in the AOH procedure, just not sure how relevant is is to Apollo 10 [17:41:10] we would need the AGC version that corresponds to that AOH procedure [17:41:16] Right [17:41:19] maybe Apollo 13, probably 14 [17:41:25] hmm [17:41:29] but 14 had V79 [17:41:31] which Margaret might also have ;) [17:41:32] for exactly this [17:43:02] if Margeret has it, then it would solve a small problem several months down the road, haha [17:43:26] in the theoretical case that we would get any theoretial AGC version [17:44:08] I am going to try this without the 1013 stuff [17:44:41] yeah, I think that part is only supposed to make the DAP wait to start the rate until the 70000E [17:46:28] Yep [17:46:39] Without that after the last E it goes into a .3 deg rate [17:46:59] And the F 50 18 is still up [17:49:22] This procedure says to turn all jets off after the deadband change [17:50:44] I cant tell if they are on 10 [17:53:21] Probably not, they give P and Y back to CMC control it seems [17:55:42] yeah, to hold them in the deadband [17:55:49] over night [17:55:51] Do probably disabled roll jets and kept the 4 PY jets on [17:55:57] So [17:56:10] But with that it seems to work well [17:59:29] from Apollo 11: [17:59:30] 151:52:27 McCandless: Mike, over here on page 9-7 of your checklist where we're setting up PTC, there's been a note penciled in after: 'Wait 20 minutes for rate to damp. Do not monitor Verb 16, Noun 20.' It turns out that the significance of that is that, if you are monitoring 16 Noun 20, then when you get down here in step 7, the second time you do a Verb 24, you've got to reload the Noun 01, to make it 'Verb 24, Noun 01, Enter', before you [17:59:31] load the three registers. Over. [18:00:28] So if we exit the F 50 18 it should work as written? [18:00:42] Or is that just for the N20 display [18:02:01] I just pre-ordered DCS: F-18. Quite excited. [18:02:13] if you don't exit V50 N18 I would have thought [18:02:18] oh, hmm [18:02:43] so when you do the first V24 N01E [18:02:51] does it revert to V50 N18 after that? [18:03:00] V24E should work as long as it still has a N01 up [18:03:01] Yes [18:03:10] And Thymo I am looking forward to that as well :) [18:03:24] so maybe in Comanche055 the 50 18 is more persistent :D [18:03:40] Thymo, have you seen this? [18:03:41] https://www.youtube.com/watch?v=bUbacP5uq9s&feature=youtu.be [18:04:26] indy91 after the first 3 enters following the first V24N01 it brings back the F 50 18, thats where the V24 by itself failed to work [18:04:36] yeah [18:05:53] rcflyinghokie: Looks quite impressive! [18:05:53] Ok those groups are added to the checklist [18:06:13] Can't wait for the multicrew F-18. [18:06:19] Haha that will be fun [18:06:25] I will need to get back into DCS [18:07:02] indy91 this also means Apollo 11 needs the G&N PTC procedures as well [18:07:26] I will probably need a new GPU to properly play DCS again. I' [18:07:34] I'm still running a 7950. [18:07:50] probably, yes [18:07:54] And I'd really ought to get TRACK-IR [18:09:52] Looks like 10 used the 30deg Db procedure for the rest fo TLC [18:10:12] Hey gents [18:11:22] hey lotisully86! [18:11:47] Finally figured this out [18:12:42] Welcome! [18:13:13] Not sure if it was already mentioned but there is a procedure for setting up ptc in the Apollo 16 aoh v2. I’ve tried it on 11 and 10 and it works [18:13:47] yeah, we were just trying that [18:14:08] just one part of it doesn't seem consistent with the AGC version we use for Apollo 10-13 [18:14:26] the part where the address 1013 is nulled and set to 70000 [18:14:31] Omitting that part seems to work properly [18:14:46] Right the inhibit manuever part [18:14:54] yeah, it's not super important. It just gives control over when the roll rate is actually started [18:15:58] oh! [18:16:00] HOLDFLAG [18:16:03] 1332 [18:16:13] that's its own erasable address, lol [18:16:19] that instead of 1013 [18:16:22] I bet that will work [18:18:24] But was that even used [18:18:52] what do you mean? [18:19:07] It only mentions the last enter of the V24 part as the starting of the maneuver [18:20:03] you mean the comment in the Apollo 10 transcript [18:20:30] 029:05:33 Duke: That's negative, John. You - you wait 20 minutes - all that down to "wait 20 minutes" is good. Then you go to Manual Attitude Pitch and Yaw to Accel Command. You enable all the jets, and then you let the DAP start - stop - start the roll rate by doing the Verb 21 Noun 01 Enter and the Verb 24 Enter, and on the last Enter, the thing ought to take off and roll, and when the roll is attained, the Manual [18:20:30] Attitude Roll goes to Accel Command. Then you increase the deadband to the desired value and the Manual Attitude pitch and yaw to the Rate Command. Over. [18:20:32] Yes [18:20:40] On the last enter [18:21:09] right [18:21:18] so maybe on Apollo 10 they didn't do that inhibit part yet [18:21:44] but at some later point they probably did [18:21:46] Thats what i am thinking [18:22:07] They do mention the V24 and not a V24 N01 [18:22:17] I wonder if the 50 18 needs to be cleared first? [18:22:23] hmm [18:22:33] No that collapses the deadband [18:22:58] oh, it does? I thought only entering V48 again does that [18:23:18] in that case [18:23:24] just do a V24 N01E [18:23:28] instead of V24E [18:24:30] either the V24 or the 50 18 must behave differently in the AGC version to which the AOH procedure applies [18:25:07] Once you enter the deadband there’s no way to get back to p00h without collapsing it unless you enter it before you enter on the 50 18 [18:25:28] Yeah i thought there was a reason to leave the 50 18 up during [18:25:44] Yeah I have V24 N01 in the checklist [18:25:59] ah right, even V37E 00E is bad then [18:26:05] Yes [18:26:09] When should one clear the 50 18 with an enter then? [18:26:22] After the maneuver starts? [18:26:36] Or after the deadband is set [18:26:48] After the deadband [18:27:06] oh, the AOH procedure does it after the 70000E [18:27:08] step 7 [18:27:18] I have mine after the deadband is entered [18:30:09] Actually come to think of it I may have been setting up the deadband after the first pro on dap load...I would start the roll rate then load the dap 5.0 db, pro and then load the 30 db and pro my way to p00h that way [18:33:33] The checklist mfd procedures work properly [18:33:44] Now to figure out the settings for TEC [18:33:55] And to add them to Apollo 11 [18:41:29] @indy91 in the rtcc which setting should be used calculating mcc2? I thought it was 4 but I only got 5 to work [18:41:40] For Apollo 15 [18:41:55] it probably should be option 4 [18:42:04] non-free return, fixed LPO [18:42:24] if you have a scenario where option 4 didn't work, then I can try to debug the issue [18:43:51] Yeah I’ll need a few minutes how do I post on here thru dropbox? [18:44:25] that will work, yeah [18:46:13] I’m already up to loi using option 5 :/ oh well [18:47:21] do you have any scenario between TLI and MCC-2? [18:48:08] the main issue with option 5 is that your approach azimuth to the landing site won't be right [18:48:37] which is not so good for the terrain model in the LGC [18:49:50] nominal approach azimuth is -91° [18:49:59] I kind of doubt it will be much different for you [18:50:07] so you might be ok [18:50:09] Right ya, I have a few saved ones just lamenting [18:50:15] ah [18:50:41] I'm surprised that option 5 would work when 4 doesn't [18:50:44] they are mostly identical [18:50:54] indy91 did Apollo 11 do any PTC? [18:51:07] uhh, of course they did [18:51:08] Or was it all drifting flight during sleep, I cannot remember [18:51:21] flight plan is full of PTC [18:52:01] your RCS quads and a bunch of other systems wouldn't appreciate the lack of PTC [18:52:49] Sorry Apollo 9, not 11 [18:52:55] I know 11 did [18:53:01] oh [18:53:02] Any lunar flight had to [18:53:06] indeed [18:53:10] Apollo 7 did as a test [18:53:11] Typo on my part [18:53:15] I'll check for Apollo 9 [18:53:25] I dont remember any on 9 [18:56:08] can't find anything [18:56:12] probably didn't do any [19:03:27] Ok [19:03:44] And 11 did the 30 deg throughout the mission [19:03:50] So I added that to the checklist there [19:08:06] https://www.dropbox.com/s/nxtzng9ohk4mguo/Apollo%2015%20-%20Launch%200001%200001%200003%200001%200001.scn?dl=0 [19:09:45] @indy91 that scn is around 26 hrs i believe [19:10:36] great, thanks [19:17:29] Off to work, catch you guys later! [19:18:30] cya! [19:52:51] Well I am glad we finally have the right PTC procedures in place [19:53:05] Both the 20 and 30 deg seem to work correctly [19:53:32] I never really noticed that they all were SCS until today honestly [19:53:43] SCS in the checklist mfd I mean [19:59:19] right [20:27:03] night! [12:33:46] hey [12:36:19] hey [12:36:56] is 60x during tlc okay, it doesnt seem to be a problem [12:47:01] as long as your frame rate doesn't drop to nothing [12:47:18] I'm using 50x during TLC regularly [15:27:22] @indy91 hi again [15:27:37] hey [15:27:52] do you have a link to those microtextures [15:27:59] sure [15:28:32] i am beginning loi day now [15:28:39] http://users.kymp.net/p501474a/Orbiter/MicroTextures.zip [15:28:53] thanks [15:29:15] no problem [16:06:47] morning! [16:16:20] hey Mike [16:17:07] so i have a question about mcc4 [16:17:33] i am on a free return so do i have to do an option 1? [16:17:39] the dv was 1.4 [16:18:15] option 1 just targets a specific point in space [16:18:24] the coordinates on that page, latitude etc. [16:18:36] it is always used for MCC-3 and 4 [16:18:43] 1.4 ft/s is really low [16:18:50] maybe not necessary to do [16:18:59] okay [16:19:13] unfortunately I haven't yet added a page to the RTCC MFD to aid that decision to burn the maneuver or not [16:19:17] I will eventually [16:19:47] for Apollo 8 the decision for MCC-4 was a specific DV [16:19:57] but for all other missions it was a bit more abstract [16:20:23] mostly the constraint that LOI can be targeted normally [16:29:05] thewonderidiot, tell me about Block I schematics [16:29:17] nothing to tell yet? :D [16:29:43] they've been at the scanning center for 36 days [16:29:47] not that I'm counting :P [16:30:01] you aren't counting... in days [16:30:13] hours or minutes instead [16:30:20] lol [16:30:30] 36 days is a long time [16:30:41] but you said something about some preparation they did? [16:30:44] nearly 3 weeks of that were spent in the book freezer [16:30:46] yeah [16:30:47] ah, that [16:31:07] so they've been out for a bit now [16:31:24] realistically we might see something this week, if we didn't get preempted by some other scanning thing [16:32:21] great [16:34:04] in the mean time I'm making schematics for the B16/B17 Rope Driver module in this AGC [16:34:10] lots of circuits changed here [16:34:22] and the schematics in ND-1021042 are remarkably bad/hard to follow [16:34:37] unfortunate [16:36:20] haha, yeah [16:36:46] oh well [16:36:50] we can reconstruct it :D [16:41:13] we don't have any Block I version that would have been used by astronauts, right? [16:41:28] just those semi-automatic ones like Sunburst? [16:41:56] yeah, we've only got Apollo 4 and 6 [16:42:08] and will have AS-202 when Francois finishes his rope reader [16:42:14] no Apollo 1 software [17:10:43] so i just need the landing site refsmmat right? [17:12:13] at the time of MCC-4? [17:12:20] yes [17:12:25] i am scrubbing it [17:12:30] ok [17:12:36] yeah, just the REFSMMAT [17:12:47] use the "LS during TLC" option [17:13:14] what is the difference between them? [17:14:57] "LS during TLC" option uses the nominal trajectory for the REFSMMAT calculation [17:15:07] Landing Site option uses your current trajectory [17:15:13] okay [17:15:20] so before LOI, it's best to use the "LS during TLC" option [17:15:48] i think there is another landing site refsmmat in lunar orbit right? [17:16:45] yep [17:16:48] a small update [17:17:01] there you would use the normal Landing Site option [17:17:20] and is that is a non desired? [17:17:40] for the CMC that's still a Desired REFSMMAT [17:17:53] the LGC has no REFSMMAT before activation [17:17:58] okay [17:18:09] so during LM activation, the LGC needs a direct REFSMMAT uplink [17:18:12] last time i did do a non desired one i cant remember when [17:18:15] same one as the CMC gets [17:18:43] probably doesn't hurt much [17:19:01] but only because the REFSMMAT wouldn't change much from before LOI [17:19:21] if you uplink a REFSMMAT directly, then you can destroy your alignment [17:19:49] so always be careful with that :D [17:20:47] and also i did this last night https://www.youtube.com/watch?v=MJU-cKY4pHY [17:21:01] if you uplink a REFSMMAT to the CMC that is different than the one you had before by e.g. 0.1°, then during your next P52 you would get gyro torquing angles of the same magnitude [17:21:25] oh nice [17:21:58] and not that it matters now but for the ptc refsmmat should the tig be at tli ignition or cutoff? [17:22:27] really depends on the mission [17:22:33] not quite sure what they used for Apollo 11 [17:22:38] the sources vary [17:22:50] usually they seem to have used the time of TEI [17:23:07] the average TEI for the launch window though [17:23:17] for mcc3 which i scrubbed put the tli cutoff time 2:50:00 and the attitude was not in gimbal lock [17:23:23] and another source has TLI ignition during TLC [17:23:45] the time input for the PTC REFSMMAT is only relevant to one of the axis [17:24:00] one of the axis used is the Earth-to-Moon axis [17:24:16] and you can imagine it won't change by any significant amount from TLI ignition to cutoff [17:24:26] only as much as the Moon travels around the Earth in that time [17:26:01] yeah its only 5 minutes and 33 seconds [17:26:20] and the Moon needs about 28 days to travel around the Earth [17:26:26] so if 28 days equals 360° [17:26:39] then 5 minutes isn't much :D [17:27:40] so are you still working on 9? [17:29:13] yeah, I am [17:29:17] i am gonna do that after 11 [17:29:21] just didn't have much time for it in the last few days [17:29:52] not looking forward to the manual tvc burn [17:31:08] oh, I found it great fun [17:31:16] it's challening though [17:31:21] challenging* [17:31:29] maybe with a bit of practice i might like it [17:31:42] do you have a joystick? [17:31:51] no just a keyboard [17:31:54] hmm [17:32:07] it's more challenging without joystick [17:32:14] i have a flight yoke [17:33:13] would that work? [17:33:24] hmm [17:33:35] I mean, all you need is pitch and yaw :D [17:33:46] roll is controlled automatically [17:35:07] unfortunately the assigned axes will probably be pitch and roll [17:35:15] cant wait for apollo 13 in nassp [17:35:23] you can fly that right now [17:35:37] but arent their different checklists? [17:35:38] it's not much less supported than Apollo 11 [17:35:49] there is no Checklist MFD file for Apollo 12 and later yet [17:36:09] so you would need to follow printed out paper checklists [17:36:18] instead of using the Checklist MFD [17:36:49] which is a step more challenging [17:37:06] with the Checklist MFD it really helps you to not miss any switch setting [17:37:40] well there are checklists but just no flight plan [17:37:56] the full Apollo 13 flight plan is available [17:38:53] i meant the checklist mfd [17:39:36] there is nothing specifically for Apollo 13 in the Checklist MFD yet [17:39:45] what about 12? [17:39:50] only 7-11 [17:39:54] okay [17:40:00] there is a generic Checklist MFD file [17:40:05] which is currentl used for 12-17 [17:40:19] it covers most of the steps through TLI [17:41:58] but yeah, for Apollo 12 and later you only have the same tools available as the actual astronauts [17:42:10] no blinking buttons telling you it wants to be pushed :D [17:42:45] you mean the yellow markers [17:43:06] yeah [17:43:17] really helpful to not miss a step in the checklist [17:43:52] but still just a tool to make it easier for NASSP users [17:44:12] so flying a mission without that is more challenging [17:44:54] i could probably use paper checklists for at least the TLC [17:47:39] are their only checklists for 15 for landing missions? [17:48:58] I don't think we have the complete flight documentation for any mission, both CSM and LM [17:49:07] but we are quite close with some missions [17:49:12] 15 is up there [17:49:23] we should have a lot for Apollo 14 and 16 as well [17:49:33] we have nearly a complete set for Apollo 8 [17:49:51] and other than that it really depends on the mission [17:50:18] Apollo 12 is fairly complete [17:50:34] and it should be quite usable for the Apollo 13 checklists we don't have available [17:51:17] For Apollo 13 we have only have Flight Plan and LM Data Card Book [17:52:39] there is a data card book for 12 too [17:55:28] and there are surface checklists for 11 [17:56:38] did you know about those? [17:58:33] I'm pretty sure I know about all the Apollo checklists that are currently available online, haha [17:59:05] for some of them I was the one that initiated the process of making them available [17:59:13] nice [17:59:38] like this one? https://www.hq.nasa.gov/alsj/a11/surface11.html [18:03:10] no, I've had nothing to do with that one [18:03:33] but you would need that document if you wanted to fly an Apollo 11 mission without Checklist MFD [18:03:52] Hi [18:03:59] hey [18:04:18] hey [18:05:15] @lotisully86 are you flying any missions? [18:07:01] Currently I was trying out 15 just to see what works I’ve made it up to doi [18:07:21] im doing 11 just starting loi day [18:07:49] lotisully86, I guess you know about the current issues with the "DOI as LOI-2" targeting? [18:09:18] the apolune and perilune locations of the 60x170 orbit after LOI aren't always orientated correctly [18:09:19] Yup. My smallest predicted ha is still over 100 nm [18:09:24] hmm, bad [18:09:30] I'll fix that... eventually [18:09:52] the fix really already starts with midcourse correction targeting [18:09:56] so it is rather involved [18:10:52] That’s what I figured. I know I’m I few missions ahead of what is being worked on just testing it out [18:12:15] yeah, support for some of those maneuvers of later missions isn't perfect yet [18:12:20] My loi by the way dvx and y were good dvz was over -1000 [18:13:02] probably has to do with the option5 [18:13:03] option 5* [18:13:34] hmm [18:13:35] maybe [18:13:40] I got option 4 to work btw [18:13:47] I needed to lower the altitude on that page [18:13:51] with 68NM it didn't work [18:13:54] 60 worked [18:14:03] of course 68NM should be working [18:14:16] I didn't have time yet to figure out why it doesn't [18:14:20] Ya, I used the fixed lpo option for loi to try to save a good orbit [18:14:39] ah [18:14:47] that is probably responsible for the large DVZ then [18:15:17] because the point of ignition was not close to perilune [18:15:45] Right [18:17:11] Looking over the flight plan tho, that bail out burn looks like fun [18:17:27] not crashing into the Moon is fun, yeah [18:18:33] you just need a bit too much PIPA bias [18:18:39] and you end up needing the bailout [18:19:08] or the SPS refusing to stop [18:20:32] No I always insist my sps stop [18:21:46] Orbit with a 3 mile apopsis not to much room for error there [18:23:18] talking about LOI and DOI targeting almost makes me want the documentation for it [18:23:35] because, I know the documents I need to implement the calculations exactly as they were done by mission control! [18:24:04] they just aren't available yet [18:24:42] we have the documentation available for the translunar MCCs, which is why I was able to implement all these different options [18:25:04] although, we don't have it available for the relevant missions [18:25:17] Are these part of the list waiting to be scanned? [18:25:33] by personal list, yes :D [18:26:00] Ron Burkey once went to that archive and scanned all the first pages of the documents [18:26:14] so we know what documents we could get [18:27:13] MIT wouldn’t have any of these docs archived would they? [18:28:32] no, those are at NARA [18:28:43] National Archives and Records Administration [18:28:54] MIT wasn't involved in this anyway [18:29:03] it's all Manned Spaceflight Center documents [18:29:25] they wrote requirements documents, and IBM made it into computer programs [18:29:27] Oh ok ya sorry I was thinking agc development [18:29:30] I think that's how ti worked [18:29:50] oh, some early AGC documentation is still interesting for this [18:30:00] the AGC developers were quite ambitious [18:30:17] early on there were onboard programs for: DOI, lunar liftoff time calculation [18:30:27] lunar landing time calculation [18:30:38] was all deleted because of lack of memory in the AGC [18:30:57] but we have some guidance equations for these [18:31:35] That explains why you have program numbers in the 60’s but not 60 programs then I guess [18:31:46] yeah, indeed [18:31:56] that's how you end up with P12 being the lunar ascent program [18:35:23] Out for a bit, c ya [18:35:47] cya [18:41:46] also is there a slingshot maneuver for 11? [18:42:08] yes [18:42:19] couldnt see it [18:42:19] your S-IVB should have done one [18:42:36] possible that it still impacted the Moon though [18:42:48] i did see the burn on apollo 10 [18:42:59] from the csm [18:43:56] well time to get back to my loi now [18:43:59] it was a bit different on Apollo 11 [18:44:07] bye [18:44:07] oh [18:44:19] you probably didn't enable the slingshot maneuver [18:44:26] how do i do that? [18:44:27] the MCC would have done that on Apollo 10 [18:44:35] through the Project Apollo MFD [18:44:48] on the IU page [18:44:49] guess its too late now [18:44:54] haha, yeah [18:45:10] Timebase 8 Enable is the command [18:45:11] not really concerned about that [18:45:22] yeah, not super important [18:45:46] i will do it for my tli and docking video after loi [18:46:05] sure [18:46:19] well goodbye for now [18:46:54] cya! [18:49:32] for the ls during tlc do i have to calculate my loi first? [18:49:44] nope [18:49:48] that used to be the case [18:49:49] okay [18:49:50] but not anymore [18:50:04] all it needs is landing site coordinates, time of landing, and approach azimuth [18:50:10] should all be pre-programmed in the MFD [18:50:15] it is [20:13:52] hey @thewonderidiot [20:14:15] yo [20:14:46] i dont know if your the right person to ask but i just did loi for apollo 11 and my vertical velocity is 250 is that normal? [20:14:57] no idea :D [20:15:01] okay [20:15:15] maybe loi will make it better [20:15:20] loi 2 [21:53:06] so how long have you been with Nassp? [22:11:43] astronauthen96__: just checked -- I started talking to indy91 in August 2016 [23:20:06] @thewonderidiot i started talking to him in last December [23:20:17] but im not a developer [11:06:04] good morning [11:06:16] about to do doi [11:09:11] hey [11:09:19] LM activation all done already? [11:09:25] yeah [11:09:32] and i did the seperation burn this time [11:11:17] and i am rather confused about this minimum impulse [11:11:41] PGNS or AGS minimum impulse? [11:12:11] the manual attitude control is quite slow for the pre doi p52 but not for the insertion one [11:12:20] i think its in pgns [11:13:30] there might be a difference between ascent and descent stage [11:14:34] hmm [11:14:35] no [11:14:46] minimum impulse mode is only different in the docked case [11:15:30] so what is that you are confused about? [11:15:41] minimum impulse mode fires the RCS thruster for exactly 14ms [11:16:15] and heavy LM with descent stage versus light LM with ascent stage and most APS propellant gone makes a significant difference [11:16:17] i tried the minimum impulse after insertion but its still not as slow forthe pre doi p52 [11:16:45] i was thinking it could be the weight [11:16:56] yeah it is [11:17:12] full LM with descent stage is like 35000 pounds [11:17:21] and empty LM ascent stage is 7000 pounds [11:17:26] but the RCS is the same [11:17:33] so it's way overpowered for the ascent stage [11:17:46] you don't have as significant differences in the CSM [11:18:03] the better comparison is SM RCS with the CSM versus CM RCS with the CM [11:18:08] the CM RCS feels overpowered as well [11:19:23] and would having the cabin fan on affect anything? [11:23:51] in the CSM or LM? [11:23:59] in the CSM it certainly does [11:24:02] lm [11:24:10] not right now I think [11:24:31] but it probably will be like in the CSM eventually [11:24:38] yeah its kind of quiet in the lem without it on [11:24:40] no cabin fan, lack or air circulation [11:24:45] of* [11:25:06] and I think that causes the temperature to go up and the CO2 level to rise [11:25:14] so one cabin fan should always be on the CSM [11:25:28] LM doesn't have a crew health simulation yet [11:38:46] not looking forward to the rendezvous [11:40:42] does not look easy [12:36:02] landed [12:57:07] i think my roll might have been off [12:59:49] @indy91 i couldn't see the moon out the window for most of the descent like i did last time [13:19:34] was the last time Apollo 11 as well? [13:24:21] what do you mean? [13:25:37] last time it was 11 [13:25:57] and which misison was it this time? [13:26:01] mission* [13:26:14] same [13:26:24] that's what I meant with "was the last time Apollo 11 as well?" [13:26:31] okay [13:26:41] which window are you looking out of? [13:26:47] left [13:27:03] below the left window is the LPD window [13:27:11] that is what you should be looking out of [13:27:33] but i did land successfully [13:27:43] with P65? [13:27:49] yes at the end [13:28:14] if you want to have any chance at a successful, non-automatic landing, then you need to use the LPD window [13:28:24] it was automatic [13:29:08] then you don't need to look out at all, haha [13:29:15] i dont think its possible to save and reload during the burn is it? [13:29:19] nope [13:29:29] best point is before Average G in P63 [13:29:34] which means, before T-35 seconds [13:29:39] before the DSKY blanks for a moment [13:29:51] you technically can save during the burn [13:29:59] but the accelerometers don't like to too much [13:30:09] so your landing would be off a bit [13:31:06] so am i the only one flying 11 right now? [13:31:13] no idea [13:31:30] i noticed some errors in the checklist during lem activation [13:32:02] try to remember them until rcflyinghokie joins us here the next time [13:32:05] mostly with the comm switches [13:32:39] i dont remember what they were but in the mfd it would say something but when flipping the switch it was something else [13:32:49] hmm [13:33:05] not sure if that made sense [13:33:45] the text of the checklist and the switch that is blinking are not the same, right? [13:33:57] on some items [13:34:07] comm switches [13:34:19] it the error CDR vs. LMP side? [13:34:20] the switch was right but not the position [13:34:23] ah [13:34:32] mostly on the lmp side [13:34:43] and the 4 and 2 jet switch as well [13:34:49] before pdi i think [13:35:13] yeah, if you know the approximate place in the timeline, then rcflyinghokie will find it [13:35:29] should it be 4 jets for pdi [13:36:51] probably, yes [13:39:42] yes it 4 jets in the apollo 12 checklist [13:40:06] which one? [13:40:25] it might not have been pdi its the activation checklist [13:41:16] the Apollo 11 LM Timeline Book says at T-4 minutes to "check DPS Config Card" [13:41:25] and we have that cue card for a later mission [13:41:35] basically says a bunch of switch settings for a DPS burn [13:41:40] and 4 jets is among that [13:41:54] switch is only used by the AGS anyway [13:41:58] i am pretty sure i had it on 2 jets [13:44:37] next time you know the right switch setting [13:44:40] and so did you on your 11 landing video [13:44:42] and it's not critical at all anyway [13:45:02] I'm not sure if the switch was even doing anything when I did that video :D [13:45:14] yeah its from 2016 [13:45:32] but I definitely don't have all the switches in the right position in those videos [13:45:42] im gonna create a save closer to pdi ignition [13:45:48] might as well do the landing again [13:46:03] practice is good [13:46:16] and doing a landing with P66 is definitely possible without a joystick [13:46:26] not much to practice if the landing is automatic though [13:46:37] guess i could try a manual landing [13:46:38] right [13:46:54] but last time it started ascending [13:47:15] in P66? [13:47:33] cant remember [13:47:41] P66 is the Rate-Of-Descent mode [13:47:54] where you control the rate of descent (ROD) with the switch for that [13:48:00] P67 is the fully manual mode [13:48:06] i think as soon as i started controlling it [13:49:20] if it happens again, you could make a video of it [13:49:45] i will [13:53:42] and i guess there will be no v8 for 2010? [13:56:26] hmm [13:56:30] maybe there will be [13:56:38] we have a development branch for that [13:56:45] but it hasn't been updated in a while [13:56:57] i prefer 2016 [13:57:11] as a user I prefer 2016 [13:57:27] but it has a bunch of difficulties for development [13:57:36] 2010 is much nicer on the frame rate as well [13:58:12] not for time acceleration the spacecraft maneuvers alot [13:59:20] uhh [13:59:28] that's not a Orbiter 2010 issue [13:59:50] you should configure your CSM or LM so that it doesn't fire thrusters at all during time acceleration [14:00:00] yeah [14:00:32] it doesnt do that in 2016 for me [14:01:23] also is it normal for the vertical velocity to be at 250 in between loi 1 and 2? [14:01:48] not sure, it might be [14:01:55] your orbit should be 60NM x 170NM [14:02:15] it was [14:02:25] then it's all right [14:02:37] loi 2 brought it to zero [14:02:44] never checked what the maximum altitude rate is in the intermediate orbit between LOI-1 and 2 [14:02:53] yeah, after LOI-2 your orbit is circular [14:08:14] and also had some ecs issues before lem activation [14:14:07] couldnt open the lem hatch [14:16:03] and i was getting a yellow cyro warning light and my cabin pressure was almost at 4 psi [15:11:39] just cant remember how i fixed it [16:33:32] for apollo 9 do i just need the orbit numbers for the sps burns? [16:35:41] @indy91 i can see them in the flight plan [16:54:00] was cryo pressure or quantity low? [16:54:24] and for Apollo 9, orbit number for what? Calculating the burn? [16:54:46] yes [16:54:52] the burn [16:55:03] my cabin pressure was low [16:55:28] and i had the repress package on and the tunnel venting [16:57:13] morning! [16:57:25] Hi Mike [16:59:34] astronauthen96__, tunnel venting with the LM docked or not? [16:59:44] yes before activation [16:59:59] ah [17:00:08] just make sure you aren't venting into space the whole time :D [17:00:09] hey Mike [17:00:25] i think it was another checklist error [17:00:53] https://www.ebay.com/itm/Apollo-16-17-Lunar-Module-Contingency-Checklist-Owned-By-NASA-Flight-Director/291942246579?hash=item43f91d28b3:g:e5EAAOSwHMJYGzQC [17:01:02] i think it was supposed to be at LM PRESS [17:01:21] UHCL also has that one [17:01:57] ah nice [17:02:38] can't find it right now [17:02:56] ah [17:03:01] APOLLO 17 ALL LAUNCH DATES BASIC LM ( LUNAR MODULE ) CONTINGENCY checklist [17:03:09] APOLLO 17 ALL LAUNCH DATES CHANGE A LM ( LUNAR MODULE ) CONTINGENCY checklist [17:03:16] APOLLO 17 ALL LAUNCH DATES CHANGE B LM ( LUNAR MODULE ) CONTINGENCY checklist [17:03:47] all already scanned [17:04:49] also will there be scenarios for different launch dates [17:05:10] yes there will be [17:05:18] I even have some preliminary ones right now [17:05:23] for Apollo 11 [17:05:29] July 18th and 21st launches [17:05:34] for V8? [17:06:03] yes, I would like them to be supported by the MCC for Apollo 11 [17:06:44] APOLLO 16 AND APOLLO 17 ALL LAUNCH DATES CHANGE B LM ( LUNAR MODULE ) CONTINGENCY checklist [17:06:51] that's exactly the one on ebay [17:06:59] also already scanned [17:07:06] just had no need to request it yet [17:07:30] there are also some Apollo 1 checklists [17:07:41] if we want procedures for Block I [17:12:16] also my maneuvers appear to be heads up [17:13:16] @indy91 do you have a before TEI scenario for 10? [17:13:30] yes [17:13:54] thewonderidiot, do we have any document called "Guidance and Navigation Summary"? [17:14:05] is that an early Delco Manual? [17:14:24] no, that's that silly trifold pamphlet with hotel room phone numbers [17:14:31] ah, lolo [17:14:33] lol [17:14:56] pretty sure at least [17:15:13] astronauthen96__, I can get you the scenario later [17:15:15] do you have one before final undocking [17:15:17] okay [17:16:18] thewonderidiot, did that document have 512 pages? [17:16:19] :D [17:16:20] actually I'm wrong [17:16:25] I'm looking at Guidance and Navigation Information [17:16:48] APOLLO 10 GUIDANCE AND NAVIGATION SUMMARY // CM ( COMMAND MODULE ) SOFTWARE * LM ( LUNAR MODULE ) SOFTWARE * ASPO ( APOLLO SPACECRAFT PROJECT OFFICE ) 45 CRT ( CATHODE RAY TUBE ) DISPLAYS * LAUNCH AND BURN SCHEDULES * BURN PERTURBATIONS * ENTRY * OPTICS * PIPA ( PULSE INTEGRATING PENDULUM ACCELEROMETER ) * COARSE ALIGN FINE ALIGN * digital autopilot * MISCELLANEOUS [17:16:53] oh yeah [17:17:08] that's the same as the Apollo 15 and 16 Delco manuals we have [17:17:13] yeah [17:17:22] probably still doesn't help me with DAP padload... [17:17:27] and Lauren couldn't scan them because of the way they are bound [17:17:33] ah, I remember [17:17:47] and yeah, probably not :P [18:39:07] astronauthen96__, so what scenarios do you want? [11:40:56] good morning [11:41:07] major problem in the csm [11:41:22] looks like my electrical system is failing [11:42:05] that's not good [11:42:11] what's the issue? [11:42:49] getting all kinds of warning lights and the mission timer changes to some wierd number and the LEB timer stops working completely [11:43:03] ouch [11:43:24] and my o2 tank is empty i think [11:43:30] hmm [11:43:55] maybe you were dumping O2 over board the whole time after all [11:44:23] tunnel hatch is closed? [11:44:30] pressure equalization valve as well? [11:45:06] and what about the vent valve? [11:46:42] the rest period before lem activiation i left the tunnel vent on all night [11:46:56] https://www.dropbox.com/s/gixi2dkm3aasw4l/EVA%20REST.scn?dl=0 [11:49:56] I wonder if your configuration at undocking was wrong [11:50:04] in this scenario the hatch etc. are right [11:50:56] in my before activation scenario the o2 is empty [11:51:23] oh [11:51:28] but not before the rest period [11:51:30] then the issue already happened before [11:51:53] maybe you had the pressure equalization valve open and the tunnel vent valve as well? [11:52:10] then the O2 would escape through the hatch and then through the tunnel into space [11:52:15] i think they were open the whole sleep period [11:52:19] and the tunnel vent as well [11:52:27] could that cause electrical issues? [11:52:42] you won't be able to come home [11:52:52] you have almost no O2 at all [11:53:21] it was supposed to be at lem press [11:53:36] probably, yeah [11:53:53] wonder what is causing the electric issue [11:55:05] fuel cells cutting out [11:55:08] due to no O2 [11:55:30] so i dont need to refly the mission then [11:55:46] on the day 4 lem checkout the o2 is high [11:56:15] yeah, just make sure to not dump all your O2 [11:56:30] I think over night the pressure equalization valve should be closed [11:56:38] LM press valve open maybe [11:56:52] that was a checklist error [11:56:54] but press equal valve plus LM tunnel valve open is a veeeery bad combination [11:57:05] I very much doubt that [11:57:16] LM tunnel vent would not be used until before undocking [11:57:23] in mfd it says lem press but the yellow marker wanted it to be at tunnel vent [11:57:29] hmm [11:57:32] so that kind of error [11:57:37] yes [11:57:40] the text is almost always right [11:58:02] flight plan says lem press as well [11:58:04] of course checklists don't replace system knowledge [11:58:14] so next time you know that this is bad, haha [11:58:38] if this happened in real life, before PDI, then there still is a chance for survival actually [11:58:43] the LM could perform TEI [11:58:54] and then you have a Apollo 13 like scenario [11:59:03] have to power down all the CSM systems etc. [11:59:11] is there any chance you could fix my scenario or is that impossible [11:59:18] hmm [11:59:40] I think all you would need is to fix the O2 levels in the tanks [12:00:03] i dont know how to do that [12:00:35] find the line with [12:00:36] O2TANK1 [12:00:38] in the scenario [12:00:50] below that is [12:00:51] CHM 0 1459.406447530015 1458.870617489934 2310970.823964320123 [12:00:58] hmm [12:01:05] this is a bit tricky to fix [12:01:11] 1459 is basically the O2 mass in grams [12:02:00] i do have a scenario before the tunnel vent could i just copy it [12:02:37] I have a good Apollo 10 scenario with a H2 state that is very close [12:02:51] and the O2 state there is [12:02:52] CHM 0 97957.198127232914 0.000000000000 14347652.903150286525 [12:03:01] just replace the CHM lines for O2TANK1 and 2 with this [12:03:41] i will try it [12:04:23] 97957 is a bit more than 1459, haha [12:04:58] do you think it will fix my electrical problem? [12:06:36] it will for sure [12:06:54] your fuel cells just didn't get enough O2 anymore [12:11:55] o2 is back up [12:12:20] you saved my mission [12:12:24] thank you [12:12:54] no problem [12:13:04] and do you have that tei scenario? [12:13:49] Apollo 10? [12:13:53] yes [12:14:02] sure, let me find it for you [12:16:00] https://www.dropbox.com/s/ehc4uuomlfpgujl/Apollo%2010%20MCC%20-%20Before%20TEI.scn?dl=0 [12:16:10] thanks appreciate it [12:16:13] at T-10 minutes, just before entering P40 [12:17:15] i would make a video but its your scenario [12:17:37] haha, feel free to do a video about anything you like [12:17:54] I'm only making videos to show something interesting or new in NASSP [12:18:02] from a developer point of view [12:18:12] still have to make my tli and docking vid [12:18:39] and the 11 tei if i can make it through the rendezvous [12:21:32] I'll try to continue work on Apollo 9 today [12:30:22] hey [12:32:10] hey Alex [13:00:02] whats up? [13:01:35] trying to make some Apollo 9 progress [13:03:35] nice [13:14:56] I'm using some placeholder calculations [13:15:13] for example, I don't really know yet what attitude was desired for the AOT star observation check [13:15:45] so I first will use the attitude from the transcript and then I'll know if it is e.g. the AOT pointing away from the Earth or so [13:22:10] right [13:26:21] other than that, most MCC updates for the LM activation are straight forward [13:29:08] and unfortunately the S-Band antenna checks won't work [13:29:29] because the signal strength simulation right now is only meant for translunar distances [13:29:39] peak signal strength is center of the Earth [13:29:46] any tracking station doesn't matter [13:31:03] could be added though [13:54:52] Hi Alex [13:55:01] hmm I had never tried those checks yet even on translunar flights [13:55:03] hey [13:55:29] just lost my save because of the radio mp3 button [13:55:54] oh yeah, thats a Orbiter Sound bug [13:56:41] Orbiter Sound 4 is not technically designed for Orbiter 2016, hopefully a new version will come soon [13:56:54] now im back to before the eva and i can only go 30x [14:01:27] you need to save more often, haha [14:03:43] indy91, I have been toying with the LVDC azimuth function and it works well for all missions except 17, It seems to always give 72 deg on Apollo 17, even for delayed launch [14:04:03] I'll check [14:04:19] probably looks at the wrong segment of the polynomial or so [14:07:15] oh [14:07:17] or [14:07:25] the issue is that it looks at the wrong day [14:09:02] Apollo 17 scenario starts before midnight GMT [14:09:06] but launch is after midnight [14:10:53] yep [14:10:56] that's the issue [14:12:16] easy fix [14:17:32] AlexB_88, how did you test it? [14:17:41] change the MJD in the scenario? [14:17:52] yes [14:17:59] I just added 1 hours to the MJD [14:18:04] ok [14:18:26] and then tested it immediately after opening the scenario [14:18:43] you can give me that MJD? [14:22:02] yeah, I think that was it [14:22:05] 1 hour later gives me 78° [14:24:21] I used 41657.995127 [14:24:33] yeah, same [14:24:36] it's fixed now [14:24:38] however [14:24:48] launch on time gives me 72.0° exactly [14:24:53] that shouldn't be the case either [14:25:36] it should be more like 72.1° [14:28:41] ah [14:28:53] planned vs. actual liftoff is -0.0001 [14:29:04] and it can't deal with a negative number [14:33:43] the LVDC itself might also have this issue right now [14:33:44] hmm [14:40:49] fixes pushed [14:46:51] thanks @indy91 [14:47:00] at 121 hours with no issues [14:47:18] just needed some oxygen [14:47:28] and i saved this time [15:06:23] does anyone know the keycommands for the lm rcs thrusters [15:06:46] for the number pad [15:06:57] rotation or translation [15:07:13] translation [15:07:20] for the rendezous [15:12:58] what do you want? keys vs. up/down or for the axes displayed on the DSKY during P41? [15:13:06] yes [15:13:24] lol [15:13:33] just which buttons are for which axis [15:13:36] ah [15:13:52] was about to say, that was an "either... or" question, yes doesn't work as an answer, haha [15:14:33] we've talked about this before [15:14:39] and I got all confused about X and Z axis [15:14:41] cant remember them [15:15:15] 1 and 3 are certainly the Y axis [15:15:25] 6/9 is X, 2/8 is Z [15:15:28] so the second register? [15:15:39] yeah, the registers are X, Y, Z [15:16:11] I might have gotten X and Z wrong though [15:16:26] I always forget [15:16:32] i thought i remembered 2 and 8 being x [15:17:41] will there be manuals for v8? [15:18:21] there will be some quick start manual with e.g. keyboard controls [15:18:30] then for more details probably the wiki [15:18:52] and for anything else we probably would just provide links to the AOH and such [15:19:31] why write new manuals if there already are such documents about the real spacecraft [15:19:43] but for any NASSP specific things there should be a manual, yes [15:36:35] astronauthen96__, LM axes: http://www.ninfinger.org/karld/My%20Space%20Museum/lmrefb.jpg [16:19:06] indy91, yep looks good now, 78.0981 1 hour later [16:20:46] found a bunch new MPAD document, no return to Earth targeting yet, but I am still hopeful, haha [16:20:56] cool [16:21:07] what are the new MPAD's^ [16:21:58] one document dealing with FP7 [16:22:09] Kalman verification [16:22:23] and another about FP8, verification of the automatic RR data transfer from LGC to AGS [16:24:50] no new RTCC Requirements yet, but I haven't searched the whole new range yet I found [16:24:52] back in lunar orbit [16:30:05] and in case you forgot again, MPAD stands for Mission Planning and Analysis Division. A division of the Manned Spaceflight Center. [16:30:18] Any document relevant for the RTCC was written by that division [17:05:14] so were in the alpha stage right? [17:05:24] im making a playlist for my nassp videos [17:05:51] NASSP 8.0 is in Alpha, yes [17:05:58] not too long anymore though [17:06:05] Just the MCC for Apollo 9 and 11 needs to be done [17:08:22] and have you looked into that windows 7 issue? [17:11:13] morning! [17:11:30] Hi Mike [17:20:42] @indy91 i just checked the apollo 12 scenario and the yellow markers are there [17:22:24] What Windows 7 issue? [17:22:38] What do you mean with the yellow markers? [17:22:41] Checklist MFD? [17:22:44] the ntdll with the threading [17:22:48] yes the mfd [17:23:00] no, I haven't found what could have caused that [17:23:12] and as I explained, there is a default Checklist MFD file [17:23:16] which gets used for Apollo 12-17 [17:23:21] it should be usable through TLI [17:23:31] but it has no mission specific checklist items [17:23:41] hey Mike [17:23:46] okay [17:25:13] and it might not be compatible with the CMC [17:25:17] of Apollo 14 and later [17:25:40] I wonder if this week will be the week for new schematics [17:26:40] I hope it is! [17:30:44] me too [17:30:48] for my own sanity lol [17:31:22] also I'm starting to think that the Block I manual will hold more insights into the circuitry inside the Block II rope modules than the Block II manual has [17:32:12] haha [17:32:15] that would be fun [18:09:04] it's kinda silly -- ND-1021042 pretty much only says "yeah there's a network of resistors and diodes in the rope modules to make strand selection happen" and doesn't have any diagrams or anything for how they're actually connected [18:11:00] ND-1021041 has two illustrations, "Rope Organization" and "Rpoe Module Organization" that might have this detail [18:11:09] and I think these circuits did not change much between Block I and II [18:12:25] how dare it not have the full details on this [18:12:49] it's very rude [18:13:04] Systems Handbook is like that sometimes [18:13:13] full details, down to relays for some systems [18:13:28] and then almost all of the CSM high gain antenna circuits are basically a black box [18:13:39] lol [18:13:43] yep [18:29:46] so i am trying the rendezvous and i am constantly getting this 06 49 in the dsky do you know what it means it keeps popping up [18:37:43] @indy91 [18:50:25] yeah, so, when the rendezvous radar does a mark on the CSM, it wants to update the LM state vector [18:50:44] but the computer first compares the current state vector and the updated one [18:50:56] if the difference is too large, then it shows you the N49 [18:51:01] which is position and velocity error [18:51:31] then the astronauts check that number and can judge by themselves, if the update is good [18:51:44] it is expected that the first mark gives you a 06 49 [18:51:58] what you have to do to allow the state vector update is press PRO when you see the 06 49 [18:52:06] or else it doesn't do any update [18:52:07] yes [18:52:27] how large are the numbers it shows you in N49? [18:52:33] i can check [18:52:56] the first mark after orbital insertion will almost always have a 06 49 [18:53:19] but once it has converged, so that the updates by the RR are identical to what the computer thinks, then you won't get any more of them [18:53:33] what can also happen is that the CSM state vector in the LGC is off [18:53:39] or the alignment of the LM IMU [18:53:55] if the 06 49s persist, then that might be the case [18:55:38] dont seem to be getting it now [18:55:53] did you press PRO on the ones you were getting? [18:55:59] i didnt do the tig for the state vectors [18:56:10] that's not so critical [18:56:21] yes i pressed pro for all of them [18:56:22] you mean the time tagged state vectors, right? [18:56:38] PDI plus something or so, as it says in the flight plan? [18:56:45] yes [18:56:58] insertion -10 or something like that [18:57:07] yeah, so the RTCC (MFD and in real life) were a little bit better at propagating the state vector [18:57:09] than the AGC [18:57:11] but not much [18:57:18] and in Orbiter it barely matters at all [18:57:26] so you don't win much accuracy with that [18:57:31] and for the alignments i was getting 00005 [18:57:38] good enough [18:58:03] if the 06 49 don't appear again, then you are all good [18:58:13] okay [18:58:13] also gives confidence in the P3X burn solutions for CSI etc. [18:58:32] did you ever try the Apollo 7 rendezvous before? [18:58:36] and im at 8 marks [18:58:41] no i didn't try that yet [18:59:06] the 06 49 don't appear again for you, because the updates by the RR are very small [18:59:12] state vector in the LGC is already accurate [18:59:21] for Apollo 7 that accuracy threshold is disabled [18:59:35] so if you ever do that rendezvous and wonder why the 06 49 don't go away [18:59:40] it's because they never go away [18:59:56] okay [19:18:52] for your apollo 10 scenario did you get your rendezvous right the first time [19:19:29] legends say he has never gotten a rendezvous wrong [19:19:30] :P [19:22:34] probably yeah [19:23:03] I had that one Apollo 7 rendezvous where the clock was off [19:23:16] right, thewonderidiot? :D [19:23:39] that's also a possible cause for the 06 49 not getting smaller [19:24:04] but even then I just had larger midcourse corrections and I still found the S-IVB [19:24:46] when I started using NASSP, the Apollo 7 rendezvous is the only one we could do [19:24:52] and I got it wrong many times [19:25:14] so I learned from the most challenging rendezvous [19:25:26] and when I mastered that, I could do any other rendezvous :D [19:25:51] hahaha [19:26:21] I really thought that was going in the direction of "The only time I got it wrong was that time Mike screwed up the AGC clock" [19:26:23] :P [19:26:42] nah, I had plenty of experience by then [19:26:48] MCC-1 was 10 ft/s or so [19:26:54] which was very unusual [19:27:09] I forgot about that, that was a silly bug [19:27:13] off-by-one errors, bah [19:27:35] small error, great effect [20:11:52] night! [22:23:03] [00:20:36] [13:40:55] good morning [22:23:03] [00:20:36] [13:41:07] major problem in the csm [22:23:04] [00:20:36] [13:41:22] looks like my electrical system is failing [22:23:04] [00:20:36] [13:42:05] that's not good [22:23:05] [00:20:36] [13:42:11] what's the issue? [22:23:06] [00:20:36] [13:42:49] getting all kinds of warning lights and the mission timer changes to some wierd number and the LEB timer stops working completely [22:23:06] [00:20:36] [13:43:03] ouch [22:23:07] Glad to hear my mission timer corruption code is working still :P [22:33:06] lol [11:13:07] good morning [11:13:50] i have a feeling i am not going to get through this rendezvous [11:14:22] hey [11:14:24] why not? [11:15:26] looks fairly complicated [11:15:42] and for the ags update it froze at V47 it didnt do that before [11:16:38] it was in the middle of many 6 49's [11:16:50] the rendezvous just requires practice [11:17:18] once you understand all the DSKY displays and procedures it's not too hard [11:17:56] if you have trouble with performing the rendezvous with the PGNS, I wouldn't even bother with the AGS yet [11:18:19] i guess i could skip the ags updates since im not using it anyway [11:19:06] it can be quite confusing, because the DSKY wants to have like 3 different displays [11:19:22] the 16 45, which you are normally in while taking marks [11:19:26] then occasionally the 06 49 [11:19:43] and then when do in addition to that do a V47, then it gets really confusing [11:20:06] as it takes in more marks the 6 49's gradually decrease i think [11:20:14] as it should [11:20:37] but they also should go completely away eventually [11:21:27] and i checked and the numbers in the 6 49 werent that big [11:21:33] I think rendezvous procedures are a case where some sort of tutorial would help [11:21:49] and where it also actually makes sense to have videos or so [11:21:52] and i have been reading this https://history.nasa.gov/afj/loressay.html [11:21:59] in other cases I would just say "read the AOH" [11:22:18] i think 11 uses the Coelliptic Method right? [11:22:25] yes, that is a good essay [11:22:38] yep, coelliptic method was used until Apollo 13 [11:22:45] well, in the Apollo 13 flight plan :D [11:22:52] From Apollo 14 on they used the short profile [11:22:57] with just TPI, no CSI and CDH [11:24:38] i think the launch puts it in a 45 mile orbit which is why the csi isn't required [11:25:13] for the direct profile? [11:25:17] yes [11:25:21] no, that's not right [11:25:41] the orbit after insertion is not so different between coelliptic and direct profile [11:26:43] for the direct profile TPI happens at about the point where CSI would happen in the coelliptic profile [11:26:53] so the TPI maneuver is quite different then [11:26:59] direction and DV wise [11:27:20] for thr direct profile you need a high accuracy insertion [11:27:25] or else it doesn't work [11:27:50] CSI and CDH maneuvers can fix an inaccurate insertion [11:29:05] also for the lock on with the program 20 i got this program alarm once or twice [11:29:27] maybe it wasn't immediately finding the CSM [11:29:35] yeah it wasnt [11:29:43] that's possible if the alignment or state vector is a bit off [11:29:53] had to got to P00 then restart P20 [11:30:19] there is a procedure to do manual lock-on in P20 [11:30:24] but it can be quite confusing [11:30:31] I've done the back to P00 in the past as well [11:30:54] and P20 also has the option to search for the CSM in a pattern [11:31:43] but the Checklist MFD won't help you with that [11:31:54] it can't really deal with different problems or program alarms [11:32:12] that's where you need to read the G&N Dictionary [11:32:26] or learn all the different things that P20 can throw your way [11:33:05] i will try to make some rendezvous videos once i get past CSI [11:37:35] there are many things that can be done wrong during a rendezvous, so I'll watch them and try to help you improve [11:37:43] okay [11:39:31] and the csi is one axis right? [11:40:19] yeah, the CSI DV is always horizontally [11:40:24] so only in the DVX axis [11:40:41] so that would be 2 and 8 on the numpad i think [11:40:48] oh, that's not what I meant [11:40:57] x-axis like in P30 [11:41:08] which thrusters to use still depends on the attitude [11:41:28] and I think the desired attitude for the CSI burn is windows forward [11:41:37] so in that case you would have to use 6 and 9 on the numpad [11:42:29] you will rarely be in the exactly right attitude with a RCS burn [11:42:49] so for nulling the residuals, you probably will need to use all of the thruster directions anyway [11:42:54] at least a little bit [12:46:02] i am uploading my lunar liftoff video now [13:01:58] morning [13:03:04] hey [13:03:05] https://youtu.be/UYI9C-30yeE [13:03:12] Hi Alex [13:03:28] AlexB_88, we actually have one more abort/rescue document that I totally forgot about [13:03:38] it's from the Michael Collins Papers collection [13:05:35] http://digitalsc.lib.vt.edu/Ms1989-029/Ms1989-029_B13_F1 [13:07:41] oh nice [13:08:34] astronauthen96__ Nice Vid! [13:10:56] yeah, good ascent [15:21:26] thanks [15:38:59] indy91, will that give new insights to the rendezvous programs in RTCC MFD/MCC? [15:39:16] will that new doc* [15:41:06] not much, no [15:41:19] a little bit more detail about CSM rescue cases than I had before [15:43:25] ah right [15:44:44] but nothing really new for the LM [15:45:02] the mission technique documents rarely seem to have good specific information [15:45:38] I think at this point most LM active maneuvers can be calculated [15:47:13] yeah, I just have to make it easier to calculate the Apollo 11/12 PDI+12 maneuver [15:51:05] yeah [15:52:31] also confused about state vectors in the rtcc mfd [15:52:45] with the target and slot [15:54:30] target is the vehicle for which the state vector is calculated [15:54:48] and the slot is an AGC thing [15:55:10] the AGC can store two state vectors at any time [15:55:26] right [15:55:28] one for the CSM and one for the LM [15:55:46] but they don't necessarily have to actually be CSM and LM [15:56:02] like for Apollo 7, where the target vessel is an S-IVB [15:56:14] so the LM slot would be used for the S-IVB in that case [15:56:31] the list of targets in the MFD is simply all vessels in the current simulation [15:56:51] so, if you want to, you can uplink the state vector of any vessel to any (CSM and LM) slot in the AGC [15:57:57] it works exactly the same in CMC and LGC [15:58:03] both have CSM and LM slots [16:01:49] anything still unclear? [16:05:52] nope [16:06:14] i am pretty sure i did the uplinks right [16:10:42] any problems with the rendezvous? [16:12:17] no [16:12:27] just had a long nap so i should be set [16:14:08] gonna try to get past csi today [16:32:26] I had a thought about NTRS [16:32:31] where are the originals? [16:32:51] a document like RTCC Requirements [16:33:26] after scanning, where are the documents now? [16:35:43] I don't think they got the NARA copies, because the first pages that Ron scanned don't have the accession numbers etc. [16:35:55] or it's been that long since Ron was at NARA [16:36:07] probably in some shed somewhere in Houston [16:36:24] but it's not like all of the documents gone from NTRS are suddenly restricted again [16:36:48] they didn't go through them one by one to see if they should be available online or not [16:36:52] that's the whole problem [16:36:56] that is too much work [16:38:18] so either: it should be possible to access the original documents [16:38:30] or I have at least 2 dead links [16:38:43] that I could ask about getting the PDF from [16:39:58] can't be more expensive than NARA to somehow get these documents [16:40:04] or even let them be scanned again or something [16:40:55] There also is the possibility that a document like the Requirements for the Return-to-Earth Processor were uploaded to NTRS in 2012 and taken down again in 2013 [16:41:14] in that scenario NTRS did have these documents, but they still can't be accessed [16:41:24] because the last archived version we have is from 2011 [16:50:53] Evening [16:51:08] morning! [16:52:56] hey Thymo and Mike [16:57:31] what's up? [16:57:50] just getting annoyed about NTRS again [16:57:54] see above :D [16:58:01] haha [17:01:26] hmm [17:01:34] I think the documents came from various sources [17:02:07] like I'm pretty sure some came from NTIS [17:02:12] yeah [17:02:16] who I've called and they say they no longer have their documents [17:03:48] I also think some came from the Smithsonian at some point, based on the Bellcomm Technical Library stamps on a lot of them [17:03:56] right [17:04:05] but where would these MSC documents be now? [17:04:26] oh [17:04:30] Bellcomm [17:04:39] the relevant documents also have that stamp [17:05:07] any word on the 11 checklists? [17:05:49] from the Smithsonian? [17:06:04] I think it's been a while since Ryan heard the last time about it [17:06:21] https://sova.si.edu/details/NASM.XXXX.0093?s=0&n=10&t=C&q=&i=0 [17:06:39] but I don't think everything is there so [17:06:44] I'm not sure [17:08:20] nothing about RTCC on that page [17:09:18] almost all of these RTCC documents have the "Technicanl Library, Bellcomm" stamp [17:10:08] back in a bit [18:08:41] blah [18:08:51] I'm starting to have dreams about scans showing up on our archive.org page <_< [18:09:49] i have had dreams about nassp [18:10:36] I remembered I was given a time estimate so I went back and checked my emails [18:10:40] and found this line: [18:11:10] "If retrieving, I believe we can have these turned around within a week if mold/mildew management is swift." [18:11:14] and here we are six weeks later lol [18:11:28] blame the mold then :D [18:11:36] damn mold! [18:38:37] I guess I shouldn't complain too much -- the pages are in remarkably good condition for having spent several decades in an unairconditioned Florida garage [18:40:58] haha, yeah [20:43:46] night! [13:29:21] Log ended by Thymo, total logging length 790730 seconds [13:29:22] .endlogging