[15:03:47] NASSP Logging has been started by thymo [16:49:55] morning! [16:55:13] hey Mike [16:55:24] hey [17:08:58] I made a Sundial video [17:09:01] oh nice! [17:09:04] should be uploaded in about 5 years [17:09:11] hahaha [17:09:25] I was just typing in your youtube channel but I guess I will wait then :D [17:10:23] yeah [17:10:45] I had a bunch of good video ideas lately, but there was always one or two things I wanted to implement first [17:10:52] but Sundial was of course simple enough [17:12:13] hey [17:12:47] hey Alex [17:16:30] hey [17:16:34] what other videos do you have planned? [17:17:00] weird mission techniques [17:17:05] your on the way home with Apollo 8 I assume? [17:17:12] like if CSM/LV sep isn't working [17:17:17] you're* [17:17:27] then you lower the perigee with a S-IVB LOX dump to 80NM [17:17:35] and then separate the CM directly from the SM and Saturn [17:17:44] oh jeez [17:17:48] and do the rest of the deorbit with the CM [17:17:56] which kind of works [17:18:00] a bit tricky [17:18:12] AlexB_88, yep, I'm past TEI [17:18:37] and the other thing is a super short rendezvous profile [17:18:50] another contingency, with e.g. the LM ascent stage water tank [17:18:53] nice, you should do a V37E01E during TEC for added realism :D [17:18:57] if that has a leak [17:19:17] then you lower the CSM orbit to 11x60 [17:19:29] do orbital insertion with the LM at 10NM as usual [17:19:45] but timed in such a way that you a exactly 1 mile below the CSM at insertion [17:19:55] and the braking phase starts exactly then [17:20:06] that's if you have a time critical leak or so [17:20:14] one that only causes problems after lunar liftoff [17:20:25] like a ascent stage water tank leak [17:21:20] or probably rather the plumbing from it [17:21:49] that is the case they mentioned in the LM Abort and Rescue Plan anyway [17:22:48] and maybe I'll make a series on all the Apollo 11 rescue cases [17:22:55] I wanted to fly them all at least [17:22:59] haven't continued that yet [17:23:14] I think I've done the first two one, partial DOIs and then CSM needs to come and rescue [17:23:22] first two ones* [17:24:35] I hope Michael Collins doesn't seen those videos, we would get PTSD from pre-mission training [17:24:42] he* [17:25:27] him complaining about rescue cases being such a huge part of the training lead to the development of MINKEY [17:30:13] haha really? [17:30:17] I didn't know that [17:31:53] yeah, there is a big monologue in the technical debriefing [17:32:03] and I'm sure that set the development of it in motion [17:32:11] because MINKEY is directly what he was requesting there [17:38:39] "From the command module viewpoint, with one man inside the command module, I think the procedure should be simplified, and if that requires a greater degree of automation, then I think we ought to have more automation." [17:39:11] and I'm sure there is a relevant Tindallgram [17:39:14] there always is [17:46:27] hehehe yeah [18:02:49] hmmmmmmm, I wish I knew how full banks 31 and 32 were for LUM131 rev 9 [19:02:47] you weren't joking about that video taking forever to upload :D [19:06:51] yes [19:07:10] to be fair, I also screwed up the settings and the file became larger than necessary [20:38:40] thewonderidiot, did you ever talk to your company lawyer about the LVDC listing? [20:39:42] and another question which I might not even want to know the answer to, did you acquire the LVDC listing yet? :D [20:42:25] indy91: yeah, he wasn't sure. he pointed me to a government portal where we can make official requests [20:42:27] and not yet! [20:42:31] I should ask Ron about that [20:43:55] official request [20:44:03] so the answer will be no, in about 1-2 years [20:44:15] yeah [20:45:56] I need to tell Ron about that, in case he decides to try it [20:46:00] but I'll be amazed if he does, haha [20:46:12] yeah, I have the feeling that could hurt more than it helps [20:47:24] I guess he is still at the point where he tries to understanding how the listing and the LVDC language works [20:47:45] thinking about an emulator, without a connected simulation it would be even less useful than the AGC [20:47:56] and it doesn't even have something like the DSKY [20:48:03] so just telemetry [20:48:29] but if we ever get to that point I can contribute a simple launch simulation to the project [20:50:24] the LVDC just has a handful of true output bits [20:50:37] during a simulated launch it of course sends many commands to the switch selector [20:50:56] so in an emulator you would best have a display with the various commands that each stage receives [21:05:20] right [21:05:23] that makes sense [21:07:08] I wonder how much preflight code there is in the listing [21:08:05] I've never properly understood why they are making a big deal out of the difference, but the EDD is very clearly separating the code between flight software and preflight software. [21:08:15] and they don't mean something like Sundial with it [21:08:30] it's preflight software as in the minutes and hours before GRR [21:08:39] which does GMT syncronization and other things [21:09:08] I wonder if that was an actual separate software [21:09:13] or just part of the same thing [21:30:48] hmmm [21:30:55] that's a really good question [21:31:12] since it only uses core memory (as far as I remember) they could very easily just replace the whole software shortly before launch [21:31:45] hmm, but that part of the software would be used minutes before launch [21:31:57] maybe less likely then :D [21:32:56] here is what the EDD says [21:33:45] "In specifying the LVDC flight program requirements, portions of other programs (RCA-110A and LVDC preflight) will be described when they interface with flight program requirements. These programs are not controlled by this document and are mentioned for completeness only." [21:33:59] it's probably just that the EDD isn't responsible for that part [21:34:13] the EDD is like GSOP section 5 [21:34:20] and 2 [21:34:30] GSOP section 3 is FCC schematics :D [21:34:37] GSOP section 1 would be LVDC preflight [21:34:40] maybe it is like that [21:36:07] hahaha maybe [21:36:17] man I really hope we're able to get this listing to you [21:36:44] Video is up. [21:36:51] https://www.youtube.com/watch?v=Pz406vmOlPo [21:37:01] Also [21:37:02] hey [21:37:06] hey [21:37:12] yo [21:37:13] and yay! [21:37:30] quality is not so great again. If you have a 1680x1050 monitor you are basically screwed with Youtube. [21:37:37] it badly downscales to 720p [21:38:13] this monitor is 10 years old, it has to give up some day! Before that I am too cheap to upgrade, haha [21:38:52] maybe I can trick my PC into recording 1080p, I have to try that again [21:38:53] hehehe [21:39:54] anyway, this upload took forver. Good night! [21:40:00] night! [14:16:58] hey [15:13:55] hey Thymo [15:14:49] I was taking a look at the PanelSDK configs yesterday. To take a look at that issue with the ecs heaters on github [15:15:00] ah [15:16:16] I'm doing some scary low level changes with the orbital mechanics calculations of the RTCC, to get rid of bad code [15:17:06] Fun [15:19:12] and I figured out that the JSC History Collection might have one more useful RTCC document [15:20:21] have to request that some time. I already requested a very large document not too long ago, so I don't want to do that too often. [17:01:10] morning! [17:02:31] late last night while trying to figure out which code got distributed into which banks in LM131, I found another incredibly useful memo from Don [17:02:36] about the variable servicer :D [17:02:48] http://www.ibiblio.org/apollo/Documents/LUM139_text.pdf [17:03:01] page 3 has a table that shows words per bank for the servicer for luminary 1C, 1D, and Zerlina 3 [17:03:50] so I just need to count the servicer words in Luminary 131, and that should tell me where to put what for the changed servicer stuff [17:04:56] oh, that is useful indeed [17:06:48] the trick is figuring out what he counts as servicer code, haha [17:09:13] anyways, what's up? [17:10:31] I think there is another good IBM RTCC document in the JSC History Collection [17:10:45] oh cool [17:10:57] want to request it for me? I just requested a very large document a bit ago :D [17:11:15] I have a strict once a month policy, haha [17:11:27] hahaha, but too impatient to see it? :P [17:11:59] totally separate people sending requests is fine by me [17:12:04] hehehe [17:12:45] so how does this work now? just send an email to archives@uhcl.edu as I would have to Lauren? [17:13:09] yep [17:13:15] with the same request data [17:14:08] alright, what's the document? [17:14:14] IBM rtcc Apollo Programming Series, AS-500 Systems Integration, Mission Systems, Volume 2 [17:14:23] from the archive search [17:14:47] oh that sounds very similar to some of the ones we found on NTRS [17:14:52] yeah [17:15:00] but for AS-200 Systems Integration was useless [17:15:04] well, near useless [17:15:08] hahahaha [17:15:18] I got Volume I of the document above eventually [17:15:26] oh archive search, right [17:15:28] but forgot about Volume 2 [17:15:43] or, I thought I had requested it [17:15:45] but I didn't [17:15:46] haha [17:15:48] this is from box 15 [17:15:54] I never requested or got anything from box 15 [17:17:00] I've never requested anything from the archive search before :D [17:17:11] works the same really [17:17:16] Title, Location, Bux Number, Date [17:17:27] right [17:17:29] and I mentioned it was from the archive search [17:17:36] probably not that relevant [17:22:36] okay, email sent [17:23:07] awesome, thanks! [17:23:22] these IBM RTCC documents are so unorganized, there might as well be lots of good stuff in there [17:23:35] hehehe [17:23:45] speaking of, I should send a document scan request to Ron as well [17:24:59] what do you want to have? [17:25:06] LVDC code :D [17:25:45] and the Luminary 1C flowcharts, but he already knows that one [17:26:07] oh [17:26:19] I have the feeling he doesn't need to scan the LVDC code anymore :D [17:26:38] oh yeah, he's scanned it a ton of times while trying out his fancy new overhead scanner [17:26:42] but I still need to request the scans :P [17:27:06] right [17:27:21] a request of scans, not to be confused with a scan request [17:27:33] hehehe [17:28:01] I should go through the box he indexed and make absolutely sure there isn't anything else in there that I want scanned other than the flowcharts [17:28:27] .....other than the MIT System Status Reports which are going to be amazing but with good data spread thin throughout them [17:29:06] in which box is the flowchart? [17:29:35] https://www.ibiblio.org/apollo/NARA-SW/IndexOfNaraBox209G.html [17:29:50] box 28 [17:30:09] if scanning of that goes fast he's also going to get the Comanche 67 and Comanche 72 flowcharts [17:30:09] and that is still the case? Or has that been reorganized as well? [17:30:16] this has all been reorganized sadly [17:48:30] meh [17:48:41] looking at this list just makes me want to take my own trip there [17:52:18] I'm sure Ron would like that, haha [17:52:57] less for him to do [20:25:52] night! [15:56:36] morning! [16:03:59] hey [16:04:49] what's up? [16:05:08] doing some big behind-the-scenes RTCC changes [16:06:31] mainly thruster handling for maneuvers [16:07:36] nice [16:08:09] was annoyed with how inconsistent that was handled [16:08:24] it is moving closer to the real RTCC with the changes as well [16:14:38] awesome [16:14:43] closer to the real thing is always better :D [16:15:11] almost always [16:15:25] I'm not going to make the MFD user use the same input method [16:15:37] haha fair [16:15:44] that would be a bit... primitive [17:01:41] you are talking to somebody who would eventually like to convert all of our AGC programs back to punch card format though :P [19:34:20] Evening! [19:36:38] hey Thymo [19:40:55] What's up? [19:44:20] still doing the behind-the-scenes RTCC changes [19:45:16] it's like the real thing, in early 1968 they had barely an idea how to properly support a lunar mission. So many changes between early and late 1968! [19:46:47] I just installed EVE Online. A friend recommended it to me. [19:47:13] I've heard about it, but don't know much [19:47:54] Some space game where you can explore and battle. I'm not entirely familair yet. [19:48:09] Trade is a big deal too [19:49:25] I've heard about the gigantic battles [19:50:48] Yeah, they can go on for days from what i've heard. [19:51:17] sounds like a nice time sink if you really get into it, haha [19:51:28] Oh yeah it can be. [20:55:43] night! [17:51:03] morning! [18:47:56] Hey Mike [18:48:30] hey [17:09:00] morning! [17:10:26] hey Mike [17:10:46] what's up? [17:10:57] still changing the MFD a lot [17:11:25] for the better [17:11:27] I think :D [17:11:45] hehehe [17:12:10] any news from UHCL yet? [17:12:24] no, nor Purdue [17:12:54] ah, too bad [17:19:21] did you see Ron's email? [17:19:26] no scans this week for us [17:19:39] :( [17:19:45] I was going to ask about it [17:20:12] Wednesday next week is the official day [17:20:12] I'm changing so many things about the RTCC MFD right now even without more material, haha [17:20:54] if the first document from my request list is as good as I think it might be then it will be implemented immediately though [17:20:59] I've been dragging my feet on the LM131 stuff because I'm hoping that the flowcharts will (a) cover either version after Luminary 131 and (b) indicate bank jumps like they do in the Luminary 1D flowcharts [17:21:16] if they do then figuring this out will be so much easier [17:21:26] yeah [17:21:33] not much point doing it the hard way [17:21:54] what do you think is going to be so good about your first document? [17:22:30] it would have better targeting for LOI-2, DOI and lunar orbit plane changes [17:22:57] I guess LOI-2 is pretty simple, but DOI and LOPC targeting are definitely areas that can be improved in the RTCC MFD [17:23:13] and they are relevant for Apollo 11 [17:23:24] so relevant for NASSP 8 [17:23:58] the best other lunar orbit plane change documentation is the GSOP from 1967 when that was still planned to be part of the CMC :D [17:24:02] but it's not very good either [17:24:39] that was P33 [17:25:42] hmmm yeah, I could see how that would be less than ideal :) [17:26:02] LOPC hurts my brain a bit, because landing site is rotating, CSM orbit is shifting due to non-spherical gravity [17:26:10] and TIG is not fixed but needs to be determined [17:27:01] In the cases where our current targeting is buggy Alex invented some convoluted method with 3 or 4 RTCC MFDs opened to figure out the right burn parameters [17:27:42] oh jeez [17:30:43] I've also been listening to the FIDO loop from Apollo 11 lunar orbit a bit more [17:30:59] and I am happy to say that they are confused about some of the same things as I am [17:31:06] hahahaha [17:31:34] they have been reading back and forth the nominal abort constants twice [17:31:42] to figure out if they are on the same page [17:31:50] have to compare those to the padload some time [17:31:56] should be the same [17:32:24] and the numbers they calculated from scratch are quite different [17:32:37] as are the numbers the RTCC MFD usually outputs [17:33:54] and the FIDO biased the landing site latitude to do some testing [17:34:05] leading to hour long confusion about plane change numbers etc. [17:34:49] I get a better feeling to how calculations were done in MCC-H and there usually happen quite a few weird things [17:35:31] like when some from JPL was calling wanting to talk to "Houston Computer". Nobody has such a callsign, but somehow he ended up in the FIDO loop. [17:35:37] someone* [17:35:40] hahahaha [17:38:28] that sounds a lot less streamlined than I would have guessed [17:39:10] yeah [17:39:17] they probably got better with later missions [17:39:45] and they definitely had their work schedules with stuff they did without mentioning it on the loop [17:42:34] oh, just found an interesting program in the 1967 GSOP for the CMC [17:42:41] never read about it before [17:42:47] P70, Safe Perilune Program [17:43:02] it's a submode of the Return-To-Earth program P37 [17:43:22] calculates a burn that adjusts the perilune to be at a safe altitude [17:43:49] I can see why that can be a submode of P37 [17:44:00] P37: Arrive at specific radius with angle X [17:44:15] radius being EI altitude, angle in the reentry corridor [17:44:26] for that P70 it would be the input altitude and 0 flight path angle [17:45:01] huh, weird [17:45:30] sounds like something that would have been useful in combination with CSM DOI [17:45:57] to calculate the bailout burn in case they accidentally lowered the orbit too much [17:45:58] yeah [17:46:14] so I take it that only Sundisk knew how to do this? [17:46:23] or did it never make it to a flight rope? [17:46:27] hmm [17:46:32] probably not in a flight rope [17:46:58] and it's specifically perilune [17:47:05] not perigee or periapsis [17:47:14] so probably was only worked on for Colossus [17:47:15] right [17:49:13] Sundisk didn't even have P37 it seems [18:01:13] oh haha [18:01:15] so definitely not [18:01:37] who needs to return to earth when you are already there :D [18:02:17] I didn't realize Sundisk was so earth-focused [18:02:22] like Sundance [18:02:26] Earth orbit only version [18:02:35] I thought Sundance was lunar-capable, though [18:02:40] hmm [18:02:41] is it not? [18:03:25] probably [18:03:38] it has the full coasting integration routine [18:03:53] not sure Sundisk had that [20:28:19] night! [21:31:00] hey [21:31:08] Hey Alex [22:17:16] thewonderidiot, is the "time robbing cycles" trick that was used to simulate the alarms on the FPGA/real AGC something that we could do with Virtual AGC as well? [22:18:39] yeah, Niklas experimented with it a while back [22:19:52] essentially you just need to omit a call to agc_engine() once every 156.25 microseconds [22:20:07] or maybe a little bit less than that [22:24:36] ah ok [00:21:30] Hey thewonderidiot [01:36:36] hey SteveH [01:38:20] Been working on my AGC and spacecraft peripherals again. Have all signals for basic guidance wired up and running. Was just playing with PGNS in ATT_HOLD and injecting gyro attitude changes and watching RCS fire :) [01:38:41] oh nice!! [01:39:14] that's awesome :D [01:39:45] so what's next? [01:39:49] Yeah I was really happy to see this work. injected +/- 10 degree deltas in single axis and observed 2 or 4 thrusters fire in a common direction [01:39:56] awesome [01:40:10] sounds exactly like what you'd expect :D [01:40:15] pretty basic test but it worked. next is to improve gui so I can interactively play with multiple axis deltas. [01:41:36] Working on getting DES engine signals working. I also picked up a nice 3 axis hall effect joystick to wire up for handcontroler [01:42:09] sweet [01:42:13] Then I need to get a socket connection opened up so I can start to feed signals to/from nassp [01:42:38] and finally get your emulator cloned so I can set initial state correctly [01:42:53] how are you going to wire that in? are you making a replacement A circuit that translates a DC value into a series of pulses? [01:42:57] Just wanted to say hi and that progress is once again being made :) [01:43:01] the hand controller, I mean [01:43:12] I'm very glad to hear it, thanks for the update :D [01:44:00] I cheated a little with the A circuit. I'll use a PIC to emulate the pulse width modulated signals for the hand controller. The I/O is authentic but just a simple analog joystick driving the original input pulses [01:45:00] yeah, you gotta cheat with that thing. a 3-axis joystick with resolvers would be ridiculously expensive to buy or build [01:45:42] so you're exposing GATE*/ and SIGN* directly on the I/O connector? am I understanding that right? [01:45:46] Oh yeah. But the detent signal, and the timed pulse widths will be used [01:46:18] yes that's correct. I drive GATE and SIGN from the PIC controller based on analog inputs from the joystick [01:46:46] got it. and I guess that PIC will also use the ADC readings to determine if each axis is out of detent or not? [01:46:55] yup [01:47:03] sounds like a reasonable solution to me :D [01:47:07] Just three one-shot timers when you think about it. [01:48:10] I still cannot get free drift state vector updates to occur. May need to play with that. Most likely some variables not in correct state [01:48:41] hmmm [01:48:43] probably, yeah [01:49:17] May need to pick Nick's brain a little but I want to investigate a little more on my own just so I can ask intelligent questions. :) [01:50:30] haha yeah, he's definitely the right one to ask those questions to [01:51:53] I gotta go, I'll be around and will let you know as I get more of this hardware responding. Goodnight! [01:52:01] goodnight! [16:17:43] hey [16:19:42] hey Alex [16:20:12] I'm in the middle of some bigger RTCC changes. Will take a while still until you get to see it, but it will be worth the wait. [16:20:47] nice [16:21:19] I've been listening to the Apollo 11 FIDO loop while falling asleep. [16:21:27] bad move sometimes when interesting stuff happens :D [16:21:28] haha [16:22:05] but I think I get a grasp on what specific planning went into the lunar descent and abort stuff [16:22:11] and I want it work exactly like that [16:22:18] so that needs a bunch of changes [16:22:23] it to* [16:23:46] the descent planner or what ever it was called? [16:25:02] no, like the general procedure [16:25:10] ah ok [16:25:21] the descent planning processor might be in a document that Ron is going to scan [16:25:27] next week, not this week as originally planned [16:25:41] oh really? [16:25:56] that would be sweet [16:26:04] I put it on the top of the list [16:26:27] but for planning I mean something like this [16:26:36] direct input into the MPT [16:26:46] sep maneuver with the 2.5 ft/s [16:26:57] then lunar descent planning, DOI maneuver [16:26:59] put on MPT [16:27:12] then simulate PDI, put on MPT [16:27:24] use T2 time, ascent processor, ascent to MPT [16:27:36] checkout monitor display with ascent burnout vector [16:27:40] figure out apolune time [16:27:59] direct input into the MPT, TIG from above for the boost, 10 ft/s [16:28:16] then run concentric maneuver processor, CSI at next apolune (I think) [16:28:28] figure out PAD data [16:28:33] oh, a trajectory update came in [16:28:37] delete everything [16:28:50] start again for final PADs :D [16:29:33] and most of this is FIDO talking to DYNAMICS [16:29:50] Dynamics doing the inputs as requested from FIDO [16:30:03] Dynamics is super busy in the time before undocking [16:30:15] also gets requests from e.g. GUIDO, docking alignment processor and what not [16:30:23] so basically they put evrything on the MPT [16:30:36] yeah [16:30:54] for most processors you would specifiy a GET to take the vector from the current ephemeris [16:31:05] and that depends on the trajectory follow the MPT maneuvers [16:31:23] so the parts I am currently adding are: [16:31:38] most calculation pages get an extra page to specify thrusters for the maneuver (and later more stuff) [16:31:45] Direct Input into the MPT [16:32:00] and then descent and ascent being added to MPT [16:32:18] then we are able to following the same general procedure [16:32:22] follow* [16:33:31] and when that is all implemented and tested I can release it [16:33:42] but a lot of the MFD is in a half-changed state right now [16:33:47] sounds like quite the job [16:34:02] but im looking foward to seeing it [16:34:03] yeah, and I'm skipping over many features for now [16:34:09] still lots of work [16:34:21] but for a lot of this I have the IBM RTCC documentation [16:34:58] we're moving closer and closer to a RTCC++ lol [16:35:26] yeah, I'm already naming some routines like their real RTCC counter part, when they are essentially doing the same [16:35:54] makes sense [16:38:07] when I get back to my home PC Ill start work on the SIM bay panel [16:38:20] I put that in a development branch for now [16:38:23] the coding [16:38:28] ok [16:39:34] I guess you can kinda already do direct inputs in the MPT with the general purpose maneuver processor [16:39:41] flight controller options [17:01:02] oh I wanted to ask you, apparently there is a way to artificially create the alarms during the Apollo 11 PDI, with "time robbing cycles" [17:01:19] Mike was saying "essentially you just need to omit a call to agc_engine() once every 156.25 microseconds" [17:01:34] any idea how to try that with the vAGC code? [17:02:22] hmm [17:02:42] when I tested that with Mike I just added some code that Mike gave me [17:03:17] but I don't really remember what [17:03:42] ah ok [17:03:46] I don't think it was omitting calls to agc_engine() [17:03:53] it was still incrementing the clock [17:03:58] but nothing else [17:14:03] morning! [17:14:59] hey Mike [17:15:05] what's up? [17:15:39] same as the last few days, haha [17:15:44] hehehe [17:16:25] I started fiddling around with Luminary 1D reconstruction this morning [17:16:40] since I'm awaiting documents for LM131 rev 1 and Comanche 45 [17:17:09] I was wondering about that Virtual AGC website update as well [17:17:21] yeah, deletion of things is very un-Ron-like [17:17:36] must be all this ITAR talk about the LVDC listing [17:20:06] it sounds like it's just some guy that was asking NTRS about stuff they had deleted [17:20:09] and not that [17:20:11] which is good [17:20:51] I think he just doesn't want to be responsible for having been the one to resurrect them from the old NTRS [17:21:35] well, most of it will be on archive.org and similar at least [17:21:44] so it's not like it is gone from the Internet again [17:22:02] yep [17:22:09] still no answer from UHCL? That is very un-UHCL like. [17:22:24] not even "we are working on it"? [17:22:25] yeah, still no answer from them [17:22:26] nope [17:22:45] you sent it to archives @ uhcl ? [17:23:14] yep [17:23:53] well they first replied to me the last time because they were too busy with Apollo 50 celebrations [17:24:00] but then got it done a few hours later anyway [17:24:12] so maybe they'll just have it done when you get a message [17:24:17] maybe it's a really big one :D [17:25:57] haha maybe [17:26:06] I'm also still waiting to hear from Purdue and NARA [17:26:08] lots of waiting [17:26:41] yeah [17:26:49] on Ron as well :D [17:26:56] yep! haha [17:27:09] and on me, because I need to go scan the Norton document on Luminary 1D at Don's [17:27:21] ah [17:27:30] I remember a few other things that Don had... [17:27:34] not sure when I'll be able to plan that trip [17:28:00] and not sure it will be long enough to commit to scanning whole flight plans for you :P [17:29:03] haha, damn [17:29:44] I really want to focus on things that only Don has, like the Contents of Luminary 1D, and the Luminary anomaly reports [17:29:52] flight plans can show up elsewhere :D [17:31:00] yeah [17:31:05] I am sure NARA has it as well [17:31:11] I think they have complete flight data files [17:31:27] but I will be happy to take more pictures or scan smaller things [17:33:52] thanks! I think you already got some important parts for the next time I fly Apollo 7 [17:34:15] it probably won't be for another couple of months [17:34:18] I need to email Don [17:47:55] okay, Don has been emailed [17:59:24] now I'm anxiously awaiting four emails, haha [17:59:53] haha [18:00:04] that's a lot of emails [18:00:09] also, it is exciting that Ron is done with LVDC transcription [18:00:35] I wonder what his assessment of the repairability of the assembly errors is [18:00:39] emulator should be done any day [18:01:25] depends where the errors are [18:01:33] I would help, but... [19:44:26] maybe someday! [19:44:51] also I need to follow up with the RR guys about dumping their sundance modules [19:45:00] add another email to the pile to wait for :D [19:45:08] Don got back to me -- we're probably going to do November [19:48:23] nice [20:27:48] night! [16:25:21] morning [16:27:48] hey Alex [16:37:25] Hello everyone, hope you guys are having a great day! [16:38:30] hello! [16:39:22] welcome to the channel (unless you have been here, then I can't remember) :D [16:40:59] My first time here I think [16:42:03] Not really into development, I just fly pretty good [16:42:47] haha, fair enough [16:43:12] yeah, most development talk is happening here. Not on one of the forums anymore [16:48:18] Not sure if anyone is working on it, but ever since the post regarding the J mission walkaround came out, I've been transcribing the Apollo 15 flight plan into the checklist MFD excel sheets. Since that's the one with the most complete documentation on AFJ [16:49:31] oh, not even just AFJ [16:49:40] https://readux.ecds.emory.edu/collections/emory-control:LSDI-Apollo15/ [16:49:43] if you haven't seen it [16:50:05] but yeah, that sounds useful. We can definitely implement it to be used for Apollo 15 [16:51:18] any problems using the RTCC MFD for flying Apollo 15? [16:51:49] or have you just been transcribing so far? [16:53:46] I'm flying A15 at the moment without the checklist MFD, currently at the hacky MCC around 25-28h [16:53:54] trying to find out the best way to implement it [16:55:06] you mean how to calculate MCC-2? [16:55:09] I've not needed performed a SCS course correction since Apollo 7 which I last flew who knows how long ago. [16:55:24] so far I've had no issues with RTCC MFD [16:55:30] oh [16:55:46] you mean that SPS test they did [16:55:52] yeah the test [16:57:07] I don't know much about that [16:57:53] yeah, SCS TVC was rarely used [16:58:23] My plan is to just bypass the test for now, and do the MCC under G&N. I could always come back to it in the future. [16:59:15] I'll have to read about that test [17:00:51] Apparently there was a short in one of the thrust switches (A or B I don't remember) [17:00:52] they didn't do a MCC-2, but instead this vaguely defined test [17:00:58] that's why MCC-4 was so large I guess [17:01:23] so the burn attitude is probably right for a MCC-2 they had planned [17:01:32] I believe this test was indeed MCC-2 [17:01:44] yeah, at that time [17:02:33] but they didn't call it that, because it was more a SPS test [17:03:00] It could also be because this was one of those hybrid trajectory missions, they needed to actually get to the proper inclination for LOI [17:03:45] yeah, it seems like the burn attitude was the same as for the MCC-2 they had calculated [17:04:03] "Because the SPS check burn was so close to that needed for MCC-2, [17:04:03] both MCC-2 and MCC-3 were cancelled." [17:04:39] so you probably should calculate it like a normal MCC-2 [17:04:55] TLMCC option 4 [17:07:00] Question: When I fly a mission with mission control enabled, does MCC try to fly the mission according to the planned trajectory, or the actual flown trajectory? [17:07:28] actually, I believe Apollo 15 was directly inserted into a non free-return translunar trajectory (so not hybrid) I believe Apollo 14 was the last of those [17:07:56] MCC follows pre mission plan [17:08:58] yeah, those later missions didn't even both starting out on a free return after TLI. But Apollo 15 is very close to it I think. [17:09:03] bother* [17:10:01] which is why MCC's are all listed as "nominally 0" on the flight plan [17:10:21] I see, that's where my philosophy differs. I fly the missions according to the mission report. [17:11:02] and the RTCC MFD should give you the tools to do that [17:11:31] there always is a element of randomness in a mission, if you fly the same mission twice you would never get the exact same trajectory, as it would have been in real life. [17:11:54] So the MCC feature doesn't even try, in most cases, to emulate the things that went differently during a mission [17:11:57] morning! [17:12:02] hey Mike [17:12:13] Yes it does, I'm so grateful for that MFD. I used to use GMAT for all my astronavigation needs, which is a pain in the a** to use. [17:12:32] Good morning sir [17:12:37] were you like copy&pasting state vectors from the scenarios to GMAT? :D [17:12:42] hey Mike [17:12:48] exactly [17:13:32] MJD in orbiter and MJD in GMAT have different epochs so that's always fun. [17:13:43] and Orbiter coordinates are left handed [17:13:52] uh huh [17:14:26] In earlier MFDs I did I used the state vectors like I get them from Orbiter and ran into issues [17:14:46] so now they first thing anything is done with Orbiter SVs is exchange Y and Z coordinates :D [17:14:59] don't want anything to do with left-handed math [17:15:02] not if I can avoid it [17:15:49] I'm listening to the Apollo 11 FIDO loop a lot lately, that inspired me to currently do some bigger RTCC MFD changes to make the workflow a bit more like it was in reality [17:16:14] I found a trajectory solver for kerbal, and once tried to get it to work for Orbiter. [17:16:19] It didn't [17:16:52] haha [17:17:15] Which is a shame really, it's really powerful for such a simple-to-use tool [17:17:17] RTCC MFD isn't perfect, but it should cover most of your Apollo trajectory calculation needs [17:18:35] So far I find it goes above and beyond my needs. Since all I need to do is follow the actual flown trajectory [17:18:52] For which data is easily available [17:20:42] Ah, I'm afraid it's getting late for me (0120 where I am). I'll leave you guys here, thanks for the chat everyone. [17:21:44] thewonderidiot, any answers to your numerous emails yet? :D [17:21:52] a couple [17:22:26] got a discount on the $1.55? [17:22:35] haha not that one [17:22:58] https://drive.google.com/open?id=1F2wAx-czDXjW0m4Dhp6yEVWokk-EuKSB [17:23:02] there's the SCD for the FDAI [17:23:07] or at least what NARA has of it [17:24:28] ah, nice [17:24:42] anything useful for your purposes? [17:25:54] pinouts! [17:26:18] definitely looks like it will be useful [17:26:27] ah yes [17:26:33] maybe not quite all of teh information we need though [17:26:47] we need to know what voltages to put on all of those things [17:27:32] the Systems Handbook should have most of that info, no? [17:27:33] also heard back from about the rope modules, they're checking with the consigner but rope reading is looking likely [17:27:40] yeah [17:27:41] also [17:28:06] I was saying that the systems handbook referenced the original FDAI drawings but NARA didn't have them [17:28:19] the drawing numbers were EFD9-507 through EFD9-510 [17:28:34] but I was wrong, those aren't original FDAI drawings [17:28:44] EFD stands for "Elementary Functional Diagram" :) [17:28:58] so those might be pages in those books [17:29:48] ah, of course [17:30:15] I haven't had time to try to find them yet [17:30:21] but I did poke through the EFDs just a little bit [17:30:33] and noticed that all of the pages with drawings have LDW 270-xxxx numbers [17:30:48] which means NARA almost certainly has the drawings, just not the surrounding text [17:32:49] I want to change our FDAIs to take sine and cosine inputs for the attitude [17:32:58] mostly because that's the numbers on telemetry [17:33:23] so that the IMUs have the right output [17:39:30] sounds like a good idea :D [17:39:37] how do the sine and cosine inputs work? [17:39:52] like, how do they translate to ball rotation? [17:40:28] kind of like atan [17:40:38] atan(sin(angle)/cos(angle)) [17:40:56] I'm sure voltage wise it's a bit different [17:42:23] hmm, okay [17:42:55] but it's absolute? like you apply a voltages to sin(angle) and cos(angle) and the ball will spin until it hits that angle? [17:43:11] yes [17:43:17] huh, weird [17:43:52] maybe wouldn't work with a single voltage [17:44:12] and that's how the IMU outputs angles anyway [17:46:33] I guess the operating principle is similar to GDC align [17:47:21] hmm, so those are probably just resolver outputs then [17:47:29] unless the GASTA does some ADC thing [17:48:39] pretty sure GASTA output is the same as input, just different values [17:48:56] what do you mean, same but different values? [17:49:10] well, converted to display attitude [17:49:14] not IMU attitude anymore [17:49:30] oh [17:49:32] weeeeird [17:49:34] okay [17:49:37] that's what the GASTA does [17:49:38] I have no idea how this works :D [17:49:44] CSM doesn't have a GASTA [17:50:16] it's because the IMU is oriented the same way with regards to the main engines in CSM and LM [17:50:37] but in the LM the engines are "below", in the CSM it is "behind" [17:50:54] so the FDAI would show different behavior in CSM vs. LM [17:51:04] I meant, electrically [17:51:14] how it would accomplish the change, haha [17:51:15] complicated [17:51:19] yeah it must be [17:51:20] Systems Handbook [17:51:29] 10.4.1 [17:51:38] lots of conversions [17:52:32] I'm counting 16 resolvers [17:52:36] hahaha jeez [17:55:12] Luminary has a routine for it as well, much nicer than a big analog box that draws a bunch of power :D [17:57:20] but as an engineering challenge the GASTA is super nice [17:57:25] very well defined [17:57:46] six inputs, six outputs, 3 equations that define what the box has to do [18:00:15] hahaha [18:00:29] yeah I definitely need to look at that systems handbook diagram later [18:00:36] that is a really interesting challenge [18:06:53] Evening! [18:06:59] hey Thymo [18:07:41] What's up? [18:07:50] work stuff [18:07:57] and anxiously awaiting response to a few emails [18:09:16] Sweet. [18:09:21] you? [18:09:33] Work all day. Just came back and had dinner. [18:10:05] Deciding what I'll do this evening. Think I'll work on the ACM for a little bit. [18:10:27] And then I'll either do some reconstruction or work on NASSP a little. [18:10:46] oooh, reconstruction on what? [18:11:09] One of the ropes. Whichever needs it. Didn't start yet anyway. [18:11:29] there are many options, haha [18:12:05] Probably one of the CM related ropes. I'm most familair with how those work. [18:12:24] Comanche 45 is probably the one to go for then [18:12:30] The only rope for the LM that I'm really familiar with is Aurora but that's not really up to date enough to work on Luminary. [18:12:40] not even close :D [18:13:32] there's some low-hanging fruit in Comanche 45 [18:13:38] When I was on vacation I played around with my own EXTVB to test the ACM. I really found myself writing a bunch of stuff that was already included in pinball in later ropes. [18:14:07] not going to use Superjob to test it? [18:14:07] Blanking registers easily comes to mind [18:14:31] Eventually. I was just testing if yaAGC was handling my new adressing code properly. [18:14:44] And Superjob is... odd. [18:15:10] Writing a test on Aurora was easier. [18:17:56] that is definitely fair :P [18:20:31] Will mostly replace Assign and AssignFromPointer probably. [18:23:14] cya guys [18:25:15] hey Thymo [18:25:20] Hey Nik [18:28:16] thewonderidiot: What do you think of something like this? I'll make a new function, say IsSpecialReg. that operates on special registers like CYR, CYL, Z, 7 and friends that returns 1 if it is and has changed it and 0 if it's an ordinary one. [18:29:26] So I can just use AssignFromPointer to not break the rest of the code (Assign is never directly referenced). Use the new one to do Assign's old behaviour and do normal and ACM assignemnts in AssignFromPoiter. [18:29:37] s/Poiter/Pointer [18:30:13] AssignSpecial sounds better than IsSpecialReg [18:35:45] uhh [18:35:49] I think that sounds reasonable [19:39:54] thewonderidiot: I see a lot of references to FEXT. I'm not entirely sure what that refers to. Super bank perhaps? [19:40:23] yeah, fixed extension bits [19:40:54] I assume the auxiliary memory uses all three bits, instead of just the one "superbank bit" [19:42:25] Just two actually. [19:42:42] huh, weird [19:42:48] bits 7 and 6? [19:43:03] 10 bits from S, 3 from FBANK and 2 from FE [19:43:07] 5 and 6 [19:43:40] surely bit 7 matters? five and six have no impact if 7 isn't set [19:44:01] at least, not for FADDR calculation [19:49:02] puu.sh/E5egx/48e00c24c8.png [19:49:06] http://https://puu.sh/E5ehc/f28c9536aa.png [19:49:44] You've still got a couple of fixed bank's available without superbank set. [19:50:24] https://puu.sh/E5ehc/f28c9536aa.png fixed link [19:51:51] not sure what you mean [19:51:53] Actually no. Everything listed as Extended F is within ACM memory. [19:52:05] My mistake. [19:52:47] I think the "1"s in the Fixed Extension Bits column are a mistake, and should read "4" [19:53:12] and then 5 means "101" and 6 means "110", i.e., bit 7 set, and bits 5 and 6 change [19:53:27] That would make sense [19:54:25] the way addressing works in the AGC, bit if bit 7 isn't set, then it totally ignores the fixed extension channel [19:54:44] so FEXT values of 0, 1, 2, and 3 all end up pointing you at banks 30 through 37 in superbank 0 [19:55:11] 4 gives you superbank 1, 5 gives you superbank 2, etc. [19:56:23] that gets you up through superbank 4, which has banks 70-77, giving an even 64k address space [19:57:44] and interestingly, all Block II AGCs have the logic to calculate the complete 16-bit address for the 64k address space... it's just that the logic that converts that 16-bit address into rope modules and strands will only handle the first 36k of it [19:58:11] they added wires to run the full 16-bit address to Tray B across the intertray connectors, just in case they wanted to try to expand the memory to the full 64k later :) [20:00:38] I'm pretty sure that at some point I read that the AM doesn't really care about bit 7. Trying to find it in the report. [20:03:38] I mean, it has to, because if it looks at bits 5 and 6 when bit 7 isn't set, then it's going to overlay data from the ropes [20:04:03] unless it asserts MNHSBF, which I guess it could do [20:05:13] I don't think it does, MNHSBF is never mentioned in the signal directory. [20:06:04] does their additional test connector wire force a CG in addition to a WG? that would also do it [20:06:33] depending on which timepulse they write into G [20:07:04] Either 8 or 1. Let me check [20:13:38] If RAD is detected iy will will provide data at any 'convenient' time before T07 using WG/. For all other cucles it uses RG at T04. [20:14:42] I does inhibit memory strobes using MNHSBF though [20:14:56] To force the ACM to handle parity. [20:18:01] It seems to write whenever the AGC does WG or RG and W. [20:18:39] So it can put data either in G or in another central register as if it has come from G. [20:18:51] hmm, okay [20:39:29] night! [16:45:10] morning! [16:58:29] hey Mike [16:59:08] what's up? [16:59:26] listening to the FIDO loop a lot [16:59:41] finally found again where they are planning the separation maneuver, haha, that took a while [16:59:49] nice :D [17:01:22] anything new on the email front? [17:01:50] nope, nothing today [17:04:12] I'm slowly chipping away at Luminary 178 [17:04:35] I transcribed the bugger words for it last night and compared them to Zerlina [17:04:39] every single one is different :D [17:06:08] but, 21 of the 36 banks have a leading 0 in the bugger word differences, which is statistically unlikely I think [17:06:28] a lot of stuff might line up once I get the erasables and fixed-fixed correct [17:08:10] or at least, I hope so. Don didn't change every bank in Zerlina :P [17:10:12] yeah, surely not [17:11:15] I wonder if the UHCL email got overlooked. It was send at the beginning of the weekend. That rare time I make you request something for me it suddenly is more complicated! [17:11:47] hahaha [17:11:52] this is why you should just do it yourself :D [17:13:11] I just don't want them to suddenly introduce a new policy for pages per month per person or so [17:13:21] hehehe [20:08:18] night! [16:45:15] morning! [16:51:15] hey Mike [16:51:37] it's me who got an email this time [16:53:45] oh nice! [16:53:49] still nothing for me :( [16:53:52] what email did you get? [16:54:23] NTRS [16:54:26] LM Data Book [16:54:32] ?! [16:54:38] request denied because, you guessed it, ITAR [16:54:41] oh [16:54:49] sure [16:55:37] didn't they end up putting parts of the LM data book up after we requested them though? [16:55:43] yeah [16:55:48] amendmends of it [16:56:02] which amounts to a large number of pages [16:56:10] but the main document is apparently bad [16:56:28] weird [16:56:39] well, there's still hope that we'll get the MIT Museum's [16:56:48] yes [16:57:20] and for the UHCL document, apparently they all have a week off or don't read emails from Friday on the next Monday [16:57:57] or they also started checking documents for ITAR... [17:03:32] I doubt it [17:03:54] I'll follow up with them on Monday [17:05:08] yeah, I think that makes sense. Thanks! [17:05:18] not today, or they'll not read it again :D [17:05:45] haha yep, exactly [17:07:29] nice job on Artemis 71 [17:07:36] thanks :D [17:07:49] a little tricky but once I figured it out it makes sense [17:08:13] I'm slowly working on cataloging the differences between Zerlina 56 and Luminary 210 [17:09:16] I guess there will be many [17:09:32] from what I've looked at so far, 37 log sections are identical, and 38 have differences to resolve (out of 90 total) [17:10:14] oh, I think you mentioned this at some point [17:10:37] K1VAL being 140.12 vs. 141.12 [17:10:46] do you know if this was fixed for Luminary 178, or only after? [17:11:39] 141.12? [17:11:46] is that in Zerlina? [17:12:07] Luminary 131 has 124.55 [17:12:45] yeah, Zerlina has 141.12 [17:12:49] Luminary 210 has 140.12 [17:12:53] I think 141.12 was a bug [17:13:25] yeah [17:13:57] Luminary 1D definitely has a change from 1C [17:15:52] ah [17:15:53] http://www.ibiblio.org/apollo/Documents/LUM191-HMc_text.pdf [17:15:59] that says 140.12 [17:16:33] that memo is going to be useful :D [17:17:14] oh shit [17:17:18] even more useful than I thought [17:17:27] it has page numbers for every time they're referenced in the listing [17:18:03] ah yes [17:18:19] that's the memo I used for Luminary210 for Apollo 14 [17:18:26] well one of them [17:18:34] what else did you use? [17:19:11] hmm [17:19:13] no [17:19:17] I was misremembering [17:19:25] I convert the unit star vectors myself [17:19:44] could you not take them from Zerlina? [17:19:47] and found a document with the numbers for the planetary inertial orientation routine [17:19:52] but that was another memo [17:20:16] wasn't that before we had Zerlina? [17:20:19] oh [17:20:21] okay [17:20:22] Maybe I just confirmed the numbers [17:20:29] you just worried me for a second [17:20:31] haha [17:20:59] we got those memos from Don though [17:21:11] so hard to believe that it would have been before Zerlina [17:21:42] Zerlina was the last listing we had scanned [17:21:46] or at least, the last we transcribed [17:22:21] yeah, not sure about the timeline, I just remembering using some memos and doing coordinate system conversions with star vectors [17:25:23] as long as I don't have to do that and try to get exactly the original values I'm happy :D [17:33:09] Luminary 1D flowcharts don't seem to have the value of the constants [17:33:16] yeah [17:33:21] the Norton document will [17:34:32] the more I think about this the more confident I am that we're going to be able to get Luminary 1D [17:35:05] https://www.ibiblio.org/apollo/Documents/LUM167-BMc_PR_text.pdf [17:35:19] changed from 2800 lb/s to 3150 lb/s [17:35:21] and if I also finish LM131r1, then we'll have every flown LM version except for Sundance 306 :) [17:35:36] yeah, that's probably the change from the 1C value to 141.12 [17:35:42] and then they realized the math mistake later [17:36:16] 3150 lbf is 14011.9N [17:36:53] so 140.119 would be accurate with the scaling [17:36:59] hmm [17:37:07] so even Luminary 173 would have had the 1C value? [17:37:16] am I reading that right? [17:37:20] no [17:37:25] this memo is everything that changed between 173 and 178 [17:37:28] the change done in 167 [17:37:42] no, this is memo #167 [17:37:47] not luminary version :P [17:37:48] right [17:38:10] difficult to say then what 173 had [17:38:14] probably same as 1C [17:38:20] 2800lbf [17:38:28] yeah [17:38:34] per second [17:38:39] 12455.02 [17:38:45] no [17:38:50] lbf seconds [17:38:52] not per :D [17:39:18] 124.55 [17:39:20] in 1C [17:39:23] so that works [17:39:26] yeah [17:39:32] so 173 had the 1C value still [17:39:50] but what did 178 have? [17:40:00] 140.12 [17:40:03] or 141.12 [17:40:17] according to the memo of constants that references page numbers, 140.12 [17:40:31] so the 141.12 must have been a temporary thing between the two, that Don missed [17:40:57] ah, right [17:41:07] also: https://www.ibiblio.org/apollo/Documents/Memo-Norton701125_text.pdf [17:41:30] right [17:41:35] of course Norton would find that [17:41:38] "The program baseline employed seems to have been roughly a pre-H3 third (Luminary 178) release, as evidenced by the fact that K1VAL is 141.12 rather than 140.12, for example." [17:41:39] haha [17:42:11] even though Don says it has all of the updates up to Luminary 183 [17:42:23] must have been a typo or so [17:42:31] or just a missed change, yeah [17:42:35] that seems like an easy thing to miss [17:42:56] well, if that value was in some pre Luminary 178 version [17:42:59] and not just in Zerlina [17:43:07] then it was a typo at first and then got fixed [17:43:11] but Don missed it for Zerlina [17:43:28] oh yes [17:43:32] that's what I meant [17:43:40] so Norton knew to look for it [17:43:50] 141.12 doesn't correspond to a nice pound force number [17:43:54] and looks to similar to 140.12 [17:43:57] too* [17:44:01] yep [17:44:22] probably got confused with the two 1s in the more precise 140.119 :D [17:44:44] haha that could be! [18:46:11] hmm [18:46:27] now one of the documents Ron is probably going to scan would be helpful with my RTCC progress [18:49:18] his original plan to go there this week was very convenient for my plans! [19:10:17] yes I know, I am a sponge and everything with RTCC on it is a liquid [19:59:39] hahahaha [19:59:58] well, only a few more days to wait now [20:00:17] his plans were also very convenient for LM131 rev 1 reconstruction [20:00:28] now I have to entertain myself with other programs :P [20:08:21] or I need to go back and actually finish Sundial disassembly [20:11:51] that would be great [20:12:10] eventually I want to find out if there is more to that verb 47 [20:14:15] night! [20:44:53] Guenter! [20:45:05] Hey Mike [20:45:09] hey [20:45:26] What's up? [20:45:41] thinking about how to architect this thing at work [20:45:47] and also about Luminary 178 [20:45:49] you? [20:46:47] Nothing much. Chilling after replacing the main electrical panel at my granddad's today. [20:46:54] nice [20:50:46] https://puu.sh/E61DI/cd353a019d.jpg [20:50:53] https://puu.sh/E61Dr/15e31ed1cd.jpg [21:05:42] looks good :D [21:08:05] Even found out that one of the original breakers (using fuses still!) was leading to nowhere. You can see the disconnected wires on the left just next to the breaker. [21:08:45] Most likely went to the old washing machine in the bathroom. That socket was probably walled up at some point. [21:09:12] heh [21:10:55] We can always wire it up when he finds something that doesn't work. But after testing every socket and fixture in the house I'm fairly certain it's not connected to anything. [08:09:56] .tell indy91 do we have the luminary 1D downlist anywhere? the downlists are one of the things they messed with between Luminary 178 and Luminary 183, which might make that bit of reconstruction difficult if we don't have another source [11:06:31] . [17:19:49] morning! [18:08:21] hey Mike [18:09:07] I don't know about Luminary 1D downlink lists [18:09:30] hmm, okay [18:09:32] I have the feeling we should have that somewhere, but probably only because I have been using the LM-8 Systems Handbook telemetry lists so much [18:09:49] which has everything but the PGNS and AGS downlink lists [18:10:03] hah [18:10:16] hmm [18:10:33] well, maybe it's not too late to add one more scan request for Ron [18:10:42] section 2 of the Luminary 1D GSOP [18:10:46] oh yes [18:10:52] that would be good to have [18:17:02] I'm making good progress on the three-way merge between Zerlina 56, Luminary 131, and Luminary 210 [18:17:22] down to 12 out of 90 log sections that I still need to look at [18:17:31] with the goal to recreate 178? [18:17:37] and most of those are the SERVICER/P66 stuff that got rewritten for Zerlina [18:17:38] yep [18:18:53] Luminary 210 shouldn't be that different from 178 for Servicer etc. [18:19:03] after all it already the terrain model [18:19:06] yeah [18:19:08] that would be the biggest change [18:19:22] and one of the changes between 173 and 178 was the rewritten analog displays [18:19:34] which is probably second biggest [18:21:09] there's a huge number of places where AOTMARK is different from both Luminary 131 and 210 [18:21:16] but so far what's in Zerlina is matching the Luminary 1D flowcharts [18:21:22] so it must have just gotten changed a lot, twice [18:23:21] AOTMARK.. [18:23:34] P52 and P57 had substantial changes between 131 and 210 [18:24:15] when you fly mission with either Luminary version you always have to consult the checklist again, because it's so different [18:25:18] hahaha I believe it based on what's happened to this code [18:25:36] AOT ended up being the main weakness for accurate landings [18:25:43] so to improve that they changed things a bit [18:25:51] like accurate timing of P57 marks [18:25:56] because Moon is rotating [18:26:01] so timing matters, at least a bit [18:26:12] oh interesting [18:26:19] that makes sense [18:26:43] and the new mode to use the spiral alignment mode in P52 [18:26:47] while still docked [18:27:57] looks like 178 has those changes partially [18:28:51] 1D has PCR 982, Extend Capability of Lunar Surface Star Acquisition Routine R59 [18:29:04] 1E has PCR 1044, Re-design of R53-R57 [18:32:05] okay, down to erasables, noun tables, and the big Zerlina things [18:32:15] this very much does not build right now, haha [18:32:41] oh, prediction, that RTCC document from UHCL will have loads of display calculation routines [18:32:52] because that is currently completely missing from the AS-500 documents [18:32:58] while the AS-200 has a lot of them [18:33:08] are those useful? [18:33:30] yes, because we don't have pictures of all, or even many displays [18:33:43] but the routine description has a list of all variables displayed [18:33:46] awesome :) [18:34:14] one neat thing with the last document I requested, RTCC Support Plan for Apollo 11, is that it has a complete list of all RTCC modules [18:34:21] in most cases even with their size in byte [18:34:46] oh wow [18:34:50] that is really cool [18:35:02] whatever a byte was for them [18:35:18] probably 8 bit? But no idea, depends on the computer I guess [18:35:40] I think bytes are always 8 bits [18:35:47] the IBM 360 introduced that idea [18:36:13] the RTCC mission program had 3 parts [18:36:21] AS506.RTDS.GSCCAT [18:36:30] I think that would be something for Goddark or so [18:36:37] Goddard* [18:36:43] total 423,108 bytes [18:36:59] AS506.MISC.UTILITY is 1,599,924 bytes [18:37:03] but that wasn't done yet [18:37:11] has a lot of "estimate" on the sizes [18:37:20] and then the main part [18:37:26] AS506.RTDS.GO [18:37:27] that's pretty darn big for back then [18:37:36] has all the interesting routines [18:37:43] 3,269,548 bytes [18:38:03] so like 6 mega bytes [18:38:26] jeez [18:38:33] but that is including everything [18:38:38] calculation processors [18:38:40] display stuff [18:38:44] state vector processing [18:38:45] you name it [18:39:41] that's still a lot, haha [18:39:45] yeah [18:39:57] I'm learning a lot listening to the FIDO loop [18:40:02] they talk a lot about checkpoints [18:40:23] in lunar orbit they save a lot of RTCC data once per orbit on tape [18:40:33] restart tape in case a computer fails [18:40:41] and while a checkpoint is done nothing works [18:40:46] displays aren't driven etc. [18:40:59] takes less than a minute [18:41:03] but still :D [18:41:38] and they are doing this while the CSM is in LOS [18:42:00] so a computer would fail, they start up the backup and load that tape [18:42:08] and have the RTCC state at that time restored [18:42:59] makes sense :D [18:43:11] how often did they have to use the checkpoints? [18:43:32] no idea [18:43:34] probably never [18:43:58] the RTCC Support Plan goes into some detail, but I haven't read it all yet [18:45:15] the AS-200 RTCC documents usually have two variants of programs [18:45:20] 206 and EORP [18:45:28] which stands for, basically, Apollo 5 [18:45:33] and Earth Orbit Rendezvous Program [18:45:48] so I have most of the RTCC stuff for Apollo 5 support [18:46:51] awesome [18:47:11] including some annoying coordinate system conversions [18:47:18] if I want to add state vector uplink support [18:47:20] for Sunburst [18:47:47] might make the later maneuvers more accurate [18:49:27] hmm, what would be the single largest module in the RTCC... [18:50:47] QMMFIT with 211,504 bytes [18:51:36] I recognize FIT, that's the generalized forward iterator. Used for root finding and optimization [18:52:10] but the one usually referenced is PMMFIT, not QMMFIT [18:52:18] not sure what the difference is... [18:52:39] oh [18:52:45] I think that is an offline tool [18:52:49] so not used during a mission [18:52:54] but during mission planning etc. [18:53:22] yeah, programs with Q are off-line, programs starting with P used during a mission [18:53:39] PMMFIT "only" has 40,960 bytes [18:54:13] aha [18:54:16] you could fit that into a AGC, but not twice :D [18:54:18] interesting [18:54:28] haha yeah [18:55:01] largest on-line program is [18:55:02] PMMEAB [18:55:14] Return-to-Earth Earth-Centered Conic Logic [18:55:37] closely followed by the descent planner, which I will hopefully get some equations from soon :D [18:57:07] speaking of checkpoints, I only found one reference in transcripts, Apollo 16 [18:57:11] 263:17:07 Hartsfield: Stand by, Ken. We're getting a checkpoint here. [18:57:16] 263:17:44 Hartsfield: Okay, 16. Go ahead with the Logic check. [18:57:29] so takes at least 30 seconds, haha [18:58:11] haha [18:59:07] having the complete list of modules also says me that the upcoming UHCL document will either be very, very large or is still missing many modules [19:03:14] hopefully it's the former [19:03:33] they have been scanning for a whole week and still not done :D [19:04:58] even without, I am now so far that I can do the same inputs as requested by the FIDO from the Apollo 11 audio to plan a T2 abort [19:05:15] which includes CSM Sep, LM DOI, descent, ascent at T2, Boost at apolune, CSI, CDH, TPI [19:05:36] although for the PAD generation you only need CSI and TPI times really [19:05:38] oh holy cow, that's awesome [19:06:37] CSM Sep is manual input which needed to be added, and descent/ascent couldn't be previously used in mission planning [19:06:57] just need to put the descent simulation on some MFD page [19:07:28] and more MCC displays are used in the process [19:08:00] Sunrise/Sunset Display to determine TPI times [19:08:28] but I can't implement everything now, that would take ages [19:09:56] and they must have had some worksheets, checklists to do a few calculations by hand [19:10:28] "Dynamics, FIDO, give me the Sunrise/Sunset Table for Revs 9 to 15" [19:10:38] Then FIDO doesn't talk for a minute or two [19:10:55] while he probably looks at the Sunrise times, subtracts 23 minutes, and that's how you get the TPI times [19:11:42] probably done by FIDO himself. The talks them over with RETRO, who also calculated the numbers [19:11:56] He* [19:22:33] sunrise minus 23 minutes, that's a surprisingly easy calculation :) [19:23:16] it's super inconsistent how they determined the TPI time [19:23:25] in general you want it at orbital midnight [19:23:42] some rendezvous processors need a time input [19:24:01] others can calculate a time itself, but only as time since sunset [19:24:06] not time before sunrise [19:25:42] it's different in the RTCC MFD, but also very inconsistent [19:25:54] good job me, implementing things badly that were bad in the real thing! [19:26:43] :D [19:26:51] accuracy above all else! [19:29:41] CSM sep time calculation is not quite so easy [19:29:48] get orbital period, divide by 2 [19:30:32] although I haven't properly found a time in the FIDO loop where they did it this way [19:50:47] I don't have many more anecdotes from the FIDO loop [19:50:58] mostly been relistening to some stuff to write numbers down [19:51:21] The FIDO one time basically requested the same information twice, on two separate displays [19:51:29] FIDO confused why it is the same [19:51:41] Dynamics: "It should be the same, good program verification, Jay" [19:52:23] that would be [19:52:24] https://en.wikipedia.org/wiki/Jay_Greene [19:54:34] hahaha [20:44:15] night! [21:29:41] Woo great [21:29:42] I just went into gimbal lock. [21:29:53] Just before MCC-2. [21:29:58] This is fine [11:38:33] Hey [11:55:11] hey Thymo [11:56:55] I lost the platform on Apollo 8 yesterday. Wasn't paying attention during an auto maneuver, drove straight through gimbal lock. [11:57:37] I'm not entirely sure what REFSMMAT to back to though. Right now I'm on LVLH but I guess it should be the Launch REFSMMAT? [11:59:33] yeah, I think they would revert to the launch REFSMMAT [12:00:30] you can get it with the RTCC MFD [12:01:08] Well the one I have is no good. If I use the PTC angles from the flight plan my engine bell is roughly pointed at the sun. [12:01:32] Should I uplink the full or desired REFSMMAT with the MFD? [12:01:47] desired [12:01:59] and then do a P52 option 1 to align to it [12:02:59] Alright [12:03:33] Would I have been fine if I did an option 3 after P51 to align to the orignal REFSMMAT or is that no good? [12:03:44] Would result in large torquing angles. [12:04:28] hmm [12:04:35] I think P51 wipes the REFSMMAT [12:04:42] depending on the option you choose [12:04:47] PRO or ENTR [12:04:58] in one case it aligns to all 0 angles in P51 [12:05:04] if you did that then the original REFSMMAT is gone [12:05:25] Let me check that in the GSOP [12:06:27] yeah, on the 50 25, code 15 in P51 [12:06:35] ENTR there coarse aligns to all 0s [12:06:39] PRO bypasses [12:06:48] which probably leaves the REFSMMAT intact [12:07:40] Right [12:07:56] hmm [12:07:59] actually [12:08:04] But you'll need to course align to 0,0,0 after a gimbal lock. [12:08:18] V41 probably wouldn't touch it. [12:08:19] in P51 it doesn't give any torquing angles [12:08:31] so it leaves the REFSMMAT intact until the end of the alignment [12:08:54] when it calculates a new REFSMMAT from the current alignment and the two star sightings [12:08:58] It resets the REFSMMAT flag when you enter on the 50 25 [12:09:01] so P51 kills the REFSMMAT in any case [12:09:15] Right [12:09:23] they had to uplink a new REFSMMAT on Apollo 12, too [12:09:32] I think they even talked about it [12:09:36] if they could preserve it [12:09:42] but they had to do a P51, so no chance [12:15:01] I've wondered if you could trick the AGC to torque to a new REFSMMAT without star sightings. Theorhetically it's possible. If align is good and you just torgue you won't lose orientation. [12:15:18] hmm, yeah [12:15:18] You will if you course align to it, so you need to fine align with sightings. [12:15:28] I think there is even a technique in the checklist for that [12:16:10] You'll probably need the full REFSMMAT and then do an option 3 and somehow skip the sightings or something like that. [12:16:36] it's a bit like a docked alignment [12:16:46] uplink the full REFSMMAT [12:17:07] and maybe a V40 [12:17:39] Not V42? [12:17:42] V40 is zero ICDU [12:17:50] V41 coarse, V42 torque. [12:18:29] I meant 41 [12:18:54] if your alignment is good then yes, you just need to uplink a "fulL" REFSMMAT [12:19:04] and maybe reset the REFSMMAT flag [12:19:41] What you probably could do is. Reset REFSMMAT flag, Uplink REFSMMAT, Torque with V42 and set the REFSMMAT flag. [12:20:20] Would require ground calculation of the new angles but you skip the sightings. [12:20:37] that's basically the docked alignment technique [12:20:42] for the LM [12:20:54] but you know the attitude, because the CSM has an alignment [12:21:42] I wouldn't recommend this procedure though. You do have a chance of torquing into gimbal lock. [12:33:43] There's an error in the Checklist MFD flightplan. It lists MCC-2 as TLI+25 hours. Should be TLI+25 hrs. [12:34:59] hours vs hrs? [12:35:29] Typo. I meant it's listed as T+24 hours right now. [12:35:39] oh [12:37:28] yeah, 25 is correct [12:38:58] I had some commits sitting in my local repo [12:39:06] while doing RTCC work [12:39:12] I pushed those now [12:39:39] and you can make checklist file changes then if you want [12:39:49] Yep [13:32:04] How do I tell if an MCC is scrubbed? Haven't received a PAD yet. [13:32:55] you can let it re-display earlier messages [13:33:00] TAB and 6 I think [13:34:27] Nothing. Just some AOS messages. I'm in substate 6, awaiting a burn. [13:34:41] Mission state is 27 [13:34:51] MCC2 to Block Data 4 [13:35:21] yeah [13:35:28] waiting for the next Block Data update [13:35:33] which should come at TLI+32h [13:35:41] so about 34:55h [13:36:21] are you already past that time? [13:36:34] No. I [13:36:43] I'm at T+28h [13:36:47] oh, ok [13:36:50] That should be when MCC-2 is [13:36:55] yes [13:37:00] I didn't get anything [13:37:11] oh [13:37:16] I see what you mean now [13:37:29] that update was at 26:55h [13:37:38] and MCC-2 was probably scrubbed then [13:37:42] if you have no maneuver PAD for it [13:37:55] Or my dumb ass missed it [13:38:14] well if you did MCC-1 then MCC-2 is rather unlikely to be necessary [13:38:34] Would it hurt to reset the state and see what it comes up with? [13:38:44] should be fine [13:38:54] and yeah, just reset state will do what you want [13:40:29] Scrubbed [13:41:06] good to know [13:41:35] usually MCC-2 and 3 get scrubbed [13:41:41] and MCC-4 is 1-5 ft/s [13:41:57] depends how accurate MCC-1 was done [13:42:00] I got about 1 ft/s [13:42:16] lower is possible, but unlikely, the maneuver calculation is barely that accurate [19:21:47] afternoon! [19:23:50] hey Mike [19:24:53] what's up? [19:25:32] terribly breaking some parts of the RTCC [19:25:41] to hopefully result in something better, haha [19:26:10] hahaha [19:27:46] I'm making good progress on Luminary 1D [19:27:58] actually have one bank with the right sum now, and several more that are very close [19:28:13] awesome [19:46:44] heh [19:46:46] fun anomaly [19:46:51] L-1D-01 [19:47:40] apparently the Apollo 13 crew put the MODE SELECT switch to OFF at some point, and then did a P52 option 1 which includes coarse align [19:48:07] and the attitude error isn't properly initialized when you are in OFF, so they got a constant error in their error needles [19:48:32] avoidance: do not coarse align with mode switch in "off" [19:48:37] haha [19:48:43] how can the mode switch possibly cause that [19:48:47] weird bug indeed [19:49:00] wait, mode select? [19:49:16] "PGNCS mode select switch" [19:49:18] is that mode control [19:49:20] ah [19:49:36] mode select has no off position [19:49:41] mode control does [19:49:55] hahaha [19:50:00] they must mean that then [19:50:09] yeah [19:50:25] I guess PGNS mode control to off turns off a bunch of calculations [19:50:55] Off is not really a position you often use if you still want the FDAI error needles [19:52:58] DAP isn't really running then, that could be the issue [19:54:06] yep, that's exactly it [19:54:16] so this was fixed for 1E [19:54:22] now the question is, how exactly did they fix it [19:55:40] I doubt it could show anything useful in off [19:55:46] so they probably just set it to 0 [19:55:56] so that the error needles are centered? [19:56:15] but I guess the real issue was a desync [19:56:27] that they later started using the DAP and the error needles [19:56:32] and still had an offset? [19:57:12] RCSFLAGS Bit 3 was set to call for the initialization of NEEDLER whenever NEEDLER is not being done (that is, when the DAP is "off" and/or when the IMU is not usable). [19:57:22] Formerly the setting of the bit was bypassed anytime the mode select switch was off. [19:57:38] If the switch was turned on and the IMU was found usable it would go at once to do NEEDLER without specifying initialization passes. [19:58:12] Now the bit is set on any pass the mode select is found to be off, as well as when the switch is on but the IMU is unusable. [19:58:22] mode control [19:58:46] I'm just copy what the memos say :P [19:58:49] *copying [19:58:51] yeah [19:58:54] so it bypasses zeroing of that erasable [19:58:56] why do they say it wrong :D [20:00:04] they couldn't even make PGNS mode select calculate things right, so why even acknowledge it exists, haha [20:00:13] haha [20:00:56] nex bug sounds interesting too: P25 will not control spacecraft attitude if range to CSM is greater than 566 N.M. [20:01:01] *next [20:01:38] P25 is mainly a pointing program [20:01:44] point the LM at the CSM with the RR [20:01:49] rarely used [20:01:51] I think [20:02:12] maybe some overflow issue [20:02:32] 566NM is larger than the RR could deal with [20:02:46] but the range isn't unreasonable in some rendezvous cases [20:04:00] hah [20:04:10] Cause: Coding error - P20/P22 logic is also being applied to P25. [20:06:08] the checklist for most missions says to not use the RR or P20 when range is larger than 400NM [20:07:44] hmmmmmmmmmmmmmm, the code here is the same between Luminary 131, Zerlina, and Luminary 210 [20:07:55] they must have removed this for 1D and then realized it was a bad idea [20:09:16] that's annoying [20:11:41] they never fixed it in P22 [20:11:54] Luminary 1E program notes says not to use it with range >400 [20:12:07] referring to anomaly report L-1E-01 [20:14:24] oh! we have that anomaly report [20:14:28] what does that say... [20:15:33] Cause: Coding error. Program Correction: Fix coding - Do flag initialization properly. [20:15:35] thanks, Peter Volante [20:16:10] "Do flag initialization properly" 90% of AGC bugs [20:17:38] hehehe [20:17:48] ah! I think just deleting this code is correct though [20:18:04] right now my bank 24 bugger word is 15001 off of what it should be [20:18:34] if I delete the check, it becomes 00253 [20:19:10] and the errors on banks 23, 24, 25, 26, and 27 are 00271, 00253, 00245, 00303, and 00326, respectively [20:19:34] which very strongly suggests that the code in them is right and there's an offset somewhere that is impacting all of them [20:19:42] possibly in erasable [20:24:28] I would really like to know when that code was deleted, though [20:26:09] One of the revisions leading up to 1D that is badly documented? [20:28:18] maybe, I'm looking through the memos now [20:28:38] as long as Dana Densmore wrote the memo it'll be in here :D [20:40:03] hmmm [20:40:06] might be PCR 287 [20:43:55] Removal of 526 alarm in P22 and P20 [20:44:41] which is [20:44:51] "Range>400 Miles. Terminate P20" [20:45:01] sounds reasonable [20:48:25] that is from 1B G&N Dictionary [20:48:30] in 1E however it says [20:48:43] "RNG to CSM > 400NM, V16 N54E, RNG, RNG RT" [20:54:41] good night! [20:54:43] night! [22:22:17] Night! I'll be back next friday. [22:29:07] night! [16:11:26] hey [16:23:22] morning [16:24:14] did I really just say morning to myself?? :D :D [16:27:23] hey Alex [16:27:32] it happens to the best [16:27:42] hehe [16:28:08] I'm not sure where I am with this RTCC update. I'm half tempted to scrap it again. [16:28:52] classic feature creep [16:29:15] but it is difficult to not have that happen and still get the workflow right [16:32:43] the good news is, the changes don't affect all parts of the RTCC, just the MPT stuff [16:39:22] right makes sense [16:40:13] I guess you're still planning to add the ascent processor to the MPT [16:41:16] I have it working, yes [16:41:26] if I scrap the other parts of the update then I can still keep that [16:41:55] at one point it could already plan a whole T2 abort [16:41:58] before CSM sep [16:42:10] CSM sep, DOI, descent, ascent, boost, CSI [16:42:13] all pre-planned [16:43:01] maybe you can help me a bit [16:43:12] I just have some problems figuring out how it should work in the MFD [16:43:21] starting with initializing the MPT [16:43:57] prelaunch, you choose a configuration and initial masses [16:44:01] CSM, LM, S-IVB mass [16:44:16] the initial config would be CSM+LM+S-IVB [16:44:25] that could be done mission specific [16:44:35] and saved/loaded with MFD parameters [16:44:41] but masses is very tricky [16:44:48] unless it is done all manual [16:44:52] including mass updates [16:45:15] right now masses are only determined in two ways. Get mass of current vessel, or the mass of a vessel docked to it [16:46:58] you have experienced that already [16:47:11] CSM mass just has a default value before sep from the S-IVB [16:48:58] so there definitely needs to be a way to update masses [16:49:09] so I guess its a question of figuring out what mass to use? [16:49:18] yeah [16:49:23] initial masses could also be preloaded [16:49:27] but updating them [16:49:33] there are different configurations [16:49:45] all in one vessel in Orbiter, CSM, LM, S-IVB [16:49:50] and later it's 3 separate vessels [16:50:02] morning! [16:50:30] hey [16:52:01] thanks! [16:52:04] back in a bit [16:52:04] hey Mike [16:52:08] hey [16:52:11] what's up? [16:52:45] just trying to find ideas for Niklas about mass handling for the RTCC MFD [16:54:08] you? [17:02:34] settling in at work [17:02:46] I was making very positive progress towards Luminary 178 yesterday [17:03:00] and then I tried to change the erasables and now everything is very far from correct, haha [17:03:11] I need to step back and work through it more carefully [17:08:16] worst moment to have to go for a bit :D [17:08:36] now let's look at this document... [17:15:26] very nice [17:15:37] more detailed than the similar document we already for Skylab Rescue [17:15:41] and for a Saturn V [17:15:56] and especially more details on the terminal countdown [17:16:10] no specific checkout procedures, but I wasn't expecting that [17:16:24] :D [17:18:02] should be useful for some things when I get back into Saturn stuff [17:19:11] not unexpected with Luminary 178, it seemed to easy :D [17:19:17] has to get worse before it gets better [17:19:20] I'm so close [17:19:20] too* [17:19:43] once I figure out the erasable arrangement stuff is going to start falling into place [17:20:08] yeah, probably [17:20:25] but it's going to be very tricky, and the Norton document won't help me with this [17:20:30] nor will anything else I can think of [17:21:08] hmm [17:21:12] actually [17:21:17] do we have any Luminary 1D EMPs? [17:21:35] there should be in some Luminary memos [17:23:20] hmmm [17:23:21] http://www.ibiblio.org/apollo/Documents/LUM168-RC_text.pdf [17:23:26] ah, this one is for Luminary 177 [17:23:35] I wonder how that differed from 178... [17:25:01] ah [17:25:05] addresses are the same, looks like [17:25:15] the listing pictures at the end are Luminary 178 :D [17:26:27] ah, nice [17:27:02] oh, did you send out the 2nd attempt at a request to UHCL? [17:27:08] oh no, I'll do that [17:27:14] awesome, thanks! [17:27:45] I can use as much of that material as I can get for these RTCC updates :D [17:27:59] it's annoying, some subroutines I only have as the AS-206 variant [17:28:09] or AS-200 Earth Orbit Rendezvous Program [17:28:14] or AS-501 or 502 [17:28:32] and even the latest version in the AS-500 document differs in a few things from the RTCC Support Plan for Apollo 11 [17:29:24] so as so often I'm trying to distill a good compromise from parts of several different versions [17:31:13] I'm trying to implement the mission plan table properly [17:31:29] but I don't even have a good source for that table that applies to lunar missions [17:33:07] but there is a very good chance that it is in the remaining AS-500 document [17:33:50] hah, looking at my email history with UHCL [17:34:17] I guess I sent enough similar looking emails to Lauren that I eventually got caught in their spam filter so she had to explicitly whitelist me [17:34:23] I wonder if I was only whitelisted on her account [17:34:30] oh [17:34:31] wow [17:34:53] I always worded it slightly different, haha [17:35:28] I do too [17:35:44] but there's only so many variations on "hi, how are you? I want a document" [17:35:45] :P [17:36:05] true [17:36:06] okay, followup email sent [17:36:31] if that doesn't lead to anything I'll just send a request [17:36:38] I never had any issues like that [17:36:56] also helps that I sticked to the principle, one request per month, haha [17:37:15] haha maybe yeah [17:37:35] my requests still average about 20 pages per day since I first discovered the JSC History Collection [17:37:36] I think your first request still holds the record for the biggest though [17:37:40] oh yes [17:37:55] I specifically said, it's ok if this takes a year [17:37:58] hahaha [17:39:58] AlexB_88, so back to masses [17:40:26] you mainly need to update it during a mission to account for RCS usage [17:40:41] and slightly different as expected SPS/DPS/APS use [17:41:09] I guess I could implement a comprehensive function where you just click a button [17:41:20] and it scans all vessels in the simulation and updates the right numbers [17:41:52] you would do this once when the MPT is still empty [17:41:58] before a big planning session [17:42:19] you rarely plan very many maneuvers at once anyway [17:42:21] before TLI [17:42:29] before LOI, before descent, before ascent [17:42:32] that's about it [17:46:24] in reality they would update the current mass of a vessel occasionally [17:46:31] just when they had betters numbers in [17:46:36] based on remaining consumables etc. [17:52:02] what I also want to get away from is that you have to calculate maneuvers in the vehicle that will perform them [17:52:26] ahh, the feature creep... [17:53:37] hahaha [17:54:49] yeah that makes sense I guess, a button that updates all the masses [17:55:15] but hopefully not too complicated to implement [18:07:05] and to go even one step backwards from that [18:07:16] first you need to define which vessels are in the mission [18:09:27] so just for testing, I'll make a MPT init page [18:09:34] where you define CSM and LM vessel [18:09:46] and masses [18:10:03] and logic has to detect if the CSM still has a LM and S-IVB "inside" of it or not [18:10:36] after CSM sep it will update the mass of CSM and LM by calling the function for that of the vessels [18:11:27] if you specify a initial LM and S-IVB mass [18:11:43] then it could use the total mass of the CSM/LM/S-IVB to update just the CSM mass [18:20:47] to make any kind of progress and not be stuck in a loop I'll try that approach :D [18:28:53] haha [18:29:28] so is it just that that is preventing the big RTCC update you had, or will that be scrapped anyway? [18:34:38] I might be able to make progress with it [18:35:11] but mass handling and initialization is one of the bigger challenges [18:35:21] which thrusters gets used in each case I have mostly solved [18:35:36] configuration changes like undocking partially solved [18:49:05] yeah i'd imagine it being a pain in the *** [18:49:17] anyways Ill be out for a bit, cya [19:22:26] cya! [16:26:03] hey [16:28:07] hey Alex [16:51:02] making a bit more progress [16:51:15] instead of lunar descent my testing case is now pre TLI [17:00:08] with the masses issue? [17:05:32] yeah [17:10:50] FIDO puts 4 maneuvers on the MPT [17:10:54] 1. TLI [17:11:25] 2. a 0 DV dummy maneuver, probably just to calculate some numbers [17:11:32] on the detailed maneuver table [17:11:36] 3. LM ejection [17:11:42] a 3 seconds RCS burn [17:11:47] and 4. the evasive maneuver [17:12:14] and then the FIDO has the MPT prepared for RETRO, who is calculating the TLI+X abort maneuvers [17:20:28] Hey guys [17:21:54] hey [17:22:18] On Apollo 15, at around 54h GET, there is a TEPHEM update to the CMC, any idea on how to perform it? [17:23:22] it will only be updated if your mission will different from the flight plan [17:24:00] I can safely ignore it then? [17:24:14] probably, yes [17:24:26] okay, thanks a lot [17:24:27] page 3-55 has the criterium for it [17:24:31] on the right side [17:24:41] if you do LOI and DOI right then you should have no problem [17:24:44] of what document? [17:24:49] flight plan [17:25:33] the LOI page can display that time [17:25:39] in the RTCC MFD [17:26:51] uhh [17:26:53] no [17:27:09] translunar MCC page [17:27:18] with the non-free return options [17:27:30] shows a "Rev 2 Meridian Crossing" time [17:27:59] and you should adjust the pericynthion time then to get that time to agree with the time in the flight plan [17:28:06] the 80:40:37.6 [17:30:15] oh wow I've never used anything other than TLMCC option 1 [17:31:12] so I've put in -23.3 on latitude, and the new lat outputs -16.89 [17:31:15] what does that mean [17:31:58] hmm [17:31:58] rev 2 meridian crossing looks good, only 3s off from 80:40:37.6 [17:32:04] ah, nice [17:32:37] there is two coordinates being used for latitude [17:32:55] option 1 has the "normal" lunar latitude [17:32:56] morning! [17:33:15] the other options are relative to the Earth-Moon plane, it's a bit confusing [17:33:19] hey Mike! [17:33:19] morning [17:33:48] are you still on the ignore list of UCHL, Mike? [17:33:55] UHCL* [17:34:20] MrFickles, TLMCC option 1 gets used for MCC-3 and MCC-4, all missions [17:34:33] free return missions used option 2 for MCC-1 and 2 [17:34:52] option 4 for non-free return missions [17:35:35] haha, I've never bothered to go explore RTCC MFD [17:35:55] never needed to use anything other than option 1 since that information's easily found [17:36:03] so far I am still being ignored [17:36:07] hmm [17:36:09] but I have two more things from Marcel [17:36:12] seems like I am doing this request [17:36:19] and all requests from you and me in the future :D [17:36:24] love the new uplink page btw. [17:36:27] oh, great [17:36:36] MrFickles, and even more will come [17:36:46] haha I can't wait [17:38:50] oh yeah, what is the mission plan table and how do I use it [17:38:59] thanks! [17:39:03] I understand that was from your SSU MFD [17:39:19] yeah, kind of [17:39:21] love the functionality, but hate the interface [17:39:26] haha [17:39:28] fair enough [17:39:48] but they had it during the Apollo days already, so it's a real tool they used [17:40:04] I'm actually doing major changes to the MPT in the RTCC MFD right now [17:40:36] basically you can activate mission planning [17:40:44] on the MPT page [17:40:59] and then any maneuver calculation will use the trajectory from the previous maneuver [17:41:20] so you could calculate LOI-1, it goes to the MPT, end then calculate LOI-2 already [17:41:28] and not wait until after LOI-1 to calculate it [17:42:19] I'm listening a lot to the Apollo 11 FIDO loop audio right now to get a better understanding of how it was used [17:42:48] Oh yeah. thats how they could have released every single maneuver on the press kit [17:43:06] especially Apollo 7 with all their SPS burns [17:43:07] well, they had an on-line and an off-line planning tool [17:43:20] off-line for pre mission planning [17:43:24] and on-line for during the mission [17:43:59] during the mission one case is the TLI+X abort maneuver PADs they got [17:44:07] TLI+90min and TLI+4h usually I think [17:44:17] and they got that with the TLI PAD [17:44:19] yeah, that was given before TLI even [17:44:20] so before TLI [17:44:43] so they had TLI, LM ejection and evasive maneuver on the MPT for Apollo 11 [17:45:00] and used the resulting state vector and vehicle mass to calculate the abort maneuvers [17:45:14] wouldn't it have made more sense to calculate real time though? There would definitely have been errors introduced in the burns [17:46:10] oh, I'm sure they would be updated if they actually had to do these maneuvers [17:46:17] but things can go wrong with many systems [17:46:20] including communcation [17:46:33] so they had a valid Maneuver PAD to return home at any time [17:46:50] that's true, which is why they gave the PADs many hours in advance right? [17:47:01] yeah [17:47:09] Apollo 8 got a TEI PAD for every lunar orbit [17:47:14] but later they reduced that [17:47:37] thewonderidiot, checkout document is from 1965, but considering that it's pretty nice :D [17:47:40] I've never thought about it that way [17:47:48] learnt something new, thanks [17:48:53] inspired from the FIDO loop I'm trying to make the workflow the same as in reality [17:49:05] but that spiraled out of control into a huge project I am in right now :D [17:49:21] you are creating your own Monster :D [17:49:48] wouldn't expect anything less from the largest engineering project ever undertaken in human history [17:52:08] thewonderidiot, I was wondering what kind of worksheets they used in mission control, especially FIDO. This Booster systems engineer document has exactly that for their team :D [17:52:17] pretty great document as well [17:53:02] :D [17:54:31] I'd like to find stuff like that for more flight controllers [17:55:44] so I'll just request this RTCC document then [17:56:09] it must be that issue that you were talking about [17:56:17] that your mails ended up in the spam folder [17:57:22] indy any news about that difference between the input lat and 'new lat' on TLMCC option 4? [17:57:49] everything checks out except that 1 value [17:58:20] ah right [17:58:24] that is just a coordinate difference [17:58:36] option 1 and the other options use different values [17:58:43] so I'm good to ignore? [17:58:44] -16.90093° is our default we use for Apollo 15 [17:59:06] calculated dv is 1.5 at MCC-3 so it looks normal to me [17:59:10] and if you calculate an option 4 it will update the values on the page for option 1 [17:59:28] it got updated to -16.89° in your case, so very close [17:59:51] oh yeah it does! [17:59:59] didn't even notice it [18:00:17] those options 2 and 4 are used for MCC-1 and 2 and one output is new coordinates for option 1 [18:00:25] and those new coordinates will then be used for MCC-3 and 4 [18:00:31] that's how it works [18:01:04] if everything goes exactly as planned before the mission then the coordinates for option 1 wouldn't even change [18:01:41] so your suggestion would be to use option 1 TLMCC for my MCC-4? MCC-3 I'm deleting as per the actual flight [18:01:53] yes [18:01:59] seeing as though it would be 1.5ft/s anyway [18:02:16] roger that [18:02:22] options 2 and later either optimize the DV or achieve free return [18:02:39] option 1 just stupidly targets those displayed coordinates [18:03:22] doesn't take into consideration if that leads to a good LOI or not. But AlexB_88 worked out some good default option 1 values for all missions [18:03:58] so if you aren't way off the planned mission then using option 1 exclusively will still get you where you want [18:05:18] I'm following the flight plan so, yeah never needed to use anything other than option 1 [18:06:07] MCC-4 is 0.2ft/s dv [18:06:19] that's not even worth doing, haha [18:06:20] costs more to do the MCC than to delete it [18:06:37] yeah, just the attitude maneuver to burn attitude alone :D [18:07:04] trajectory is right on the money then [18:08:25] im 100% sure it'll change once I start maneuvering the spacecraft for those photo experiments [18:08:42] ahh, are those uncoupled? [18:09:31] what do you mean by uncoupled? [18:10:02] uncoupled RCS firings [18:10:17] where you deactivate half the RCS thrusters to have finer control [18:10:34] don't think so [18:10:37] but then you get trajectory changes because there aren't 2 RCS jets firing against each other [18:10:52] what did you mean then? [18:11:20] RCS is still firing off the cg of the CSM/LM stack right [18:11:35] so I'm guessing it'll have a slight translation effect [18:12:28] hmm, probably shouldn't have an effect [18:13:26] like the CSM RCS is trying to torque the spacecraft about the cg of the CSM, but in reality the cg is way further forward of the CSM cg [18:13:55] yeah, but all you have is still two RCS jets cancelling out each others imparted translation effect [18:15:07] in lunar orbit and in some other cases like P23 they deactivate half the RCS thruster to get finer control [18:15:12] then they don't cancel each other out [18:15:18] and you get a small trajectory change [18:15:27] that one I agree [18:17:42] but imagine the spacecraft cg "below" the CSM cg, and you rotate the spacecraft about the CSM axis such that it's "above" the CSM cg [18:17:53] doesn't the spacecraft gain energy [18:18:02] rotational energy [18:18:10] for the translations the CG doesn't matter [18:19:13] if I am not having an error in thinking there [18:20:22] we'll soon find out [18:20:33] I've got another hour or so in PTC [18:21:04] MrFickles, MCC-1 and 2 are usually optimized with options 2 and later. This optimization recalculates the nodal targets that you see in option 1. I had already found nodal targets that were well optimized (with option 4) and they are pre-loaded in the RTCC MFD for all the missions, so if you used the default targets in option 1 then you should still be on a pretty good trajectory [18:21:07] by the way, do you know why they kept venting the tunnel to >2.7psid? [18:21:35] hmm, no, no idea [18:21:42] pretty sure they didn't do that on earlier missions [18:22:01] AlexB_88, I'm following the actual flown trajectory, including all errors. That's why I'm not using any of the default values [18:22:33] otherwise the timing would be off like in my MCC run of apollo 11 [18:22:54] when it comes to doing LOI, all you need to do is push calculate on the LOI-1 page and it should give you a good LOI solution. The LOI-1 and DOI page all have pre loaded values too. In the case of DOI, you only need to put in TIG [18:22:58] ah, right I see [18:23:15] that's not a problem with the non-free return missions luckily [18:23:32] you can just adjust the time of pericynthion to get the same trajectory [18:23:37] and timing [18:25:42] thewonderidiot, so I'll just request the document as well. Should I write them anything? "Please unban my friend Mike?" :D [18:25:59] just to not get a resonse myself I bet... [18:26:06] I'd wait until after you get a response to ask about that, haha [18:26:54] yeah [18:29:03] MrFickles, I guess using your custom values in option 1 + but with the preloaded values in the LOI page will work well [18:29:20] AlexB_88, copy that [18:29:44] DOI would be difficult to replicate like the real mission [18:29:57] they had a plane error in the state vector used for targeting LOI [18:30:09] so they added an out-of-plane DV component to DOI [18:30:30] RTCC MFD doesn't support that. And you will probably not need it with the LOI targeting [18:31:24] hmm, I just realized that after LOI was DOI [18:31:30] yep [18:31:31] that might complicate things a little [18:31:33] done with the CSM [18:31:41] instead of LOI-2 [18:32:42] and I'm guessing the DOI trim was to get the spacecraft in the right position for PDI? [18:33:32] ok, on Apollo 15... [18:33:38] well LOI and DOI pages already support the DOI as LOI-2 style burns [18:34:07] DOI trim was planned, but nominally 0 [18:34:12] AlexB_88, indy meant the out-of-plane component I think [18:34:32] that's not supported in RTCC MFD [18:34:54] and you will likely not need it anyway [18:35:14] well that was just caused by an inaccurate SV in the real Apollo 15. Unless you try and artificially make an inaccurate SV you wont need an out of plane DV for DOI [18:35:15] LOI targeting can't use a "bad" state vector, haha [18:35:31] that's good to hear [18:35:41] DOI Trim was because the orbit decayed too much [18:35:48] perilune got too low I guess [18:35:59] or the orbit simply changed the shape [18:36:04] that will also not really happen [18:36:12] Orbiter doesn't support the weird lunar gravity [18:36:20] it's more simple [18:36:32] with mascons etc. [18:36:47] all you really need to do is push calculate on the LOI page for the LOI burn. When you come to DOI, just put in the real TIG and push calculate. all the other boxes are preloaded and should have the right data [18:36:49] that caused the DOI trim being necessary [18:37:57] AlexB_88, ok [18:38:17] thewonderidiot, request sent [18:38:22] I'll be back later [18:38:31] hopefully you don't get blocked :D [18:39:11] indy91, makes sense, I was wondering how they managed to change both apo and per with a purely prograde burn [18:45:04] gotta run! cya guys [18:51:14] back [20:03:45] night! [03:09:54] .tell indy91 somewhat strange question, do any of the LM simulation printouts have erasable addresses/values in them that are *not* padloads? I just noticed in Don's index that he has a partial simulation printout of Luminary 178 [12:32:52] . [12:39:10] .tell thewonderidiot not many, usually just state vector and a few other things to make the simulation work [16:47:01] hey [16:47:51] morning! [16:48:09] so what you're saying is that the answer is yes, and I should ask Don for pictures of it :) [16:49:13] hey guys [16:49:29] yeah, there could be a few addresses [16:49:41] the sims weren't all the same with what they had [16:49:56] thewonderidiot, did you hear from UHCL yet? [16:50:15] I did! [16:50:40] haha [16:50:42] so did I [16:50:50] nice [16:51:06] I think I need to be more creative with my email titles [16:51:09] this is what i got back: [16:51:10] RE: [External - Subject Filtered] Re: Apollo Document Scan Request 8% [16:51:15] yeah [16:51:19] I got the 8% as well [16:51:36] mine wasn't filetered though [16:51:53] I probably have used the same title in all my mails [16:51:59] Document from the JSC History Collection [16:53:10] haha [16:53:13] so I should be less creative [16:53:48] so your mail probably ended up in spam, which caused it to be seen later [16:53:58] yeah [16:54:01] but having two requests for the same document probably accelerated it [16:54:07] haha [16:54:24] now they know you're just using me for your own scanning purposes though :P [16:54:39] nah, not really [16:55:21] at most they suspect a somewhat coordinates effort [16:55:24] haha [16:55:25] coordinated* [16:55:30] anyways [16:55:36] I got some more scans from Marcel [16:55:41] oh, great [16:55:44] who wants to be introduced to you and Ron over email [16:55:47] let me upload these to drive... [16:55:54] the scans so far have been great [16:56:32] a bit down the road when they are going to be useful, but I think they all will be [16:57:13] and today is Ron's first day at NARA? [16:57:23] oh crap, I totally forgot [16:57:23] yes! [16:57:34] :D [16:57:39] that's exciting [16:57:51] here's hoping that the flowcharts are for a revision later than Luminary 131 [16:57:59] anyways, first scan: https://drive.google.com/open?id=0B3i9WUgD9n2td21GRVpKeUdpX2JtNk9hYkdQTGFoLVVra3dv [16:58:07] which looks pretty interesting [16:58:37] second scan: https://drive.google.com/open?id=0B3i9WUgD9n2tcV9CQ0p1XzJSUE03TW9obmROOS1qZjV5Smdn [16:58:43] they always turn out to be larger than expected... [16:59:09] ah great, the flight manual [16:59:44] the first document: "ah, 1965 again" [16:59:50] haha [16:59:54] "oh, December 1967 revision!" [16:59:58] that's much better [17:00:08] :D [17:04:10] good reference [17:04:23] probably not much of it will end up in NASSP code [17:04:35] but it's good for understanding the S-IVB [17:05:09] and the AS-508 flight manual will tell us a bit more about, well many things, but also the LVDC flight program [17:05:34] I think the first one might be useful for different reasons [17:05:51] these 1Bxxxxx numbers match drawings at NARA [17:05:59] yeah, that too, haha [17:06:13] so if you need more information about any of the things referenced in this we can probably get it [17:07:00] great [17:08:28] very useful from the flight manual is always the "attitude, vent, APS burn, and propellant dump timeline" [17:08:46] the flight evaluation report isn't always clear about everything [17:09:04] and it has a bunch of attitudes used [17:09:14] definitely can crosscheck those with what we have [17:10:01] and Apollo 13 S-IVB is the first they crashed into the Moon [17:11:23] AlexB_88, I'm making progress with the MPT [17:11:28] both in understanding and coding [17:11:43] ah nice [17:12:17] I bet the understanding part was the hardest [17:12:23] yeah [17:12:31] listening to more of the FIDO loop helps [17:12:36] right [17:12:43] while there is a combined MPT display, there are actually separate MPTs for CSM and LM [17:12:55] I didn't fully understand how they interact [17:12:59] like a docked maneuver [17:13:10] if that is then added to both MPTs or not [17:13:20] and it is not [17:13:26] the two MPTs are functionally identical [17:13:37] and quite separate really [17:14:04] for TLI they used the CSM one for all the normal planning [17:14:14] 1st opportunity TLI, ejection, evasive etc. [17:14:31] but a bit before TLI they used the LM MPT to calculate a 2nd TLI opportunity [17:14:44] the FIDO mostly wanted the TIG [17:15:02] but the TLI was still put on the MPT and he looked at the detailed maneuver table for it [17:15:33] the workflow to e.g. plan the lunar descent before LOI-1 would work like this [17:15:40] LOI-1 and 2 in CSM MPT [17:15:56] and then you choose a LOI-2 burnout vector as the anchor vector for the LM MPT [17:16:07] so the LM MPT would start with that [17:16:24] and that is the last trajectory change for the LM before DOI [17:16:44] so you initialize the LM MPT with the configuration code LM [17:16:59] CSM sep would be an undocking maneuver, so it changes the config from CSM/LM to CSM [17:17:10] and then you have the two trajectories for planning just like you need [17:17:59] I will probably have to make a video tutorial on how to do the proper planning with the MPT, haha [17:19:43] haha yeah [17:19:56] sounds very interesting though [17:20:36] it will really make the RTCC MFD extremely flexible for all kinds of situations [17:34:08] yeah [17:34:30] and it will fix a lot of issues where I had to make compromises [17:34:36] like mass to use for a burn etc. [17:37:51] all maneuvers that were done ended up on the MPT [17:38:01] but I'll try to keep it as simple as possible in the RTCC MFD [17:38:19] right now you can in many cases enter a TIG and press CLC and you have a solution [17:38:40] the only step added to that really will be a thruster selection page [18:00:28] man I am so impatient for Ron's NARA report now [18:18:20] for me it's the remaining AS-500 RTCC document, haha [18:18:47] the RTCC stuff that Ron will get us won't be implemented until this mission plan table update is done [18:22:17] and the first document in the list is just remaining diagrams from the last document he scanned [18:22:34] Apollo 11 LM Abort and Rescue Plan [18:32:04] even if I don't really need the remaining pages from it, I was responsible and completionist and put that first, haha [18:34:41] hahaha [19:41:44] indy91: they just sent me the document [19:41:51] oh boy [19:42:12] 568 MB :) [19:42:24] haha, ouch [19:42:52] the other ones were smaller [19:43:00] but it could just be different scan settings [19:43:25] actually quite varying in size [19:43:43] one is 150MB for 250 pages, one was 140MB for 490 pages [19:45:48] 942 pages [19:46:10] yay [19:46:17] my download is slow [19:46:19] but almost done [19:46:40] at least some stuff from '68 [19:46:48] november '68 even [19:46:55] 3/13/69 [19:47:23] yeah, that's very usual for these documents [19:47:28] the AS-500 ones [19:47:34] lots of mid and late 1968 [19:47:38] and the occasionaly early 1969 [19:47:40] 4/4/69 [19:47:43] cool [19:47:58] I've studied the module names so much, I'll be able to tell quickly if it is good [19:48:09] unlike when I first got this type of document [19:48:20] then it was just a random collection of stuff to me [19:48:40] you are the same way about the RTCC as I am about the AGC :D [19:50:05] lots of QM instead of PM [19:50:08] so offline program [19:52:21] then MED Format Tables, I like those [19:52:39] looks like there's tons of those [19:53:08] yep [19:53:24] and in more detail than in the RTCC Operational Support for Mission G document [19:53:36] I like that a lot [19:54:16] no additional calculation modules really in the whole document [19:54:23] that's a bit disappointing [19:54:27] but there is QMMFIT [19:54:33] I really wanted to find PMMFIT [19:54:39] they might be quite similar [19:55:06] the MED formats are really helpful though [19:55:11] and that is like half the document [19:55:19] hmm [19:55:30] so not as good as it could have been, but still good? [19:56:02] pretty much [19:56:10] not that surprising [19:56:18] this is AS-500 Systems Integration [19:56:41] the really good stuff is mostly in AS-500 Mission Planning [19:56:45] but not all of it [19:56:48] it's quite mixed [19:57:32] for the first time there is a bit of an order [19:57:36] the MED Formats go up to P [19:57:45] an earlier document I got started with Q [19:58:55] especially the description of the M-type MEDs are one thing I was hoping for [19:58:59] and are immediately useful [19:59:48] :D [20:02:05] ah, AP and AA stand for ascent guidance (PGNS) and ascent guidance (AGS) [20:02:19] guidance options you can choose [20:04:46] LLP [20:04:49] lunar landing program [20:04:55] if that is for e.g. Apollo 11 [20:05:02] what does LMSP mean [20:05:05] could be for Apollo 8 [20:11:35] uhh [20:11:47] hmm [20:11:54] not coming up with an acronym for LMSP [20:12:27] Lunar Module Simulation Package [20:12:29] probably not that [20:12:45] ah found it [20:12:50] in another one of these documents [20:12:56] AS-200 though, haha [20:13:03] Lunar Mission Simulation Program [20:13:06] you were close :D [20:13:30] aha [20:15:33] this probably refers to a C' or F type mission being the simulation of a lunar landing mission [20:15:42] and not that it gets used in a simulation on Earth [20:29:23] night! [06:16:59] thewonderidiot, still awake? [06:24:36] indy91: yep! [06:24:45] what's up? [06:24:55] one of the MSC memos that Ron scanned [06:25:06] haha, so you found it :D [06:25:07] oh btw, I didn't get an email from UHCL yet [06:25:24] interesting [06:25:26] they are testing us. If I don't ask for it again then they know :D [06:25:30] hehehe [06:25:47] the document seems to be mostly additions to earlier documents [06:25:53] but in the end it has general flowcharts [06:25:57] really good stuff [06:26:07] and this is just the shortest of the documents I bet [06:26:59] :D [06:27:01] the archive org viewer really needs the option to rotate a document [06:27:07] a page* [06:27:09] it sort of does [06:27:17] well [06:27:24] the website knows how to do it, the viewer just doesn't [06:27:25] I just saved the flowcharts as pictures and downloaded them [06:27:35] the PDF is not high quality enough to see everything [06:27:42] if you open the image in a new tab, you'll get something like this: [06:27:53] https://ia801505.us.archive.org/BookReader/BookReaderImages.php?zip=/9/items/68fm119images/68-FM-119_jp2.zip&file=68-FM-119_jp2/68-FM-119_0025.jp2&scale=2&rotate=0 [06:28:04] you can tweak the two options at the end [06:28:11] e.g., make it scale=1&rotate=90 [06:28:23] https://ia801505.us.archive.org/BookReader/BookReaderImages.php?zip=/9/items/68fm119images/68-FM-119_jp2.zip&file=68-FM-119_jp2/68-FM-119_0025.jp2&scale=1&rotate=90 [06:29:11] ah, right [06:30:11] the same equations were already in the IBM RTCC documents [06:30:16] but handwritten [06:30:29] and more like actually programmed [06:30:36] and not logic flowcharts [06:30:39] very difficult to read [06:31:20] if I want to implement this I need both really, haha [06:31:25] the equations are looooong [06:32:06] hehehe [06:33:09] also useful, a list of variable definitions [06:34:01] I didn't expect Ron to get everything from the list [06:34:06] I just picked 10 documents as a start [06:34:34] yeah, I wasn't expecting everything either [06:34:50] NARA picked the perfect day to disable his badge, haha [06:35:21] yeah, good for us [06:36:13] oh lol [06:36:20] variable L_1 [06:36:24] "Refers to Agena" [06:36:37] yeah, this is definitely from Gemini [06:37:02] the document is from 1968, but they didn't bother updating that yet [06:37:58] hah [06:38:34] the original document about this is from 1964 [06:38:39] it even references one from 1959 [06:39:49] anyway, I have to go [06:39:58] see you later! [06:40:01] goodnight! [17:04:49] morning! [17:28:55] hey Alex [17:33:11] hey [17:33:20] whats up? [17:37:31] refreshing the internet archive page, waiting for Ron to upload more of what he scanned at NARA yesterday :D [17:37:43] you? [17:45:46] hey guys [17:45:50] thewonderidiot, same [17:46:19] hehehe [17:46:40] I got one first [17:46:49] but probably because it was the shortest document [17:47:13] AlexB_88, making good progress with the MPT changes now [17:47:14] probably [17:58:52] btw, indy91 [17:59:02] https://archive.org/details/68fm119images [17:59:11] based on that URL [17:59:27] you can sometimes guess at other things that have been uploaded but are not being displayed yet [17:59:30] if you haven't already tried :P [17:59:36] I have not [17:59:55] mainly because I have enough material to finish this mission planning update :D [18:00:02] the new RTCC stuff is for other things [18:00:18] but if I was just waiting, then I had probably already tried that [18:00:30] hehehe [18:02:19] none of the others is up [18:19:58] indy91, sounds great [18:20:33] I implemented the checkout monitor, another MCC display [18:20:48] thewonderidiot, not much just random browsing ;) [18:20:48] they often used that to check if the MPT trajectory and masses check out [18:21:01] already helped me find bugs, haha [18:34:58] nice [18:35:21] did the new RTCC docs help? [18:39:35] Ill be back later [18:40:44] the one from UHCL helped a bit, yeah [19:24:21] cya! [16:43:50] morning! [16:48:23] hey Mike [17:01:58] what's up? [17:03:15] Pressing F5 very often [17:03:21] hahaha [17:03:32] yeah [17:03:38] and making good progress with the MPT stuff [17:03:47] all I want to know is what revision of Luminary the 1C flowcharts are for [17:03:49] haha [17:04:07] this MPT update needs to be done before I can really dive into any of the new documents anyway [17:04:19] that's a good motivator :D [17:09:17] Hey guys, my Apollo 15 DOI trim burn is completed. Looks like PDI will be only 40 seconds earlier than historic, and crossrange I managed to get 0.2nm [17:10:20] pretty good [17:10:33] on what basis did you choose the DOI trim DV? [17:12:51] just the actually burned DV? [17:14:11] or used the DOI calculation in the RTCC MFD again? [17:15:26] I ran DOI from LPO on RTCC MFD [17:16:08] DOI as LOI-2 for the DOI burn, DOI from LPO for the DOI trim [17:16:13] yeah, that's probably the right approach [17:16:19] I reduced the N value from 11 to 4 [17:16:23] yeah [17:16:41] can't have been a very large burn I guess [17:16:51] 3.4ft/s I got [17:17:02] historic was 3.2 [17:17:02] nice [17:17:05] yeah [17:17:30] interesting that it is similar [17:17:39] must be a coincidence [17:17:49] probably a coincidence [17:18:28] 1 problem I faced was that P20 wasn't working as I expected [17:18:55] hmm, P20? This early? [17:19:26] yeah, almost immediately after LOI or DOI [17:19:40] and it was left on through the sleep period [17:19:48] oh right [17:19:50] I forgot, haha [17:19:55] universal tracking [17:20:08] what was the problem with it? [17:20:24] yeah so anyway P20 F50 18 points me in a random direction [17:20:33] and just holds that attitude [17:20:51] should have been SIM bay forward [17:22:02] huh, was that a new procedure for Apollo 15? [17:22:22] kind of [17:22:27] I think Apollo 14 already did it [17:22:39] but with an extended verb instead of the P20 update in Artemis [17:22:40] there was an anomaly in Luminary 1D (L-1D-08) [17:22:47] oh P20 in the CM? [17:22:49] or LM? [17:22:50] yes [17:22:54] Artemis [17:22:55] got it [17:23:02] it gets used for more than just rendezvous tracking [17:23:08] which I also forgot for a moment, haha [17:23:16] yeah there was a P20 bug in Luminary 1D that would corrupt one of the padloaded values if done before PDI :P [17:23:36] not really a bug [17:23:42] well [17:23:52] it was anomaly L-1D-08, so they counted it as a bug [17:23:56] I thought it was pretty much established that you can't run P20 in Luminary before powere descent [17:24:02] fixed in Luminary 181 [17:24:13] pretty sure that was a long running bug then [17:24:25] all missions up to Apollo 14 then [17:24:55] maybe not, maybe I just read about that for Apollo 14 [17:25:18] MrFickles, and you are sure you had all the P20 nouns right? [17:25:19] it was only discovered in 173 at least [17:25:43] I followed the values given in the flight plan [17:25:44] +90, +90, +180 is the first P20 after LOI [17:25:54] https://i.imgur.com/xQJIWNV.png [17:25:57] The first one worked fine [17:26:00] ah [17:26:15] it's only the SIM bay pointing that's not working [17:27:05] +90 +52.25 +180 and +90 +52.25 +0 [17:27:48] that should just roll you a bit [17:28:03] and point you forward/backwards [17:28:27] possibly an alignment or state vector issue? [17:28:52] don't think so, DOI and DOI trim were fine [17:29:16] first time I tried it, it pointed me sideways, 2nd time I tried it pointed me straight up [17:29:39] when DSKY blanked I get a flashin UPLINK ACTY [17:29:51] not sure what that meant [17:30:03] can't find any references to a flashing UPLINK ACTY light [17:31:30] oh [17:31:36] that means you have to do a V58 [17:31:45] let me find the checklist reference to that [17:32:20] https://history.nasa.gov/afj/ap15fj/csmgc/3-02.gif [17:32:23] in the center [17:32:31] POSS UPLINK ACTY lt [17:32:34] that means [17:32:38] maneuver of >10° is required [17:32:44] and V58E allows it to do that [17:32:51] so maybe it was just that [17:34:10] ok, I'll try that [17:34:22] thewonderidiot, in Luminary 1E(!) Program Notes [17:34:52] 2.1.26 "If P20 is selected in the update mode prior to completion of P66, the W-matrix initialization will destroy the E-memory descent targets" [17:35:15] that might or might not apply to all Luminary versions [17:35:16] but [17:35:20] you can safely run P20 [17:35:30] as long as you don't choose to let it update either state vector [17:36:30] hey, I have a V05N01 1706E in the flightplan now [17:36:35] what is that changing? [17:36:39] TEPHEM [17:36:43] don't do it, haha [17:36:50] ok copied [17:37:03] that's another one of these clock updates [17:37:12] like the one during translunar coast we talked abot [17:37:14] about [17:37:45] where is that in the flight plan? [17:38:04] 097h GET [17:39:00] about to get extremely busy for me [17:39:12] LM activation in about 40 min [17:39:20] well the V05N01 1706E would be safe to do [17:39:25] that just displays the TEPHEM [17:39:28] liftoff time basically [17:39:44] 15 minutes earlier in the flight plan is a "T EPHEM UPDATE" [17:39:58] if it was necessary then it would have been writtent down there [17:40:15] and address 1706, 1707, 1710 would have been changed in the memory [17:40:24] but you are 40 seconds off [17:40:27] I see, so this would just have been a verification? [17:40:33] and the criterium remains +/- 2 minutes [17:40:38] yep [17:40:48] ok [17:40:51] probably changed by uplink [17:41:47] but it wasn't necessary on Apollo 15 [17:41:51] and it isn't for you either [17:42:05] good to hear [17:49:50] I guess I'll leave the LM activation for tomorrow, I kind of need a "rest period" for myself [17:50:05] I'll talk to you guys another time, thanks for the help! [18:15:48] hey Alex [18:16:31] maybe those are two separate P20 issues, Mike [18:16:41] the general one is with SV updates [18:16:57] and the one in 1D and fixed in 1E happens also when you don't have SV updates enabled [18:17:09] and are just tracking the CSM [18:17:26] but I haven't really tried this in earlier Luminary [18:17:27] yeah [18:17:32] to see if it really destroys padloads [18:17:42] it's specifically LRWH1 [18:17:57] which wasn't introduced until Luminary 1D anyways [18:18:41] so there's no other Luminary to try it on other than 1E at the moment :D [18:18:57] or Zerlina, but since Zerlina's based on 183 it has the bugfix [18:19:09] or no, nevermind [18:19:15] Zerlina doesn't have it because Don rewrote everything [18:19:49] nope, wrong branch. Zerlina does have it [18:19:55] but it's in the same place as Luminary 210 [18:20:00] so it does have the fix [18:20:22] W-Matrix overlays TLAND, RBRFG etc. [18:20:26] in Luminary 99 [18:20:30] right [18:20:32] I think this is the issue I was thinking of [18:20:53] W-Matrix gets re-initialized when you allow SV updates in P20 [18:21:16] and it's basically the same in all Luminarys [18:21:26] W-Matrix always starts at E5,1400 [18:21:38] hey [18:21:39] and so do the descent targets [18:21:42] hey Alex [18:22:01] yeah [18:22:24] but in Luminary 1D, LRWH1 gets corrupted even if you don't [18:22:34] yep, that will be the difference [18:23:56] speaking of, Don's going to be scanning that earlier Luminary 1D padload and the simulation printout pages next week [18:24:27] it figures that the one padload document I scanned that doesn't have addresses is for Luminary 1D :P [18:25:16] the usual luck [18:25:24] Apollo 11 ran P20 after DOI [18:25:36] most missions didn't risk it even running it even if it was save [18:26:54] Apollo 12 also did [18:27:07] Apollo 13 planned to do CSM DOI, so it's different anyway [18:27:29] on the FIDO loop Goddard asked for post burn state vectors for CSM sep and DOI [18:27:45] and FIDO said "you realize we don't do CSM DOI yet, that's one of the next missions" [18:27:56] so they definitely had it already planned in July 1969 [18:28:00] hahaha awesome [18:28:35] I didn't realize they were already planning to do it on 13 [18:31:15] AlexB_88, good progress with MPT initialization [18:31:25] the way I have it right now is a MPT Init page [18:31:43] you don't have to do much manually really [18:31:55] you choose which MPT you want to update, CSM or LM [18:32:13] then press an auto update buttons which finds the current configuration, CSM, LM and S-IVB masses [18:32:20] then you can manually edit them if you choose so [18:32:28] then you press 3 other buttons [18:32:36] update MPT with the chose configuration [18:32:43] update MPT with the chose masses [18:32:58] and update anchor vector of the MPT, so the initial state vector for the trajectory [18:33:06] and then you are ready to go [18:33:37] you would probably want to do this before each planning session [18:33:56] but the initial parameters will get saved in the scenario [18:34:10] and get updated with a "confirm maneuver" button [18:35:53] it's not really different from e.g. updating the masses in V48 [18:36:01] and docked/undocked in the RTCC MFD config menu [18:42:14] sounds very good [18:42:26] more intuitive then I thought [18:43:38] and you can always check if you did something wrong with the checkout monitor, just like FIDO, Dynamics etc. very often did [18:44:07] input GET, GMT, maneuver start, maneuver end and it display all sorts of trajectory parameters and the configuration and the masses [18:44:14] input either* [18:45:37] now, do I even want to retain the method of calculation stuff without the MPT [18:45:47] for now probably yes [18:45:56] until everything is 100% compatible with the MPT [18:46:10] means a bunch of additional code, but shouldn't be so bad [18:50:30] nice [18:50:58] so the checkout monitor will simulate a display FIDO had? [18:52:01] yep [18:52:13] I'd say it completes the trio of general trajectory displays [18:52:23] FIDO Orbit Digitals, Space Digitals, Checkout Monitor [18:53:06] when I first listened to the FIDO loop I was surprised by how often they used the checkout monitor [18:53:12] so will the orbit/space digitals pull trajectory data from the MPT? Like, will it know of all the maneuvers you add to it? [18:53:18] yes [18:53:22] ah great [18:53:27] haven't fully done that yet, but it will [18:53:41] it was already partially compatible before even [18:53:51] and I guess there will be a display of DV available? [18:54:16] like, I got the TIG for the boost maneuver for the T2 abort from the FIDO Orbit Digitals [18:54:26] by request apoapsis/periapsis display at a specific GET [18:54:48] haven't added that yet, but DV remaining is part of the MPT display, yeah [18:55:42] I think its a very useful feature, say in the case where I used up more fuel then planned by the time I got to lunar orbit on Apollo 16 [18:55:54] yeah [18:56:31] the TLMCC processor doesn't optimize DV in the BAP mode actually, it optimizes mass [18:56:41] so the display for it, which I have no reference for, might have a mass display [18:56:51] oh wait, I have the RTACF version of it [18:57:50] hmm, not the one display for it in the RTACF [18:58:05] I also have to find out how they input the DV remaining in the MPT [18:58:35] the initial value is 0, so in the example display I have of it it starts at 0, and then goes into minus with the maneuvers in the plan [19:01:09] hmm, so there is not only total masses for vehicles, but you can also define remaining fuel for thrusters [19:01:31] which doesn't get used in the MPT mass calculation, but might be usable for the remaining DV [19:03:19] "The fuel remaining for the CSM (RCS or SPS), LM (RCS, APS, or DPS), and S-IVB may be changed. The input of these values will result in a change to the thruster fuel remaining at the end of the last maneuver before present time and in DV remaining displayed on the MPT and DMT to be recomputed. The new fuel weights will be carried forward to subsequent MPT maneuver." [19:14:40] you could e.g. only enter SPS fuel for that [19:14:48] then RCS doesn't count for the DV calculation [19:53:51] hmm [19:53:56] still no more documents from Ron [19:54:09] I wonder if he pushed through the whole process with 68-FM-119 as a test [19:54:13] and is doing the rest of them in parallel [19:57:51] could be [19:58:06] then we would get all the rest at once [19:58:58] AlexB_88, you might like what kind of documents Ron has scanned and soon will become available [19:59:13] Logic and Equations for the Real-Time Computation of the Lunar Module Descent Planning Table [19:59:17] Logic and equations used to compute the lift-off time for the early rendezvous profile of Apollo 14 and subsequent missions [19:59:22] RTCC Requirements for Apollo 14 (H-3) Mission: Earth-centered Return-To-Earth conic subprocessor [19:59:25] and a few others [20:01:50] also flowcharts for Luminary 1C, Comanche 67, and Comanche 72 ;) [20:02:45] and those three easily outweigh all of your documents combined, regardless of how big they are :P [20:03:05] oh yeah, definitely more pages, haha [20:03:10] I am definitely the cause of most of Ron's suffering, haha [20:03:38] that sounds good for future requests of mine, once has has forgotten about this time [20:04:37] hopefully this weekend! [20:05:13] oh yeah, I am sure he will get it done this weekend [20:05:23] if the 1C flowcharts are indeed for LUM131 rev 9 or LM131 rev 1, it will be easy to finish them [20:05:39] as long as the flowcharts contain the magic words "via POSTJUMP" or "via BANKCALL" on their arrows [20:05:45] like they do on some pages [20:08:54] indy91, sounds great, looking forward for those docs! [20:09:07] thats mostly what was missing, right? [20:09:39] well if it contains what I hope it does [20:09:44] especially that Descent Planning Table one [20:10:02] the more I think about it the more convinced I am it will just have calculation for displays [20:10:16] but I hope I am wrong and it is about LOI-2, DOI and LOPC [20:10:41] well, in any case it should be the display that would also be used for those manuever types [20:11:13] heres hoping [20:11:29] there will also be [20:11:30] RTCC Requirements for Apollo 14: Trajectory computers for TLI and MCC processors [20:11:46] we have the 1968 version of that [20:11:55] and the top-level documents for Apollo 14 [20:12:12] so that might help with better non-free trajectory TLMCCs etc. [20:12:20] right [20:12:32] then [20:12:34] Operational LM Abort and Rescue Plan for Apollo 14 (Mission H-3) [20:13:03] we have Apollo 13 but the ones for 15-17 were quite short or incomplete [20:13:13] from UHCL [20:13:37] also: Skylab launch window processor [20:13:57] and the one that is already done is: Logic for the Earth Orbital AEG in the Apollo Real-Time Rendezvous Support Program [20:14:28] AEG is the analytical method to calculate trajectories for rendezvous processors [20:14:59] numerical integration was too slow and doesn't calculate some useful orbital parameters [20:15:34] sounds all great [20:15:35] so lots of good stuff, hopefully! [20:15:42] yeah [20:15:48] I have to run, cya! [20:15:51] cya! [20:21:17] https://github.com/virtualagc/virtualagc/commit/e2babef92a2f3b0c4d5ec38c1ff484caf7f28283 [20:21:32] the alternative to our theory is that Ron is just not working on the documents at all and instead is just doing LVDC things :P [20:22:05] yeah, that crossed my mind earlier today, haha [20:23:21] not that I wouldn't like a working LVDC assembler [20:27:22] yeah [20:27:23] hmm [20:27:30] and it's been 2 weeks since I've heard anything from Purdue [20:27:35] I wonder how long that's going to take [20:28:17] It probably costs $1.55 to accelerate the process [20:29:02] haha if it did I would gladly pay that [20:32:22] night! [16:07:12] morning! [16:11:11] hey Mike [16:11:50] what's up? [16:12:02] my documents are great [16:12:05] how are yours? :D [16:13:22] you definitely won out this time [16:13:43] Ron sent me this last night: [16:13:44] and the documents are smaller than expected [16:13:47] When I said I got everything that you asked for, I meant just the Luminary 1C flowcharts, not the Comanche flowcharts. [16:13:48] The good news is the Luminary 1C flowcharts are online at archive.org.  The bad news is that we got them from Don Eyles 2 1/2 years ago, so I have not uploaded any of the newly-made scans of it: [16:13:55] and then he sent me links to the 1D flowcharts [16:14:05] turned out he spent 5 hours rescanning the 1D flowcharts we already had [16:14:17] ouch [16:15:07] and the GSOP is not the final section but just preliminary changes... which still might be helpful, but not as much as I was hoping [16:15:39] right, I saw those [16:16:18] still useful though [16:16:26] yeah [16:16:55] none of the documents I requested was disappointing, so definitely a win [16:16:56] so next time he goes he's going to scan just the excerpts of the 1C flowcharts that I need before going back to aperture cards [16:17:04] makes sense [16:17:11] just the ~60 pages of lunar landing stuff [16:20:37] hey [16:20:57] hello [16:21:14] hows Apollo 15 going? [16:21:25] funny you should ask [16:21:36] right now I'm at the LM activation - P52 align [16:21:50] hey guys [16:21:51] I'm getting a 404 error (not that kind) [16:22:07] hey Niklas [16:22:25] Defined Star not in any AOT detent [16:22:31] MrFickles, weird [16:22:43] I'm using 343, right-front detent star 43 [16:22:54] definitely visible on the AOT [16:23:14] is it close to the sun? [16:23:21] or the horizon? [16:23:35] no, sun is directly behind the stack right now [16:24:08] I definitely had it before that the LGC complained about a star even though I thought it would be good [16:24:19] and the star is probably 30-40 deg above the horizon [16:24:52] crew action for that 404 alarm: [16:24:56] indy91 did you manage to solve it? [16:24:59] PRO to specify new star [16:25:09] V32E to let LGC choose new star [16:25:34] sometimes I just recycled it and then it worked. In my case it probably was too close to the horizon or so [16:25:39] or chose a different star [16:26:08] ok, I'll try 137. That's the other star defined in the checklist [16:26:27] AlexB_88, the new RTCC documents have arrived [16:26:31] they are all as good as I hoped [16:26:40] :D :D [16:26:56] any links? [16:27:01] https://archive.org/details/virtualagcproject?sort=-publicdate [16:28:25] ok 137 is a no go [16:28:32] hmm [16:28:33] front left is looking down at the moon [16:28:43] probably a timing thing [16:28:51] star will be or was available [16:29:36] tried 240, and I get a F 52 71 [16:29:41] 00240 [16:29:42] 00000 [16:29:44] 00000 [16:30:19] is it asking me to load in the cursor spiral angles? [16:30:46] I think so [16:31:02] P52/P57 is quite different in Luminary 1E than on previous missions [16:31:13] also tricky to learn the right version again :D [16:31:16] always* [16:32:24] ok so on the AGC document I have, it says to position the cursor and mark x or y [16:32:27] is that even supported right now? [16:32:43] sorry, it's mark X or ROD switch pushed [16:32:53] yes [16:33:19] what part of that wouldn't be supported? [16:33:36] there are keyboard commands you can use for all the buttons [16:33:37] indy91, so I guess all these docs is enough to implement the LM descent planning table, earth centered RTE? [16:33:39] AGC getting curor angles? [16:33:57] I don't remember that being a thing on Apollo 11 [16:34:04] AGC getting cursor angles via the interface called astronaut [16:34:11] you have to read them and input them [16:34:47] would be nice if the AGC could read them [16:34:53] probably would make things more precise [16:35:11] ah [16:35:17] I guess you are confused why you have to mark [16:35:36] I think that is to tell the LGC the exact time when the angle was valid [16:35:49] but that's all it does [16:36:50] I only really know about P57 for that [16:37:19] if you would e.g. read one of the angles, then wait for a minute or so and only input the angle then on the DSKY [16:37:31] then the Moon rotation during that time would already be significant [16:37:50] so pressing mark gives it the time [16:38:01] and that should be done just after reading the angle [16:38:19] AlexB_88, I hope so, yes [16:38:45] and in the TLMCC trajectory computers document there finally is some stuff to get the LOI/DOI geometry right on the later missions [16:39:00] nice [16:39:42] descent planning definitely will get implemented first [16:39:45] I guess it has some stuff to optimize the TLC transfer time [16:39:49] F21 79 [16:39:54] I put in my cursor code [16:40:04] and it goes straight to 06 79 [16:40:29] yeah, I think that is normal [16:40:37] did the mark counter increment? [16:40:54] brings me back to 52 71 [16:41:05] did N79 show all zeroes? [16:41:13] R2 changed to 10001 [16:41:20] yeah [16:41:28] for me the G&N Dictionary was quite helpful [16:41:30] so next mark is cursor again? [16:41:38] to learn the Luminary 1E P52 and P57 [16:41:40] https://readux.ecds.emory.edu/books/readux:snv7n/pages/readux:snwnd/ [16:42:05] alternating cursor and spirals [16:42:11] 5 marks total [16:42:15] I think... [16:42:25] it's a weird interface [16:42:25] I'm using this [16:42:26] https://www.hq.nasa.gov/alsj/a15/a15Delco.html [16:43:12] on the F 52 71 [16:43:19] press ENTR [16:43:30] that changes it to F 53 71 [16:43:44] for spirale data [16:43:54] oh *hit [16:44:09] I input the spiral on 52 71 [16:44:16] gotta restart I guess [16:45:20] well, on the N71 you shouldn't input anything [16:45:23] you press mark [16:45:58] ok I get it now [16:46:09] I'm not sure I do, haha [16:46:14] so R2 and 3 is either 0000X or 1000X [16:46:18] yeah [16:46:24] depending on what's being input [16:46:30] right [16:46:35] ENTR switches cursor and spiral [16:46:38] and X is the number of cursor and spirale marks [16:46:39] yep [16:46:47] yeah awesome [16:47:02] how do I continue though [16:47:07] PRO on 52 71? [16:47:38] after you have the 5 marks, yeah [16:48:06] https://readux.ecds.emory.edu/books/readux:snv7n/pages/readux:snwrt/ [16:48:12] the box at the top is helpful there [16:48:23] 10A to 10C [16:48:55] 50 25 [16:49:00] 00016 [16:49:04] 00002 [16:50:11] unused mark sets [16:50:41] R2 contains number [16:50:47] of unused marks sets I guess [16:50:57] it wants 5 marks, you did 5, so it has a 2 in R2 [16:51:02] you did 3* [16:51:20] I did 2 [16:51:24] haha [16:51:35] figured because I would just be inputting 5 exact same values [16:51:36] well I guess you have to start P52 again anyway [16:52:05] the P52 with spirale definitely confused me as well the first time [16:53:09] this is exactly why astronauts train before going up and solving things on the fly [16:53:23] AlexB_88, turns out the lunar descent planning processor always had the ability to calculate a CSM DOI [16:53:35] that's why there isn't an update to this early 1968 document [16:53:39] it never needed one [16:53:57] the required mode is [16:54:12] "compute CSM maneuver to establish an apsis and an input altitude at the DOI maneuver point" [16:54:55] hmm [16:55:11] well maybe it is that [16:55:31] or the normal DOI logic works different than I thought [16:55:40] in which case both DOI types would calculate the same way [16:58:58] well, I will see when I start implementing it [16:59:46] intesresting, Ron's thinking about refocusing his aperture card scanning [17:00:08] he's getting more ambitious, and wants to try to get all of the Block II CSM drawings as well [17:00:15] which are more time sensitive [17:00:39] sounds ambitious [17:01:13] indy91 you were right, you absolutely need 5 marks [17:01:50] now, on the 2nd star the procedure looks completely different [17:03:33] scratch that, the dictionary is spot on so far I'll just use that and not disturb you guys [17:04:11] haha, no problem [17:11:13] after terminating marks on the first star, the 01 70 immediately after is asking for my first star code or 2nd star code [17:11:46] I assume it's the 2nd [17:18:43] 2nd [17:19:09] PRO to terminate marks on the F 52/3 71 [17:19:17] after 1st star that goes to 7A in the checklist [17:19:33] that's the beginning of each marking sequence I think [17:19:43] the F 01 70 [17:49:13] all good now [17:49:32] I realised they did a docked P52 instead of a V42 [17:50:46] any idea what I should use for the sep maneuver? [17:50:55] I assume it'll be a radial only burn [17:52:54] yes [17:53:45] 1 ft/s [17:54:22] -1 on the DVZ huh [17:54:46] that is to trick P30 [17:55:09] you use -1 in P30 [17:55:20] and are then burning with the -X thrusters [17:55:32] so in P40 you will end up with 2 ft/s "residuals" instead of 0 [17:55:38] ok [17:55:39] P41* [17:55:59] I haven't figured out the definitive way to calculate the time for the sep yet [17:56:11] but as you are close to the flight plan timing the flight plan time will be good enough [17:56:47] yeah, RTCC MFD is giving me exactly the undock attitude [17:56:53] so I guess it's correct [17:57:01] yeah, that is always a good sign [18:10:42] so do I undock and immediately thrust -X? [18:12:55] I think so [18:13:08] earlier missions had separate undocking and sep maneuver [18:13:37] yeah I think so too [18:13:43] it's listed as 1 maneuver [18:13:54] btw, on the LM V48 [18:14:04] is R1 or R2 LM weight [18:16:28] R1 [18:17:13] yeah I got my answer [18:17:21] I forgot you could just check the noun table [18:23:18] oh man... looking at some of these Luminary memos, I have a *lot* of erasable problems in my current Luminary 1D [18:24:09] which probably explains why I still have so many banks with close to, but not quite the right checksum [18:25:31] unfortunate [18:26:01] no, this is good [18:26:17] it would be unfortunate if I couldn't find any problems but still had all of the banks wrong :D [18:26:57] I think it's probably going to be better to start with the Luminary 131 erasable assignments and work my way up, rather than trying to work backwards from Luminary 210 or Zerlina [18:26:59] haha [18:27:12] the erasable changes in revisions 179 through 181 were pretty extreme [18:27:21] yeah [18:27:34] in my padload experience Luminary 1E was its whole different beast [18:27:41] everything different from before [18:28:05] big reorganization [18:28:19] even got rid of the useless Y component of the descent targets [18:31:59] probably a big part of why Don said "I'm sorry this updated ZERLINA took so long to appear. 'No-change' changes in LUMINARY, with which most of ZERLINA is common, had a delaying impact." in his memo on Zerlina 56 [18:32:07] he probably fought with a lot of this same stuff too [18:32:42] yeah [18:33:09] branching from and merging to AGC code must have been a real nightmare [18:33:15] yeah definitely [18:33:22] without modern version control systems [18:37:39] alright gents, Falcon is away and so am I until tomorrow [18:37:46] have a good weekend [18:38:04] cya! [20:47:28] https://www.ebay.com/itm/1968-NASA-Apollo-11-Mission-MANUAL-Logic-amp-Equations-About-the-Moon-68-FM-12-/362705969726?nma=true&si=aF07ziYgbSIUy7dzbRpibhwaH04%253D&orig_cvip=true&nordt=true&rt=nc&_trksid=p2047675.l2557 [20:47:49] sometimes I can get new MSC memos this way :D [20:47:54] or at least some pictures of it [20:55:59] night! [10:23:06] PDI in progress [10:24:33] haha, nice [10:24:39] try to not hit Mons Hadley Delta :D [10:24:59] clear of the hills [10:25:16] 1:45 left in braking [10:26:28] oh shi* [10:26:41] the LM kind of crashed into the ground [10:26:52] oh oh [10:27:32] was the LR not doing its job? [10:27:32] I suspect the N69 I put in was dodgy [10:27:42] yeah you don't really need a N69 [10:28:04] what did you enter there? [10:28:08] just something in N69? [10:28:10] uhh [10:28:12] R1 I mean [10:28:15] I tried to put in some crossrange in N69 [10:28:20] oh cross range [10:28:21] V24 N69 [10:28:26] -01500 [10:28:30] +00500 [10:28:57] doesn't look that significant [10:29:12] was it still in P63 when you crashed? [10:29:20] yeah [10:29:25] DH was converged? [10:29:28] about 30sec in braking [10:29:32] DH converged [10:29:41] could it have been the hills before? [10:29:57] TM was pretty erratic [10:30:02] well the computer has a terrain model loaded [10:30:27] oh well, reset and try again [10:30:32] but if anything is off by a significant amount, alignment or clock or so, then it could cause problems [10:31:04] don't think so [10:31:17] P52 before was all balls in the alignment [10:31:26] but you were clear of that tall mountain before the landing site? [10:31:43] and about halfway between the mountains and the rille? [10:31:49] yeah I was clear, I crashed maybe a few km short [10:32:25] strange [10:32:31] I'll try a N69 without a crossrange this time [10:32:36] the N69 numbers aren't large enough really to cause this [10:33:07] if it still doesn't work I can take a look at the scenario to see what is up [10:33:43] I'll be frank, I've already landed successfully the first run through [10:33:53] I'm just refining the N69s at this point [10:34:07] oh [10:34:09] interesting [10:34:09] first time I landed with no N69 input [10:34:58] if you accidentially enter 15000 ft instead of 1500 ft downrange then the terrain model could do bad things [10:35:03] but 1500 and 500 feet... [10:35:08] hard to believe [10:35:29] there must be some other issue and you got lucky that it didn't cause a crash before... maybe [10:35:48] we'll see how things go this time round [11:31:27] quite consistent now [11:31:36] the landings are looking good [11:50:08] good [14:05:09] Hi all [14:05:26] is Indy up ana [14:05:34] and up [16:09:27] hey [16:11:31] hey Alex [16:11:59] making good progress with the MPT stuff, I'd say I'm implementing the last few minor features and doing fixes [16:13:55] great, looking forward [16:14:34] one problem I have is that it's difficult to debug the direct input maneuvers [16:14:48] they don't generate the isual TIG and DV for a Maneuver PAD [16:14:50] usual* [16:15:42] LM ejection would be defined as: 3 seconds burn with 4 -X RCS thrusters in specified IMU attitude [16:15:56] so I'm probably going to implement the detailed maneuver table as well [16:16:02] the Maneuver PAD for the FIDO basically [16:16:19] so that will delay things a bit, but it will be good for debugging [16:16:40] and then I need to do lots and lots of testing [16:16:55] and then I can release it :D [16:17:05] and then you can find the 100 remaining bugs [16:18:48] haha sounds good [16:19:02] I'm probably not going to add saving/loading for the maneuver data [16:19:13] just for the MPT "header", which includes [16:19:17] initial config and masses [16:19:21] initial state vector [16:20:56] and vehicles associated with both tables [16:21:03] so you don't have to initialize that again [16:21:23] just have to press a few buttons to get SV and masses up to date before doing some major planning [16:22:51] PDI and TLI buttons are on the MPT page now [16:23:01] those maneuvers don't additional inputs [16:23:05] don't need* [16:23:16] so you can just press the button and it adds them [16:23:29] better than having the TLI to MPT function on the TLI PAD page... [16:26:34] yeah [16:27:51] oh, and I decided to do the short rendezvous profile liftoff time calculation next [16:27:55] that is a pretty short project [16:28:03] the lunar descent planning processor is a bit bigger [16:28:40] in terms of constraints the current short profile calculation is already correct actually [16:28:52] fixed time from insertion to TPI [16:29:04] morning! [16:29:05] fixed radial insertion velocity [16:29:06] hey [16:30:02] indy91, this guy put a bunch of MPAD memos up on ebay last night: https://www.ebay.com/sch/wjcu/m.html?_nkw=&_armrs=1&_ipg=&_from= [16:30:24] oh, probably the same guy as the one memo I found [16:30:53] I'll save all the pictures I can then [16:30:56] I've posted my PDI scenario on Orbiter forums if anyone's interested [16:30:57] https://www.orbiter-forum.com/showthread.php?t=40999 [16:32:37] nice! [16:32:40] haha, very precise N69 numbers [16:32:49] how was the landing? [16:32:50] you know you could use the LPD, right? :P [16:33:19] yeah, you still do [16:34:11] what I do to get bang on to the landing site is P22 with the CSM on the landings site prior to PDI, then uplink as an RLS update to the LM [16:34:12] but at least it puts you in the ballpark at high gate [16:34:59] otherwise P63 will take you south of the double crater [16:35:21] oh yeah, Apollo 15 probably had the largest preflight landing site radius error of all missions [16:35:39] the default RLS in the LGC is the real RLS that was used on Apollo 15 and its actually not that accurate, the real mission updated it with P22s I believe [16:36:10] sure did [16:36:41] the real RLS that was loaded in the AGC before the mission [16:37:03] yes [16:38:07] honestly I think it's not that much of a N69, only about 2000ft? [16:38:39] Mostly it's because I hate correcting for crossrange in P64 [16:38:51] I do not like being at anything other than 0 yaw [16:39:01] yeah, same with me [16:39:26] glad it's not just me [16:41:21] you really have to do it immediately at the start of P64 [16:42:14] yeah, but if you do it at P64, it'll take you out of 0 yaw [16:42:18] which I loathe [16:42:33] that's why I'm using N69 to correct for the crossrange [16:42:50] I think in reality N69 was used to correct for weird lunar gravity (mascons) causing the state vector to slowly become inaccurate. Orbiter doesnt simulate that though, so getting a good RLS should be all thats needed [16:44:29] I think that's probably the reason for it [16:45:19] That's why I mentioned that N69 isn't really necessary. Even if you don't use it, you'll still land in the general vicinity [16:45:34] right [16:46:15] there is still a little bit of gravity mismatch between Orbiter and the AGC [16:46:41] during the descent the AGC only uses spherical gravity calculation [16:46:41] honestly, the difference is small enough that you can still land in the "right" spot using P64 LPD corrections [16:47:00] Orbiter simulates at least the gravity as a function of latitude [16:47:21] I think that doesn't cause more than 50 meters of crossrange error though [16:47:28] very small number [16:48:39] gotta run now guys, talk to you guys another time [16:48:55] and I'm pretty sure they used a slightly biased latitude to get the landing right [16:53:01] yeah [17:05:58] so I spent a lot of time digging through luminary memos extracting erasable addresses last night [17:06:05] and what I have is not even close :D [17:06:17] restarting from Luminary 131 is deifnitely going to be the way to go here [17:07:37] restarting sounds like a lot of work [17:08:24] only on erasables [17:08:29] I didn't do too much to them [18:07:49] I'm pretty sure I'm mostly there on fixed memory [18:15:48] great [19:36:44] wow [19:36:59] just dropping it in and deleting stuff that was moved to fixed made things angry though [19:37:04] 269 fatal errors from assembly :D [19:37:09] let's see, what's missing... [19:41:28] well Luminary 131 might be closer, but not super close :D [19:44:18] let's see [19:44:19] yeah [19:44:32] I've fixed some things [19:44:46] but I have 53 erasables that aren't defined that need to be [19:45:33] some of these are almost certainly from the "no-change" deletions of erasable definitions from various log sections [19:46:06] case in point, the first one on the list is 1/DV0, which was defined in ASCENT GUIDANCE in Luminary 131 [19:47:22] that happened in Luminary 179, so this is a good way to identify everything that moved and put it back anyways :) [19:58:02] cya! [19:59:20] hmmm [19:59:27] did Luminary 178 have ABRFGX? [19:59:34] or was that only introduced in 1E? [20:00:16] before it was vectors [20:00:31] that's what I meant with deleting the y-component the other day [20:00:51] pre 1E it had a vector e.g. ABRFG [20:01:01] but the y-component was always 0 [20:01:02] ohhhhh okay [20:01:09] so they made it ABRFGX and ABRFGZ [20:01:31] so in this case it's my fixed memory that's wrong [20:01:36] and I need to change it back to use the vectors [20:02:00] I'm pretty sure that would be part of the initial changes while they worked on 1E [20:02:18] ah [20:02:23] we have padload [20:02:48] written in vector format there [20:04:24] yeah :D [20:04:29] okay this was definitely a good idea [20:19:49] good night! [20:31:58] okay, only 33 of those are really new [21:25:21] hey [21:30:37] yo [21:31:14] What's up? [21:31:27] working through Luminary 1D erasables [21:31:33] you? [21:33:17] Trying to get my Pi Zero running again [21:33:36] Need to do some ICSP on an Atmega 8 [22:48:11] huh [22:48:26] I think the addresses in this Luminary 178 simulation printout might be wrong [22:48:32] or at least, one of them is [22:50:17] otherwise I have no explanation how VBRFG* and ABRFG* would be four addresses apart [22:53:33] I'm just going to have to wait for the full padload to sort that out [23:05:26] ...yeah, too many inconsistencies between the partial padload I took pictures of and the simulation printout [23:05:36] or at least, implied inconsistencies [16:27:50] hey [16:34:26] hey Alex [16:35:10] I'm not going to add the detailed maneuver table right now, so I'm pretty much doing final fixes, adjustments and tests for the MPT update [16:36:12] and I definitely have to do at least a bit of explaning before I'll release it, maybe as an update to the manual or as a forum post [16:42:46] nice, yeah we can definitely use a bit of a tutorial for the new changes [16:42:56] I think I'll do a quick walkthrough with pictures as a forum post [16:43:03] great [16:43:03] like I did with the Shuttle FDO MFD [16:43:37] I'll do TLI, ejection, evasive, direct return abort as an example I think [16:45:33] it's still all in a bit of a halfway state, but I can't possibly do all changes I want to make at once [16:47:35] how about this [16:47:45] I'll push my branch and you can test it now already [16:47:48] if you want [16:48:21] sure [16:49:11] https://github.com/indy91/NASSP/tree/RTCCWork [16:49:53] back in a bit [16:51:33] Ill give it a try, thanks [16:57:11] morning! [16:59:28] hey Mike [16:59:32] what's up? [17:01:48] Niklas just pushed his RTCC MFD changes, going to give it a go [17:01:55] oh man, nice :D [17:02:09] feature creep finally slowed down enough eh? [17:02:19] I hope im not too lost with all the new features :D [17:02:30] yeah [17:03:49] well what I meant by "pushed his RTCC MFD changes" is push to a separate branch [17:04:33] hey Mike [17:04:38] hey [17:05:01] "otherwise I have no explanation how VBRFG* and ABRFG* would be four addresses apart" that sounds like Luminary 1E [17:05:13] does it? [17:05:40] E5,1432 VBRFG* [17:05:44] E5,1436 ABRFG* [17:05:56] oh crap, you're right [17:06:09] there's an extra VAPFG* in there [17:06:13] does Luminary 1D have that? [17:06:23] what do you mean extra [17:06:40] or "new' [17:06:45] no [17:06:47] not new [17:06:58] ABRFG (the vector) and ABRFG* (single value) were always there [17:07:13] right... [17:07:18] in 1E it is just ABRFGX and ABRFGZ, formerly of ABRFG the vector [17:07:30] yes but [17:07:40] and sorted differently in 1E, haha [17:08:11] ah that would do it [17:08:19] I guess you can introduce a simple offset of 2 to switch from braking to approach phase [17:08:23] VBRFG* and ABRFG* are next to each other in earlier versions [17:08:36] in Luminary 1E VAPFG* is between them [17:08:46] yeah [17:08:49] always B, A, B, A [17:08:54] braking phase, approach phase [17:08:59] right [17:09:09] so, did that change for 1D then? [17:09:27] I'm pretty sure that it would be either 100% like in 1C or 100% like in 1E [17:09:32] haha [17:09:34] and I tend to exactly like in 1C [17:09:38] yeah [17:09:40] me too [17:09:51] because changing that part at all would be sketchy [17:10:02] so it is part of the big update [17:10:10] which happened right after 1D [17:10:12] I got that from the simulation printout and it's not exactly trustworthy [17:10:33] particularly in that area [17:10:51] https://photos.app.goo.gl/YDA5ZP1qtdCL23SW7 [17:11:11] VBRFG* and ABRFG* are printed at the bottom of that, with the addresses 2432 and 2436, respectively [17:11:26] but they come after a whole bunch of "FIELD BAD" errors for the other parameters [17:11:49] so, who knows what was going on here [17:15:03] yeah, that is strange [17:15:22] not even a consistent offset would work there, as GAINBRAK is even further down [17:15:42] hopefully we'll find out in the next few days -- Don's going to scan the preliminary padload [17:16:08] I think I need to go through and remove all of the addresses I got from the simulation printout because I don't trust it now [17:16:56] REFSMMAT address already like in 1E [17:17:11] which would very well be for 1D [17:17:14] could* [17:17:36] AlexB_88, tell me if I should give you a little introduction to the changes [17:18:14] sounds good, I am just building the modules now [17:18:55] step 1 activate planning mode on MPT page, then press the button below that to go to the MPT init page [17:25:02] I am having issues pulling from your git repo [17:25:11] git remote add origin https://github.com/indy91/NASSP.git [17:25:16] is that the right command [17:25:30] it gives a fatal: remote origin already exists. [17:25:40] yeah [17:25:46] origin is dseagrav/NASSP [17:25:51] or your own repo [17:25:54] right [17:25:56] I called it indy91 [17:26:09] git remote add indy91 https://github.com/indy91/NASSP.git [17:26:12] ah ok [17:26:19] but did you not already add that in the past? [17:26:34] ill try pulling from indy91 [17:26:50] sure [17:28:07] I didnt have it so I created it [17:28:21] ok building modules now [17:54:03] so in the init page, I push the AUT button? [17:56:49] first you choose which of the two tables you want to initalize [17:56:53] CSM or LEM [17:57:09] on the MPT display are the maneuvers from both [17:57:25] then the second button is the vessel in Orbiter associated with the MPT [17:57:36] so e.g. CSM and Columbia [17:57:56] and yes, then you press the AUT button [17:58:06] automatically updates all weights and the current config [17:58:16] then you could change the config and weights manually [17:58:23] although I haven't added that yet for the weights [17:58:34] and then you press the 3 buttons on the right [17:58:41] so do you have to init them for bothe vehicles? [17:59:01] only if you need separate trajectories [17:59:10] you wouldn't need it for pre TLI and LOI planning [17:59:16] but you would before descent planning [17:59:21] right [17:59:39] so does AUT update the weights and trajectory? [17:59:53] no, it just loads the weights and the config on the page [18:00:02] ok [18:00:17] and then M55, that's an MED (manual entry device code) [18:00:30] that actually transfers the config code to the MPT [18:00:40] same with the M50 button, that is the weights [18:00:46] and then TUP is Trajectory UPdate [18:01:05] then the MPT is fully initialized [18:01:51] so do the M50 and M55 buttons have to be pressed always, or just TUP? [18:02:21] only if you want to update the configuration and weights [18:02:36] okok [18:02:40] you might want to at least update weights and trajectory before using the MPT [18:02:48] the numbers on that page, or rather in the MPT, get saved in the scenario [18:03:01] so an update would be as simple as choosing CSM or LM [18:03:11] and in most cases then just press AUT, M55, M50 and TUP [18:03:44] M55 probably not every time [18:04:26] so when the MPOT is fully initialized, do you have to go back to the init page every time you change vehicles or will the MPT detect what vehicle your using when adding a maneuver to the MPT? [18:04:32] MPT* [18:05:14] so, right now only the direct input maneuvers have a selection for CSM and LM [18:05:31] all other calculation pages will use the MPT of the vehicle you are using the MFD in [18:05:42] ah ok makes sense [18:05:45] but it can be initialized in any vehicle [18:06:03] in the future you will be able to add maneuvers from anywhere [18:06:11] so you really only go to the init page when you 1st initialise it, then too update masses/trajectory [18:06:17] yep [18:06:30] oh, and does the init page get saved? [18:06:50] the page not, but the same data in the MPT [18:07:12] the page is just choosen data, the 3 buttons on the right transfer it to the MPT [18:07:22] and that is saved [18:07:30] like the vessel associated with the MPT [18:07:34] that will rarely get changed [18:07:42] once the LM is created you can choose LM = Eagle [18:08:03] and it does save the weights and the config and the initial state vector [18:08:20] to check that you can use the checkout monitor, new MCC display [18:11:27] and the PDI button, does that do a PDI simulation? [18:11:34] that puts a PDI on the MPT [18:11:43] right [18:11:47] needs a LS REFSMMAT in the RTCC MFD [18:11:49] or else it fails [18:11:53] ok [18:12:02] does it need a TLAND? [18:12:18] yeah, it uses the TLAND and RLS etc. from the data in the RTCC MFD [18:12:31] there probably will be a page for it at some point [18:12:35] with some more output data [18:13:11] PDI basically needs the LS REFSMMAT and of course the right trajectory, so a DOI before it [18:13:54] I've used pre LM activation as a test case [18:14:11] direct input maneuvers can be place on either MPT already [18:14:20] so that means you can do all the planning in the LM [18:14:29] as you can add the CSM sep maneuver there as well [18:14:52] in that case I changed the initial LM MPT config from CSM+LM to LM [18:15:02] as the first LM maneuver happens after undocking [18:17:26] can the SV uplink page pull a SV from the MPT yet? [18:17:54] indy91, you'll like this -- the archivist who sent me the AS-500 book followed up to make sure I could download it an read it okay, and then replied again with a thanks when I said yes [18:18:06] the email subject line is now this: [18:18:09] RE: [External - Subject Filtered] Re: [External - Subject Filtered] Re: [External - Subject Filtered] Re: Apollo Document Scan Request 8% 8% 8% [18:20:15] AlexB_88, didn't test that in a bit, but I think so [18:20:21] thewonderidiot, haha [18:20:28] they eventually send it to me as well [18:20:48] sent* [18:22:14] yeah, pretty sure that should work, Alex [18:32:04] it really doesn't help that they referred to Sundance as "DANCE" frequently, and that is part of the word "guidance", which makes it very difficult to search for [18:32:12] haha [18:32:20] AlexB_88, nice [18:33:52] what is P16 for? [18:34:09] haha, P16 was a term that confused me a lot at first in the FIDO loop [18:34:17] they used it quite a bit [18:34:26] obivously it doesn't mean an AGC program [18:34:31] it's another MED code [18:34:45] and it stands for copying the ephemeris of one vehicle to the other [18:35:01] so you could have a maneuver on the MPT for the CSM [18:35:18] and use the burnout vector from that as the initial SV for the LM MPT [18:35:54] I added that with the basically same format as you would really enter it in the RTCC [18:36:41] as a test mainly [18:36:50] so e.g. [18:37:12] 2;1;0;1 [18:37:22] means copy CSM (2) SV to LM (1) [18:37:33] GET set to 0, so it doesn't use a GET [18:37:52] and last digit is 1, burnout vector of CSM maneuver one [18:37:57] hmm [18:38:08] entering GET there won't work right now [18:38:23] need to change that a bit [18:41:20] one thing I have only added partially so far is maneuver confirmation [18:42:01] so instead of having to start from scratch again after a maneuver they could delete the first maneuver in the table and the initial SV and weights get updated with the postburn data [18:52:38] AlexB_88, have you tried the checkout monitor yet? [19:01:27] I have looked at it briefly [19:01:37] lots of numbers :D [19:02:06] Ill be honest, I will need a bit of a rundown on that one lol [19:05:02] sure [19:05:11] well it displays lots of useful numbers with the right inputs :D [19:05:26] 4 main options right now [19:05:31] GMT, GET, MVI, MVE [19:05:39] MVI and E are maneuver initiation and end [19:05:59] so it will display the orbital parameters and weights at any point in the current mission plan [19:06:36] 1st button is to choose CSM or LEM MPT [19:06:42] 2nd button is the option [19:06:54] 3rd button the parameter associated with the option [19:06:58] so either a time or a maneuver ID [19:07:15] 4th button is threshold time, only used for options currently not implemented yet [19:07:30] 5th button is the coordinate system displayed [19:07:39] ECI, Earth centererd inertial [19:07:55] ECT is true, so equatorial coordinates instead of ecliptic [19:08:00] MCI and MCT are the same [19:08:17] anf the FT button is to switch between two display variants for the state vector [19:08:22] either feet and feet/second [19:08:29] or Earth radius unit and ER/hour [19:09:14] to check if the MPT is initialized right you can have e.g. 0 maneuvers in the MPT [19:09:19] and just look at some GET in the future [19:09:27] and then you can check the masses on the right [19:10:19] http://wayback.archive-it.org/all/20100525000249/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19730062603_1973062603.pdf [19:10:45] PDF page 774 and later [19:11:02] or maybe 773 [19:25:36] cya! [19:35:00] gotta run! [20:16:10] whoa [20:17:28] .tell indy91 Don just sent me the padloads. it has ABRFGX and ABRFGZ, instead of ABRFG. they must have done that for Luminary 1D [20:33:03] .tell indy91 so the simulation printout is correct with VBRFG* and ABRFG* [20:37:35] .tell indy91 ah, done as part of PCR 1021, implementation of the terrain model, in Luminary 152 through 154 [15:48:41] morning [15:49:23] hey Alex [15:50:26] Space Digitals display is now fully integrated with the MPT [15:50:36] nice [15:50:38] so where do you think the update is currently still lacking? [15:52:05] I havent had a lot of time to test it, but it looked pretty good already [15:53:26] good to know [15:58:39] I like that its compatible with the ascent processor, state vector page [15:59:39] so I guess its now possible to figure out things like T2 times and LM post insertion SV for the CSM, but before the LM as started ascent [16:00:08] yes [16:04:26] I think I'll just merge the branch then [16:04:50] there is stuff still missing, but I'm not planning to stop working on the MPT [16:05:21] I'd rather expose it people finding issues with it [16:05:25] it to* [16:08:59] right [16:09:18] is there anything in particular to test? Certain maneuvers? [16:10:33] At this point I'm mostly looking for usability improvements I think [16:10:40] I've tested many different scenarios with the MPT [16:25:21] so is its still required to set the TYP box in the main config page of RTCC MFD? (not MPT config) [16:26:31] yeah, unfortunately [16:26:34] that will go away with time [16:26:41] but for every non-MPT it is still needed [16:28:43] eventually every maneuver will go through the MPT [16:29:11] they could only display the detailed maneuver table for maneuvers in the MPT, for the most part [16:29:20] so nearly ever maneuver that was done was added there [16:29:32] right [16:29:50] I think that that would be good, to only have the MPT [16:29:57] only one place to set things [16:32:13] what is the detailed maneuver table again, exactly? Is it similar to the MPT? [16:32:58] it's basically the Maneuver PAD for the FIDO [16:33:13] it has specifics about each maneuver [16:33:25] most of the number that get written on the PAD will come from here [16:34:09] GUIDANCE will create some other numbers like e.g. sextant check star [16:34:50] enough numbers are actually saved in the MPT to display the DMT for any maneuver at all times [16:34:56] so you can switch back and forth [16:35:16] right now only the most recently calculated maneuver in the MFD can be used for the Maneuver PADs [16:39:07] although, it's nearly at the point where you would be able to switch back and forth [16:39:24] not much needed for that [16:41:59] one thing that is still inconsistent on the MPT page is GETBI and DT [16:42:16] the DT is between the end of the last and the beginning of the next maneuver [16:42:32] so the GETBI plus the DT is not equal to the next GETBI [16:42:47] I have two sources for the MPT display, and this is a mix of them. That is the result :D [16:45:58] morning! [16:48:49] hey Mike [16:48:59] hey, what's up? [16:49:04] so they did part of the erasable changes already in 1D [16:49:17] yeah [16:49:53] not too many, but several bits of it [16:50:12] https://drive.google.com/open?id=1AfOVclNBZDqPbjcmz58SFI8QbAPlKIIS [16:50:58] and I learned how to read downlists last night, thanks to a very good description by Norton [16:51:16] and discovered that if all else fails, he puts the full downlists in his programmed guidance equations documents too [16:51:25] so I'll get them when I go to scan that [16:51:29] if I fail to reconstruct them [16:51:47] but now that I understand how to read them and have looked at the changes I'm pretty sure the memos are enough to reconstruct them [16:52:43] https://pastebin.com/TYfxqLRs [16:52:49] that's where I am on bugger words [16:52:58] there are so many banks that are very close [16:53:46] late October [16:53:51] that is decently close [16:53:59] and for the final LGC revision [16:54:06] yeah [16:54:09] good to have that [16:54:23] I definitely had some addresses in the erasables wrong :D [16:54:23] I'll just compare the engineering values to the final ones and can use that as the basis of a worksheet [16:54:38] after 1D is reconstructed [16:58:06] I'm curious how many differences there are between this one and the final one [16:59:09] AlexB_88, pushed MPT update and wrote a short walkthrough of it in the forum [16:59:25] might help you as well with the direct input maneuvers [16:59:32] which I hadn't fully explained to you yet [17:01:27] I am free! [17:01:45] well, the update is only so far done as it needed to so that everything still worked [17:05:49] but I need a break from it, haha [17:07:33] hehehe [17:07:41] what's next then? [17:07:52] https://archive.org/details/70fm44images [17:07:58] aha :D [17:08:02] that's pretty short [17:08:07] and then the long awaited [17:08:23] https://archive.org/details/68fm23images [17:08:42] excellent [17:08:51] that's the one you were getting worried was only going to be for displays right? [17:09:49] yep [17:09:56] but it's the whole program flow [17:10:00] for all types of DOI [17:10:02] excellent :D [17:10:02] LOI-2 [17:10:06] lunar orbit plane changes [17:10:07] and more [17:10:30] the requirement for this processor was to get the LM in position for PDI, from any kind of dispersed lunar orbit you can think of [17:10:43] that's why it has a bunch of maneuver types just to get back to nominal [17:11:27] LOI-2/DOI with plane change, double Hohmann transfer to get back to 60NM circular [17:11:30] that kind of sutff [17:12:14] that sounds awesome [17:13:00] especially plane change targeting in the RTCC MFD has been lacking [17:13:05] that will soon change [17:17:39] indy91, that is awesome stuff, looking forward to see those programs implemented [17:17:51] and thanks for the forum post, very helpful [17:18:19] no problem [17:18:31] I should invest even much more time in writing tutorials and manuals [17:25:40] so is the thruster selection functions already complete? Or will that be further implemented with the detailed maneuver table? [17:27:12] it's not added for all maneuver types yet [17:27:23] and there actually wasn't really a standard way in the RTCC for this [17:27:31] RTE processor had its own thruster selection [17:27:35] and finite burntime calculation [17:28:15] I'll add thruster selection for more processors [17:28:16] one by one [17:28:22] I like that way [17:28:56] MPT -> then leads to the thruster selection page, quite simple [17:29:42] all the rendezvous processors used MPT logic to calculate finite burns [17:29:47] and they used its thruster selection [17:29:55] so all the MED forms look quite similar [17:30:08] for the DPS you could define two special parameters [17:30:23] time at 10% and percentage of full thrust [17:30:34] right now that is done in a bit of an automatic way in the MFD [17:30:57] standard for those would be 26s and 92.5% of course [17:31:23] that's why adding extra pages for thruster selection made sense [17:31:27] more parameters to come there [17:32:57] for all this stuff the two most recent documents from UHCL have been very useful [17:33:29] here an example: https://i.imgur.com/Eg83h0q.png [17:33:38] you can work out yourself what it all means :D [17:34:43] nice! [17:34:57] Ill play with this later today, gotta run! [17:35:01] cya! [19:16:30] thewonderidiot, I have a quick AGC source code question [19:29:19] sure! [19:29:22] what's up? [19:29:34] https://www.ibiblio.org/apollo/listings/Luminary099/P12.agc.html [19:29:39] QAXIS [19:29:50] QAXIS is calculated from RRECTCSM and VRECTCSM [19:30:05] right [19:30:07] that's the permanent state vector, right? [19:30:36] I wonder if P12, when it first gets started, is propagating the CSM state vector to a specific time [19:30:50] or if it just takes the current permanent state vector [19:30:53] right, that's the permanent state vector [19:32:29] uhh [19:32:41] not seeing where it would do propagation [19:33:01] yeah, GSOP also doesn't have anything [19:33:21] so it will depend on the time tag of the CSM state vector [19:33:43] even the Moon has non-spherical gravity, but not so strong [19:33:54] so QAXIS will vary depending on the time tag on the CSM SV [19:34:11] because that's a unit vector to the orbital plane of the CSM SV [19:34:43] guess they didn't think it was important to have the CSM state vector at a specific time [19:35:58] if the CSM state vector would be super old then it would matter [19:36:09] but P00 wouldn't allow the SV to get that old [19:38:00] hmm [19:41:34] http://www.ibiblio.org/apollo/Documents/j2-80-MSC-69-FS-4_text.pdf [19:41:39] PDF page 180 [19:41:43] possibly helpful? [19:43:21] no :D [19:43:43] I know what it is calculating for QAXIS [19:44:06] I was just wondering about the time tag on RRECTCSM and VRECTCSM [19:44:47] I just figured it might be easier to poke around through pages next to that than it would be to look through the listing [19:44:57] since Norton does functional groupings [19:45:12] right [19:46:56] the normal procedure is to uplink a CSM state vector that is time tagged to some post insertion time [19:47:31] or at least that is biased to be accurate at some post insertion time [19:47:52] so P00 probably won't touch it [20:24:17] good night! [21:05:57] wow [21:06:03] sounds like Ron nearly has a working LVDC assembler [21:13:58] Great! I had to do my own compiler for college. They scare me. [21:14:36] My heartrate jumps when someone says lexer. [21:16:45] hehehe [21:16:47] well [21:16:54] assemblers are significantly simpler than compilers [21:17:05] they are very different beasts [21:19:17] True. The syntax is relatively simple. [21:23:01] Any updates on the if the listing is in fact restricted? [21:23:13] on if* [21:24:02] nope [21:24:50] It probably isn't I'm pretty sure? Ron's just super careful. [21:26:36] probably [21:26:41] there's just very big consequences if it is [15:35:28] hey [15:37:53] hey Alex [15:39:22] just saw you released the short profile rendezvous targeting, wow that was quick! [15:39:51] yeah, it was only a few pages [15:40:01] and all the constraints for it were already right [15:40:05] just not the calculation method [15:40:19] it won't have changed a lot, but a bit more accurate probably [15:40:27] tested one ascent, 1.5 ft/s tweak [15:40:37] and I only trimmed out of plane [15:40:47] nice [15:41:12] APS delayed shutdown thrust also helps [15:41:30] so is there an equivalent processor for the concentric profile in reality? [15:41:43] we have that document [15:43:22] it's probably not a very separate thing though [15:43:38] the short profile was added to the earlier program [15:44:24] Lunar Launch Window Processor [15:44:40] it's a launch window, because you can specifiy min and max DH [15:44:52] 10 and 20NM usually [15:45:03] and it then gives you launch times for those [15:45:20] but there is not much to gain in new functionality really if I would implement that 1 to 1 [15:45:45] a few more things I haven't added because I ran out of space on the MFD page [15:46:05] like you can calculate the rendezvous maneuvers so that they are done by the CSM instead of LM [15:50:13] right makes sense [15:50:57] ill be back in a few minutes and I will test the new update [16:51:01] I guess the descent planning table is next? [16:58:45] yes [17:05:35] morning! [17:07:02] hey [17:07:11] what's up? [17:07:25] AlexB_88, for the tweak burn, what you been using as the offsets for the Lambert targeting? [17:07:37] finished the short rendezvous profile targeting already [17:07:42] oh man, nice [17:07:43] that was the shortest new MSC memo [17:17:04] indy91. -1.7 [17:17:45] yeah, that's almost what I used as the hardcoded value in the new formulation as well [17:17:50] from the COT I think [17:17:52] SCOT [17:18:19] I used the 29NM value from the SCOT, downrange [17:18:29] and that gave -1.6955° or so [17:18:45] right [17:19:21] that's like 140 meters different from -1.7° [17:19:28] not really significant [17:19:45] nah [17:20:23] I think there was somewhere in the SCOT that actually said -1.7, one of the diagrams. But maybe even that was just a rounded up number [17:22:11] yeah [17:22:58] this tweak burn method is actually how they calculated the liftoff time [17:23:14] but the tweak burn calculation in a calculation loop and iterate on the radial velocity [17:23:26] because if you are early or late in orbit then the radial velocity changes the most [17:23:32] that you need in a tweak burn [17:23:45] put the* [17:28:38] makes sense [17:43:37] the DT entry on the liftoff page works the same still I guess [17:48:50] yes [17:48:58] I added default values for Apollo 14 to 17 [17:49:03] and it gets saved/loaded [17:52:45] great [18:40:39] cya! [20:29:15] night! [17:07:37] morning! [17:16:09] hey [17:16:17] hey Alex [17:16:19] what's up? [17:18:11] not much lately NASSP-wise since Ive been on the west side of the country since August 1st [17:38:52] hey guys [17:41:25] hey [17:43:08] first roadblock with the lunar descent planning processor [17:43:14] uh oh [17:43:16] a lengthy equation probably has an error [17:43:23] nice [17:43:34] which equation? any idea what the error might be? [17:44:11] for plane change targeting, calculating the orbital parameters of an orbit flying over the landing site [17:44:35] it could be in two equations really [17:44:44] the resulting longitude of the ascending node is off [17:45:13] converted back to position and velocity vectors it all looks great, except one sign is wrong :D [17:45:22] lots of hand-written stuff in there right? thats a bummer... [17:45:28] so it's probably a sign error [17:45:44] well, even printed equations often have errors, haha [17:45:51] this is handwritten, but quite readable [17:46:07] didnt you have issues with a certain LOI doc? [17:46:13] oh yeah [17:46:21] main reason I haven't implemented that yet [17:46:31] too many equations are hard to decipher [17:46:39] right [17:46:45] that's not the issue here though [17:47:04] it's all quite clear what was intended to be written [17:47:07] sign error sounds like it shouldn't be too hard to track down [17:47:46] well, I know what the expected result is, but mainly in the resulting vectors [17:48:04] and the error would be in a more intermediate equation [17:48:28] but I might be able to figure it out from understanding the equations [17:49:03] worst case, I have to derive the equations myself to trace it down [17:49:12] but I hope I don't have to go so far [17:49:36] I guess I already know the expected result from the LAN equation [17:49:42] the shouldn't be much of a plane change [17:49:49] and the LAN gets changed a lot [17:49:53] so it's not a showstopper, you'll definitely be able to figure it out? [17:50:01] just a question of how much work it is? [17:50:04] likely [17:50:06] nice [17:50:26] the calculated LAN result in an orbit with the correct velocity vector [17:50:35] and correct X and Y components of the position vector [17:51:05] Z axis is latitude, so it's like it is building a state vector at the landing site latitude, except it's minus the latitude [17:51:09] minus of the* [17:52:08] I also dislike about the equations that in the very usual case of azimuth being 270° it divides by zero [17:52:14] but in an atan [17:52:35] so atan(inf) = PI/2 :D [17:52:46] not sure if that is really safe though [17:53:04] heh [17:54:16] there is a 1967 revision of this document [17:54:26] I didn't know about it, as Ron hadn't scanned that first page [17:54:47] in doubt I need to get that at some point [17:56:00] and this document references some documents from 1964 and 1966 I also want now :D [17:57:24] I'll keep my MSC memo wishlist updated [17:57:55] https://archive.org/details/68fm23images/page/n57 [17:58:04] the equation on the left side, H_J [17:58:17] if anybody wants to look at it, which you don't [17:58:31] hahaha [18:01:52] it's not clear to me in some cases if I should use atan or atan2 [18:02:07] using atan makes the z component of the velocity vector have the wrong sign [18:02:12] instead of the position vector :D [18:04:56] hehehe [18:49:32] cya! [20:07:24] night! [17:04:43] morning! [17:53:33] hey Alex [18:01:59] hey [18:02:04] whats up? [18:06:33] hey [18:17:18] hey [18:17:35] AlexB_88: debugging stuff at work, thinking about Luminary 1D [18:17:55] nice [18:17:59] hey Niklas [18:19:52] I'm on the road right now, but I made a bit of progress with the issue in that LDPP equation [18:20:28] oh nice [18:21:21] great [18:21:35] I think I know in which part the error is and I can get results close to expected if I just not use part of it [18:38:17] is that enough to fix the problem [18:38:19] ? [18:39:36] I mean, do you have it narrowed down enough that you can root out the problem and fix it, instead of not using that part? [18:40:53] maybe [18:41:38] Apollo 11 is not a good test case for it [18:42:04] I need to try it with a mission that has a larger approach azimuth [18:42:45] because the relevant part should become 0 with 270° azimuth [18:42:58] and Apollo 11 has 269° [18:44:16] the part of the equation definitely should be close to 0 [18:44:33] in the equation as written it becomes 180° [18:45:07] which resulted in the weird sign issue of the number [18:54:39] I guess it is just a "maybe", because I don't understand the equation enough to say [18:54:56] that's the error and that is how to fix it [19:08:43] oh I am dumb. Surely the constructed orbit should go exactly above the landing site [19:09:14] so it would be easy to test if I actually fixed the equation or not [19:58:55] night! [16:48:08] good evening [16:51:12] hey Niklas [16:52:36] Ill finally be back home tonight and hopefully I'll be able to finally make that sim bay jettison panel over the 1st week of September [16:53:10] ah, nice [17:00:06] any more luck with the equations? [17:01:08] didn't have time yet to continue with it [17:45:31] morning! [17:58:36] hey Mike [18:00:42] what's up? [18:01:15] just came home, so naturally I'm looking at equations again [18:01:25] hehehe [18:10:57] did you make progress with Luminary 178? [18:11:16] or just wrote some updates on Github [18:31:20] just writing down what I've done essentially [18:31:45] I'm going through things more thoroughly this time, though, so hopefully new differences turn up [18:32:01] my goal is to be able to identify which revision every change between Luminary 131 and Luminary 210 happened in [18:38:15] right [18:40:07] I have an idea with these LDPP equations [18:40:24] it is possible that it is using a nonstandard definition of inclination and azimuth [18:40:36] like, 2° instead of 178° inclination [18:41:50] oh interesting [18:42:14] then the equations could be 100% right [18:42:58] that sounds very promising [18:43:24] lunar AEG orbital elements limit [18:43:29] 0 < i < PI [18:43:35] that must be it [18:44:51] so [18:44:58] I need to convert it back and forth then, haha [18:45:09] or modify the equations properly [18:47:26] interesting [18:48:08] the SCOT displays them like that sometimes, like 5 degrees, being 175 degrees [18:49:03] yeah [18:50:36] definitely not the case for all RTCC processors though [18:50:45] I have seen limits on the azimuth like 250° to 290° [18:53:27] this might have helped, haha: [18:53:28] https://www.ebay.com/itm/1968-NASA-Apollo-11-Mission-MANUAL-Logic-amp-Equations-About-the-Moon-68-FM-12-/362705969726?hash=item5472f5e23e%3Ag%3AftQAAOSw5PJdNSC8&nma=true&si=aF07ziYgbSIUy7dzbRpibhwaH04%253D&orig_cvip=true&nordt=true&rt=nc&_trksid=p2047675.l2557 [18:53:43] but it's going to be next list for documents to be scanned [20:18:33] hmm [20:18:35] lunar AEG orbital elements limit [20:18:39] 0 < i < PI [20:18:42] PI is 180° [20:18:46] so I know nothing :D [20:31:00] but the fact remains that the equation would give good resuls with azimuth 90° [20:31:09] while the azimuth is actually -90° [20:31:12] or close to it [20:32:19] that in itself should be right [20:32:21] shouldn't* [20:34:21] 90° and -90° should behave the same. So I guess I am back to "there is an error in the equation" [20:36:36] booo [20:53:43] well I get pretty good results when I change a + and - into - and + [20:53:53] I was under the impression that I should get exact results [20:54:16] but there might be a small approximation in there so that the trajectory doesn't pass exactly above the landing site [21:10:38] night! [16:51:11] hey [13:55:55] hey [14:04:07] hey Alex [17:09:47] morning! [18:47:20] hey Mike [18:48:05] hey AlexB_88 [18:48:06] what's up? [18:54:26] not much, just messing around with Sim City 4 [18:54:30] haha, nice [19:37:58] a bit busy these days. Making some progress with the LDPP. Gotta go, cya! [19:40:05] hahaha [19:57:47] Evening [19:58:07] hey Thymo [19:58:16] What's up? [19:58:52] workin on work stuff [19:59:00] and thinking about Luminary 178 [19:59:01] you? [19:59:23] Just chilling. Had my 2nd day at Thales today. [19:59:31] nice [19:59:34] how was it? [20:00:14] Interesting, confusing and exciting. [20:00:33] They have a bunch of cool shit. But there's just sooo much I need to wrap my head around. [20:01:23] Yesterday was mostly spent meeting everyone, getting my access set up and signing NDA's [20:01:27] what are you focusing on in your internship? [20:02:32] I'll be working on a common interface and containerization for microservices inside Tacticos (Naval combat management system). [20:03:05] nice [20:03:55] I hope to be able to get a meeting with some people tomorrow that may be able to tell what the hell I should do. :P [20:04:04] hahahaha [20:04:14] There's so much I need to know to even understand the system. I don't know where to start. [20:04:39] yeah that sounds like a pretty fundamental architectural thing [20:05:19] Considering NASSP takes a while to wrap your head around. This is just huuuuge. [20:05:31] The bureacracy is not helping. [20:05:58] I had to put in a request to even get access to the wiki that has some marginal info on the operation of the system. [20:06:19] hehehe [20:06:25] sounds about right for a giant defense contractor [20:06:43] 2200 employees just at this site [20:07:19] I asked for some introductory documentation just to get me started so I would know how to use the thing. [20:07:37] "Yeah... Our documentation is really not that great/existant. It's all in people's heads." [20:08:09] I'm slowly becoming convinced that there are not any places where that is not true [20:09:01] I managed to find the administrator's manual stashed away on the management VM. [20:09:19] That referenced the user operation manual. Which wasn't on there.. [20:11:50] I can't wait till I actually make some changes and then figure out how their build system works [20:39:03] yeah that sounds like it will be fun :D [17:13:06] morning! [17:20:53] Hey [17:21:02] what's up? [17:22:17] Just finished dinner. Had a productive day today. [17:22:38] Finally managed to get an idea of what I'll do and formulate a basic approach. [17:23:15] Lots of new things to take a look at. Jenkins, Maven and will be doing a bunch of OSGI stuff too. [17:25:04] Me and my coach spent some time just hacking around the system before we headed home. Quite fun. [17:28:31] nice! [17:29:05] How about you? [17:29:10] not bad for a third day :D [17:29:16] making good progress on Luminary 178 [17:29:35] Sweet [17:30:02] still feeling confident that I'll be able to reconstruct it [17:30:34] I've had a discussion with multiple people and we all came to the conclusion that learning how the whole system works is just a bad idea. But I should be able to just make an OSGI module and go from there. Then I can basically do what I want. [17:31:00] I'll probably work on NASSP a bit this evening. Have some things that need changing. [17:32:06] nice :D [17:54:45] good evening [17:54:49] Hey [17:56:17] hey Niklas [17:57:10] Mike, I saw you were doing a bunch of things Luminary 178 noun tables, extended verbs etc. If you are unsure about something, there are a bunch of Apollo 14 checklists available [17:57:16] not the G&N Dictionary, but others [18:00:17] oh great :D [18:00:49] I'm pretty sure the nouns are all completely identical to Luminary 131 [18:00:54] just some internal scaling changed [18:01:24] can you think of anywhere where I'm wrong about that? haha [18:02:48] hmm [18:03:24] and when I say internal scaling changed, I mean R1 of noun 60 changed to double precision so they had to account for that in the noun table [18:05:37] N94 [18:05:42] does Luminary 178 not have that? [18:06:48] https://farm8.staticflickr.com/7026/6391985199_99f77bc15a_b.jpg [18:06:57] this is from training though, not flown [18:11:05] hmmm [18:11:09] what am I looking for here? [18:11:18] oh [18:11:23] crossed out 63 for 94 [18:11:26] yeah [18:11:29] hmm [18:11:31] so the question is [18:11:42] if the flown Luminary 131 had N94 [18:11:51] the version we have does not [18:12:02] noun tables aren't in the module that was changed [18:12:19] no chance it was added [18:13:13] http://www.ibiblio.org/apollo/Documents/LUM188-DD_text.pdf [18:13:29] according to the memos though, N94 wasn't added until Luminary 193 [18:14:04] guess they just kept using that G&N Dictionary then [18:14:25] the memos aren't always perfect, so this is worth digging into [18:14:41] what does Contents of Luminary 1E say... [18:15:01] if that is Ed Mitchell's copy [18:15:07] ah, first page [18:15:08] he was backup LMP for Apollo 16 [18:16:07] https://i.imgur.com/nyTn0lx.png [18:17:00] yeah, must have been changed in the checklist after Luminary 178 then [18:17:01] so that's probably it then [18:17:26] flown checklists don't say much about it unfortunately [18:19:15] I don't know what else could have been added [18:19:22] so Apollo 13 and 14 might have had the same nouns [18:20:04] when did they change N63? [18:21:48] N92 was already added in Luminary 131, didn't know that before [18:22:40] and in terms of verbs, they already had V68 [18:22:44] not sure about other changes [18:23:17] on Apollo 14 that is [18:29:24] yeah, the terrain model verbs were the big thing [18:29:52] if you mean R1 of N63 changing to delta-H, that was also Luminary 193 [18:30:02] 193 had the majority of the noun changes [18:31:28] a lot of the changes to the EXTENDED VERBS section was just coding changes or moving things to different banks, not even things really visible to astronauts [18:32:22] one big difference between 178 and 210 is that verb 57 still generates a display [18:35:14] yeah, that goes along with N63 showing DH [18:35:57] before you did V57 which showed N68 and that had the Delta H [18:36:16] although they changed that around a bit [18:43:47] yeah [18:43:56] the good news with 178 is that I'm through the most heavily changed sections, I think [18:44:04] or at least the sections that were changed across many revisions [18:44:23] now I have a bunch in a row that either had no changes at all between 131 and 210 or were only changed in one rev [18:44:40] although I'm going to hit the landing code soon and that will be a big challenge :) [18:45:14] since for those sections I pretty much only have 131 and 210 to go off of, since Zerlina is so far away from Luminary [18:46:11] I guess with the terrain model and Auto P66 Luminary 210 should be a lot closer than 131 [18:46:41] yeah [18:46:47] and the new analog displays [18:49:35] but, there were definitely some differences [18:49:41] I already know of a few that I haven't accounted for yet [20:30:24] night! [14:27:40] hey [14:38:21] hey Alex [14:43:03] whats up?\ [14:44:34] I have all the calculations in place for the plane change [14:44:39] and now need to find bugs [14:44:58] it's weird, there is only one threshold time for both the PC maneuver and flying over the landing site [14:45:19] and right now it actually finds a PC time after flying over the landing site [14:45:55] and then when it checks if it flies over the landing site it finds the time of the next revolution and so it is off by a bit [14:48:36] weird [15:12:10] did you end up figuring out the equation issue? [15:12:40] I have something that works, but I am not really sure on it [17:18:37] morning! [17:43:29] hey Mike [17:44:48] hey [17:44:50] what's up? [17:49:42] nothing much, just killing time before work. you? [17:51:51] work :) [17:57:35] hey indy91 [18:22:32] yes thewonderidiot? [18:23:02] just saying hi :D [18:23:21] ah [18:23:39] I think that was just my computer coming back from energy saving mode on its own [18:23:46] while I was still very afk :D [18:24:09] haha [19:04:58] well if I carefully choose the threshold time for the plane change maneuver it calculates a pretty accurate result now [19:42:08] whats the threshold time, the target time for the maneuver? [19:43:57] the earliest time for it [19:44:12] but the same time seems to apply for both the maneuver and flying over the landing site [19:44:38] so if you would choose a time just before flying over the landing site then the maneuver would always happen after flying over it [19:44:52] which can't be right [19:45:13] it wouldn't pass the check how close it comes to the LS [19:45:18] and be stuck in a loop [19:45:33] I'm probably overlooking something [20:01:08] right [20:21:40] night! [16:04:40] hey [16:36:50] hey Niklas [17:04:42] morning! [17:22:55] hey [17:43:45] what's up? [18:43:55] not much just browsing around, you? [18:44:50] implementing some of the other equations in the LDPP [18:45:00] there is a lot of modes and submodes [18:45:37] as a consequence of that it's a label/goto labyrinth [19:18:13] nice [19:44:00] I bet its a lot of new pages/labels for that one [19:49:42] hmm, not particularly [19:49:48] you have to define up to 4 threshold times [19:49:53] that is definitely more than before [19:50:18] all in all it might be even fewer pages than before [19:50:27] LOI-2, PC and DOI pages will be merged [19:51:03] if I go by the manual entry devices then there are two [19:51:10] two input pages [19:51:19] "Initialization for Lunar Descent Planning" [19:51:36] that has all the constants [19:51:51] like descent flight time, descent flight arc, height at PDI etc. [19:52:32] and the other MED has mode, sequence (which is basically the sub-mode), 4 threshold times and a desired height [19:52:42] interesting [19:52:43] which would be 60NM [19:52:57] for LOI-2 [20:01:11] by label/goto I meant: https://en.cppreference.com/w/cpp/language/goto if that wasn't clear [20:04:51] the program flow is jumping back and forth all over the place [20:05:03] a bit disorienting [20:05:22] India attempts a lunar landing: https://www.youtube.com/watch?v=7iqNTeZAq-c [20:05:30] let's see if they do better than Israel, haha [20:20:41] uh oh [20:26:55] doesn't look like it made it to the surface [20:27:04] well [20:27:14] not in a controlled way [20:28:01] got pretty close [20:36:35] :( [20:51:47] night! [13:05:23] morning! [13:15:49] hey Mike [13:16:02] you are up early :D [13:16:14] indeed [13:17:23] I'm sitting in the airport with these guys: https://i.imgur.com/vK1VJiZ.jpg [13:18:43] Sundance? [13:18:48] yep [13:19:06] B1, B3, and B5 are Sundance 292, and B6 is Sundance 306 [13:19:16] right [13:19:58] if nothing goes wrong I should have them dumped in ~6 hours [13:20:10] oh great [13:20:14] and then we can piece together our 6 mismatched Sundance modules and see how badly it does not work :D [13:20:41] git merge [13:20:44] hehehe [13:22:23] B3 will be particularly interesting to look at since we'll have both 292 and 302 for it [13:23:45] yeah [13:23:53] helps reconstructing each revision, hehe [13:23:58] yep [13:24:06] also we don't have the memo, but I noticed this yesterday: [13:24:14] SUNDANCE Revisions 280, 281 and 282 and LUMINARY Revision 0 [13:24:22] Luminary branched off earlier than 292 [13:24:40] so it's possible all changes from 292 to 306 also went into Luminary [13:25:19] which we have memos for [13:25:27] yeah [13:25:38] Luminary 12-16 had a change corresponding to Sundance 290 [13:25:54] specifically rev 13 [13:28:45] Luminary 27-34 brought it up to date with Sundance 302 [13:29:00] but there's lots of annoying change notes like this: [13:29:10] SUNDANCE anomalies Y18, Y30, Y32 and Y36 were fixed. [13:29:43] with no further info on those anomalies [13:30:07] right [13:31:18] maybe I'll be able to dig stuff out at Don's [13:31:40] but I don't remember seeing too much Sundance stuff [13:32:00] the really good Luminary things came from Russ Larson, and he wasn't involved in Sundance, at least at a high level [13:34:41] power cables for the AGC, tools, fixed jumpers, monitor, USB cables, laptop [13:34:47] er [13:34:59] meant to send that to another chat, but I'm just making sure I have everything needed :P [13:35:16] haha [13:35:31] better have that list everywhere then, that should help [13:36:00] well it's too late now since I'm about to board the plane [13:36:21] just trying to calm my anxiety since this is the only chance I'll have to read these [13:38:17] right [13:38:20] I will be very happy in multiple ways once this is done, haha [13:42:10] alright, time to board. I'll be back in a few hours! [13:48:10] cya [15:19:41] hey [15:27:52] hey Alex [17:06:55] morning! [17:11:44] hey Mike [17:12:10] seems like the rope dumping was successful [17:13:06] yep! [17:13:12] got all of the ropes [17:13:18] good parity and banksums throughout [17:13:39] very nice [17:13:49] I did a brief comparison of the 292 and 302 revisions of B3 [17:14:04] there are some pretty big changes [17:14:12] a decent bit of code was added between the two [17:14:25] no idea what code yet though :D [17:15:50] interesting [17:16:54] GSOP section 4 might be the best to figure out changes [17:17:03] there was a GSOP update in January 1969 [17:17:13] which presumably has the last changes to Sundance [17:17:16] nice [17:17:17] yeah [17:17:31] what's all in B3? [17:17:37] haha [17:17:39] I have no idea [17:18:02] I can tell you what's there in Luminary 69, but I can also tell you that code has definitely changed banks betwee Sundance and Luminary 69, so [17:19:27] right [17:19:52] I will get to that eventually, but I want to try to finish Luminary 1D and 1C first :) [17:20:46] you won't get bored anytime soon [17:21:05] definitely not [17:21:21] I have all the lunar descent planning processor equations in code now, but it's more like the first iteration of a AGC listing transcription [17:21:33] hahaha [17:21:34] nothing will work with just that [17:22:17] and I really would like the previous version of that document [17:22:39] pretty much all of the references from the LDPP document [17:23:13] is that something that NARA has? [17:23:19] probably [17:23:28] Ron didn't scan the first page of it [17:23:35] but he started with late 1967 [17:23:53] and this is mid 1967 [17:24:09] although it says May 1968 in the references list [17:24:12] which has to be a typo [17:24:19] you can't reference something from the future [17:24:32] the LDPP document we have is from January 1968, so... [17:25:23] E.157G. MISSION PLANNING AND ANALYSIS INTERNAL NOTES. [17:25:28] 64OM-02 to 71FM384 [17:25:29] hehehe [17:25:52] so E.157G, or whatever that is now, probably has all of the referenced memos [17:26:02] although it's missing a bunch [17:26:10] even where Ron scanned document [17:26:17] first pages of documents* [17:26:41] I wonder if there is an update to this LDPP document in one of the missing documents from 1968 or later [17:27:10] so if this is like the first iteration of a transcription, does that mean there's still proofing/corrections to be done? or do you think that what you have should work? [17:27:37] there are many modes and submodes in the LDPP, some might already work [17:27:42] most probably won't without fixes [17:27:51] have to test them all [17:27:58] right [17:28:27] most aren't that complicated really [17:28:45] they are just Hohmann transfer back to a circular 60NM orbit [17:28:54] with or without plane change and then DOI [17:29:26] the submodes are just maneuvers in different orders [17:31:18] the RTACF version of the LDPP for Apollo 1 definitely had more submodes than this RTCC Requirements documents [17:31:23] Apollo 11* [17:31:54] I'm not really sure how software development worked in RTCC vs. RTACF, but I think we can assume that there were more updates [17:32:51] one very useful mode is already missing from the MSC memo [17:33:05] so I have doubts that this is really the latest version of it [17:33:10] with or without another MSC memo [17:33:57] hmmm, interesting [17:34:00] which mode? [17:34:40] combined plane change and circularization maneuver at specific altitude [17:34:58] this is not what Apollo 15 used, as Apollo 15 did a DOI with plane change [17:35:00] but it's close [17:35:48] and I have to listen to the Apollo 11 FIDO loop before LOI-2 again [17:36:03] but I am pretty sure they calculated a LOI-2 with plane change as a test [17:36:34] the MSC memo does have a mode like that, but the TIG is at the right time for the plane change [17:36:40] and not the given altitude [17:36:48] so it wouldn't be useful for a LOI-2 with plane change [17:40:12] if NARA doesn't have an updated memo, and UHCL doesn't it either [17:40:28] then I need to hope it appears on eBay some day, haha [17:41:28] if there is one [17:41:36] hehehe [17:42:12] there is a "to be relased" memo for the "supervisory logic" of the return-to-Earth processor [17:42:24] which is also not among any documents I have seen yet [17:42:30] so not sure if that was ever released [17:42:39] I hate it when that happens [17:42:42] 64OM-02 to 71FM384 [17:42:48] Ron didn't scan more [17:42:56] the Luminary memos have something like that that greatly annoys me [17:42:59] so it might well have been released on early 72 or so [17:43:04] in* [17:43:44] The following test plan has been established to verify LUM 131 A REV 3. It is anticipated that testing and review will be completed by 9 February. A forthcoming memo will describe the changes between LUMINARY 131 Rev 009 and LUM 131 A Rev 003. [17:43:51] that memo never came >:( [17:44:33] Ron only scanned up to 71-FM-16 even, so it could be anywhere from 1971 really [17:44:43] I at least have hope that the memo exists somewhere :D [17:44:47] haha [17:48:42] there are lots of MSC memos from 71 about verifcation of AGC routines of Luminary 178 [17:49:11] hmm, interesting [17:49:48] well, a bunch [17:49:56] not that many, haha [17:50:03] but the list isn't complete [17:50:16] from the JSC Document Index [17:59:59] heyè [18:00:03] hey* [18:00:28] hey Alex [19:09:13] hey [19:09:33] making somewhat progress with the LDPP. Adding lots of untested code, haha [19:24:40] yeah, the document definitely doesn't have all sub-modes of the LDPP [19:24:58] the RTCC Support Plan for Apollo 11 says there are up to 5 submodes [19:25:11] but the MSC memo only has 3 [19:25:16] 3 max* [19:25:42] :( [19:26:01] but 5 would agree with the two additional modes that the RTACF Support Plan mentions [19:26:17] plane change and circ maneuver at altitude or time [19:26:25] so I probably just need to implement that [19:26:33] additionally [19:27:12] not an easy task with this complicated program flow [19:27:14] but possible [19:28:43] would still not cover the Apollo 15 DOI case, that could be an additional mode that was added at some point [19:29:02] although I have nothing on the LDPP modes post Apollo 11 [19:32:24] G TO H MISSION RTACF ( REAL TIME AUXILIARY COMPUTER FACILITY ) REQUIREMENTS REVIEW [19:32:25] maybe [19:33:30] Tindall claims that no RTCC changes were necessary for CSM DOI [19:33:49] but there is definitely no mode that covers DOI with plane change [19:36:41] hmmmm [19:37:35] ! [19:37:40] I found something [19:37:47] https://archive.org/details/NARASWSelectedApolloBoxes/page/n49 [19:37:52] right side [19:38:02] changes to 68-FM-23 [19:38:06] which is this LDPP memo [19:38:38] damn [19:38:45] if only I had known about this earlier [19:38:58] this would have been the most important thing to scan after 68-FM-23 itself [19:40:22] 68-FM-23 is misplaced a bit in the list of first pages [19:40:24] not in order [19:40:32] but these changes are between 22 and 24 [19:40:39] 21* [19:41:40] oh man [19:42:08] well, you should let Ron know :D [19:42:57] I will [19:43:29] I'm pretty sure that will at least cover those two extra submodes [19:43:45] that is probably the state of it during Apollo 11 [19:43:52] but often the changes come as a pacakge [19:43:58] so it might have way more changes [19:44:39] most other RTCC documents I requested this time around were for Apollo 14, and it had changes up to Apollo 17, so [19:46:15] guess I'll stop work on the LDPP then for now. No point in implementing an outdated version, that definitely has some, but probably many errors [19:46:36] seems fair [19:46:40] so what's next then? [19:46:57] The calculation modes for LOI-2 and DOI should work fine and there can't be too many errors [19:47:01] might as well finish that [19:47:05] not sure about plane change [19:47:15] definitely some things that don't make sense [19:47:22] not without fixes [19:48:07] I'll probably take a look at the translunar midcourse correction processor next [19:48:31] nice [19:48:54] for me... I just finished looking through P40-P47, which means the next log section to clean up for Luminary 178 is THE LUNAR LANDING [19:49:10] in which Don rewrote everything so I can only see Luminary 131 and 210 [19:49:25] difficult times ahead :D [19:49:29] haha, yeah [19:51:05] oh actually [19:51:08] this one may have not changed as much [19:51:35] three-way diff is still possible :) [19:54:17] yeah, THE LUNAR LANDING is more top level sequencing it looks like [19:58:22] yep [19:58:29] LLGE is where it gets hairy [20:03:12] btw, Thymo, your server's certificate expired [20:03:46] Oh, right. [20:03:55] I got the reminder's for that. [20:04:01] "I'll do it later." [20:04:04] Too late :p [20:04:06] hehehe [20:05:42] There. [20:07:24] oh that was fast [20:07:42] I just have to run certbot renew on the box. [20:08:11] It's set up to request a new cert, verify using Apache and install the new cert. [20:08:26] Should probably put it in a cronjob to run every 3 months. [20:09:32] oh nice [20:09:44] haha yeah a cronjob would take care of that :D [20:13:17] also damn [20:13:33] my flight home from Houston was just suddenly delayed by 3 hours 15 minutes [20:13:38] looks like I'm gonna be at this airport for a while [20:15:55] At least you know how long it will be delayed. [20:15:59] well [20:16:13] the fact that it was on time and then delayed by that much makes me worried [20:16:23] only rarely have I ever been on a delayed flight that was only delayed once :) [20:17:23] When I was in Milan this summer and heading back my train didn't depart. After 30 minutes of waiting we learned it wouldn't depart after asking staff. [20:17:39] Later we learned no trains were going at all due to some outage up the network. [20:17:56] damn [20:18:02] Got back an hour later, information office didn't even know about any outage. [20:19:01] Were able to get the last possible train at 2330 back. That train wasn't even on any departure boards either, luckily an Italian guy heading to the same place informed us. [20:19:43] nice [20:32:29] night! [21:02:58] ohhhhh there's some stuff in Zerlina and 210 that wasn't added to Luminary until 186 [21:03:00] sneaky sneaky Don [16:55:22] morning! [16:59:46] Hey Mike [17:06:29] hey guys [17:07:48] I can't reproduce this counter bug yet [17:08:28] oh it's very random [17:08:49] I had it once when I exited wrong out of P40 during Apollo 7 [17:09:35] or maybe not random [17:09:40] just difficult to reproduce [17:09:59] It's bound to have some preconditions. [17:10:04] yeah [17:10:11] Unless it's those nasty cosmics rays again. [17:10:19] and I think the issue in the computer is that it still is set to TVC instead of optics [17:10:32] why, I don't know [17:10:39] What is? [17:10:45] Is the CDU reused? [17:11:12] OCDU output is used for both SPS TVC and driving optics, yes [17:12:06] Controlled by an output channel I guess? [17:12:15] in yaAGC yes [17:12:20] but I think it's a confusion in the software [17:12:38] Channel 12 bit 8 [17:13:07] does this only happen with Colossus? [17:13:13] Confusion on our end or MIT's end? :p [17:13:26] probably our, in some way [17:13:41] haven't seen it with the RR [17:14:10] if the optics is driven to zero but N91 doesn't change then it's not doing a OCDU Zero [17:14:37] Hmm. Wonder if I can get TVC control without going through P40 [17:14:50] in Artemis you can [17:14:54] there is a EMP procedure [17:15:08] you can do the gimbal drive test from P40 [17:15:15] but just that, without entering P40 [17:17:39] and it's definitely a very old issue [17:19:44] Mike, I've got a different question for you. [17:19:53] What would happen to the IO channels on a GOJAM? [17:20:23] Right now we have a comment saying we should reset them because they're flip-flops, but we don't because it's 'too difficult'. [17:21:16] I have a memo for you :) [17:21:33] http://www.ibiblio.org/apollo/Documents/dd_memo_340.pdf [17:21:46] most channels are reset to 0 [17:22:25] thewonderidiot, I spoke to Ron, he will try to scan the missing updates to the LDPP memo in two weeks [17:22:31] nice :) [17:22:48] Definitely not all though. [17:23:01] even when I didn't ask it specifically he scanned all the update sheets. So these definitely got separated from the main document [17:23:24] in the old box system it was the first and last title page he scanned from one box [17:23:25] ALTMTR is a computer signal? Something to do with altitude?? [17:24:58] I'm actually not entirely sure what that is, that's not a net name I'm familiar with [17:26:41] hmm [17:26:44] I see the GOJAM wiring [17:26:55] goes into a pair of flip-flops used to generate the ALTM count pulses [17:27:06] probably just makes sure that circuit gets reset properly [17:27:32] so they're not out of sync with the channel [17:29:40] Ron got me the Luminary 1C flowchart sections at the end of last week [17:29:58] unfortunately they all seem to be for Luminary 131 :( [17:33:46] :( [17:34:08] so both would like updated versions of scans we got from Ron :D [17:34:15] hahaha [17:34:21] well [17:34:27] the difference is that you know your updates exist :D [17:34:42] I'm just gonna ask him to double check that there aren't any addenda or anything [17:34:44] yes, barely, and a few weeks later I should have known [17:34:49] later thanÜ [17:34:53] than* [17:35:04] it seems weird that they would publish 131 flowcharts in January 1970 [17:35:32] well, maybe not [17:36:08] 131 was December, 131 Rev 9 was January, LM131 Rev 1 was February [17:36:09] my conspiracy theory lives on. They had to mess up the mission because they lost of track of the LGC software that was flown [17:36:19] so I guess it really depends on when in January [17:36:19] hahaha [17:36:45] and publishing lengthy flowcharts takes time [17:36:45] I have a new thing to be hopeful for though [17:36:56] I spotted this in my index of Don's stuff: [17:37:12] "Folder containing information about P66 Auto" [17:38:04] I'll have to see if I can find pictures of anything in it in my photo album [17:38:40] you know what publishing date is late? MSC memo 69-FM-217 [17:38:58] Cislunar Navigation Sightin Data for Apollo 11 (Mission G) July 18, 1969 launch [17:39:06] published July 30, 1969 [17:39:26] it's not even the flown launch date and published after the mission :D [17:40:07] so I wouldn't be too worried about January 70 for Luminary 131, haha [17:47:44] hahahahaha wow [17:47:48] amazing [17:52:39] might be still useful for us if someone wants to do P23 with the July 18 launch scenario we have [17:56:12] ah, finally found this in the FIDO loop [17:56:33] about the landing being a few miles long [17:57:40] FIDO:"this has us 4 miles long" GUIDO: "yeah, I believe it" Dynamics: "yeah" FIDO: "yeah" [17:58:10] the "yeahs" in a kind of "it's consistent with what Neil said, but not really happy about it" tone [18:04:29] hahahaha [18:05:08] when was this? I assume they already figured out what caused it based on that? [18:06:14] I think it's based on MSFN tracking of the LM [18:06:25] aha [18:06:35] about 50 minutes after the landing [18:07:57] they haven't really talked about the cause of it [18:08:01] not much time for it [18:08:14] first they were busy with T2 stay/no stay preparation [18:08:38] and they mainly wanted the most accurate landing site data for a launch on the next rev, T3 [18:09:27] maybe they will talk about it when it gets less busy [18:10:58] the onboard landing site vector would probably not useful for this, it would only have a small difference to the planned site [18:11:21] as much as Neil steered away from it [18:11:36] they don't trust the P57 gravity vector data at all [18:11:46] it currently gives 0.5° instead of 0.7° latitude [18:11:50] probably an alignment issue [18:12:28] although that happened on two consequtive P57s [18:12:39] consecutive* [18:26:32] Our Apollo 17 scenarios use Artemis right? [18:49:45] indy91: Did you ever put Sundial E in the tree? [18:52:31] You did not [18:56:53] Apollo 17 uses Artemis [18:57:04] I will put in Sundial E and Luminary 69R2 [18:57:32] Should we? [18:57:49] Unless we plan on making a 2TV-1 mission it will just take up space. [18:57:53] and there is a NASSP update still coming to easily use any AGC version with a scenario [18:58:26] hmm, wasn't Sundial also used on the launchpad to do tests? [18:58:38] a while before launch, but still relevant to prelaunch checkout stuff [18:58:45] Yes, but before T-4h [18:59:14] 36KB [18:59:34] if it was only run in 2TV-1 I would not add it [19:00:06] I don't know, I think it is relevant and interesting enough to be added [19:00:09] just barely :D [19:00:27] we have a scenario for Saturn V stacking and rollout [19:00:29] It most likely was used (or at least a variant of it) on the pad. We just don't have scenario's pre T-4h when it could've been used. [19:00:46] which worked fine in NASSP 7.0 release [19:00:52] not sure about now, haven't tested it since [19:01:10] Besides, then we would need to add a AGC Monitor MFD first to replace the rope and do the padloads. [19:01:31] Would the stacking stuff be affected by the touchdown point business? [19:01:41] probably [19:02:13] You'll probably end up in venus orbit once you stack the first stage [19:02:25] sounds likely, yes [19:04:46] But as I said. I'm all up for adding Sundial, but then we need to do all the GSE stuff first. [19:06:47] I don't think so. When the update to choose a AGC rope with a line in the scenario is done then all you need to do to run Sundial is add a line in the scenario [19:07:13] I don't plan to actually add code that switches out the ropes [19:07:19] not anytime soon at least [19:07:42] How do you want to go about that then? Replace ApolloNo or just add a special case? [19:08:02] Right now I've got Sundial special-cased as Apollo 99 [19:08:23] that update would already be done, but I was so smart to add in a development branch for something else [19:08:32] add it* [19:08:44] it just needed more testing, it was basically done [19:08:59] the ApolloNo doesn't get used in that case to choose the rope [19:09:20] it would be a line in the scenario that overrides the normally used rope [19:09:52] same goes for the LGC in the prelaunch scneario [19:10:02] that's how I plan to run Mike's rope Terminus [19:10:54] I think it was e.g. "CMCVERSION SundialE" [19:11:11] that in the scenario and it will always use that and not choose based on mission number [19:11:32] And without it, it will still use apollono? [19:11:45] yes [19:13:05] in the long run that will be moved from the scenario to a mission specific config file [19:13:34] that would be the better solution to use mission specific, but constant parameters [19:14:03] I think [19:14:15] Sounds reasonable. [19:14:52] What kind of things would you want to put in this config file? Just AGC versions or also things like LVDC parameters? [19:15:02] SIMBay presence, etc. [19:16:10] yeah, SIMBay presence [19:16:15] HGA [19:16:46] only some LVDC parameters that aren't presettings [19:16:53] like, configuration differences between missions [19:17:02] like the early S-II center engine cutoff [19:17:16] DSKY versions in the LM [19:17:31] everything vehicle specific [19:17:33] Forced failures and failure times ...eventually [19:18:00] maybe, yeah [19:18:11] that's actually another currently dormant dev branch I have [19:18:23] Sidenote: Is there any operation information for Sundial? [19:18:24] I got as far as displaying failure state (on/off) and times in the PAMFD [19:18:36] a bit [19:21:39] https://archive.org/details/apertureCardBox435Part1NARASW_images/page/n31 [19:21:44] not necessarily Sundial E [19:22:25] but that is basically the procedure I used to demonstrate the FDAI, S-IVB takover and SPS TVC test in the video I did [19:30:40] That shows a full control and display test. Seems I can only test TVC if I do the others first. [19:30:58] Do we know of any other test values? [19:31:31] I'm on a test branch that has some IMU changes, let's just say the test isn't going to pass with those changes. :p [19:31:56] thewonderidiot had a list [19:32:06] hey Mike, how goes the Sundial E deassembly :P [19:33:32] <_< [19:34:05] I'll get back to it soon... [19:34:49] you had a Sundial E V57 option code list, right? [19:35:22] Looks like they are scattered around the aperture cards too [19:36:10] thewonderidiot: V61 is POSTAND if I'm not mistaken? [19:36:11] code 4 should be a IMU alignment test [19:36:18] same as Aurora [19:36:43] I need to do TVC without touching the IMU. [19:37:00] almost everything is the same as aurora [19:37:07] minus the specifics of which tests are behind V57 and V47 [19:37:33] I don't remember if I had a list... [19:38:54] oh right, we just had the mystery V47 [19:39:01] and I basically did V57 codes with trial and error [19:39:22] not sure about TVC only test [19:39:36] does it have to be Sundial? [19:39:46] I mentioned an Artemis EMP earlier [19:39:54] you never responded to it, but I can give you the procedure [19:40:07] Oh right, I pulled that up. [19:40:35] Figured I'd use a rope specifically with that test [19:40:52] Looking for excuses to play with Sundial :p [19:40:53] Sundial might have it [19:40:56] but not sure really [19:41:21] It probably has it. We just need to know how to do it :) [19:49:36] I am way too deep in the Luminary 1D hole to do anything with Sundial at the moment :D [19:50:01] I found another little bit of code that was added for 1D and then deleted in 179-183 [19:51:28] I know the feeling, my brain is RTCC only right now [19:52:48] what was that, added in 1D and deleted just after? [19:56:18] yes, the flight controllers are busy after the landing. [19:56:21] FIDO to CAPCOM: "Did you give them a 27 or 37 minutes mark to T3?" CAPCOM: "37" FIDO: "That should be 27" CAPCOM: "That was 10 minutes ago" FIDO: "Ohhhh" [19:56:54] time flies :D [19:57:36] hahaha [19:57:54] the code in question was initialization of LRPOS to 1 in P63 [19:58:07] sounds useful [19:58:19] apparently it was not only unnecessary, but also wrong [19:58:37] oh is that a flag? [19:58:42] (it should have been set to 2, because the numbers are the opposite of the position for some crazy reason) [19:59:03] no, it holds 1 or 2, just 1 means position 2, and 2 means position 1 [19:59:12] of course [19:59:15] must have simplified the coding or something [19:59:17] anyways [19:59:28] I know the card numbers from Don's ACB form [19:59:45] it took two cards; I'm assuming CAF ONE, TS LRPOS [20:00:00] and I can see it in the Luminary 1D flowcharts, in P63SPOT4 in THE LUNAR LANDING [20:00:15] So, did the gimbal test. OCDU still zeroes just fine [20:00:18] and when I put those two instructions there another bank got the right banksum :D [20:00:37] I'm up to 4 banks with the right sums, so I'm definitely on the right track [20:01:50] awesome [20:02:07] LUNAR LANDING GUIDANCE EQUATIONS is, as expected, an enormous pain [20:02:11] Thymo, yeah I don't know, I only ever got it if I exited out of P40 at the wrong time [20:02:22] before ignition, after gimbal test [20:03:58] but that's probably not consistent either [20:04:25] If I don't go to pooh after the test the OCDUs don't zero [20:07:18] Before I go to P00 ch12 has bits 2,8,11 set. [20:08:04] Enable OCDU error counter, TVC enable, Disengage optics DAC [20:08:31] So do me a favor. Whenever you see this happen again, do a V01N10E 12E for me. [20:08:59] sure [20:09:03] might be a while, haha [20:09:50] Disengage optics DAC [20:09:57] I don't think that does anything in NASSP [20:13:45] Doesn't look like it [20:14:23] assuming it's not a AGC software bug, it's probably some NASSP code that indirectly prevents the OCDU Zero [20:14:47] not sure how [20:14:53] does it happen in Comanche or Artemis? [20:14:59] I haven't verified but my guess is that channel 12 is reset when you go to P00 [20:15:09] This is Artemis [20:15:15] hmm [20:15:16] But others too probably [20:15:17] okay [20:15:35] I was going to say, I feel like bugs in Colossus would not be surprising, but Artemis is more surprising [20:15:38] gimbal test code is unchanged since colossus237 AFAIK [20:15:39] yeah, I got it in Apollo 7 about 5 years ago [20:17:52] I'll walk through ENEMA and GOPROG3 to see if chan 12 is reset to sane values [20:18:09] and STARTSB2 [20:20:30] does a V37E 00E fix it? [20:20:40] It's part of the EMP [20:21:09] If I don't do it, OCDU doesn't zero. As soon as I go to P00, 15 seconds later the OCDU zeroes [20:21:19] huh [20:21:41] so if the issue happens, a V37E 00E and then later the normal optics zero procedure should work? [20:22:16] Yeah. It doesn't even matter if the switch is already in zero. [20:22:31] hmm [20:22:45] Zero optics -> Huh, CDU doesn't zero -> go to pooh again -> CDU zeroes [20:23:12] OCDU Zero with the switch not in Zero and the optics not at 0 angle could be a problem [20:23:18] in NASSP [20:23:26] but would be fixed by a normal optics zero procedure [20:24:11] Eh? [20:24:32] Going to POO doesn't zero the CDU. It just resets channel 12 so you can zero them [20:24:42] The CDU won't zero if the switch is not in zero [20:25:02] oh, right, you meant "As soon as I go to P00, 15 seconds later the OCDU zeroes" with the switch in zero [20:25:10] yes [20:30:47] Oh, the conclusion of the 27 or 37 minutes issue. There was a post landing press conference which they had on the PAO loop instead of air to ground. They then played back the air to ground audio in the PAO loop, 10 minutes after it happened. [20:31:14] And someone who listened to that told FIDO "isn't it 27 minutes to T3 now instead of 37?" [20:32:03] so that started the confusion. But these flight controller have been getting tired anyway, haha [20:32:08] controllers* [20:32:10] When I move the optics during TVC, the CDU is still updated and visible to the CMC. I wonder if that's right. [20:32:45] not sure [20:32:51] TVC only would use the error counter [20:33:15] optics shaft and trunnion position is the read counter [20:33:49] Yeah [20:34:10] we of course are not using the CDU class yet for the OCDUs [20:34:24] in the real thing, if you have the optics in CMC mode, TVC would move the optics [20:34:35] because that OCDU output isn't inhibited [20:34:39] it just goes out to both [20:35:55] I'm still not sure why exactly the optics can't be zeroed. [20:36:13] As far as I can see the only things affected are related to error counters [20:38:21] optics are zeroed fine, just not the registers in the AGC [20:38:43] Right, that's what I meant [20:38:49] yeah [20:39:09] I was sure you meant that, just making sure :D [20:39:45] but it's strange, what in NASSP code could cause it [20:40:09] I really don't think it is a AGC software bug, that would appear somewhere in documentation, checklists etc. [20:41:33] Let me just make clear that we're assuming chan 12 isn't reset when this happens after P40. Basing this on no reset after no V37 after a manual TVC test [20:42:19] that or its equivalent in a flagword [20:42:31] probably TVC enable [20:42:54] I haven't checked any of the flagwords yet. [20:43:04] CMC drive of the optics also doesn't work then, right? [20:44:13] Let me check [20:46:11] does the channel 12 zero optics signal even do anything in NASSP [20:46:57] well anyway, good luck figuring this out some more [20:47:03] good night! [20:48:37] .tell indy91 Optics torque after the test results in a 115 and two 117 alarms. Mode switch not in CMC (eventhough it is) and optics not availab.e [17:07:27] morning! [17:34:33] Hey [17:40:44] what's up? [17:42:28] Looking at the OCDUs again [17:42:59] When the bug happens after a P40 channel 12 is apparantly set correctly, not what I expected. [17:43:12] But that makes it most likely a bug in NASSP [17:43:14] You? [17:43:29] being completely stumped by a comment in one of the Luminary memos [17:43:46] indy91 may be able to help :P [17:44:10] hey [17:45:02] indy91, there's a note in a Luminary memo that is defeating me [17:45:10] haha, ok [17:45:32] Changes to other areas due to R10 design: [17:45:46] VBIAS calculation moved from STRTP66A into NORMLIZE; parameter GHZ removed [17:45:54] R10 is the new analog displays [17:45:58] the first half of that is easy [17:46:03] but "parameter GHZ removed" [17:47:40] GHZ is still there in Luminary 210, exactly how it was in Luminary 1C [17:48:02] which memo? [17:48:06] it's part of auto P66 and has nothing to do with the analog displays, and I can't see how or why it would have been removed [17:48:18] https://www.ibiblio.org/apollo/Documents/LUM167-BMc_PR_text.pdf [17:48:20] page 3 [17:48:26] so I'm pretty sure it's a typo [17:48:34] but I can't figure out what was actually meant [17:49:33] where is it in 131 and earlier? [17:49:46] like I said, it's part of auto P66 [17:49:56] so it showed up first in Luminary 131 rev 9 [17:49:58] ah right [17:53:29] the value of BIASFACT changed when it moved to NORMLIZE... so maybe it has something to do with that? [17:54:50] or maybe they meant BIASFACT since GHZ is defined close to where BIASFACT was... [17:57:14] that something would have to be moved wouldn't be unusual [17:57:26] that's how GHZ could have something to do with R10 [17:57:45] but removed... [17:57:57] hmmmm [17:59:10] in the GSOP it looks pretty much the same [17:59:41] yeah, same with the Programmed Guidance Equations [17:59:56] what's in 210 is the same as what Norton shows for 1C [18:00:05] as far as GHZ is concerned [18:01:35] it's not a padload in Luminary 1D [18:01:49] so it wasn't, temporarily, moved to erasable [18:01:57] QHZ was, though, right? [18:02:03] that was one thing I thought, maybe they meant QHZ [18:02:48] QHZ is padload in 1C [18:02:58] and 1D [18:03:09] and 1E [18:03:33] yeah [18:06:44] if it had been removed and some other solution for it had been there then it would have been added after 1D again [18:07:52] I feel like that would show up again in a later luminary memo [18:07:56] or in Contents of Luminary 1E [18:07:57] yeah [18:08:08] I doubt it was outright removed [18:08:13] yep [18:08:15] maybe moved, but not re :D [18:08:38] moved is a possibility, but it's loaded in basic with a CA so it can't have gone far (changed banks or anything) [18:09:04] yeah [18:12:47] no idea [18:13:50] I think I'm going to just ignore it for now [18:13:54] yeah [18:14:01] I really hope the Norton document for 1D is for 178 and not 173 [18:14:12] most other ambiguities like this I could answer with the flowcharts for 173 [18:14:22] but this is the only memo that describes changes between 173 and 178 [18:14:35] I do have one other option if I get stuck [18:14:40] which is to take what I have for 178 [18:14:47] and try to make 173 and 163 [18:15:00] 163 we have more information than just bugger words, we also have a word count for every bank [18:17:56] then you would at least know you have 163 100% right [18:18:03] and work up from there? [18:18:07] yep [18:18:37] and all of the changes from 173 to 178 are very very easy, other than the analog displays [18:21:10] did those change much from 178 to 210? [18:22:34] I don't think so [18:24:49] I've been listening more to the FIDO loop, post landing. Trying to find a time where they are actually using the LDPP to calculate a plane change [18:25:02] Apollo 11 didn't do one, but I expected there to at least be a calculation [18:25:24] have a bit to go, but they busy finding where the LM actually is [18:25:37] before trying to say yes or no to a plane change maneuver [18:25:58] and the decision of the crew to do the EVA early also threw them off a bit [18:26:33] so it's a bit of improvisation [18:26:55] they might say "close enough" in a while and never calculate one [18:27:48] they actually think the LM might do the return to the CSM just after the EVA [18:28:02] did they even look when the crew was woken up? [18:28:20] of course they are going to have a rest period after the EVA and launch back to the CSM on schedule :D [18:29:43] hahaha [18:30:06] who knows, those astronauts are crazy :D [18:30:24] as a result they also switched flight controller teams [18:30:30] the Green Team was prepared to do the EVA [18:30:58] so they were called in or so [18:31:01] or [18:31:05] a bit earlier at least [18:31:11] hah [18:31:12] I didn't know that [18:31:45] seemed like a harmless decision from Neil and Buzz [18:32:13] but the nicely planned schedule was useless suddenly [18:33:24] hmm, there were two shift changes in short succession actually [18:33:26] 104:35:37 Duke: And, Tranquility Base, the White Team is going off now and letting the Maroon Team take over. We appreciate the great show. It was a beautiful job, you guys. [18:33:41] that is the landing team to the planning (night shift) team [18:34:40] 106:11:12 McCandless: Columbia, Columbia. This is Houston... [18:34:47] McCandless is from the EVA team [18:35:12] so Milton Windler and his team had a nice 90 minute shift :D [18:36:19] hahaha [18:37:06] 114:33:39 McCandless: Okay. And your friendly Green Team here has pretty well been relieved by your friendly Maroon Team, and I'll put Owen on with the questions. (Pause) [18:37:41] this is when the night shift team took over again [18:38:56] so basically shifts were switched, just with a short stint for the night shift before the early EVA decision was through [18:39:14] man that's rough [18:39:30] no wonder I had difficulties distinguishing the voices [18:39:46] I've been listening to the whole lunar descent shift [18:39:50] I've done night shifts on console before and it would be miserable having to switch shifts in a day [18:39:52] and then suddenly two shift changes in short order [18:39:59] yeah [18:40:02] haha [18:40:40] EVA team was called in early, night shift had to work late basically [18:41:07] I need to listen more to the planning shift [18:41:13] probably will be useful [19:42:06] yeah that sounds relevant :D [20:21:38] night! [15:34:27] Afternoon [15:37:46] hey [15:42:23] hey [15:43:42] LDPP update. If you didn't know yet Alex, I discovered that NARA has some updates to the early 1968 document after all [15:43:48] Ron will try to get them scanned in two weeks [15:44:17] in the mean time, with some changes to the program flow as presented in the document, I have LOI-2, DOI and LOPC calculations working fine [15:44:44] so I think I'll try to get that released and if the updates help a lot then I can implement the other modes properly as well [15:45:34] glad to hear you got a fair portion of it working [15:46:03] and I did finally find a point in the FIDO loop where they are calculating a plane change with the LDPP [15:46:32] what I thought before is that they could only calculate a plane change for the following crossing of the landing site longitude [15:46:45] and that's why they apply a bias to the latitude [15:46:55] to get it right for crossing the landing site more in the future [15:47:19] but that doesn't seem to be the case, they used two threshold times, one for the TIG one for flying over the landing site [15:47:26] and in addition to that they apply a latitude bias [15:47:46] but it's all confused, the calculation failed twice [15:47:52] TIG was all messed up they said [15:48:25] so FIDO and Dynamics gave the task to someone else [15:48:38] and unfortunately all that was on the loop was that it works now, a bit later [15:48:50] so not sure if they were using wrong inputs or so [15:49:31] and the mission control amateur hour continued when they calculated PADs for T5 with the biased LS latitude and had to do it all over :D [15:49:46] bias is only for the LDPP [16:07:57] now I dont feel so bad when I have to re-do a pad calculation because of a rookie error or something lok [16:07:59] lol* [16:09:02] yeah, haha [16:10:02] FIDO has a lot of stuff to juggle [16:10:40] best current state vectors, giving the commands for RTCC calculations etc. [16:11:10] but it's great for me that he had to request the RTCC calculation by voice like this [16:11:18] gives me a lot of data for RTCC inputs [16:12:03] whenever I hear "Dynamics, FIDO" I am ready to write some numbers down, haha [16:13:06] there are some rarely heard people in the loop who often tell FIDO if he has done something wrong or overlooked [16:13:15] especially callsigns Trajectory and Rendezvous [16:13:20] not really sure what their job is [16:14:54] the best call sign is for the computer supervisor of the RTCC, who mostly does computer backups etc. [16:14:58] comp soup [16:17:53] anyway, I am starting work on the LDPP input pages and display page now [16:18:11] so with that and some more testing it shouldn't be long until the first version of it is done [16:27:49] great [17:06:15] morning! [17:12:19] Hey Mike [17:27:24] what's up? [18:19:49] hey Mike [18:20:41] yo [18:20:49] I think I finished with LLGE, at least for now [18:20:57] nice [18:21:01] I'm reasonably happy that what I have probably reflects 178 [18:21:18] now I have a few sections that are easy, before I get to the SERVICER :) [18:22:24] it's going to be servicer which in the end makes all banksums correct, that's how it is meant to be :D [18:22:31] hahaha [18:22:54] I will be so happy if messing with SERVICER gives me more than a single correct banksum [18:23:03] it's been frustrating to make all of these changes and still have 32 out of 36 be wrong :D [18:23:32] actually I can do a quick experiment right now [18:24:39] changes in SERV1 can impact banks 1, 4, 6, 15, 36, and 37 [18:25:17] SERVICES can impact banks 1, 30, 32, 33, 36, and 37 [18:25:49] SERV2 can impact banks 22, 23, and 37 [18:26:20] SERV3 can impact banks 2, 11, 22, 23, 24, 27, and 30 [18:26:49] SERV can impact banks 1, 5, 27, 32, 36, and 37 [18:27:24] that covers a bunch of banks [18:27:27] yeah [18:27:53] 36 is one of the ones I have correct right now, but it may be wrongly correct [18:28:23] hate when that happens [18:28:46] right now I have banks 0, 36, 40, and 41 with the right checksums [18:37:50] oh, yesterday I was complaining that they still hadn't calculated a plane change in the Apollo 11 FIDO loop. Today I listen for 5 minutes further and there it was, haha [18:39:09] hahaha nice [18:39:49] unfortunately they seemed a bit confused with the inputs, just as I am. Someone in the RTCC had to help them, which did not happen on the FIDO loop though [18:39:58] just a few minutes later "it worked this time", unfortunately [18:40:01] hah! [18:40:07] that's annoying [18:40:30] but I think I still learned enough from it to be happy with my solution [18:45:32] there is one person with callsign "Select" and one is "Select Support", confusion ensues [18:45:57] lol [18:45:59] whose idea was that [18:46:02] the RTCC Support Plan says "Select Support" should be called Support, seems a bit easier... [18:46:18] but that's not what they are doing, haha [18:46:47] hehehe [18:47:47] FIDO is behind his schedule, due to all this talk about finding the LM on the surface [18:47:56] very interesting though to listen to that [19:07:19] I so hope these audio tapes still exist for Apollo 13 [19:07:49] that would be incredible [19:08:14] they just don't have the manpower to digitize it all [19:08:24] they haven't done the Apollo 7 air to ground loop yet [19:08:43] one mission's A/G loop was added fairly recently [19:08:49] Apollo 15 or 16 or so, I forgot [19:09:02] so NASA does have a lot of tapes and they are digitizing them [19:09:13] all these Apollo 11 loops was for the specialy occasion only [19:09:19] special* [19:09:34] maybe we'll get lucky with a special apollo 13 anniversary [19:09:50] the Apollo 13 flighr directors loop for the accident and many hours after is available [19:09:58] I have listened to that a while ago, awesome stuff [19:10:57] https://archive.org/details/nasaaudiocollection?sort=-publicdate [19:11:23] two days ago they added some STS-61A stuff, and two weeks ago Apollo 15 [19:11:35] they just have a loooot of material :D [19:12:31] heh, yeah [19:12:34] they need an army of Rons [19:13:34] well [19:13:37] we need an army of Rons [19:13:51] they need an army of people like Ron but who are interested in tapes :P [19:14:38] I also need my own army of Rons [19:14:46] separate from the AGC army of Rons [19:15:45] Lauren is an honorable member of that army [19:17:05] haha [19:31:25] "107:25 in the old flight plan" "I thought it was THE flight plan" "well, they issued a new one" [19:49:00] oh man [19:49:54] and they just forgot that moon rocks have mass [19:50:03] which might be in the LM on ascent :D [19:51:00] although I wouldn't call 21kg "a significant update" [19:52:15] what's a few rocks between friends :D [19:52:35] all of the people in the loop sound like they are doing this moon landing thing for the first [19:52:37] time [19:53:08] I bet Apollo 17 went a lot smoother :D [19:53:45] probably yeah, haha [20:33:41] night! [14:47:46] hey [14:55:59] hey Niklas [15:00:20] I have to test some more, but the new DOI calculation seems to work fine for both DOI types [15:01:07] the old "DOI from LPO" only worked properly from a circular orbit, and the "DOI as LOI-2" only ever had issues because the orbit wasn't shaped correct by LOI [15:01:27] so there will be no distinction between those, same calculation [15:02:59] just as a Tindallgram had claimed [15:04:48] I guess it was always supposed to work from a fairly elliptical orbit, even before they thought of doing DOI as a LOI-2 replacement [15:06:34] so it will be one mod for both of them? [15:06:38] mode* [15:07:38] yep [15:07:47] LDPP mode 4, DOI only [15:08:15] the only other modes working right now are mode 7, CSM prelaunch plane change [15:08:24] and mode 1, sequence 2 [15:08:29] CIRC + DOI [15:08:32] that's for LOI-2 [15:08:40] always calculates DOI as well [15:09:55] the descent planning is also the main tool to simulate powered descents [15:10:07] but I haven't implemented that yet, should be easy though [15:10:21] so there is a mode for just PDI [15:10:41] and for all most other modes there is an option to also simulate a PDI in addition to calculating maneuvers [15:10:47] most* [15:11:35] oh, you can help me play the "what does each value mean" guessing game [15:11:37] https://i.imgur.com/iZaR7a6.png [15:11:48] this is the RTACF LM Descent Planning display [15:12:01] only thing I have [15:12:18] probably a little different from the RTCC and sometimes there are some errors in this [15:12:27] but it should be fairly close to the RTCC one [15:12:40] there are a few abbreviations there that I haven't figured out yet [15:13:06] like [15:13:10] "SN. LK. A" [15:13:11] ??? [15:16:09] hmm good question [15:17:11] AC/HPC probably should read HAC/HPC [15:17:19] apolune and perilune, at cutoff [15:17:25] DEL/THPC, no idea [15:48:33] gotta go! cya [16:46:58] morning! [16:48:39] hey Mike [16:49:12] what's up? [16:49:40] almost done with the not-so-fun work of merging the old calculation pages into the descent planning [16:49:46] LOI-2 gone, plane change gone [16:49:52] DOI only page gone [16:50:13] nice! [16:50:33] LOI-2 was on the LOI page, so I am minus 2, and then plus 3 pages in the MFD [16:51:25] always quite annoying to change many MFD displays at once [16:53:58] yeah I can imagine [16:54:36] good evening [17:02:38] morning! [17:04:16] SSU wants to use a sound from NASSP, circuit breaker opening/closing [17:04:32] Any idea if there is any issues with that? Licence, crediting etc.? [17:07:34] if it was some code it would be easy, but I have no idea if the same applies to sound files [17:11:51] uhhh [17:12:23] is NASSP GPL? [17:12:31] I think the sound files are probably covered by that as well [17:14:09] both are GPL2 [17:14:59] how do you give credit with a sound file though? Do you have to? Should you? [17:15:28] if I was to take some piece of code from SSU I would probably put something in the header file, that it is from SSU [17:18:55] uhh [17:25:41] yeah I'm not sure [17:25:55] maybe an external copy of the NASSP license with a note saying which sound files are covered? [17:28:53] NASSP license sounds redundant, as SSU has the exact same license [17:29:42] I'm pretty sure that's how I've seen stuff like this done [17:29:48] hmm, ok [17:29:50] but beyond this, this is a question for stack overflow :P [17:30:04] I think I'll ask Daniel, I'll let him decide :D [17:30:19] that works too [17:31:55] so good news on the Luminary 178 front [17:32:04] I found another difference in ASCENT GUIDANCE last night [17:32:35] turns out the constant 40FPS was originally in bank 5 [17:33:08] I've been super worried about bank 5 because it has the ephemeris constants in it, as well as the downlink lists [17:33:19] things that could feasibly be wrong with no way of knowing [17:33:43] and I've been over everything in the bank multiple times but it still had a big error in the checksum [17:34:00] but moving 40FPS to bank 5 not only almost entirely fixed bank 5, but it also made another bank correct [17:34:05] so I have five banksums matching now :D [17:34:13] nice [17:34:24] I would have been surprised if we had the ephemeris constants wrong [17:34:34] well [17:34:43] I wouldn't have been, haha [17:34:49] I think the Apollo 11 issue with those only happened that one time [17:34:55] because our only source for them is Zerlina [17:35:04] which started before these constants were added [17:35:29] wasn't there a memo that also had those? [17:35:37] not that I'm aware of [17:35:41] at least not that we have [17:35:50] I think I thought that, but it didn't turn out to be true [17:35:59] when I searched for it [17:36:20] But then I am not sure what I used for the modified Luminary 210 [17:37:23] another concern I had was that they were off by 2 in one of the numbers used to derive the calculations [17:37:40] well, first concern was that Don may have made a typo in adding them to Zerlina, which happened in a few places that I've found [17:37:48] second concern was the off by 2 in the precursor number [17:37:55] so I was wondering whether Don had fixed that [17:38:06] they never did for mainstream Luminary because they just moved to the next set of numbers [17:38:14] next year set, that is [17:38:56] https://www.ibiblio.org/apollo/Documents/LUM119_text.pdf [17:40:12] that doesn't cover the stars or the effects of http://www.ibiblio.org/apollo/Documents/LUM169-HM_text.pdf [17:41:17] right [17:41:27] I think we took the stars directly from Zerlina [17:43:56] listened a bit more to the FIDO loop, there was some "serious talk" from the flight director to his main flight controllers, off the FD loop [17:44:17] on the Assistant FD conference loop instead [17:44:32] he complained about too many people being in the room :D [17:45:31] "We have 97 people in the room and we have some comm checks coming up" if those people are all listening in that apparently would cause problems [17:45:43] I guess he didn't want to say that directly to all those people [17:46:57] haha [17:47:43] what we can hear on the FIDO loop, and it will probably be the same for most others, is the FIDO and then everything he hears [17:47:57] so if the turns up the volume on what the astronauts say, we can hear that [17:48:13] definitely useful to follow conversations [17:48:18] but veeery confusing at first [17:48:30] you can hear RETRO and GUIDO faintly in the background all the time [17:48:46] so it was difficult to tell at first who is talking to whom [17:51:42] oh interesting [17:53:28] must also be something with the way it gets recorded [17:53:36] when e.g. RETRO wants to talk to FIDO [17:53:42] they sit exactly next to each other [17:54:00] then I can first hear very quietly "RETRO, FIDO" and then the same again at normal volume [17:55:23] hmm, I think this is not correct on the Apollo 11 in Real Time website [17:55:24] COMPUTER SUPPORT: Apollo Guidance Computer Support - Often pronounced 'computer soup [17:55:45] that's the callsign of the person in control of the RTCC computers [17:55:56] have to get that correct some time, hehe [17:56:44] on that loop it will be mostly stuff about operating the computers, not really about using it [17:56:59] So not super interesting for me, but I'll have to give that loop a listen as well [17:57:14] I need to listen to some of these loops at some point [17:58:13] haven't listened much beyond a few I wasn interested in [17:58:24] not sure if there is one e.g. covering the 1202 alarms [17:59:17] not sure what we could get from that other than how wrong they are about what's happening :D [17:59:36] but it would be interesting to hear [18:01:26] they are still mostly busy figuring out where the LM actually is [18:02:20] right [18:02:20] well, the main flight controllers are [18:02:44] there is SPAN audio [18:02:50] Spacecraft Analysis Room [18:02:57] that would be the best for Apollo 13 [18:03:05] and might also have some good stuff for 11 [18:03:12] they would do a bunch of this analysis there [18:03:30] that other people can't deal with, as they are working on real-time issues [18:04:37] a bit boring right now, they are just listening in to the FD loop [18:27:39] FIDO is confused again, don't think the LOI processor is all that useful a few hours after the lunar landing [18:27:55] he meant the LDPP [18:30:42] good for me, another confirmation of the plane change inputs [18:36:13] :D [18:42:34] so looking over the Luminary 178 banksums right now [18:43:11] I think I feasibly only have significant code errors in banks 10, 11, 21, 33, and 43 [18:43:16] the rest of the banks are probably correct :) [18:46:11] that's not that many [19:54:05] yeah I'm feeling pretty good about it [19:54:11] SERVICER is the next log section to do [19:54:21] and it's going to be a massive pain [19:54:34] but hopefully the flowcharts will be able to resolve all of the ambiguities [19:56:27] yeah, servicer is always the big one [19:56:56] it's the "dump everything for the descent in it that doesn't fit elsewhere" section [19:57:28] haha [19:57:34] yeah [19:57:36] lots and lots of changes [20:21:34] and Zerlina is almost useless for telling which ones came before 178 and which came after :D [20:31:05] it sure is [20:37:50] night! [18:08:33] morning! [18:11:39] keyboard broken, how does that even happen. brb [18:13:15] hahaha [18:13:17] now it's fine, but it was just randomly not working, lol [18:13:30] mouse was fine. Did restart all is fine again [18:13:46] weird [18:14:30] I don't think I've ever had that happen, haha [18:14:42] I have all kinds of weird Windows issues lately [18:14:46] have to do a reinstall soon [18:15:18] So I did more test cases with the LDPP, CSM DOI does not converge properly without a fix. [18:15:24] Because it's 11 orbits between DOI and PDI [18:15:32] and nonspherical gravity at work [18:15:45] that is definitely not considered in these early 1968 equations [18:16:00] I hope that's the kind of thing that is fixed in the updated pages [18:16:24] hmm [18:16:31] at least I could fix this one [18:16:32] that would be nice [18:17:29] you can definitely see if one of these equation documents is very new or quite mature [18:17:44] the Apollo 14 moon-centered return-to-Earth equations that I implemented [18:17:58] the documents has some errors, but it doesn't have these kind of problems [18:18:22] and considers some weird edge cases which you would only find after lots of testing [18:18:27] or flying a few missions with it already [18:19:12] that's why I always say everything up to early 1968 is not very useful [18:19:28] because it has these kind of issues [18:19:36] right [18:19:45] looks nice on paper, but in reality (or at least put to a real test) there are obvious issues [18:20:09] mid 1968 documents are good enough to apply to Apollo 8 [18:20:17] everything later is usually very good [18:22:14] the result I get with the LDPP in an Apollo 14 scenario is quite different from what was actually done for DOI in that scenario [18:22:28] guess I have to coast along in these 11 orbits to find out if it's good or not... [18:23:20] when are you going to get the update from Ron? [18:23:23] is it this week or next week? [18:23:47] "I've tentatively scheduled it for the 25th or 26th." [18:23:59] so a bit to wait [18:24:27] but what I have seems quite good, at least the three modes that are often used (DOI, LOI-2 and plane change) are working [18:24:37] so I can get that part done [18:24:55] the other modes are mainly for the case where you end up in a wrong orbit after LOI-1 [18:25:32] and there are the two mission modes that the update adds [18:25:36] two missing* [18:25:45] definitely want to know about those [18:26:08] I can't imagine that they could have added those without major changes to the full program flow [18:26:22] which is good, that means they had to update many pages with, hopefully, many fixes [18:26:31] hehehe [18:28:58] in general the new DOI targeting accounts better for nonspherical gravity [18:29:11] at least the DV calculation, the TIG iteration was the issue I had [18:29:35] I guess right now we get PDI at an altitude 900 meters too low [18:29:50] that doesn't sound tooo bad [18:29:54] so maybe 47500 feet instead of 50000 [18:29:59] yeah, not that bad [18:30:49] it's not like the Earth, where the initial circular orbit of 100x100 NM quickly becomes more like 100x108 [18:31:01] 8NM is a bit more :D [18:31:15] haha yeah [18:33:35] so I made a couple of changes to MOONSPOT in SERVICER [18:33:47] but it's looking like it really didn't change much between 178 and 210 [18:38:07] what does MOONSPOT do? [18:40:58] it's part of the mass monitor, I think [18:43:35] oh, is it the special P63 Average G? [18:45:25] part of it I guess [18:45:29] mmm [18:45:43] MOONSPOT is the point MASSMON branches to if the LM is on the surface [18:45:56] oh, if it IS on the surface [18:45:57] not before [18:46:00] right [18:47:41] I see no equivalent of that in the GSOP [18:47:47] so I don't know about it :D [18:48:34] hehehe [19:03:21] well if it's just a mass update, or lack of it, then I am not surprised it didn't change much [05:28:36] whoa, huge breakthrough on Luminary 178 [05:28:51] it turns out I've been using the Zerlina version of LANDING ANALOG DISPLAYS this whole time [05:29:02] which has less code because Don did some computations elsewhere [05:29:34] I pulled in the Luminary 210 version, and then added in a check that had been removed in Luminary 196 [05:29:43] and I had five banks get the right checksums at the same time! [05:30:26] so I'm up to 10 banks with the right checksums with my current build, and only 3 banks that I can definitively say still have code errors in them (10, 11, and 43) [14:45:35] hey [14:55:09] hey Alex [14:59:47] whats up? [15:00:04] more finishing touches for the LDPP [15:00:22] nice [15:00:45] I discovered one issue, which was easy to fix, but it means that the LDPP equations from the document alone won't work right for the CSM DOI [15:00:54] specifically, the 11 orbits between DOI and PDI [15:01:12] too much nonspherical gravity happening there [15:01:34] guess they didn't really think of that case yet in early 1968 [15:02:13] but it still is one function that finds the TIG for both types of DOI [15:02:36] ah I see [15:02:56] I guess Ron will scan some documents that might shed some light on that? [15:03:02] yeah [15:03:11] if they can locate it [15:03:24] it's a rare case where the update sheets have been separated from the main document [15:03:34] otherwise he would have already scanned it [15:04:24] the title page of the updated pages has its own department internal memo number [15:04:30] that helps finding it I guess [15:05:03] the only remaining issue I have to solved is cases where the old DOI targeting gets used [15:05:11] I put it in the non-free return TLMCC targeting [15:05:21] for the display on that page [15:05:28] so that you can get the orbit right [15:05:48] but I will work on that next, so that the TLMCC targeting for that already sets everything up [15:06:21] so maybe I will remove that for now [15:06:38] sure [15:06:49] with the MPT you can still try to get the orbits right [15:06:59] just a bit more annoying, switching between pages etc. [15:07:13] yeah [15:08:21] so there is the full equations for the non-free TLMCC targeting? [15:08:57] pretty much [15:09:02] it's two separate documents for that [15:09:15] the overall flow is something I had requested Ron to scan the previous time [15:09:29] https://archive.org/details/70FM14Images/ [15:09:42] the more detailed equations he scanned this time around [15:09:50] https://archive.org/details/70fm26images [15:10:30] specifically the subroutine PRCOMP [15:10:31] https://archive.org/details/70fm26images/page/n49 [15:11:21] there even is a change to that subroutine, from November 1971 [15:11:36] so we definitely have the latest, or rather last state of that subroutine [15:12:45] hmm [15:12:54] I remember you spoke of some sort of polynomial that optimizes the TEC transfer time or something like that [15:13:00] TLC* [15:14:10] yeah, there is something to calculate the optimal translunar flight time [15:14:18] used in the initial guess [15:14:26] so that it converges faster [15:14:27] or at all [15:14:58] for different modes there are also different initial guesses for the velocity at pericynthion [15:15:12] that is probably for the large flyby altitudes used by Apollo 12 and 14 [15:15:24] which the TLMCC has some problems calculating [15:16:13] right [15:16:31] that polynomial is why it is good to have multiple versions of the same document [15:16:47] the numbers for it are only found in the TLMCC document from mid 1968 [15:16:53] not in the later versions of it [15:19:25] the initial guess for the "new" non-free targeting also uses the nominal longitude at pericynthion [15:19:48] that might help with the iteration as well [15:20:20] for the free returns that is usually close to 180°, but not for non-free return trajectories [15:24:24] hmm, I would have to make many changes to the TLMCC targeting if I get rid of the old DOI targeting [15:24:48] so for now I'll put a button on the TLMCC page to switch between the two DOI options and keep it as it works right now [15:29:40] makes sense [15:33:31] hmm, ok, still have to solve the issue of calculating a new landing time [15:33:38] that was an output from the old DOI targeting [15:33:44] and could then be uplinked [15:34:30] probably just less accurate now [15:34:41] oh, from the display, "SN. LK. A" [15:34:47] LK A. might be look angle? [15:34:56] but what is SN. then [15:36:02] I also wonder if there is any crossrange display there... [15:59:16] AlexB_88, do you prefer to have a TLAND uplink button on the descent planning page? I can add another MCC display just for that purpose [15:59:22] seems like they had one just for the TLAND [15:59:53] then you could also have a look at the octals first, like the other pages [16:00:04] would that be in the uplinks section? [16:00:25] yes [16:00:32] I think its best juts to have it there [16:00:39] just* [16:00:42] sure [16:17:44] MFD display formatting is such tedious work :D [16:30:04] I bet it is [16:51:51] running a few test cases. For our Apollo 11 scenarios, if I want to correct the orbital plane some time before DOI, then it costs 1.8 ft/s. If I insist on getting back to the nominal approach azimuth (-91°) then it's 2.8 ft/s [16:52:17] that's one of the options, to choose between specified or optimal azimuth [16:52:27] optimal as in, changing it as little as possible [16:55:07] no point in using the specified azimuth option for the post landing plane change maneuvers of course. No reason to have a specific azimuth for those. [16:59:36] morning! [16:59:46] hey Mike [16:59:54] congrats on getting so many banksums right [17:00:23] thanks! [17:00:38] I'm feeling pretty good about 178 :D [17:01:29] I have been waiting for the change that finally makes multiple banks go at once, haha [17:02:41] yeah [17:07:34] first thing on the list for today is P51-P53 [17:07:48] which had a good deal of changes, and I've made no changes from what Zerlina has so far [17:08:54] hmm [17:12:32] P57 had changes between Apollo 13 and 14, and P51/52 between 14 and 15 I would have thought [17:12:54] so P51 and P52 should be very similar between Luminary 131 and 178 [17:12:58] as far as I can see [17:16:16] we shall see :D [17:16:56] a lot of the changes I'm seeing in here are moving bits and pieces between different banks, which wouldn't show up for you [17:17:38] yeah [17:18:04] the code for MATMOVE was even rearranged [17:18:06] for some reason [17:18:23] didn't change, they just moved the whole subroutine much earlier in the log section [17:19:01] ...or at least i don't think it changed, I guess I should check that [17:23:18] of course, no mention of this in the luminary memos, ugh [17:35:32] ooooh I'm on to a different subroutine now [17:35:34] LEMP50S [17:35:47] Don made no changes between Luminary and Zerlina here :) [17:36:16] the asterisks can tell me which rivision of Luminary this is from then... [17:37:28] yeah, why would Don do changes there :D [17:43:47] I don't know, haha [17:44:17] he did move some non-Zerlina-related code around to make room for the variable servicer and P66 LPD [17:47:00] hmm [17:47:10] so Luminary 131 had revision 119 of LEMP50s [17:47:15] Zerlina has 126 [17:47:20] 210 has 130 [17:50:22] oh [17:50:30] is all or most of P57 in there as well? [17:50:40] P57 changed a lot between Apollo 13 and 14 [17:50:50] I don't see any asterisks in Zerlina. they must have only deleted things between LEMP50S 125 and 126 [17:51:20] looks like it is, yeah [17:56:47] okay, based on asterisks in 210, there were no changes between Luminary 192 and Luminary 210 [18:00:30] and Don didn't explicitly specify a version of LEMP50S so revision 126 is likely current as of October 21, 1970 [18:01:13] which falls between the Luminary memos for rev 183 and rev 184, so that's consistent [18:18:23] and then the section was "rewritten" in Luminary 186 [18:18:26] which isn't helpful :P [18:22:12] yes, rewritten, very descriptive [18:22:44] it's PCR 1044, which we have [18:22:48] but also isn't too helpful [18:22:50] haha [18:24:14] yeah, that's the big change between 1D and 1E [18:24:43] for 1D there was PCR 982 [18:24:57] Extend Capability of Lunar Surface Star Acquisition Routine R59 [18:27:37] that went into Luminary 144-147 [18:27:46] er, not even [18:27:57] 140-143 [18:28:20] extended capability and made the coding for R59 a good bit shorter [18:28:22] win-win :D [18:28:39] haha, yeah [18:28:50] that's always going to get approval [18:29:45] alright well [18:30:31] I'm pretty satisfied that the change between 178 and 183/Zerlina is only the removal of SPIRAL, CURSOR, and POSCODE erasable definitions [18:33:31] doesn't sound so difficult [18:34:37] this is probably why the moving of MATMOVE and things don't show up in the memos [18:34:42] because they just fall under "rewritten" [19:01:38] indy91, so will the DOI as LOI-2 case work but be slightly inaccurate over long periods from DOI to PDI as you said? [19:02:24] I'm not quite sure yet [19:02:43] the downrange position at perilune was off by about 20-30 seconds [19:03:05] but that probably just means, that PDI doesn't happen exactly at perilune, but 20-30 seconds earlier/later [19:03:19] right [19:03:20] no big issue really [19:03:53] the updated equations might have something on that as well [19:04:21] yeah [19:04:48] I first had some code in there that forces it to perilune [19:04:55] that's how I know how much it was off [19:05:05] but that wasn't the cause of the iteration issue there [19:05:26] that was something different, also due to the many orbits with nonspherical gravity [19:07:50] for my Apollo 14 test I have DOI that's a bit different [19:08:02] I'll implement that code again that forces it to perilune [19:08:08] just to see what it does to the TIG [19:08:38] oh remember the equations which I had problems with earlier? Where I suspected an error? [19:09:34] my "solution" worked fine for Apollo 11 [19:09:41] azimuth close to 270°, inclination low [19:09:59] but it was very, very off for the Apollo 14 LOPC [19:10:23] so the "fix" I had there was not right [19:10:50] instead I am now using an entirely different solution to build the target state vector that flies over the landing site [19:10:54] which seems to work fine now [19:11:32] I commented the old equations. If the updated document has something better I'll use that method again [19:17:10] ok [19:18:01] so the LOPC function in the LDPP will be the correct one to use for the LOPC-1 and LOPC-2É [19:18:08] ?* [19:18:20] hmm [19:18:24] two LOPCs, right [19:18:36] which missions had 2? [19:19:03] I've rarely/never flown the later missions that far :D [19:20:55] or I mean, the LOPC to align the CSM's plane with the landing site before liftoff [19:21:06] they would of used the LDPP for that? [19:21:24] yep [19:21:32] Mode 7 of it [19:21:39] PPC, prelaunch plane change [19:21:48] there are some other modes with plane changes [19:21:55] but they would all be before the landing [19:22:21] Apollo 16 had a LOPC-2 after LM jettison [19:22:27] or, at least they had it planned [19:22:40] "to increase lunar surface photography coverage" [19:22:52] hmm [19:23:04] I guess you have to change the landing site coordinates for that [19:23:13] if they had a specific target in mind [19:23:22] then yes, it would work for LOPC-2 [19:24:29] about this photo coverage LOPC [19:24:41] there are some equations for that in the TLMCC documents actually [19:24:46] for the full mission optimization [19:25:38] and there you have to specify coordinates and approach azimuth for a photo site [19:26:49] if we find those numbers then the LDPP is the ideal tool to calculate that LOPC [19:31:36] hmm [19:31:48] the SCOT has that LOPC-2 at 0° latitude [19:32:06] so that would rather sound like the general purpose maneuver processor to me [19:32:11] equatorial crossing, 3° plane change [19:36:30] Apollo 12 LOPC-2 is not at equatorial crossing [19:46:37] Apollo 12 and 13 SCOTs each have coordinates for photo sites [19:46:46] those could be used [19:50:43] a I hadnt seen those [19:51:19] previously I would just use the post-burn inclination from SCOT for targeting LOPC-2 [19:52:34] so as far as I can see Apollo 12, 13 and 16 did LOPC-2 [19:52:53] for 12 and 13 I would use the LDPP from now on, with coordinates of those photo sites [19:53:12] Apollo 16 looks more like a GPM processor thing [19:57:08] but not possible to verify that from flight data [19:57:33] right [19:57:34] because they didn't do a LOPC-2, instead they returned home 24h earlier than planned [19:58:00] LM jettison, subsatellite launch and TEI in fairly quick succession [19:58:25] so [19:58:36] I guess Apollo 12 had the only LOPC-2 that was ever actually done :D [20:10:31] I didnt do a LOPC-2 either on 16, not for the same reason though. I had not enough DV available [20:10:54] Ill be back in a bit [20:20:23] ! [20:20:32] I may have just found the bank 11 difference [20:21:06] I added in a line that may or may not have been in Luminary 178, and the bank 11 checksum went from very wrong to exactly correct [20:21:12] haha [20:21:27] nice job [20:22:11] ah yeah, it very likely was in Luminary 178 [20:22:16] it's a STORE RQVV [20:22:41] RQVV was deleted in Luminary 179, "along with obsolete references" to it [20:22:55] because it was unused [20:23:07] it looks like it's already unused in Luminary 131, but that still has the STORE RQVV [20:23:23] it's still in Luminary 210 [20:23:28] but only in the comments, haha [20:23:34] lazy programmers! [20:23:40] hehehe [20:23:59] wow [20:24:08] even in Luminary 69 it's stored but not used [20:24:15] it must have been for something in Sundance at some point [20:24:45] RQVV POSITION VECTOR OF VEHICLE WITH RESPECT TO SECONDARY BODY [20:25:15] something like that is definitely used in the cislunar orbital integration, but maybe not that specific variable [20:25:45] it's also stored into VECTAB +6,2 [20:26:04] so that is probably what gets used [20:27:24] it seems to be used in Colossus 249 and earlier [20:27:36] R23 [20:28:33] aha, nice find [20:28:39] so it probably is in Sundance :) [20:38:49] good night! [23:39:38] !!!! another huger breakthrough [23:39:52] very similar to the RQVV thing [23:40:14] deleted at the same time as RQVV was R1SAVE [23:40:45] there was a bunch of code in Luminary 131 that used R1SAVE and it was all gone in Zerlina [23:41:10] I just tried putting all of it back, and it caused 14 banks get the right checksums (!!!) [23:41:25] so now I have 25 right, and only 11 wrong [23:41:33] and the only obvious code error is in bank 43 [23:45:00] nice :) [14:00:32] hey [14:00:45] hey Alex [14:30:32] just realised eaglelander3d is now free, just downloaded it [14:30:53] its a bit buggy though, very old indeed [14:37:36] oh right [14:37:53] a free old version, and a new VR version? Something like that... [14:38:43] yeah [14:39:20] one thing I noticed is that the range rate tape meter moves in the opposite direction that ours does [14:40:38] I was thinking, nope thats inaccurate [14:40:52] but then later I was thinking, what if we got it wrong :D [14:41:01] certainly possible [14:42:15] black is positive, white is negative [14:42:20] black is up, white is down [14:42:36] or rather above and below [14:43:28] right [14:43:39] and that is what is more natural to me [14:43:44] is that from the AOH? [14:44:10] yeah [14:45:14] so, I guess we got it right? :D [14:46:03] I guess, if the book says so [14:46:41] yeah, there are a bunch of diagrams in the AOH with the tape meter [15:18:36] with this slow progress I have been making with the LDPP I can almost just wait for if/when the updates pages become available [15:19:07] but I have almost no issues to solve anymore [15:19:20] there is still the Apollo 17 case, where PDI isn't at perilune [15:19:35] that's not properly handled yet for e.g. the TLAND update in the MFD [15:19:57] at least not in the LDPP. The solution for it in the old DOI targeting wasn't really good, but good enough [15:45:16] right [15:46:00] oh and I guess choosing the peri height will still be an option? [15:46:30] yeah [15:47:09] two separate height options in the LDPP, one for the circular orbit (so usually 60NM) and the other the descent orbit perilune height [15:47:37] so basically as we had it, just with LOI-2 and DOI in one processor [15:50:48] there is two input pages [15:51:07] split up like the manual entry devices, K16 and K17 [15:51:28] one is for rarely changed parameter, LDPP Initialization, and the other is for the more often used inputs, LDPP Computation [15:53:37] here, from the RTCC Support Plan document: https://i.imgur.com/uC8Ojan.png [15:53:46] it's 1:1 this [15:53:48] well [15:53:49] almost [15:54:11] some processors take its state vector from the main ephemeris [15:54:22] but others like the LDPP want a vector ID input [15:54:30] which is not implemented in the RTCC MFD [15:55:04] I guess this is for the case where you e.g. want to run the LDPP's PDI simulation with the onboard state vector [15:55:12] instead of the latest best from tracking [16:29:58] gotta go! cya [16:46:45] morning! [18:02:45] Hey [18:02:49] yo [18:03:16] indy91: Figured out that GPL issue with SSU yet? [18:04:20] Hey Mike, what's up? [18:05:11] I am aggravatingly close to having Luminary 178 worked out [18:05:18] Awesome [18:05:38] only 8 banks left with wrong bugger words [18:06:00] but they're all so close to correct that I don't have a clear thing to try to fix [18:06:10] I'm thinking it might be a misplaced erasable [18:48:35] hey guys [18:48:51] Thymo, yeah, I asked dseagrav and he said simply crediting NASSP should be enough [18:54:34] Did my last message go through? [18:55:11] Looks like it didn't [18:55:12] It's interesting to apply the GPL to a sound file though. Since one could stipulate that a wav file technically is the binary and not the source code. And as the GPL requires you to distribute the source code we would technically have to distribute the files used to mix that effect in the first place. [18:56:04] yeah, didn't come through [18:56:26] I really need to setup another AP upstairs [18:56:28] that would be basically impossible to track down now, haha [18:56:45] Or figure out a way to fix my thinkpad's bloody WiFi antenna [18:59:19] what happens if the source code of an open source project is lost [18:59:34] can you not distribute the binary files anymore? [18:59:45] well [18:59:50] depends on the license I guess [19:00:47] You'd be in violation of the license [19:00:49] I think [19:02:15] You're not [19:02:32] If you own the code, you can do whatever you want. [19:04:17] But I don't think if you have a derived work you can't redistribute it legally anymore [20:21:35] night! [06:13:18] I just found one of the problems with my erasable definitions! [06:13:24] that fixed four of the eight bad banks [06:13:29] this is all that's left: [06:13:42] Bugger word mismatch in bank 01; actual 40223 != expected 40225 (diff = 00002) [06:13:42] Bugger word mismatch in bank 31; actual 62503 != expected 62504 (diff = 00001) [06:13:43] Bugger word mismatch in bank 32; actual 67520 != expected 67523 (diff = 00003) [06:13:43] Bugger word mismatch in bank 33; actual 51154 != expected 51327 (diff = 00153) [06:14:51] most of the error is in bank 33, which is almost entirely used by the servicer [06:14:58] so I probably have an error in some servicer erasable [07:40:07] down to two banks! found a dumb error I made in erasable [07:40:34] Bugger word mismatch in bank 01; actual 40223 != expected 40225 (diff = 00002) [07:40:35] Bugger word mismatch in bank 33; actual 51154 != expected 51327 (diff = 00153) [07:41:53] but now it's looking like that bank 33 might be a code error... bank 1 can become correct if I delete 2 words from UPDATCHK to REREPOS in the SERVICER section [07:51:02] SUCCESS! I hadn't deleted an INHINT/RELINT [07:51:07] I have Luminary 178!!! [16:50:43] morning! [16:56:20] indy91: https://drive.google.com/open?id=1OWo2WV4gnBVN0skGHb2BQteVHh9XfE5A [16:56:25] this could use some testing :D [16:56:32] I'm pretty confident that it's right, though [16:56:36] haha [16:56:37] nice [16:56:49] I'm behind in testing LGC versions coming from you... [16:56:58] haha [16:57:16] so tell me [16:57:19] https://github.com/virtualagc/virtualagc/blob/luminary178/Luminary178/ERASABLE_ASSIGNMENTS.agc [16:57:25] there are no addresses there [16:57:35] which would be very helpful with developing the padload worksheet [16:58:03] anything better I can look at? [16:58:09] do you need more than http://www.ibiblio.org/apollo/Documents/apollo14_preliminary_padloads.pdf ? [16:58:20] ah right [16:58:23] if you want something searchable... one sec [16:58:24] I forgot about those [16:58:39] is that definitely the final Luminary 178? [16:58:50] the padload addresses I mean [16:58:56] yes, the addresses in that are final [16:59:02] ah [16:59:03] great [16:59:06] I forgot we had that [16:59:12] that will be enough [16:59:16] we didn't until Don scanned it just recently :D [16:59:38] yeah, now I remember that [16:59:42] great [16:59:52] it was very very helpful in sorting out the erasables, heh [17:00:02] I really can't believe you have done this [17:00:10] Didn't think it was really possible [17:00:22] honestly, I can't really believe that it actually came together either [17:00:40] I barely slept last night because I was so excited, haha [17:00:45] https://drive.google.com/open?id=1BRwIo4vQZbULO8lVB16V2du46vXSKtyQ [17:00:51] here's the .lst file from my last assembly [17:01:01] you should be able to search for addresses in there [17:01:45] thanks [17:01:51] I really only need the padload addresses [17:02:20] :D [17:02:58] so tonight I'm going to work on cleaning this up -- getting comments in order, the ASSEMBLY AND OPERATION log section corrected, etc. [17:03:13] and as we found out the descent target stuff had been reorganized before 1D [17:03:14] but I'm going to work on validating it by pushing backwards to Luminary 173, and then 163 [17:03:20] yep [17:03:27] so I started with the 1E padload worksheet [17:03:30] instead of 1C [17:03:46] I think overall the padload situation is much closer to 1E [17:04:07] and most values are already in there, as we had already one for Apollo 14 [17:04:09] so that sounds like the right call :) [17:04:14] so this shouldn't take that long [17:06:03] AZO already fixed memory in 1D, that also makes things nicer [17:06:40] and REFSMMAT starts at EMEM1731 [17:06:53] so probably no RTCC changes, yay [17:09:16] yeah, almost no changes so far and I am halfway through [17:09:20] only deleted two things [17:15:25] I have basically only one real change [17:15:28] LRWH1 moved [17:15:47] and I deleted N26/PRI and N26/2CAD [17:15:53] which don't exist in 1D I guess [17:16:39] yep [17:18:59] very simple [17:21:52] :D [17:23:04] this is probably optimistic [17:23:13] I move that one padload in a Apollo 14 pre PDI scenario [17:23:20] make it use Luminary 178 [17:23:28] hahahaha oh boy [17:23:51] yeah [17:23:52] while the padloads didn't shift a lot between 1D and 1E, the other erasables moved a *lot* [17:23:54] program alarm [17:23:56] so you'll have to do a fresh start [17:23:58] guaranteed [17:24:04] 31203 [17:24:12] ooo, that's a fun one [17:24:18] too many waitlist tasks :) [17:24:44] and orbital integration is a bit in trouble [17:24:50] hmm [17:24:52] it finished [17:25:28] state vectors didn't move, so V82 is good [17:25:40] P63 ignition algorithm is calculating [17:25:46] and it passed [17:26:03] no, I don't want to do an alignment :D [17:26:12] didn't miss that from 1D and before [17:26:45] hahaha [17:32:18] so far so good, before ignition [17:32:34] haha I'm kind of amazed [17:33:35] yeah, me as well [17:34:55] maybe that 1203 got everything that moved sorted out [17:35:38] I only tried this because I had to move one single thing only in the erasable [17:35:48] and everything padloaded and uplinked is in the same place [17:36:08] yeah but there are entire chunks of erasables that shifted by one or two addresses in 1E [17:36:14] the padloads moved much less than everything else did :P [17:36:48] erasable layout was one of the biggest changes from 1D to 1E from an implementation point of view, haha [17:38:37] most of that will be temporary erasable though [17:38:44] so in P00 it doesn't make much of a difference [17:38:49] fair enough [17:39:49] all good at throttle down [17:39:55] nice! [17:40:17] I first thought the DH didn't converge [17:40:22] but I looked at R1 of N68 [17:40:25] that is slant range [17:40:27] hehehe [17:40:28] R3 is DH... [17:46:31] hmm [17:46:33] not good [17:46:41] uh oh [17:46:49] what did it do? [17:47:04] landed too long [17:47:04] https://i.imgur.com/6wQJYin.png [17:47:12] terrible performance by the astronaut using the LPD :D [17:47:16] no, all was great :D [17:47:18] works perfectly [17:47:25] hahahaha awesome!! [17:47:38] :D [17:48:01] thanks for testing! :D [17:48:18] and it definitely wasn't Luminary210A14 by accident [17:48:28] the alignment option in P63 [17:48:47] the tape meter single precision issue thing was noticable [17:48:58] excellent [17:49:05] and I got confused how to use V57 and N68 [17:49:11] hehehe [17:49:17] all classic examples of pre Luminary 1D issues [17:49:19] 1E* [17:49:24] yep [17:49:46] well, except for the tape meter thing -- this has most of the analog display changes [17:49:54] hmm [17:50:02] at least you shouldn't have gotten the "lurch" [17:50:04] the altitude looked good [17:50:09] which confused me a bit [17:50:19] but the altitude rate definitely had a bit of back and forth [17:50:27] hm, weird [17:50:28] was there anything other the lurch? [17:50:48] maybe it was just confirmation bias [17:51:07] I'm trying to think if any calculations there changed... [17:52:24] hmmm [17:52:34] most of the fixes to calculations were for better accuracy in DVTOTAL [17:53:05] and what also confused me was that it took the DPS so long to get from 0% to 10%. I implemented that just before I started work on the LDPP, I've been at this for a while... [17:53:18] hahaha [17:54:06] interesting [17:54:19] I'm pretty sure nothing changed there [17:54:21] I definitely didn't seen an issue with the altitude [17:54:40] hmm [17:54:56] I'll do what you did with the demonstrations [17:55:36] tape meters are also driven during ascent [17:56:07] how often does the tape meter get updated? [17:56:15] did that change between 1D and 1E? [17:56:17] should be 4 times a second I think [17:56:33] I don't believe so [17:56:36] Zerlina has it faster? [17:56:53] I think they're the same [17:57:02] the code in Zerlina and 178/210 is very nearly identical [17:57:24] maybe what I saw was just a little bit of thruster oscillation or delay to send the commands vs. the tape meter [17:57:35] no lurch on the altitude rate during ascent just now [17:57:40] so maybe I didn't see anything really [17:58:27] hopefully throttle oscillation was also not much, because THROTLAG was fixed between 173 and 178 [17:59:14] just the usual we get [17:59:19] because we have 0 delay [17:59:24] right [17:59:30] instead of the 0.075s actual or whatever it is [17:59:50] you sure altitude rate gets updated 4 times per second? [17:59:53] altitude does [18:00:02] oh maybe not [18:00:06] I'm not completely sure [18:00:09] hmm [18:00:16] I think the altitude rate change was just very low [18:00:28] and one bit of change is still something noticable [18:00:50] https://www.ibiblio.org/apollo/Documents/Memo-Larson700807_text.pdf [18:00:51] so it didn't have to update 4 times per second [18:01:05] Tindall has answers :) [18:01:24] Update display of altitude and altitude-rate each 1/4 second instead of every 1/2 second as at present. [18:01:54] change from 1C to 1D? [18:02:11] yes, this was the main change between 173 and 178 [18:02:32] 173 -> 178 had the new THROTLAG, a fix for APS overburn, and the new analog displays [18:02:40] file:///home/mike/agc/luminary178/LUM167R1-BMc_PR_text.pdf [18:04:17] well on ascent it all looked fine [18:04:21] so I guess I just imagined it [18:04:26] all worked fine [18:04:33] sweet [18:04:37] P71 insertion apolune is correct [18:04:53] Luminary 178 is go [18:05:03] :D [18:05:21] next stop, 173 [18:05:28] haha, sure [18:05:34] and then Sundial E [18:05:36] and then Sundance [18:05:38] if I can undo the changes in that memo and end up with 173, that gives more confidence that 178 is correct [18:05:40] haha yeah [18:05:42] well [18:05:42] and then Skylark... [18:05:45] also Luminary 1C somewhere [18:05:48] right [18:05:53] I still need to finish that [18:06:08] Skylark we still need rope modules or a listing [18:06:17] I can go backwards in time, but not forwards :D [18:06:30] so unlike every other human being then [18:06:37] hahaha [18:07:15] I'll give Luminary 178 a better test after I implemented some new translunar midcourse correction things [18:07:39] that's a good test case for updated non-free return targeting, new DOI calculation etc. [18:07:45] Apollo 14 I mean [18:09:07] perfect [18:28:06] https://github.com/dseagrav/NASSP/commit/b5b5ac573e0cc0d8390d4d59da5662f6e07c2e25 [18:29:01] \o/ [18:29:24] and for the first time I think NASSP has a program available before VirtualAGC [18:29:28] :P [18:30:17] hmm [18:30:18] Sundial? [18:30:26] you gave me that very early :D [18:30:33] oh that's probably true, haha [18:31:13] so we now have an as-flown AGC version for Apollo 14 [18:31:22] we don't have one for Apollo 13 yet [18:31:30] and for Apollo 7 [18:31:30] 9 and 13 are the only two missing LM programs [18:31:32] but that's it [18:31:39] yeah [18:31:47] and 13 I'm still confident that we can remake [18:31:56] significantly less changed for it than did for 1D :) [18:32:13] good luck with Sundisk, lol :D [18:32:25] hahaha Sundisk we also need more info on [18:32:29] as difficult as Skylark [18:32:32] yeah [18:33:14] probably moreso, actually... we have the programmed guidance equations for Skylark 48 [18:33:31] how difficult would be Comanche 45? [18:34:48] more tricky, without development memos [18:35:05] but Don might have some stuff that could help with it [18:35:09] right [18:35:22] and 10 revision down from Apollo 11 can't be that difficult [18:35:35] yeah, in theory it might not be too bad [18:35:36] there are definitely no major changes [18:36:25] do we have a padload for 10? were there any address changes? [18:37:02] and it's 10 revisions but even that is overstating it [18:37:13] because everything from 51 to 55 was development of the R-2 potential model [18:37:23] so it's more like 6 revisions to figure out [18:38:24] I don't think we have a padload for Apollo 10 CMC [18:38:39] the alternate and contingency checklist would have one [18:38:43] just like for Apollo 11 [18:40:06] hmmm [18:40:08] that's unfortunate [20:39:08] night! [15:02:56] hey [15:04:24] hey Alex [15:05:41] Mike has successfully reconstructed Luminary 178! [15:06:02] nice! [15:06:12] is that what flew on 14É [15:06:17] yep [15:06:18] ?* [15:06:21] great [15:06:48] I should really set my keyboard to be English by default lol [15:07:04] I've tested it and it works great [15:07:09] padload change was minimal [15:07:20] will it work with existing Apollo 14 scenarios? [15:07:20] in old scenarios you basically only have to change one address [15:07:26] ah great [15:07:33] it gave me a 31203 alarm at startup [15:07:44] but after that it worked fine [15:08:22] that might only apply in P00 though [15:08:32] a lot of temporary erasable addresses have changed [15:08:41] so we have all LM software's that landed on the moon I guess [15:08:48] yeah [15:08:58] Luminary 131 never landed, so that is correct :D [15:09:26] he still has to reconstruct Luminary 131 Revision 1 [15:09:42] which I guess is possible? [15:10:02] yeah [15:10:07] even a bit easier than 178 [15:14:10] and I am on my final tests for the intial release of the LDPP [15:14:20] doing an Apollo 14 LOPC right now [15:15:35] cool [15:15:48] looking forward to giving it a try [15:18:57] most modes have a "N/A" in the MFD right now [15:19:13] but all modes are displayed, so you can already see what is going to come [15:20:32] ok [15:21:01] do you have that address that needs changing in luminary 178? [15:25:21] yes [15:25:30] find [15:25:33] EMEM1315 13146 [15:25:42] change that to [15:25:43] EMEM3756 13146 [15:25:49] that's it [15:29:17] thanks [15:30:27] LOPC was a success [15:32:43] great [15:33:05] I tested a Apollo 14 DOI [15:33:29] because the orbit after the maneuver now better accounts for non-spherical gravity it shifts PDI a bit [15:33:45] DOI had a 70 ft/s DVZ component and PDI was off by 2 minutes [15:34:00] but that just requires different targeting before LOI [15:34:08] which I will work on next [15:35:30] the DOI from LPO only changes slighty in DV, not in timing [15:38:23] it seems to pretty constant in my test cases that the non-spherical gravity has an effect of about 0.5NM in perilune altitude [15:38:56] so until now the perilune ended up being 0.5NM lower than the desired 50k feet [15:39:06] so about 3000 feet [15:41:18] and over 10-11 orbits that makes a difference in timing as well, which is one reason for the Apollo 14 DOI being different than before [15:49:14] right [15:51:11] those new TLMCC equations should do the trick [16:12:28] the LDPP is fully MPT compatible now, including calculating maneuvers for the LM with the MFD opened in the CSM [16:13:31] I'll have a think about what could possibly still be missing, then I'll push the update [16:16:30] just tried a landing with 178 [16:16:35] worked good [16:21:00] nice [16:21:09] I guess you also got the 31203 alarm at first [16:22:38] yeah [16:36:34] oh, have you made any progress with the SIM bay panel jettison panel yet? [16:37:21] I have pushed the LDPP update! [16:44:08] awesome [16:44:41] writing a post in the forum right now [16:44:49] a few things need explanation [16:45:33] about the SIM bay panel, I have much less time then I originally thought this month but I will see if later today I can start work on it... it shouldnt take too long to make I hope [16:45:41] sure [16:45:53] I have enough RTCC things to do :D [16:45:57] haha [17:04:52] ok, finished writing the post on the forum [17:06:21] morning! [17:10:21] hey [17:10:41] what's up? [17:14:18] Alex can also land with Luminary 178 [17:14:25] excellent! [17:14:29] and I released the first version of the LDPP [17:14:35] oh nice! [17:14:37] :D [17:14:50] not used yet by the MCC, still need to delete old LOI-2 and DOI targeting etc. [17:14:55] maybe after a bit more testing [17:15:44] the old DOI targeting is slightly incompatible with the new one, and the old one is used in the MCC processor, so that's the issue I need to address next [17:15:53] also with the help of the new RTCC documents [17:17:19] hmmm, so you have the document that should resolve that? [17:18:09] well, the MCC processor should do its own calculations, instead of using a full other processor for its internal DOI calculation [17:18:14] and yes, I have the document for that [17:19:48] a very large subroutine in one of the latest MSC memos Ron scanned [17:20:00] awesome [17:21:16] indy91, the new LDPP looks very nice [17:21:33] thanks [17:32:22] one thing I notice in 178 is that doing a V57 brings up N68 [17:33:08] during powered descent [17:33:26] yeah [17:33:33] it's the same as Apollo 12 and 13 [17:33:35] I think [17:33:41] V57E, gives 06 68 [17:33:47] the PRO to allow update [17:33:52] which makes it switch to 50 68 [17:34:04] verify there that DH is decreasing [17:34:10] then PRO again gets you back to 06 63 [17:34:44] so V57E, PRO, PRO is the procedure [17:34:58] yeah, all of that display logic is in Luminary 131 and was removed in Luminary 194 [17:35:36] and that is a perfect example of why Zerlina was an advanced development rope because it already had that change, despite it not going in until 194 :P [17:36:04] definitely prefer the Luminary 1E way [17:38:29] what about the 16 68 increased the load for Apollo 11? [17:38:49] Is it actually calculating additional numbers or is it just the display [17:39:38] just the updating of the display, I believe [17:39:58] probably this whole key release mode [17:40:01] I think any monitor verb would have the same computational impact [17:40:08] against any noun [17:40:16] right [17:40:34] so does the Apollo 12-14 way of doing this decrease the load? [17:40:54] hmm [17:41:01] maybe [17:41:06] where it kind of sequences from 06 63 to 06 68, then 50 68 then back to 06 63 [17:41:20] yeah, it might do [17:42:39] so that change was probably less of a user friendly change but more of load decrease [17:43:07] so that was added in for 12? [17:44:00] yeah, that was changed from 11 to 12 [17:44:45] 11 and 15-17 V57E simply allows LR updates [17:45:01] but 12-14 it caused this sequence of displays [17:45:57] hmm [17:45:59] revision 104 [17:46:14] "PCR 814 was implemented. (Reduce keystrokes required to check and approve LR data)" [17:47:03] ah [17:47:05] I got it wrong [17:47:09] for Apollo 11 [17:47:16] the memos don't mention load, only reducing keystrokes... but maybe the PCR does [17:47:37] or did I [17:47:59] no, V57E just permits LR updates [17:48:03] yeah [17:48:05] V16 N68 has to be done manually [17:48:10] yep [17:48:34] PCR 814 definitely doesn't reduce keystrokes to approve LR data then, haha [17:48:45] it reduces the keystrokes to monitor it I guess [17:49:28] at least the first time [17:49:41] when you have approved LR data and are back to 06 63 [17:50:00] then you probably would do V16 N68 [17:50:05] or maybe V57E again? [17:50:16] then you definitely would have to PRO twice on that [17:50:34] yeah, I always thought it was dumb in Luminary 99 that you had to do V16N68E to see your delta-H, and then V57E to permit updates takes you back to the 06 63 display [17:50:46] and then you have to do V16N68E again to actually see if your DH is decreasing [17:51:04] yeah [17:51:16] so, the change was an improvement [17:51:31] but still worse than the later solution to just put the DH on the main display in P63 [17:55:09] yep [17:55:55] I think Luminary 69 has it the same as 99 [17:56:02] just with more LR bugs in general [17:56:38] hehehe [17:57:02] I still haven't tried Verb 68 in Luminary 69 [17:57:08] VB68 START P64 IMMEDIATELY. [17:57:19] wait excuse me [17:57:20] should be fun if you do it real early [17:57:22] really? [17:57:28] that's crazy! hahahaha [17:58:08] the descent targets in P63 and P64 are chosen to ensure a smooth transition at the nominal switchover point [17:58:17] using verb 68 won't be very smooth then [17:58:22] oh man [17:58:26] I want to try that now [17:59:24] I can use the scenario I made for you for demonstrations, haha [18:00:21] routine P64NOW [18:00:28] seems to set TENDBRAK to POSMAX [18:00:37] because of course that's their solution to do this, lol [18:00:49] amazing [18:01:19] I'll try it 1 minute too early [18:01:20] just to see [18:01:49] before we got the switches wired right we had P63, P64 and P66 (or 67?) in short succession at ignition [18:01:59] not long enough to see if it does anything interesting [18:02:01] hmm [18:02:05] maybe it skipped P64 [18:04:02] seems really more like a debug feature, P64NOW [18:04:16] yeah [18:05:04] created in Luminary 49 [18:05:19] Extended verb 68 was created in connection with item 2. If the guidance is in the one-phase mode of operation, execution of verb 68 will force an immediate switching to P64. [18:05:34] item 2 is: [18:05:42] PCR246 was implemented, thus giving the Descent guidance two distinct modes of operation (see LUMINARYMemo43 and 44). [18:06:18] Luminary 96, the only change was PCN 762, which was deletion of verb 68 [18:06:29] one-phase mode, hmm [18:07:52] oh [18:08:02] I think that just means something that was removed at some point anyway [18:08:12] originally there was some linear guidance in late p63 [18:08:28] one-phase means quadratic guidance for both P63 and P64, in their full duration [18:09:21] right [18:09:29] I switched to P64 2 minutes too early [18:09:32] no issue [18:09:43] that will be interesting to see in Sundance, once we have that disassembled [18:09:54] assuming it's already there [18:09:54] not even really an attitude change [18:09:57] oh really? [18:10:22] but then the pitchover with the Apollo 11 descent targets is barely noticable [18:10:41] so maybe the trajectory to the P63 target and P64 target are almost the same for a long stretch of the descent [18:10:54] definitely wouldn't be the case for later missions [18:11:03] with a very noticable change at P63->P64 [18:13:07] ok, mid to late P64 in drawn out very long [18:13:19] so maybe it had an influence on the trajectory [18:15:56] not sure what it did with the LR [18:16:07] probably commands it to position 2 immediately when switching to P64 [18:16:34] oh yes I could definitely see it doing that [18:17:00] if you do it real early it would point the LR into space [18:21:24] oh boy, so Luminary 173 differs from 178 in 32 out of 36 banks [18:31:12] extracting just the analog displays is going to be interesting [18:33:31] was 173 actually assembled? [18:33:53] I mean, made into rope modules? [18:33:57] it was, yeah [18:34:10] 163 was too [18:34:15] well, that probably means they had to remake them all :D [18:34:20] yep! [18:34:51] funnily enough, Sundance was the only other time they had to remake all six modules for a mission [18:35:06] and for both Sundance and Luminary 1D, all six modules had to be remade twice [18:35:13] 163 and 173 also differ in almost all banks [18:53:47] man [18:54:21] as much as I love all of the electrical and mechanical drawings... these drawings with the banskums might be the best thing to come out of NARA [18:54:24] so ridiculously useful [19:05:16] indeed [20:15:36] Ron is starting on the LVDC emulator! :D [20:20:21] he can tell all us non-Americans how much fun he is having with it :D [20:21:00] hehehe [20:22:17] as I kind of suspected, the listing has no preflight program though [20:23:07] that will be a bit of an obstacle for using it in NASSP some day [20:23:59] yeah, that's too bad [20:24:11] I hadn't realized those were actually separate [20:24:26] well I was never really sure [20:24:31] the EDD mentions it a bunch of times [20:26:11] there is a seperate document that describes it [20:26:31] IBM: LVDC Preflight Program Descriptions Document, NAS8-14000, September 1, 1969 [20:26:39] very interesting [20:27:31] there might a bit of trickery involved in getting the flight program in the right state for GRR [20:27:36] shouldn't be too bad though [20:27:46] a bunch of things are initiated outside of the LVDC anyway [20:27:53] like azimuth laying of the platform [20:36:22] night! [14:19:38] morning [14:39:54] hey Alex [15:31:23] cya! [16:45:04] morning! [16:50:52] hey Mik [16:50:55] Mike even [16:50:57] haha [16:51:00] hey Nikla [16:51:01] what's up? [16:51:28] back to the reading stage [16:51:38] of RTCC requirements [16:53:34] woohoo [16:53:36] what's next? [16:54:33] improving the translunar midcourse correction targeting to better take the early DOI into account [16:56:01] nice [16:57:24] although it is tempting to start implementing routines from the Earth-centered RTE processor [16:57:45] the flowcharts are very readable and look quite complete [16:59:42] much easier to implement 1:1 [17:01:40] awesome [17:02:20] I think I am going to be spending a lot of time in flowcharts too [17:02:27] Luminary 173 is turning out to be difficult [17:02:44] soooo much changed with the analog displays [17:03:44] probably because the old implementation was bad :D [17:04:17] and what also changed is that the stuff for the displays only gets calculated if the mode switch is in PGNS [17:04:18] haha [17:04:48] well that is another problem [17:06:30] between Luminary 131 and 173, they changed the analog displays so that FORVEL and LATVEL are always calculated for the DSKY, even if the mode switch is not in PGNS [17:06:31] and we of course have no programs with those changes in them, since the whole thing got changed for 178+ [17:08:00] I got it down to 8 banks wrong [17:08:09] I have definitely 2, possibly 3 code errors somewhere [17:08:12] but I have no idea where [17:09:46] hmm, tricky [17:10:27] unfortunately this memo was not written by Dana Densmore so I trust it a lot less :P [17:13:55] haha [17:15:15] I really need all MSC memos [17:15:29] hahahaha [17:15:37] I found another instance where a document refers to an earlier revision of it for a subroutine [17:15:56] and the Earth-centered RTE targeting refer to the Moon-centered RTE targeting for a root finding routine [17:16:10] in that case we are lucky to have both already of course [17:27:09] I wonder how hard it would be to convince Ron to scan all of them for you :P [17:29:02] if he starts at the beginning, when the MPAD was created in 1964, then I will quickly move over to some Gemini simulation project [17:29:45] and maybe eventually come back to Apollo :D [17:31:25] hahahaha [17:35:13] well step 1 is in any case working further on the list of memos we already have and are still missing [17:37:48] which has not progressed very far yet, lol [17:40:07] hehehe [20:43:48] night! [14:33:38] hey [14:35:17] hey Alex [15:12:54] implementing some utility RTCC functions right now [15:13:23] but the next real update should still be the LOI/DOI geometry stuff in the TLMCC processor [15:19:20] nice [15:19:39] what kind of utilities? [15:19:57] cape crossing table [15:20:13] a lot of MCC displays can use a REV input, so revolution [15:20:31] and there is a table of revs and associated times [15:20:40] so I make it calculate that, to be used in the future [15:21:02] for the Moon it's 180° longitude [15:21:13] and for Earth the Cape Canaveral longitude [16:44:38] morning! [16:55:23] hey Mike [16:55:28] what's up? [16:56:19] a bit of RTCC here, a bit of RTCC there [16:56:31] hehe [16:56:36] and you? [16:57:52] I found three errors in my Luminary 173 last night [16:59:03] wrong noun scaling, wrong placement for setting of RODFLAG in STRTP66A, and missing SGNAGREE [16:59:13] so now I have a single bank wrong, and the error is 00035 in it [16:59:20] but the problem is, it's the LANDING ANALOG DISPLAYS bank [16:59:45] they made some changes to it between 132 and when it was rewritten in 174 [16:59:58] and so far my attempts to recreate those changes haven't converged [17:00:11] do you roughly know what the changes are? [17:00:24] the only one that I know of for sure is ACB L-11 [17:00:51] which let it calculate LATVEL and FORVEL for Noun 60 in ascent and descent, regardless of the mode switch position [17:00:52] ACB? anomaly control board? [17:00:58] assembly control board [17:01:01] ah [17:01:03] makes more sense [17:02:33] I might need to see the original ACB form for that one [17:02:47] the ACB forms are usually much more descriptive about their changes than PCRs or PCNs [17:03:12] if I get too stuck I might ask Don to just scan that one [17:04:05] it's almost certainly in the "Contents of Luminary 1D" binder [17:06:03] well at least you know some more sources to figure it out [17:10:34] hopefully :P [17:26:34] oh, that's rare [17:26:47] I found a big in my coasting integration routine in the RTCC MFD [17:26:49] bug* [17:27:16] bad for performance only, not inaccurate or anything, but quite bad anyway [17:28:25] hmm, performance because it loops too much? [17:29:28] it chooses a step size too small [17:29:35] aha [17:29:58] in lunar orbit only [17:31:41] I'm not even sure why I added some additional code there, it doesn't appear in the AGC code [17:32:33] it looks quite smart [17:32:36] but it causes this bug :D [17:33:02] hahahaha [17:34:55] that bug must have been there since before the RTCC MFD was added to NASSP [17:35:15] it's already there in the commit adding the files [17:37:13] oh man [17:37:15] so long long ago [17:37:27] yep [17:37:59] I only noticed now, because I am saving state vectors for (almost) every iteration of the coast integrator [17:38:45] in an ephemeris [17:39:17] is the change in performance noticeable? [17:40:14] no, probably not [17:40:38] I was just confused when the ephemeris got filled up to maximum (805 state vectors) in a quite short time [17:40:59] the step size is 11 seconds with the bug [17:41:05] and 101 seconds with the bug fixed [17:41:31] 60NM circular lunar orbit [17:45:25] I'm mainly surprised that there is any bug of this sort [17:45:33] in such a very well tested function [17:47:13] hahaha [17:47:32] yeah, and for it to have gone unnoticed for so long [17:48:23] yep [17:59:39] the fix will make most orbit calculations in lunar orbit slightly less accurate [17:59:44] can't be any significant amount though [15:06:37] hey [15:08:03] hey Alex [15:11:10] I tried computing LOPC-1 with the LDPP on my Apollo 14 pre-ascent scenario, I think it worked quite well [15:11:50] just to verify, threshold 1 would be the TIG and 2 would be the desired time of alignment with the landing site? [15:12:04] yes, both of them the earliest allowed time for it [15:12:15] so choose e.g. 30 minutes before the flight plan times [15:12:33] ok [15:12:59] example from Apollo 11 [15:13:04] the not executed plane change maneuver [15:13:12] 106:30:00 as the threshold for the maneuver [15:13:19] flight plan time is 107:05:33 [15:13:29] and second threshold time was 124:00:00 [15:13:44] flight plan liftoff time is 124:23:26 [15:14:25] ok makes sense [15:14:29] I wonder if the calculated GET of the pass over the landing site should be displayed [15:14:35] maybe as the second maneuver [15:15:52] but I have not much info for the display, other than the RTACF version of it [15:16:04] the requirements document doesn't have any picture of it [15:16:16] or even math to calculate any of the displayed parameters [15:16:34] it just has a block as the last step of the program flow, "calculate display parameters" [15:16:44] maybe the 1967 version of the document would have more on that [15:18:33] I doubt the later updates will have that [15:18:40] but I will see, next week probably! [15:45:58] hopefully [15:52:18] the update document definitely has the feature that was implemented by Apollo 11, LOI-2 with plane change basically [15:52:43] if it has no further updates then I'll just implement DOI with plane change based on that LOI-2 with plane change [15:53:03] as that was definitely a desirable feature for CSM DOIs [15:57:52] yeah [16:43:11] upcoming RTCC MFD feature [16:43:11] https://i.imgur.com/9hPQEVZ.png [16:45:32] this is what the cape crossing table is useful for [16:45:50] as you can tell it to calculate those times for e.g. rev 9 and later [16:46:14] and this table was used a lot to define TPI times [16:46:41] lunar liftoff time processor has no calculation for TPI based on lighting, so TPI time is input [16:47:01] concentric rendezvous processor has a lighting based calculation, but it's broken for lunar orbit [16:47:08] or at least it was on Apollo 11 [16:47:13] so it also needs a TPI time input [16:47:24] DKI on the other hand has a working TPI calculation based on lighting :D [16:47:30] RTCC, consistent as ever [16:52:03] haha [16:52:09] interesting stuff though [16:52:21] so the TPI time was defined outside of the ascen processor [16:52:26] ascent* [16:54:12] yeah, in most cases I have heard the FIDO giving that time directly to Dynamics, for the calculation [16:54:32] RETRO is less busy than the FIDO during the hours before the landing, so he helps out a bit [16:54:46] so I think RETRO has been calculating a bunch of TPI times [16:55:19] and I've not 100% heard evidence of it, but I am very sure the times come from this sunrise/sunset table [16:55:32] RETRO and FIDO were definitely cross checking TPI times [16:55:40] if they came up with the same number [16:55:55] it's not that difficult really, take sunrise time from table, subtract X minutes [16:57:18] either 16 or 23 minutes [16:57:32] depending on the rendezvous/rescue sequence [17:00:49] yeah makes sense [17:00:54] they had some worksheets for this, basically checklists which assist in doing this stuff [17:00:56] gotta go, cya! [17:00:58] cya! [17:05:05] morning! [17:05:17] hey [17:06:20] https://www.ebay.com/sch/m.html?_nkw=&_armrs=1&_ipg=&_from=&_ssn=wjcu&_sop=10 [17:06:29] more MSC memos on ebay today [17:06:32] ohh [17:06:50] Apollo 11 mission techniques [17:08:53] manual ascent, partially answers a question I had about that [17:08:57] cutoff condition [17:09:30] if I do a manual ascent in NASSP and fly to fuel depletion the orbit is too high for the CSM to be able to rescue the LM [17:09:37] maybe our APS is too efficient or so [17:10:04] :D [17:11:09] DVS = 0 is the alternative condition for cutoff [17:11:16] I think this is a display in mission control [17:11:21] based on tracking I guess [17:12:31] https://i.ebayimg.com/images/g/0SwAAOSw4FtdhZD5/s-l1600.jpg [17:12:35] something from there [17:14:56] well I saved all the interesting pages [18:38:52] hmm, so I've gone through all of the memos and I think ACB L-11 is the only thing that should have affected bank 21 [18:39:08] and Luminary 163 and 173 have identical checksums for that bank [18:39:22] so I think I'm going to commit what I have for 173 and then see if I can undo all the changes between 163 and 173 [18:39:36] and if that works out then ACB L-11 will complete both ropes [18:40:27] at this rate you are going to accidentally reconstruct Luminary 131R1 from "above" instead of from 131 :D [18:44:33] when was the terrain model added? [19:29:16] hahaha [19:29:33] terrain model was added... I wanna say around 155 [19:30:09] nope, 152-154 [19:32:55] Auto P66 might be a big one, but with the terrain model in between it probably doesn't make sense to work your way down from 178 to 131R1 [20:10:28] man IRC is just not delivering me your messages [20:10:38] yeah, it's definitely not easier to work down [20:11:04] the trick with 131 is figuring out how they packed the Auto P66 changes into just a few banks without changing other modules [20:11:17] so the code there is probably going to be different from what's in 178 anyways [20:11:40] yeah, right [20:19:11] finally figured out who that guy on the FIDO loop is with a (to me) a bit funny voice [20:19:25] real expert on all things trajectory rendezvous [20:19:34] Jerome W. Kahanek, called Jerry [20:19:43] wrote a bunch of the MSC memos that Ron has scanned for me [20:19:56] oh nice! [20:20:35] they are preparing some calculations for a possible any-time liftoff [20:20:40] so outside the normal liftoff time [20:20:48] that has some crazy rendezvous procedures [20:21:03] which is why the FIDO is talking things through a bit with someone who really knows this stuff [20:21:15] oh jeez yeah [20:21:25] any time liftoff sounds incredibly problematic [20:22:16] yeah, it truly is [20:22:27] getting the LM and CSM back together before batteries run out [20:22:43] and with little enough DV to still be able to do TEI [20:23:09] we have a pretty good Apollo 11 memo for this case [20:23:23] with some updates for later missions in documents we got from NARA and UHCL [20:24:32] in the worst case the LM quickly does a 100 ft/s maneuver and then powers down [20:24:50] then CSM does two maneuvers to go to a 20x20 orbit [20:24:55] as opposed to its normal 60x60 :D [20:25:04] then lots of coasting I guess [20:25:21] and then a fairly standard rendezvous a few hours later [20:25:41] oh wow [20:25:50] 20x20 would be a fun orbit to be in [20:26:06] yeah [20:26:26] in the 60x8 orbit when the CSM does the DOI you are really flying by the mountains at perilune [20:28:39] have to fly some of the anytime liftoffs some time [20:28:50] I think I was waiting on me implementing some other MCC display for it [20:30:27] hehehehe [20:41:49] okay, got a skeleton Luminary 163 put together [20:42:10] funnily enough, the analog displays change was so big that more changed between 173 and 178 than change between 163 and 173 [20:43:28] yeah, that tends to happen [20:43:45] 1 revision is not equal to 1 revision, hehe [20:44:14] a few times 1 revision just meant a reassemble without any changes even [20:44:26] yep [20:50:48] okay, issue created [20:50:53] now I can actually work on the changes :) [20:50:59] in theory this will be quite easy [20:53:33] so essentially you now have two puzzles (163 and 173) but you know the same piece will complete both? [21:00:15] yeah exactly [21:00:29] they both have the exact same bank 21 checksum [21:00:41] so I'm expecting that I should be able to resolve all of the banks except for that one [21:00:58] and then once I'm there, I'll play around with ACB L-11 a bit more, and if I don't figure it out I'll ask Don for scans of it [21:01:11] right [21:01:58] coming up on the first step on the Moon, I wonder how quiet the FIDO loop will be :D [21:03:17] The Apollo in realtime website has a bunch of TV footage from mission control. I always stare at the screens but they are never close enough to really see anything on them [21:04:53] I guess they don't have much to talk about on EVAs, haha [21:05:11] oh, the FIDO was busy preparing all this contingency rendezvous stuff [21:05:16] but I think they are done for now [21:05:19] right [21:05:36] they are still calculating liftoff time, ascent and CSI PADs for each orbit [21:05:41] too bad you can't make anything out on the screns [21:05:43] *screens [21:06:07] yeah, still a severe lack of info on many of those displays [21:07:00] small step happened, no talk on the FIDO loop in the last few minutes [21:07:09] just the air-to-ground audio turned up all the way [21:08:19] :) [21:08:49] TV footage from MCC-H also shows, they are all just watching the EVA, not doing any of their work :D [21:10:06] hehehe, that sounds reasonable :D [21:10:31] comp soup breaking the silence [21:13:18] and then back to business really [21:24:25] Guenter! [21:24:28] okay there [21:24:35] I think I fixed IRC on my laptop [21:24:46] ah, nice [21:25:24] the screens in MCC-H are really just TV screens. Just saw a wide shot of the room, every flight controller with more than 1 screen has the EVA on one of them. [21:25:35] so in that wide shot you can see about 10-15 EVAs [21:25:42] haha nice [21:34:53] 3 banks down [21:42:35] ACB L-20 is fun [21:42:46] An error was made in reading assembly card numbers: 2234 vs 2334. By coincidence, they are concerned with the same noun (60) in the NOUN Tables (output and input scaling). The fix makes the output scaling 0. 5571 fps/bit and the input scaling the way it was originally, though it is not intended for use. [21:43:03] reintroducing silly bugs :D [21:50:03] haha, ouch [21:50:39] https://cdn.arstechnica.net/wp-content/uploads/2019/06/console-row3-procedures-detail2.jpg [21:50:53] that's from the restored MCC [21:51:02] they don't have many screens like this [21:51:29] but that one on the left I have no other source of [21:51:37] and there is the DVS [21:52:24] when that becomes 0 during manual ascent CAPCOM says to cut off the APS [21:55:11] have you reached out to the people that did the restoration to see what their source for that was? [21:56:13] I asked one person on Twitter and never got an answer :D I think I know someone else to ask though [21:57:01] their source was probably this same TV footage from the MOCR [21:57:27] I don't think they have found that Philco document with all the definitions [21:59:47] I see 3 displays with data, and two S-band antenna look angle displays [21:59:53] so they only use 5 here [22:00:36] hmm, too bad [22:01:38] which they could have figured out from the footage [22:05:23] good night! [05:53:07] all changes from 163 to 173 figured out! [05:53:20] now all we need is ACB L-11 and both reconstructions will be done [06:24:35] oh crap! [06:24:40] I figured out ACB L-11!!! [06:24:53] thanks to the Luminary 173 flowcharts :D [06:25:13] another check moved that wasn't mentioned in the memos [07:22:28] two more programs down! [07:22:44] we're getting quite close to having the code for all manufactured Luminaries [07:23:07] three left: LUM131 Rev 9, LM131 Rev 1, and Luminary 96 [17:02:13] morning! [17:21:29] hey Mike [17:22:05] yo [17:22:07] what's up? [17:22:13] fixing bugs [17:23:04] so Luminary 163 and 173 are done? [17:23:09] what's next? [17:28:40] yep, all done with 14 [17:28:49] so I'm probably going to have another go at 13 [17:29:31] nice [18:57:34] hey [18:59:25] hey Alex [19:05:19] if you order one of these: https://i.imgur.com/TUdTbfC.png [19:05:29] then you get one of these for (almost) free: https://i.imgur.com/dDd7cXD.png [19:07:26] 2 for 1 I like it :D [19:08:13] al the same display and essentially the same logic [19:13:53] moonrise/set display only works in Earth orbit of course [19:14:13] I guess it's useful for those Apollo 7 P23s on the Moon [19:18:18] that's most of one category of MCC displays implemented :D [19:18:23] displays 1501 to 1508 [19:18:33] moonrise moonset times, check [19:18:37] sunrise sunset times, check [19:18:42] next station contacts, check [19:18:54] S/C Pointing Display, no. I think I have the display for this though [19:19:46] MSK 1505, "Recovery Ascending Node", no idea what this is [19:20:47] experimental site acquisition can be implemented easily [19:20:56] Landmark Acquisition Display should be very useful for P22s [19:21:13] and will replace that MFD page we already have to calculate landmark PADs [19:22:28] "Figure OT 2.2.4-1 Land Mark Acquisition Display [19:22:29] (To be provided)" [19:22:34] thanks, very helpful... [19:35:45] lol [19:36:03] Ill be back later, cya [21:00:30] night! [17:09:04] morning! [18:13:20] hey Mike [18:21:15] what's up? [18:23:28] looking at midcourse corrections again [18:24:28] I think the easiest way to implement the new equations from one of the documents Ron scanned is to build up a new system, this time using all the right equations, and not having to deal with the baggage of the old implementation [18:26:00] oh man [18:26:15] rewrite time :D [18:27:11] always [18:27:26] I have to do a good round of code cleanup soon anyway [18:28:23] already a bunch of redundancies [18:29:58] deleting code is almost more satisfying than adding it, haha [18:31:01] yep! [18:31:21] I dismantled all that old non-Virtual AGC and non-LVDC code from NASSP [18:31:33] many, many lines of code [18:33:15] :D [18:33:39] the main reason to be hesitant in the case of the RTCC stuff is the MCC [18:34:02] only if I am very sure that calculations are working correctly, over a range of different mission, can I really remove old functions [18:34:07] or the MCC might fail [18:34:22] in some odd case I hadn't tested [18:34:50] right [19:40:25] hmmm [19:40:34] I wonder what the chances are that Norton is wrong in this document [19:40:43] from what I have gathered probably very low [19:48:30] wrong about what? [19:53:27] whether VHZC calculations happens in STARTP66 or STRTP66A [19:54:03] hmm [19:54:06] try both :D [19:58:06] haha [19:58:10] that's not so easy :) [19:58:49] I'm inclined to believe Norton because it seems like his description matches the flowchart in the auto p66 memo [19:59:12] but if that's the case then as coded in Luminary 1D, STRTP66A would fall right in the middle of a chunk of interpretive code [19:59:20] but on restarts it is branched to from basic [19:59:40] so they'd have to exit from interpretive and then go straight back into it [20:00:15] sounds like messy code [20:00:31] single-module remanufactures are always incredibly messy [20:00:55] "not enough room to fit this change? make it jump to the end of the bank, or a different bank, do the thing, and then jump back" [20:01:31] in the case of Sunburst 120, they left big pieces of completely dead code in place, that had to be there so everything still assembled to the right addresses [20:01:40] I'm hoping they didn't do that much for LM131 [20:05:54] I doubt it [20:05:59] Sunburst is... early [20:18:55] well, it is [20:19:14] but also, the banks they changed in LM131 has references all over the place [20:19:28] and there are chunks of code dedicated to P65 that are wasting space that could be used for Auto P66 [20:19:42] so if they need more room, why not just use up parts that were used by P65? [20:19:55] and if that bit is shorter, maybe some pieces of P65 still exist [20:20:29] Norton already points out that the P65START function is still there but never called [20:20:41] ah [20:21:00] P65START being still there is not a good indication [20:21:04] yeah [20:21:14] that's why I think this is going to be harder than 1D, even though only one thing changed :) [20:22:45] December 6, 1969 [20:22:53] how early is that in terms of Luminary 131? [20:23:21] Luminary memo 130 is from then [20:23:27] has an interesting program note for P65 [20:23:36] apparently it already was kind of broken then [20:23:54] issue "Avoidance: Land in ATT HOLD" [20:24:02] that doesn't sound very P65 to me :D [20:24:18] hmm [20:25:26] probably not very relevant [20:26:49] hahahaha [20:26:56] let's see [20:26:59] that's pretty early [20:27:30] Don's copy of Luminary 131 was printed December 19 [20:27:53] LUM131 rev 9 was released January [20:27:59] LM131 in February [20:28:38] oh here we go [20:28:39] timeline [20:28:58] http://www.ibiblio.org/apollo/Documents/LUM143_text.pdf [20:29:14] third page, second paragraph [20:30:59] so December 6 was from just a few days before they even had the idea to do Auto P66 [20:31:44] so those program notes will apply to the Luminary 131 we already have [20:32:53] yep [20:34:06] so I think my first task is going to be to map out what code lives in what bank, exactly [20:34:18] then figure out what could feasibly have been removed from P65 [20:36:27] if there are really significant parts of P65 still in there then the Luminary 131 situation is worse than I thought :D [20:36:57] haha yeah [20:37:13] and I had already made up that theory that they didn't land on Apollo 13 to hide the fact that they had no idea which LGC version they were even flying... [20:37:14] that is a big part of why I switched gears to work on 178 [20:37:18] hehehe [20:38:14] what about P67? [20:38:58] didn't that die before Luminary 1B? [20:39:39] hmm, no, but it does look like it died before 131 [20:39:40] I don't think so [20:40:20] http://www.ibiblio.org/apollo/Documents/LUM124_text.pdf [20:40:27] Luminary 121-130 [20:41:07] ah [20:41:14] was deleted when N92 was added [20:41:16] make sense [20:42:29] I guess P67 was always mostly "lack of P66 or P65" anyway [20:42:34] hahaha yeah [20:42:40] I need to try P67 at some point [20:43:06] I recommend a joystick [20:43:18] hehehe [20:44:25] it still does attitude hold of course [20:44:37] but if you need to make large throttle changes a joystick with throttle lever is much better [20:45:23] right [20:45:33] I guess you can go even more manual if you set PGNS mode to Off [20:45:42] and then no more attitude hold? [20:45:44] haha [20:46:20] the att hold is just the same DAP mode as it also would have in P00, nothing P67 specific [20:47:37] hardover mode is only on with full ACA deflection [20:47:46] so it's probably better to switch to some AGS control mode [20:47:51] right [20:48:02] AGS att hold or direct mode maybe [20:48:12] what's direct mode? [20:48:41] the three attitude control switch to DIR instead of MODE CONT [20:48:51] fires 2 jets (instead of 4 in hardover) [20:49:01] and already when the ACA is out of detent [20:49:09] not at full deflection [20:49:36] switches* [20:49:56] gotcha [20:50:26] if I had no PGNS and not AGS att hold available that would be my preferred control mode [20:50:37] hmm [20:50:51] DPS gimballing might be a bit awkward in AGS mode [20:51:23] haven't tried landing on the moon with the AGS yet :D [20:52:45] good night! [16:43:56] morning! [17:17:04] hey Mike [17:38:49] what's up? [17:40:20] making some good progress with implementing TLMCC routines [17:40:32] :D [17:40:39] the document Ron scanned is for Apollo 14. We already have the same document twice, from 1968 [17:40:50] both of which have lots of errors and some unreadable passages [17:41:00] and of course not the logic for the CSM DOI [17:41:23] so in the past I had trouble implementing this stuff and had to come up with my own calculations [17:42:17] but this one is readable and has less errors? [17:42:28] yep [17:42:32] excellent [17:42:48] I'm not sure I have encountered any so far actually [17:43:01] maybe a small ommission [17:44:06] very nice :D [17:44:19] of course in most cases it's not a full program flow. But the explanations are sufficient, as opposed to in lots of other RTCC documents [17:46:45] https://archive.org/details/69FM327Images/page/n27 [17:46:56] can you guess why I didn't implement this LOI targeting yet? :D [17:50:22] oh dear [17:56:36] so, preview for the next RR auction is up [17:56:55] https://www.rrauction.com/preview_gallery.cfm?Category=543 [17:57:13] and they put the AGC in the "Don Eyles Apollo Computer Collection" so I guess it's not a secret anymore, haha [17:57:40] 69, AP11ROPE, and 116 are the listings [17:58:38] nice [17:58:56] I hope Don is going to make some nice $$$ :D [17:59:06] haha yeah he is definitely going to [18:01:16] and I also hope the new owner can appreciate what he will get [18:03:11] yeah I really hope so too [18:15:33] also did more homework on LUM131 Rev 9 [18:15:44] I don't think THE LUNAR LANDING changed at all for any 131 revision [18:15:54] and am working my way through SERVICER now [18:16:30] it's so much easier to compare 131 and 163 than 131 and 210, haha [18:18:09] yeah I bet [18:18:21] none of that terrain model stuff and the analog displays [18:18:36] 163 still has terrain model [18:18:46] but yeah, no analog displays [18:19:10] ah right [18:19:22] and no IMU bobbing correction [20:17:28] night! [16:54:37] morning! [16:57:02] hey [17:01:09] what's up? [17:02:18] something fun to read: https://waynehale.wordpress.com/2019/09/25/oops/ [17:16:57] "This was done on purpose to see what the limits of the spacecraft were.  We found out." [17:16:58] hahaha oh man [17:18:09] did you read to the end? [17:19:07] not yet [17:19:28] the best bit is at the end [17:21:23] somehow I never knew that the shuttle's radiators were inside the doors, and the doors had to remain open or it would overheat [17:22:21] oh yeah [17:22:33] not being able to open them after launch makes for a short mission [17:22:36] due to thermal issues [17:44:43] haha oh man I just finished it [17:45:04] riding down in the payload bay after trapping yourself inside :D [17:45:09] amazing [17:45:49] ah, it's unlikely, let's not think about it too much :D [17:46:15] I also like "Those darn Sim Sups! They always made us work problems that were unrealistic!" [17:47:11] hehehehe [17:55:19] did you see the picture from this morning's Soyuz launch? [17:55:26] https://twitter.com/Astro_Christina/status/1176864846178136064 [18:37:16] yeah, quite awesome [18:37:28] I think they get this view when they do the short Soyuz rendezvous profile [18:37:37] nice :D [18:41:02] on the Apollo short rendezvous profile the CSM flies over the LM about 1-2 minutes after launch [18:41:10] I wonder if any of the CMPs saw something of that [18:43:45] probably were too busy doing other things, if they had pointed the sextant at the right spot he surely could have seen the LM [18:57:43] too bad, that would have been awesome [20:10:40] hmm [20:10:56] so I've been making some progress on mapping out lum131 rev 9 [20:11:30] I printed out the programmed guidance equations document and have been marking it up in different colors, with each color meaning a different bank, to try to get an idea for how it all fits together [20:11:39] I think the hardest thing will be figuring out how P66HZ fits into bank 32 [20:14:02] so far there isn't any changes that obviously don't fit... for rev 9 [20:14:16] LM131 rev 1 will be interesting, because there isn't room for some of the priority changes [20:14:21] like the one at the beginning of RODCOMP [20:17:32] so there is probably going to be some bank madness in the flown version [20:18:40] oh absolutely [20:19:47] rev 9 already has bank madness in bank 33 that I figured out, with HLROFF [20:20:01] they replaced a TC INTPRET with a jump to the end of the bank [20:20:42] put the TC INPTRET there, followed by the check against HLROFF, and then jumped back into the original code in interpretive [20:21:17] I actually discovered something interesting there while doing diffs between 131 and 163 last night [20:22:54] https://archive.org/stream/luminary21000miti#page/888/mode/1up [20:23:05] that POSUP label appeared between 131 and 210 [20:23:40] the TC INTPRET right before it is the one that got replaced in the 131 remakes, and the POSUP line was the destination for the branch from the end of the bank back [20:24:05] it's not referenced anywhere in 210, but I'm pretty sure POSUP got added as part of the 131 remakes :) [20:24:13] ah, so a remnant of those changes [20:24:18] yeah [20:24:27] I need to see if I can find any other labels that appeared for seemingly no reason [20:26:09] oh, when we talked about reconstructing other programs like Sundisk a few days ago I remembered something [20:26:16] https://web.archive.org/web/20100524020614/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740072687_1974072687.pdf [20:26:46] that's a quite interesting document, because it has so many different ways of explaining the same routine [20:26:51] oh interesting [20:26:52] first a derivation of the equations [20:27:01] then "CMC coding" [20:27:13] then a flowchart like you are oftenworking with [20:27:21] then GSOP section 4 excerpt [20:27:23] and then a checklist [20:27:35] the "CMC coding" looks pretty similar to the programmed guidance equations document format [20:28:03] that's a really cool document [20:28:06] does Ron have that? [20:28:12] you should send it to him if it's not on the website [20:28:41] I don't know [20:28:43] I'll check [20:29:00] but yeah, that kind of document would be rather useful for some other routines of other programs :D [20:29:02] I think he probably doesn't, because we have extremely little about Sundisk [20:29:05] yeah absolutely [20:30:06] doesn't appear like he has it [20:30:52] well, at least something I can give back, for what he hopefully will find at NARA today or tomorrow :D [20:31:23] :D [20:42:27] what's the name of the document these "MIT flow charts" are from? [20:43:09] we have that for some AGC versions, right? [20:55:54] yeah [20:56:03] just "Flow Charts", haha [20:56:30] we only have the full flow charts for 1D [20:56:39] right [20:56:40] NARA has some for 1C, as well as Comanche 67 and 72 [20:56:51] http://www.ibiblio.org/apollo/Documents/j2-80-E-2471-REV2-VOL1_text.pdf [20:56:56] http://www.ibiblio.org/apollo/Documents/j2-80-E-2471-REV2-VOL2_text.pdf [20:57:16] Luminary 163-178 absolutely would not have happened without those flowcharts [20:57:42] and also wouldn't have happened if they were the flowcharts for 178 instead of 173, haha [20:58:10] or at least, 163 and 173 wouldn't have [20:58:14] they were key for ACB L-11 [20:58:59] yeah [21:04:55] speaking of scanning [21:05:08] we're rapidly approaching the onset of 4 days a week NARA scanning :D [21:06:54] more AGC schematics than we could ever handle [21:06:59] :D [21:11:38] I wonder if we're going to find any other unexpected treasures like the bugger word drawings [21:14:45] I bet we will [21:16:05] hopefull! [21:16:07] y! [21:16:34] and he hasn't pushed anything yet to github today, which is normally a good indication of scanning [21:17:16] oh yeah, he definitely is there today and/or tomorrow [21:17:34] I hope they are able to locate the LDPP changes [21:18:33] yeah that would be great [21:32:16] night! [17:03:22] morning! [17:06:54] indy91: how is 68-FM61-230? [17:38:13] thewonderidiot, good [17:38:23] it has no further changes after that July 1968 update [17:38:35] which adds two calculation modes, which I already knew [17:38:57] it also has 2 pages which don't have to do with the update just for fixes [17:39:05] which is helpful [17:39:15] nice! [17:39:21] although it's not a change to the bigger issue I had [17:39:27] oh boo [17:39:41] which I solved by implementing a quite different formulation [17:40:25] so I should be able to implement some more modes [17:41:18] oh, and I mentioned to Ron that I have a bunch of tabs of the same RTCC document open when I am working on it [17:41:35] which resonated well with that, that what he is scanning really does make a difference for NASSP [17:41:41] well with him* [17:42:45] nice :D [17:43:24] he seems a bit more motivated to do scanning, he is looking for some memos from 1964 that are mentioned in the LDPP document [17:43:32] also just to see if they even have documents from this early [17:43:55] which we can't really know, he started scanning first pages way later [17:46:09] well, if my email has reached him before he is leaving NARA today he is going to ask, haha [17:48:02] these 1964 memos might be some of the most used MSC memos for trajectory calculations [17:48:07] all the way to Shuttle [17:48:16] "Logic and Equations for the Real-Time Computation of Arrival Time at an Equatorial Crossing, A Specified Longitude, A Specified Radius, and Apsis Points." [17:48:18] is one of them [17:48:58] none of the MSC or IBM RTCC documents I have found are giving any procedure for this [17:49:14] they are either directly or indirectly referencing this 1964 memo [17:49:49] of course I know how to calculate that stuff, mostly [17:49:52] but still... [17:50:46] well I doubt he is going to scan the documents today, at most we will know how far back NARA has these memos, which would be quite nice to know [17:57:59] nice, yeah, that would be awesome to know :D [17:58:20] for once you're looking for documents older than I am, haha [17:58:51] yeah, that's quite rare [18:00:39] I only have two MPAD memos from 1964 so far [18:00:56] one deals with Gemini abort to orbit basically [18:01:07] and one is a study of a lunar mission [18:02:00] very similar to the flown profile already [18:02:07] no LOI-2, LOI in one go [18:03:31] haha [18:03:33] "September 17, 19&9 was selected as the launch date for this mission. [18:03:34] The year 1969 was an arbitrary choice." [18:03:37] 1969* [18:03:49] not a bad guess! [18:04:30] hahahaha [18:04:32] awesome [18:05:04] that's an excellent guess [18:05:08] right between 11 and 12 :D [18:06:14] "Control Weight Mission for System Design" is the name of the memo, July 20, 1964 [18:06:33] I guess it's mostly about figuring out how much propellant they really need for this mission profile [18:07:08] yeah, sounds like it [18:07:34] I read that S-IC and S-IVB were ahead in development of the S-II, so the poor S-II had to do most of the weight saving when the Saturn V became too heavy [18:08:00] oh yeah, the S-II really got the short end of that stick [18:08:32] that was the reason for its common bulkhead, wasn't it? [18:09:14] yep [18:12:14] so in reconstruction land [18:12:27] I am starting to develop my own conspiracy theory about the Apollo 13 software [18:12:52] ah, nice! [18:13:28] I've been scratching my head over the 30 words that showed up in bank 34 between LUM131 rev 9 and LM131 rev 1 [18:14:02] because the changes between the two, I think, don't amount to that much, and there's certainly no way those changes would have impacted bank 34 to that extent [18:14:29] and they're spread relatively thinly across all of LLGE, so it's not like there's just a new big chunk to plop down there [18:14:40] so what I'm starting to think happened, is they got up to LUM131 rev 9 [18:15:17] and then when they realized that they didn't have room for the changes they wanted to make to rev 9 [18:15:27] instead of making rev 10, they just completely abandoned LUM131 [18:15:57] and instead made LUM131A directly from Luminary 131, and re-sorted the new code in such a way that the additions would now fit [18:16:09] and that is why the name of the rope changed [18:16:20] interesting theory [18:16:35] so I'm thinking that in terms of code distribution, LUM131 rev 9 and LM131 rev 1 will have little in common [18:16:42] since they're different forks from Luminary 131 [18:16:52] even though the majority of the added code is the same [18:17:58] that could really be the case. Doesn't make reconstructing either version any easier of course :D [18:18:06] no, it makes them both harder, haha [18:18:29] back in a bit [18:18:34] and I found a place last night where the flowcharts from the Automatic P66 memo don't match Norton's programmed guidance equations [18:19:00] which means either that Norton missed a change, or that that is the difference between LUM131A rev 3 and LM131 rev 1 [18:38:13] hmm, in this theory, rev 9 a broken version? [18:38:51] only with high TLOSS [18:39:26] rev 9 didn't have CNTTHROT, 2LATE466, or TOOFEW [18:39:47] it couldn't omit servicers, and didn't have protection against multiple servicers running [18:40:09] but without TLOSS it was totally fine [18:44:22] " 2LATE466, or TOOFEW" for once I know what you are talking about :D [19:18:56] hehehe [19:19:10] yeah I thought you might recognize new padloads :D [20:14:15] night! [17:04:46] morning! [17:07:41] hey Mike [17:08:57] what's up? [17:09:16] NARA has those MSC memos from 1964 :D [17:10:08] nice! [17:10:28] was yesterday just looking or did Ron manage to scan some of them? [17:11:15] he will try to next week [17:11:46] nice! [17:11:50] :D [17:11:52] but they told him that the memos are there [17:12:14] it sounded like he started scanning the MIT aperture card boxes from the beginning yesterday [17:12:30] the beginning sounds early [17:12:30] since he sent me a little note about ND1002319 [17:12:50] "ACE-S/C Computer Subprogram Specifications for Apollo CM and LM G&N Testing", and (among other things) seems to have detailed descriptions of telemetry formats [17:13:18] these early drawing numbers are all specifications and things [17:13:28] so who knows what we'll find [17:13:30] right [17:13:40] so probably a similar timeframe as these MSC memos? [17:13:54] not necessarily [17:14:04] they could be from any time in the program [17:14:32] but must will be more early like that, yeah [17:18:08] so, while feeling frustrated with LM131 this morning I looked back at Comanche 45 [17:18:21] and found an interesting comment [17:19:16] http://www.ibiblio.org/apollo/listings/Comanche055/P40-P47.agc.html#5334302E31 [17:19:27] "COMPUTE FOR P30/P40 INTERFACE THUS PERMITTING MODULE-ONLY CHANGE" [17:19:47] do you know what that's about? which remake this would have been? [17:20:20] hmm [17:22:17] hmmm well [17:22:55] it's in bank 16, which is in module B3 [17:23:21] which is the module that was remade between Comanche 44 and Comanche 45 [17:23:27] so I guess it must be that [17:24:03] I wonder what that's about [17:24:55] lol [17:25:38] it's amazing we know so much about Luminary but not even what changed between two manufacturings of Comanche [17:26:44] buuuut it's nice that they left that comment in, since it gives us a nice starting point for getting to 44 if I can figure out 45 [17:28:32] that saves DELVSIN into DELVSAB, right? [17:28:36] yep [17:28:42] or rather, the magnitude of it [17:28:48] yeah [17:28:57] DELVSAB = |DELVSIN| [17:28:57] and where does it get used? [17:29:08] just a few lines below there and nowhere else? [17:29:23] looks like it yeah [17:29:51] S32/33.1 in P32-P33, P72-P73 also writes into DELVSAB [17:29:54] but doesn't load it [17:29:55] and what does it do there with it? [17:30:34] uhh [17:30:38] it's part of a big calculation [17:31:01] P32 and P33 were new in Colossus 1 [17:31:23] Colossus 2 [17:31:34] UT = unit(VTIG x RTIG) [17:32:29] oh man this is using the pushlist [17:32:53] but how does it use DELVSAB there? [17:33:00] I'm trying haha [17:33:04] I can't read interpretive well [17:33:09] hold on [17:33:36] oh [17:33:39] I know what that is [17:34:00] oh? [17:34:07] it uses THETAT there? [17:34:13] and calculates it? [17:34:44] that is mentioned in a comment at least [17:35:18] then that is the finite burntime compensation the AGC does [17:35:36] and in the equation to calculate the theta_T it uses a "DV_LV" [17:35:40] which is the DV magnitude [17:36:15] oh you know what will have the answer to this? [17:36:23] the comanche flowcharts Ron just scanned [17:39:02] haha, yeah [17:40:38] is S40.1 called in P30 or P40? [17:41:51] P40 [17:43:11] why is that for the P30/P40 interface then? [17:43:17] you call P30, then you call P40 [17:43:52] well, P30 writes into DELVSIN [17:44:51] and P40 calculates DELVSAB from DELVSIN? [17:45:02] yes, DELVSAB = |DELVSIN| [17:45:45] interesting [17:45:56] the subroutine S32/33.1 has this: [17:45:57] STORE DELVSIN [17:45:57] PUSH ABVAL [17:45:58] STOVL DELVSAB [17:46:29] I wonder if there's some case where this subroutine doesn't get called when they were expecting it to be [17:47:42] so P32/P33 already should have been calculating DELVSAB [17:47:46] but to be sure P40 also does it [17:48:04] here you go [17:48:05] https://archive.org/stream/e24562dimages#page/n1084/mode/1up [17:48:09] that sheet and the next one [17:49:02] I would not have gotten there looking at that interpretive code :P [17:49:04] yeah, that is what I was expecting from the GSOP part of this [17:50:50] ah [17:50:58] P32/P33 are indeed a bit special [17:51:12] P30 uses one path [17:51:26] P31, P34, P35 and P37 are all using the lambert aimpoint guidance [17:51:44] so the P32+P33/P40 interface is different from the rest [17:51:53] maybe it has to do with that [17:52:02] hmm, could be [17:58:45] you know [17:58:50] I still haven't heard anything from Purdue [17:58:53] I should probably follow up [18:04:17] wow, that indeed has been a while [18:29:30] hmm [18:29:36] yeah I think I am going to go for Comanche 45 this weekend [18:32:46] nice! [18:33:12] I will definitely need your help though :D [18:34:07] sure, if I can [18:37:53] I reckon there's 13 banks where code actually changed [18:38:01] which is a decent bit [18:39:40] unless I did something dumb [18:40:01] okay no [19:48:33] ugh [19:48:41] not a good start to Comanche 45 changes, haha [19:49:14] Changed Selective Max RCS Rate from 4°/s to 2°/s (last two numbers in MANTABLE) [19:49:20] I thought this would be a nice easy place to start [19:49:22] and it is [19:49:29] but because of the way those numbers are stored [19:49:39] DEC .568889 [19:49:40] DEC -.568889 [19:49:53] the positive and negative in a row cancel each other out from the bank summing point of view [19:50:08] so making that change changes exactly zero banksums [19:53:39] hmm [19:53:55] but don't we know the values for that? [19:54:06] we do, from Colossus 249 [19:54:22] it's just annoying when changes aren't detectable by banksums [19:54:34] right [20:20:03] hmm so [20:20:28] you said K2VAL and K3VAL were still in fixed, and only K1VAL and FANG were added to erasable? [20:20:54] and K1VAL was the same as in 249? [20:21:03] er I mean [20:21:09] K2VAL and K3VAL were the same as in 249? [20:23:21] K1VAL and FANG added to erasable [20:23:26] probably PCR 729 [20:23:47] well, 100% PCR 729 [20:24:02] K2 and K3 are still fixed [20:24:29] and value wise, they are NOT the same [20:24:35] as per PCR 734 [20:24:42] oh boy [20:24:47] what are they then? [20:25:49] hmm, they changed the unit in the GSOP from metric to imperial [20:26:08] also, whatever happened to K4... [20:26:37] oh [20:26:38] loool [20:26:47] I was looking at the GSOP for Luminary... [20:26:51] hahaha [20:27:00] whichs also has these kind of values, for DPS and APS [20:27:33] R-567, R-577, quite similar numbers... [20:29:01] K2 changed from 6590 pounds/sec to 5000 pounds/sec [20:29:22] or maybe pound seconds, the two documents disagree with each other [20:29:31] alright I definitely need your help here then [20:29:34] and K3 changed from 26475 pounds to 25500 pounds [20:29:42] K2VAL 2DEC 293.137805 B-23 # 6590 LB-SEC, SC.AT B+23 NEWTON-SEC/E+2 [20:29:43] K3VAL 2DEC 11.7766668 B-9 # 26475 LBS, SC.AT B+9 NEWTONS/E+4 [20:29:50] that's what Colossus 249 has [20:30:11] so we need to go from pounds to... whatever these units are :D [20:32:30] question [20:32:33] 293.137805 [20:32:36] 293.137804 [20:32:42] would that make a octal difference? [20:33:06] no [20:33:11] good :D [20:34:12] even 293.11 is close enough [20:34:22] 293.11 and 293.137805 give the same octal [20:34:23] K2 becomes 2DEC 222.411081 [20:36:20] K3 becomes 2DEC 11.3429651 [20:37:04] great, thanks! [20:37:26] hmm [20:37:39] banksums got worse as a result of that :/ [20:37:55] I wonder if K2VAL and K3VAL were in a different place in memory... [20:38:17] they're only used in interpretive so they could be almost anywhere [20:41:26] hmm [20:41:50] was FANG even a thing in Colossus 249 and earlier? [20:41:57] because the coding also slightly changed [20:42:11] the Colossus 249 coding uses F instead of FANG [20:42:24] yep [20:42:27] that's the only difference [20:48:45] hmmmmm [20:48:53] so why does this make things worse [20:50:34] I can check my math if you want [20:50:40] nah, it's not a math thing [20:50:45] I totally believe your numbers [20:50:51] also yay, just found a routine I had been searching in a Shuttle document [20:50:54] for a MCC display [20:50:55] nice! [20:51:07] also dammit, I found another MSC memo I want [20:51:25] hahahaha [20:54:31] hah [20:54:57] Scott Manley put out a video about that payload door blog you sent me :) [20:56:33] ah, nice [20:56:41] he also tweeted about it [20:57:03] but at that point I had already read it, have been following Wayne Hale's blog for years [20:57:09] always good stuff there [20:59:12] have fun with Comanche, good night! [17:10:49] morning! [17:22:35] hey Mike [17:23:08] what's up? [17:24:32] oh just working a bit more on the iterative procedure for the TLMCC processor that finds e.g. the Delta V to do a flyby and also does some optimization [17:24:44] that's what my most recently desired MSC memo would be about... [17:25:11] found some 1964 and 1965 papers on it, but in a quite early state of it, not very detailed [17:28:22] haha [17:28:37] so you have a number for Ron to look for then? [17:29:30] I would have, yes [17:29:44] I didn't even ask for those 1964 memos he is going to scan next week, haha [17:29:51] hahaha [17:30:17] I just wrote him an email where I explained how useful the documents have been [17:30:28] and how not every document has been useful, as I only know the title pages [17:30:45] and how every document makes me want at least two more documents from the references [17:30:57] so I just gave those Gemini memos as an example [17:31:09] as they are referenced in the LDPP memo [17:31:19] and he just offered to scan them, haha [17:31:29] nice :D [17:31:39] but after that I would already know the next document now [17:31:48] I should look through his NARA documents and see if there's anything I want [17:31:55] those System Status Reports sure would be nice... [17:34:02] there are also some TRW memos about the same topic, the generalized iterator [17:34:16] so not only MPAD memos could be useful [17:36:57] "The Generalized Forward Iterator", 66-FM-55 [17:37:03] this is on the archive NTRS and totally useless [17:37:09] doesn't have anything interesting [17:37:30] if I had requested it, there would be major disappointment [17:38:04] "AS-503A/504A Requirements for the RTCC: Generalized Iterator" 66-FM-131 [17:38:10] this one however should have the good stuff [17:38:39] well I guess I'll get it eventually. If I don't make much progress with the TLMCC processor then I still have some modes to implement in the LDPP [17:42:20] even on the current: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19700026459.pdf [17:42:36] you know it's not going to be exceedingly useful if it still is on NTRS after 2013... [17:43:56] hahahaha yeah [18:04:14] made any progress with Comanche? [18:10:07] no :( [18:10:19] I'm thinking about switching gears for a bit and going back to Sundial / Sundance disassembly [18:17:03] sounds like you have as many projects to choose from as me :D [18:18:53] hahaha yeah :D [17:11:16] morning! [17:12:51] hey [17:12:54] what's up? [17:13:33] figured out that the LOI RTCC Requirements have similar routines for simulating LOI and DOI [17:13:40] both documents, LOI and TLMCC, are for Apollo 14 [17:13:55] LOI document is handwritten, barely readable in places [17:13:59] but it has a program flow for this [17:14:11] TLMCC document is readable, but only explains things in text [17:14:22] so I can combine the knowledge of the two, kind of :D [17:14:24] sounds like a pretty good pairing :D [17:14:32] perfect [17:16:04] there also is a LOI targeting revision 1 for Apollo 14, not changed pages, but a whole new document, and another complete document for Apollo 15 [17:16:12] so eventually those might help [17:17:17] probably should have asked for the later version in the first place [17:17:56] restricted NTRS has a few LOI targeting documents, but they were never freely available [17:18:15] I could still ask for them [17:18:25] can't hurt, worst thing they say no in December or so [17:18:27] that sounds like something they would say no to [17:18:30] haha [17:18:46] for whatever reason they would say no [17:18:55] it's just equations [17:19:05] it's not even engine data, like the LM Data Book might have [17:19:32] spooky equations though [17:19:38] who knows what evil people might do with them [17:19:52] get into lunar orbit [17:25:52] make some sort of apollo simulator [17:26:07] it's hard to think of something worse than that [17:29:16] I'm very guilty already then [17:29:23] :D [17:32:31] so I decided to take one step even further back this weekend [17:32:54] I'm properly reverse-engineering the Retread 50 extended verbs and finishing that disassembly [17:33:15] giving all of the labels and variables proper names instead of "UNKxxxx" [17:34:50] ah, nice [17:35:11] I have everything done except for the pulse torquing verb [17:35:56] which is interesting, it seems like you have to use V21 to set three different addresses to the number of pulses you want to send out before invoking it [17:37:32] sounds like a hassle [17:37:37] yeah, it's weird [17:37:50] there's an extra variable after each channel [17:37:57] at first I thought it was a double precision word or something [17:38:23] but it seems like it counts from address X into address X+1 or something... and once all counts have made it into the second location then it's done [17:38:39] they very clearly didn't care how many erasables they used to implement stuff this early :D [17:38:56] there's a whole three locations that are dedicated into indexing these addresses [17:40:24] before they realized, oops, this is going to be tight [17:40:30] heheh yep [19:32:38] so is Ron doing a full week of scanning this week? [19:53:57] not sure [19:54:03] didn't say anything specific [20:03:34] I'm finally at the point where I can test the calculation for the TLMCC maneuver targeting the specific LOI/DOI geometry of Apollo 14 and alter [20:03:46] very complicated, definitely a lot wrong still [20:49:20] nice! [20:52:00] unfortunately I believe these calculations won't really be valid for missions with LOI-2 circularization maneuvers [20:54:05] I don't even know how it gets to the LOI/DOI geometry when using free-return, but apparently is does, somehow [20:55:49] haha [20:55:56] magic! [21:00:45] I guess it can shift the LOI point enough [21:00:53] which would be costly in DV, but attainable [21:02:37] or if you shift the time at which you arrive at the Moon [21:02:50] which wouldn't be very compatible with any flight plans [21:05:08] good night! [21:16:33] Guenter! [21:16:37] your log is getting big [21:16:40] .stoplogging [21:16:53] ehh is it not that? [21:16:57] .stopmeeting [21:17:29] hmm [21:18:11] Log ended by thewonderidiot, total logging length 4601664 seconds [21:18:12] .endlogging