[21:03:09] NASSP Logging has been started by n7275 [21:03:13] Guenter! [21:43:21] I'll be out on the road again tomorrow. Back on monday. Let's hope everything stays up this time. :) [14:46:30] good morning [14:55:13] hey Ryan [14:56:22] I'm starting to suspect that there might be something wrong with the Block I emulator instead of my IMU/CDU code... [14:56:44] oh really [14:56:58] what's leading you down that path [14:57:57] I admit it's a bit too convenient, but it starts with the prelaunch alignment that it calculates [14:58:05] roll and yaw angle are good [14:58:18] pitch angle is "PI - X" of the angle I am expecting [14:58:34] too exact to be a coincidence? [14:58:40] yeah kind of [14:58:53] although it could be that the issue happens when it takes the complement of a number or so [14:59:44] the IMU is angled at 33° in the Block I CM [14:59:52] so you don't get 90° pitch for launch [15:00:14] oh really [15:00:16] I've checked and rechecked those calculations and I think they are sound [15:00:32] and the prelaunch alignment I am expecting is confirmed by the AOH for Apollo 1 [15:01:01] is the angle just the physical orientation in the vehicle? [15:01:08] yep [15:01:31] the IMU coordinate system in Block I is actually like the sextant coordinate system [15:01:46] 0° trunnion and shaft pointing at 33° also [15:02:10] but I believe it's more for reentry [15:02:12] something to do with sharing CDUs or just orientation of both parallel to the sides of the CM [15:02:31] (just a guess) [15:05:16] I don't really know, but I think during reentry you want the IMU to coincide with the trim pitch angle or so [15:05:53] oh and the gyrocompassing also doesn't make much sense [15:06:05] although that could be caused by the initial alignment being 60° off [15:06:16] haha thats a bit large [15:06:44] and reading this in the emulator code is also not too reassuring [15:06:46] "All the instructions implemented now, though I've had no way to test DV so far." [15:07:00] hmm yellow flag there [15:07:03] DV is divide. Which has a bunch of special cases and is complicated in the Block II emulator as well [15:09:39] I know that at least some of the more complicated calculations in the emulator work right, like the sine and cosine calculations. Or else roll and yaw angle couldn't be correct. [15:09:47] Although I don't know if those need divide [15:11:27] could be a lot of things still though [15:11:45] and the issues start in interpreter code, probably doesn't make debugging easier [15:23:45] if its the emulator itself, is it fixable by you? [15:24:22] morning! [15:24:33] I sense a bus driving my way and feel like I might get thrown under it :D [15:32:41] rcflyinghokie, not by me :D [15:33:05] thewonderidiot, admit it, you love working on the DV instruction [15:33:12] :( [15:33:39] maybe a little bit lol [15:34:13] I mean, it's a long shot, still need to investigate some more if that would even be the problem [15:35:10] right now I am at a point where I think my IMU and CDU work correctly [15:35:54] and the CALCGA routine, which I am quite familiar with, gives a pitch angle I don't like. So maybe the next step is to check the inputs to that routine, if it is consistent with the outputs [15:39:02] on the other hand, I wouldn't be opposed to you taking a quick look at the DV instruction... if it's consistent with R-393 for example [15:46:01] thewonderidiot, so far Antares LGC is performing by the book, no surprises [15:48:27] rcflyinghokie: excellent :D [15:48:52] indy91: sooo Solarium fails SELF-CHECK very badly [15:49:03] it's not even making it to the DV tests because it bombs out before it gets there [15:53:57] indy91 is there any way to use RTCC to compute my sep time for 14 (basically looking for the time my spacecraft is radial down at a given inertial attitude) [15:54:48] or is it radial up lol, ordeal is 90 [15:56:07] up it is [16:02:45] thewonderidiot, oh fun, I guess I'll not even try to get to a liftoff then until we have figured that out [16:03:47] rcflyinghokie, sep time was interesting in the Apollo 11 FIDO loop [16:04:51] there are a few way to get it. And then the FIDO before the descent decided to just use the flight plan value, which is a bit off in pitch [16:05:19] And the lead FIDO Jay Greene, responsible for the descent, wasn't happy about that, but the time was already given to the astronauts [16:05:42] I am doing guess and test with P30 and P41 lol [16:05:47] iterating the time [16:06:02] usually there is a fixed time between sep and DOI... although that doesn't help you on 14 [16:06:34] right [16:06:52] this is just a radially up time, I could just use ordeal but I am trying this iteration and its working [16:08:01] the sep time is also pretty much at a fixed time relative to PDI [16:08:55] so it probably happens at a fixed longitude due to that [16:11:26] indy91, the LP register is not quite working as expected [16:12:20] hmm, not good [16:16:25] rcflyinghokie, another way is using the Maneuver PAD page [16:16:36] and change the TIG until you get the desired IMU pitch [16:18:35] Haha pretty much what I did with P30/P41 [16:18:38] thewonderidiot, I can bother Ron with it if you are too involved in other projects [16:18:42] right haha [16:18:47] RTCC MFD is probably faster [16:19:13] I got it to pass the first failed check :D [16:19:56] I think now it is actually failing in DV [16:20:14] haha [16:20:18] indy91 yeah it would have been :P [16:28:14] what has also helped me having confidence in the IMU orientation is a note in the GSOP [16:28:18] "The sextant base coordinate system referred to above is frequently called the Block I navigation base coordinate system in deference to the present navigation base coordinate system (Block II). Any transformation of vectors [16:28:19] between the sextant and the present navigation base requires use of the above transformations." [16:28:34] indy91, I can look at the DV problem more tonight, but for now I can tell you what my fixes are so far to see if they make any difference [16:28:42] sure, thanks a lot! [16:29:17] so AD and INDEX should both be editing their operands but are not [16:30:10] ok, what does that mean in terms of code [16:30:39] lol, how did anything work if even AD has some issues [16:31:01] so you want to add the line "edit(operand);" after this line: https://github.com/virtualagc/virtualagc/blob/master/yaAGCb1/executeOneInstruction.c#L351 [16:31:01] and after this line: https://github.com/virtualagc/virtualagc/blob/master/yaAGCb1/executeOneInstruction.c#L426 [16:31:23] the instructions themselves work, but they don't cause editing to happen on the writeback [16:31:52] so if you do e.g. "AD LP", what gets added to A is the value of LP, but that also should cause the value stored in LP to be divided by 2 [16:32:02] and it wasn't doing that second part [16:32:05] ah ok [16:32:28] so you can see if that works by doing [16:32:50] V15 N31E [16:32:51] V21 N27E 77777E [16:32:52] KEY REL [16:33:01] second edit between the two } right? [16:33:08] correct yeah [16:33:25] if you did the fix right, the middle register of N31 should make it up to 06305 [16:33:34] otherwise it will be at 06171 [16:34:03] sounds like a good test [16:38:23] that gets me a program alarm, but I see 6305 in R2 [16:39:27] ah wait, N31 is program alarms :D [16:40:38] still calculates the "wrong" pitch angle, but that might be something with DV then [16:41:28] maybe P02 vertical erection works better [16:43:28] P05* [16:44:03] nah, doesn't really make a difference [16:44:32] yeah, I wasn't expecting this to help with your current problem [16:44:41] DV seems like a more likely culprit at this stage [16:46:40] right [16:49:35] with IMU and CDU hopefully working right the last step is to send the attitude error commands to the SCS [16:50:07] then the PGNS part should be mostly done (minus emulator fixes) [18:46:00] I also get to do some fun rewiring, like the LVDC gets to command launch escape tower jettison via the switch selector on Apollo 4 [18:47:46] hehehe [20:35:54] night! [21:08:38] wow okay yeah I just took a quick look at it and DV is definitely extremely broken in Block I [21:19:24] and SELF-CHECK has less useful comments than it does in Block II lol [21:19:34] luckily ND-1021041 has some extremely detailed examples [23:23:56] .....damnit Niklas [23:24:16] I'm going to have to write a control pulse-level simulation of DV to work through this, because the documentation is ambiguous [01:30:16] lol okay [01:30:52] so there was a minor issue in which the contents of LP are either 140000 or 140001 when the result of DV is negative, depending on whether the numerator or the denominator was the negative one [01:31:20] and the emulator was only ever giving 140001 [01:31:29] I doubt that would break anything but SELF-CHECK [01:31:33] *however* [01:32:15] there was a significantly worse bug in which the result of any division with a negative numerator was set to POSMAX = 37777 [01:32:20] regardless of the numbers input [01:32:29] so you couldn't divide a negative number by anything [01:32:35] that is probably where things were going wrong [01:32:53] so, my local emulator is now passing DVCHK [01:33:13] now, what's the next broken thing... [01:34:54] uh oh [01:35:05] now the DSKY just completely stops working when I start SELF-CHECK [01:35:07] lol [03:10:02] that doesn't sound good [03:17:36] yeah this is going to be harder to track down because this next test has a lot of stuff going on [07:36:25] .tell indy91 I opened an issue on github for the yaAGCb1 stuff. Also made a pull request for my fixes so far: https://github.com/virtualagc/virtualagc/pull/1149/files [07:36:49] .tell indy91 DV was extremely broken before, and is now either fixed or at least much less broken [13:29:37] hey [13:50:37] hey [13:50:48] sadly didn't fix it [14:15:08] morning [14:44:27] hey Ryan [14:49:27] So I think I am going to be giving the Apollo 14 abort discreet workaround a try today [14:49:53] I am coming up on PDI0 time which I think is about when they discovered it? [14:53:20] 105:11:05 Haise: Antares, Houston. What we're looking at there is the abort bit, and it looks set. And we'd like to proceed with the following to reset it. [14:54:05] yep thats the transcript page I have up :) [15:21:08] I hope my circ burn worked properly, all I did was use the FP TIG and 60 miles [15:23:37] what calculation method did you use? [15:23:54] I think I've used the general purpose maneuver processor before [15:25:05] I wonder if it can also be done with the descent planning [15:27:19] I think the Apollo 13 FIDO got as far as calculating a circ maneuver [15:27:33] but I didn't take notes properly when I listened to that [15:30:09] hmm actually it might be the same calculation method as Apollo 11 LOI-2, using the rendezvous CDH calculation to get a circular orbit at TPI and not circular just after the maneuver [15:36:20] Yeah I used the general purpose I believe [15:38:50] in Orbiter orbits stay circular, so should be good [15:41:58] haha ok cool [15:42:32] and not this: https://i.imgur.com/8rq3mUI.png [15:48:24] was that actual? [15:48:27] mascons? [15:50:05] morning! [15:51:32] good morning :) [15:53:02] hey Mike [15:53:28] rcflyinghokie, that's with the onboard gravity model, also used in the RTCC, yeah probably mascons [15:53:47] thewonderidiot, thanks for the DV fixes! Sadly they didn't change a thing for me... [15:53:55] I also got the DSKY freeze during the self test [15:54:07] cool cool [15:54:13] fxing things makes behavior worse :D [15:54:19] haha [15:54:22] I have been investigating from my own angle [15:54:48] as you know I didn't like the angles that P01 tries to align to [15:55:02] returned by the routine CALCGA [15:55:14] so I saved a scenario that still has the inputs to that routine [15:55:28] which is two rotation matrizes basically [15:55:35] converted it from octal and scaling etc. [15:55:44] and fed them to my own CALCGA [15:55:53] from Block II GSOP, but it's the same [15:56:06] and it does have a difference to what Solarium came up with in pitch [15:56:22] it's actually 90° away from what I thought, but I think this was a change from earlier Block I [15:56:44] it still has the PIPA along a main axis, X-axis, not Z-axis. I have two sources that pointed to that [15:57:09] so instead of 56° something I get 328.3° [15:57:12] both values good [15:57:18] 121.69° is what Solarium calculates, bad [15:57:37] so I then tracked it down even further, recovering data from VAC areas haha [15:57:48] and that's what I wrote on Github [15:58:07] hahahaha wow [15:58:07] I know the inputs and output of the last call to ARCTRIG [15:58:11] and they are not consistent [15:58:26] so now we have to learn how to read and debug Block I interpretive code :P [15:58:49] I haven't gotten much further, but my feeling is ASIN doesn't like negative numbers as input [15:58:59] https://www.ibiblio.org/apollo/listings/Solarium055/BANK_03_INTERPRETER_SECTION.agc.html#41524353494E [15:59:06] so maybe this is where we should look [15:59:07] ARCSIN [15:59:32] in the AD routine there is a comment " // FIXME Not sure what's supposed to happen if A already has [15:59:33] // overflowed." [15:59:51] so maybe an AD bug? [15:59:53] no idea [15:59:55] that's all I have haha [16:00:58] hahahaha [16:05:12] I've started to experiment with debugging directly in the emulator [16:05:33] I have e.g. added a hold point that stops when MPAC has a specific value [16:06:28] maybe it would be helpful to add a stop when a specific instruction is read from fixed memory [16:06:38] so basically when the emulator gets to the ARCSIN routine [16:09:25] yeah [16:09:42] ARCSIN is complicated but at least if the error is there, it's in basic and not interpretive... [16:13:05] right, I think before my approach is going to be of any help we have to get back to basic [16:14:00] I wonder if "AD POSMAX" is related to that FIXME... [16:19:28] oh well, for now, back to the programer [16:19:52] hahaha [16:20:36] LVDC has everything through orbital insertion, but a bunch more work needed for later [17:30:18] hmm I seem to be unable to calculate my PDI pad [17:31:32] my tland is now nan [17:32:30] I was trying to compute a PDI0 earlier and couldnt make it work...but I think I screwed up something in the process [17:35:33] maybe calculate a new DOI, that gets you a new TLAND [17:36:15] I thought there was a manual input, but right now there doesn't seem to be one [17:36:37] ah well, untrue, you can input it on the REFSMMAT page [17:36:48] when it has the LS REFSMMAT option up [17:37:44] I need to use the MPT for a new DOI? [17:38:01] why would you? [17:38:13] because its in the past? [17:38:30] I think you can't even calculate maneuvers in the past with the MPT haha [17:39:07] I just compute a DOI again like I did before? [17:39:13] yes [17:39:15] revs = 0 [17:39:33] so as if you would do a DOI half an orbit before PDI [17:40:16] where do I put revs in? [17:40:21] init page I think [17:40:24] for the LDP [17:40:38] N? [17:40:57] yep [17:41:04] it has 11 right now [17:41:17] right, that's the actual DOI on Apollo 14 [17:41:22] but you are well past that [17:41:31] you don't even want to calculate a DOI, just the TLAND [17:41:42] when I put 1 in there it sets my tland to 89h [17:41:47] 11 had the correct tland [17:42:10] then your threshold time needs to be changed [17:42:18] also it is 0 [17:42:19] why cant I just leave 11 in there [17:42:20] not 1 [17:42:25] it worked just fine lol [17:42:41] well that not going to improve accuracy [17:42:56] propagate 11 orbits back and then DOI and iterate on 11 orbits in the future [17:43:02] N is zero [17:43:08] TH1 is 86h [17:43:19] when is PDI roughly? [17:43:26] use 1.5 hours earlier as the threshold time [17:43:42] as DOI will normally be 1 hour before PDI, on Apollo 11/12 [17:43:45] 108:42 or so [17:43:58] doesn't have to be exact, just to the hour I think [17:44:03] this is 14 [17:44:45] with N=0 there is just half an orbit between DOI and PDI. So maybe use 107:15 as the threshold [17:45:01] used 107 [17:45:14] got the same tland as when I left N=11 and everything else alone lol [17:45:28] and what kind of DOI DV do you get? [17:45:32] Should be really small [17:45:44] 0 0 .2 [17:45:44] this is essentially a DOI trim calculation [17:45:53] ah I see [17:46:03] I thought we were computing the original DOI again thats why I was confused [17:46:15] nah, that is way in the past, no advantage to that [17:46:52] doing a DOI calculation for near the current time is definitely the more accurate solution, but if it's the same TLAND; all the better [17:47:03] yep down to the second [17:47:39] and what did you calculate for PDI0 that might have screwed up the TLAND? [17:47:48] Was that a DOI, too, or a PDI PAD [17:49:37] no idea I think I just started experimenting [17:50:10] the instructions in the RTCC manual didnt work quite right [17:50:46] couldnt get a GET P in the FDO display that matched my pdio0 time [17:50:57] pdi0 [17:53:32] hmm, bad [17:54:26] what did it find instead? Random time or a different rev or so? [17:56:13] different rev I assume [17:56:21] I'd need to reload and look [17:57:34] that might be a threshold time, too [17:57:39] what you input [17:57:58] I'd have to check [17:59:40] I didnt see a entry for that [18:00:39] but I was kind of loosley trying it anyways [18:01:12] U12 MED, right? [18:01:48] well if it comes up again we can check [18:02:20] I just went to the page and looked for GET P [18:03:45] well there is two of them [18:03:52] one is the next upcoming GET of periapsis [18:04:21] and then there is the GETR button where you can request apoapsis/periapsis data with a input time, maneuver or rev [18:05:04] "(for later REV use GETR: U12,LEM,REV,desried REV)" is what Alex wrote there [18:06:06] yeah it wasn't clear to me to be honest haha [18:07:12] hmm another issue [18:07:42] Arent I supposed to be getting a time until PDI ignition on P63 N61? [18:09:00] uhh, I think so [18:09:05] is it at 59:59? [18:09:08] its 59 59 but less than an hour to go [18:09:21] you can check TIG directly [18:09:27] V16 N33 [18:09:38] hmm [18:09:42] 108:48 [18:09:45] more TLAND issues? [18:09:46] pad has 108:44 [18:09:58] just uplinked it [18:10:11] MPT active? [18:10:27] nope [18:10:53] tland on the PDI page is correct [18:11:10] pdi pad page* [18:11:12] they should agree very closely, to a second, or else something is wrong [18:11:17] either in the LGC or the RTCC [18:11:35] pdi pad is 4 minutes earlier than LGC [18:11:51] I think I need a scenario [18:12:08] yep im doing that now lol [18:12:26] a while ago I even gave the RTCC the ability to use the exact same ignition algorithm parameters as the LGC [18:12:32] before it was the same for all missions [18:12:38] now it's mission specific [18:13:26] https://www.dropbox.com/s/95m0agz7b2xh3jn/Apollo%2014%20-%20PDI%20Mismatch.scn?dl=0 [18:14:15] when I moved those mission specific parameters to a RTCC config file I could have made some errors [18:14:17] will check [18:15:08] but it's probably something else [18:15:13] pad tig is 108:44:21.46 LGC tig is 108:48:42.37 [18:17:20] ignition algorithm numbers in the RTCC agree with the padload document [18:18:47] so what could be causing the difference [18:19:38] I was confused about the SV update, it said PDI-10 but I didnt know if it was for both vehicles or just one of them [18:19:50] I did a PDI-10 SV update for both slots in both vehicles [18:20:06] state vector is good [18:21:56] hmm [18:22:03] R1 of N61 doesn't look right [18:23:11] -19 yeah [18:24:21] isnt that TGO [18:25:06] yeah, should be identical to a padload [18:25:17] 470 seconds [18:25:25] I think... [18:26:21] "TG min-sec" [18:27:16] none of these numbers in the memory make much sense to me [18:29:14] that doesnt sound good [18:31:29] not even sure how this is passing the ignition algorithm [18:32:20] did you run P20 in the LGC at some point? [18:33:48] what I have seen so far is that the memory that is completely gone is the part overlayed with the W-Matrix [18:34:38] bank E5 is completely gone it looks like [18:34:48] completely different set of data [18:35:07] if you ran P20 and it took just one mark then this is what would happen [18:35:18] You can run P20 somewhat safely if no marks are done [18:36:54] I ran a P20 with marking [18:36:58] ouch [18:37:13] Why did that mess it up? [18:37:20] yeah, this is always going to happen then [18:37:34] W-Matrix uses the same erasable memory as all the descent padloads [18:37:44] oh wow [18:37:54] I had no idea lol [18:38:27] "If P20 is selected in the update mode prior to completion of P66, the W-matrix initialization will destroy the E-memory descent targets." [18:38:46] where is that [18:38:47] should have sticked to the flight plan lol [18:38:56] AGC program notes [18:39:09] https://www.ibiblio.org/apollo/Documents/msc05225.pdf [18:39:25] I think you can recover though [18:39:37] but you basically need to replace the entire bank E5 [18:39:40] with the padload [18:40:38] well, I think I know what to do [18:40:44] Nothing in the docs for earlier missions? [18:41:34] it's the same for them all [18:41:45] W-Matrix always overlays the descent targets [18:42:00] I can do a quick copy&paste job [18:42:22] but I'll delete the rest of your bank E5, hopefully nothing else important in there [18:42:59] there are some checklists that call P20 without markings before landing [18:43:03] always makes me nervous lol [18:44:10] but yeah, this is something good to keep in mind [18:44:13] no marking before landing [18:44:45] it's a wonder this was able to pass the ignition algorithm [18:45:21] well the PDI TIG now agrees within a tenth, hopefully it all works from here [18:46:08] https://drive.google.com/file/d/1Tay27KQftI5uGthLJUdI9ydyBsNrHIpM/view?usp=sharing [18:46:25] what I did was replace EMEM2400 to 2777 with the LMPAD values from the launch scenario [18:49:48] Lol if that works I can roll with it [18:58:53] yeah I hope nothing permanent is stored in the upper regions of E5 [19:01:11] mostly P52/P57 temporary data [19:02:10] I hope, and I am sure, that the GUIDO had this case prepared haha [19:02:29] some tape or punch cards with the descent targets for the case they get deleted [19:02:45] would be a lengthly uplink, but doable [19:07:51] well I am computing the no pdi 12 now, so I will let you know how PDI goes haha [19:08:06] I also need to pull the procedure for the abort [19:08:13] *abort discreet* [19:10:19] VAGC site to the rescue lol [19:11:10] quickly call Don if he can do it from memory [19:19:00] haha [19:19:19] hmm what kind of orbit should my no pdi+12 give me [19:20:16] I got 117x7.7 [19:20:38] sounds about right [19:21:01] you want to end up behind the CSM [19:21:05] so you need to go hiiiigh up [19:21:06] OK cool [19:26:33] there are some extremely unlikely cases where you need to go as high as 300NM [19:48:57] so for the manual throttle up, will my manual throttle work if throttle is in auto? [19:51:00] its a little confusing in the transcript [19:51:15] "manual throttle up overriding the auto" [19:54:32] I think manual throttle just gets added to auto throttle [19:55:08] even in auto throttle mode [19:56:17] thats what it sounds like [19:58:56] ok set to 71 [19:59:05] 4 minutes to go [20:11:45] ok everything is in, no aborts lol [20:20:51] :D [20:41:48] night! [15:19:39] good morning [15:41:45] i dont know if it has something to do with the padload changes but LPD mode crashes me into the moon [15:43:05] tried 3 times last night all just took me right into the surface, going to try auto now [15:49:28] hm or was there no longer auto [15:52:00] hey [15:52:34] LPD mode? So you are doing some redesignations and it does bad thing? [15:52:36] things* [15:53:52] wvwn if I leave it in nominal landing site it does [15:53:54] *even [15:54:29] there still is about 40 seconds left on the timer when I hit the surface [15:54:30] right [15:54:41] LR is converged? [15:54:45] yes [15:54:58] so you crash in P64 [15:55:39] yes [15:55:41] https://www.dropbox.com/s/zxn830cl4axbf2o/Apollo%2014%20-%20PDI%20Ignition.scn?dl=0 [15:56:07] uhhh [15:56:12] this is weird [15:56:23] in the scenario I send you there is still some "LMPAD"s [15:56:39] ah no [15:56:49] I saved the scenario under a different name [15:57:05] but somehow I had already saved the original scenario with some edits [15:59:26] so those edits are ok? [15:59:36] yes [15:59:46] I deleted all of bank 5 though and replaced it with the padload [15:59:59] but I am not seeing anything permanently stored in there... [16:00:49] I could put the part of the memory back in that isn't taken up by the W-Matrix [16:01:03] but I am 90% sure that won't do anything [16:01:34] if it just happily flies into the surface then that sounds like a problem with the P64 descent target, but that has been fixed [16:02:44] I am going to triple check the LR converged but I am pretty certain it did [16:03:34] its just the V57, PRO, verify R1 decreasing, and PRO [16:03:37] correct [16:04:05] well if R1 is near 0 it's all good [16:04:24] uhh [16:04:29] R3 sorry [16:04:31] your procedure is for early missions [16:04:39] now I am confused [16:04:45] oh, we have Luminary 178, I forgot [16:04:56] not using Luminary 210 anymore for Apollo 14 [16:05:11] yeah [16:05:13] they changed the display, I guess for Apollo 15 [16:05:29] yeah R3 [16:05:39] in N68 [16:05:47] and if something LR related goes bad you would also get a blinking ALT or VEL light [16:06:00] It went to zero then climbed in the negative [16:06:11] then back towards zero then climbs in the positive etc [16:06:36] yeah, quite normal with terrain [16:06:46] always seems to try to converge on zero [16:07:07] we have tried landings with Luminary 178 before, right? [16:07:13] when it was new... [16:07:17] not sure about a complete mission [16:07:18] checking the tapes they are about 200 ft different and converging [16:07:23] I never have so I cannot speak for it [16:08:15] N68 still looks good [16:08:29] oh on the 14 LM timeline, what is V21N69 [16:08:53] redesignate landing site? [16:09:38] yep, from last minute ground tracking [16:09:45] for pinpoint landings [16:09:48] first used on Apollo 12 [16:10:05] N69 is in all three axes, R1 (so what you edit with V21) is downrange [16:10:17] ok so the LR and PGNS have about 700-1000 feet difference in P64 [16:10:26] they never seem to converge closer than that [16:10:30] interesting [16:10:32] maybe my antenna isnt moving to hover? [16:10:40] maybe I need to take a look at the padload [16:10:50] I'll try a landing with your scenario [16:10:59] would the landing target be an issue? [16:11:01] ok [16:11:16] so still need master arm and enging arm des [16:11:31] engine* [16:11:41] then the Apollo 14 "hack" [16:11:59] nah, I don't have your code change [16:12:11] or if you have just pushed in the abort button I can unpush it [16:12:23] I did the code change [16:12:37] but I also have the modereg change in [16:12:42] oh [16:12:53] well, I'll see what happens [16:12:54] so you will need to do it [16:13:22] I'm kind of betting on a padload problem right now [16:13:31] maybe one I didn't do in the testing scenario where I tried a landing [16:13:38] an error* [16:13:51] but now appears because I screwed it up in the launch scenari [16:13:52] o [16:14:44] I believe we don't even have the padload in octal form for 14 [16:14:53] conversion error? [16:15:08] my conversions are usually good, it's the typos in the padload that is getting me [16:15:19] or could this still stem from the w matrix fixes [16:15:20] the same address twice etc. [16:15:23] ah [16:15:31] I mean it could be, but I'm kind of doubting it [16:15:39] not the first thing I'll look at [16:21:14] hides [16:23:15] rcflyinghokie, did you move your throttle all the way back to 0? [16:23:21] after the procedure [16:24:05] yes [16:24:15] throttle down etc worked properly [16:28:39] oh I do get a blinking ALT light [16:29:22] I got it shortly before hitting the surface [16:29:27] and large DH [16:29:32] in P64? [16:29:36] yep [16:29:38] just before impact [16:29:40] same here every time [16:30:07] either a padload issue or something with the abort discrete masking [16:32:32] found something [16:33:10] EMEM3756 5 [16:33:17] "LR Weighting Function" [16:33:28] should be [16:33:29] LMPAD 3756 13146 [16:33:39] so a lot larger [16:33:52] I guess that would make the LR data converge extremely slowly [16:34:29] already 5 in the scenario I fixed [16:34:34] now, this is the last entry in the LM padload [16:34:39] and we have a weird system for it [16:35:09] LMPADCNT 247 [16:35:20] this number has to match the number of entries in the padload [16:35:23] but it does match [16:35:24] hmm [16:35:30] hmm indeed [16:35:48] there are some overlays for this [16:35:54] maybe it got destroyed with the W-Matrix [16:35:55] RM [16:36:02] # I(2)OUT RANGE READING [16:36:05] RR related [16:36:42] LRWH1 is the one padload that moved between 210 and 178 [16:37:00] interesting [16:37:18] I'm glad you came out of hiding haha [16:37:24] haha [16:37:48] well (for better or worse) I plan on flying 15-17 completely after 14 [16:38:13] Having never flown 14-17 I can look on things with fresh eyes [16:38:20] it moved because of anomaly L-1D-08 [16:40:49] https://www.ibiblio.org/apollo/Documents/contents_of_luminary_1e.pdf#page=325 [16:41:32] so, rcflyinghokie, did you ever use P20? [16:41:48] yes [16:41:55] we crossed that bridge lol [16:42:15] Nik fixed my bad EMEMs [16:42:22] hah gotcha [16:42:54] But yeah I did not know that issue existed [16:43:02] was that an issue with 11/12 as well? [16:43:22] yes [16:43:23] or before (I know 10 ran P63 as well) [16:43:50] I will keep that in mind before pressing V80 ;) [16:44:07] yeah even in Luminary 69 the W-Matrix is overlayed with the descent targets [16:44:11] LRWH1 was added between Luminary revs 152 and 154 [16:44:26] so that padload specifically isn't an issue before 14 at least [16:45:22] trying to find out what all writes to RM [16:46:29] but I guess L-1D-08 is the answer [16:46:43] got overwritten by P20 [16:47:21] and that only says "selected" [16:47:38] P20 might even overwrite LRWH1 without marking [16:47:58] rcflyinghokie, or is P20 normally called on Apollo 14, just without marks? [16:48:23] nope that was all me [16:48:32] I think they did some RR tracking but didnt use P20 [16:48:57] V21 N01E 3756E 13146E [16:49:22] or change "EMEM3756 5" in your scenarios [16:49:34] to EMEM3756 13146 [16:49:52] did the P20 mess that up [16:50:00] yeah [16:50:03] ok [16:50:22] Luminary anomaly L-ID-08 describes it nicely [16:50:33] lets give her a test [16:50:51] and this might have even done something bad with just P20, not marks [16:51:07] yeah no P20 in the flight plan or LM procedures for 14 [16:51:10] in Luminary ID only. Thats why they moved it in 1E [16:56:06] thewonderidiot, I've done a bunch of work on the programer. Still lots to do, but the AS-501 Systems Handbook is quite good. Just one page not 100% readable. [16:56:14] oh nice :D [16:56:30] I didn't get a chance to work on Block I stuff yesterday, but will try to today [16:56:38] ah great [16:56:53] the only help I can be with that is to track down further this issue that happens in ARCTRIG [16:57:30] that would certainly help :D [16:57:39] with TRIG1 and TRIG2 it has two branches. So I could try to figure out if it gets there at all [16:57:58] because right now the next level further down is any of the interpreter instructions used [16:57:59] I think I'm going to keep going with SELF-CHECK to try to get that all passing [16:58:04] right [16:58:32] I need to get some debugging stuff going that tells me if and how often it gets to a specific point in the code [16:58:55] it probably only calls ARCTRIG three times, for each of the IMU angles to align to [17:00:01] SINTH positive and COSTH negative seems to work correctly, that's in one of the other angles [17:00:08] this is already looking a lot better [17:00:10] SINTH negative and COSTH position doesn't [17:00:15] at throttle down [17:00:56] rcflyinghokie, the problematic padload value is how much weight it gives to the LR measurement vs. the current PGNS state vector [17:01:02] normal value is 0.35 [17:01:17] you had about 0.0003 [17:01:39] that's never going to converge quick enough [17:02:49] hehehe [17:06:05] touchdown [17:06:07] all worked well [17:06:13] hooray! [17:06:25] so all stemmed from the P20 haha [17:06:32] I am perfectly happy with the problem being that my Luminary 178 is accurate haha [17:08:05] isnt the dps pressure supposed to decrease when I fire the vents? [17:08:39] ah there it goes [17:09:47] if (regBank == 022 && regZ == 06436) [17:09:47] { [17:09:48] agc.debugcounter++; [17:09:49] } [17:09:51] thewonderidiot, would this work? [17:10:05] to see how often it got to 06,6436? [17:10:08] very crude I know... [17:10:16] uhh [17:10:31] 22,6436 of course [17:11:36] yeah, I put in stuff like that all the time when I'm debugging this stort of stuff [17:11:49] I hope for 3 [17:12:05] and then I can check if it gets to TRIG1 and TRIG2 at all [17:16:26] hmm, didn't work [17:16:46] uhh one sec [17:17:17] oh [17:17:18] yeah [17:17:20] that won't work [17:17:40] Z will never point to interpretive code [17:17:54] since it's not the process executing it but rather the interpreter [17:18:02] ah damn [17:18:15] I thought it would at least be as simple as "has to read from that location" [17:19:03] hopefully I can track it down enough today that we get out of interpretive... [17:20:18] looks like the interpreter loads instructions from the address stored in LOC [17:21:23] it might just work if you replace regZ with address 120 [17:21:46] but keep bank the same [17:21:51] I think so yeah [17:22:19] let's see what that does... [17:27:07] still 0 [17:27:12] mmm [17:27:30] I think I'll just add a memory access function [17:27:34] and check it there [17:28:00] because then all places where the emulator accesses the memory is included [17:28:14] right yeah, that's probably better for interpretive stuff [17:30:06] hopefully it's not reading from it more than once at a time [17:31:58] hey there simplygeometry :D [17:32:29] Hi there thewonderidiot :-D [17:36:37] hello! [17:38:24] damn I was given a star not on the markers list and I cannot tell which it is visually :P [17:42:33] sometimes that works well, but with the AOT it's always hard [17:46:38] yeah I am going to need to just use a marker star :P [17:47:07] the coordinates from the checklist are just beyond the AOT view there [17:47:40] maybe I can make an extended marker file with all the RTCC stars [17:47:47] well, I don't have all the RTCC stars sadly [17:48:03] but the next few hundred, surely all the ones used on actual missions [17:48:37] thewonderidiot, I am confused by the macro "flatten" [17:48:47] is that supposed to just subtract 6000? [17:49:08] I thought it would give me the fixed memory address directly [17:49:22] like 22,6436 converted to a large number [17:49:36] directly the address to agc.memory [17:49:40] it's basically making a CADR [17:49:45] but it just gives me 436 [17:50:05] but flatten is used to directly request something from memory in some places... [17:50:13] wait [17:50:19] fetchedFromOperand = readmemory(flatten(regBank, operand)); [17:50:21] waaait [17:50:22] like that [17:50:34] #define flatten(bank,offset) ((bank == 0) ? offset : (bank + (offset & 01777))) [17:50:37] well that is my own readmemory function [17:50:42] there is no way that adding bank directly to the bank offset is correct [17:50:48] oh unless bank is pre-shifted [17:51:10] used with regBank [17:51:13] might be preshifted? [17:51:53] yeah looks like it is [17:52:12] for a moment we both probably thought "surely it can't be that broken" haha [17:52:19] hahaha yup [17:52:21] if (®Bank== &agc.memory[flatAddress]) agc.memory[flatAddress] = value & 076000; [17:52:30] yeah it's only writing the upper bits to regBank [17:57:39] let's see [17:57:45] so how the hell do I debug RUPTCHK [18:03:25] lol [18:03:38] CALCGA is not the same in Solarium... [18:03:52] it's never even calling ARCTRIG for the problematic angle [18:04:35] how did I overlook that haha [18:05:01] hmm [18:05:07] or does it... [18:05:44] it doesn't do it for the yaw angle [18:06:02] but does for the pitch angle, so it's just one call less [18:07:15] just slightly inferior math, but over all the same [18:07:55] so it should get to TRIG1 twice and to TRIG2 one time [18:08:06] and it got to ARCTRIG twice, that's how I noticed [18:08:39] haha [18:08:42] instead of three times [18:08:45] Block I interpretive code is so weird [18:08:54] it just takes an ASIN for the yaw angle [18:08:58] instead of ARCTRIG [18:09:28] doesn't change the result [18:11:48] it does reach TRIG1 twice [18:13:48] oh actually [18:14:06] that FIXME in AD about the accumulator already having overflow [18:14:16] may actually be the problem with RUPTCHK [18:14:49] it does a whole lot of weird stuff with overflow assuming that it will hold off a waitlist task they scheduled [18:15:28] it gets to TRIG2 twice, which it shouldn't do [18:15:53] oh! that's a good clue :D [18:16:02] so what does it do there.. [18:16:19] BMN 0 [18:16:20] COSTH [18:16:22] TRIG2 [18:16:30] COSTH is positive [18:16:35] but it goes to TRIG2 anyway [18:16:50] but I will check if that's actually the case [18:17:00] COSTH being positive there [18:19:17] BMN being broken somehow would be very surprising lol [18:19:22] that seems like an easy one [18:21:04] COSTH is the same as I saved it from the VAC area [18:21:14] EMEM0237 = 6635; [18:21:15] EMEM0240 = 11244; [18:21:57] so BMN does triple precision, too, right? [18:22:19] 241 is negative, because 241 and 242 are SINTH [18:22:26] but probably not the reason for this... [18:22:53] but if it's some overflow thing who knows... [18:23:48] yeah [18:23:56] man RUPTCHK is insanity [18:23:59] haha [18:24:00] specifically the code at WAIT1 [18:25:11] following through it, I think that there may be multiple emulator errors all happening in the span of a few instructions [18:25:22] I wonder if I can manipulate this ARCTRIG calculation haha [18:25:29] sounds fun [18:25:37] like I think that A is supposed to have overflow for a long time, but it's lost on the very first CCS instruction [18:26:06] and then that TS A at the bottom -- I'm pretty sure A is supposed to retain its value when you do that, but it gets set to +1 [18:26:17] actually that might be the most glaring problem [18:26:50] and I thought implementing the peripherals for the emulator was going to be the difficult part [18:27:03] hehehe [18:27:37] let me look at the control pulse sequence for TS [18:28:10] !!!! [18:28:12] hey guess what [18:28:21] while I'm looking at this [18:28:30] 0419 REF 1 03,6624 3 6753 0 ARCSIN CAF TCTAG+1 PICK UP ARCSIN BRANCH [18:28:31] 0420 REF 2 LAST 48 03,6625 6 4476 0 AD POSMAX TO FORCE OVERFLOW [18:28:32] 0421 03,6626 5 0000 1 OVSK SKIP AND RESTORE NON-OVERFLOW [18:28:35] that OVSK [18:28:41] that's a TS A, that I think is broken [18:30:43] yeah that's definitely a big bug [18:34:10] indy91_: https://github.com/virtualagc/virtualagc/pull/1149/commits/fd07c5b8170141de2ae8115ba2f61464f91acb8d [18:34:16] ARCSIN is definitely broken without this [18:34:58] and I still have more problems to fix in RUPTCHK, but this is the one most likely to affect you at the moment [18:40:31] great! [18:40:58] oh wait hold on, that might still be slightly wrong [18:41:07] yeah so what I had figured out before is that for the angle ARCTRIG comes up with to make sense it has to both branch wrong and then ASIN returning a wrong value [18:42:08] in both cases where SINTH is positive ARCSIN works right [18:42:18] in the case where it's negative it was wrong [18:43:36] no that is correct [18:43:38] that fix [18:43:45] ok, let me try [18:47:28] ! [18:47:32] angle is now correct [18:47:39] oh hell yeah [18:47:58] maybe P05 and P02 like it better now, too [18:49:50] I'm still confused about the branching [18:49:59] maybe I got that wrong, it looked like it's still doing it [18:50:38] all the PIPA increments are now in the X-axis [18:50:42] I think that's what it wants [18:50:58] meaning IMU angles and IMU coordinate transformation in NASSP are correct [18:51:54] hmm, that is still wrong, but could be something with our PIPA [18:52:12] I just added a bunch of Block II code that we used for the PIPAs [18:52:21] might be wrong to do it that way [18:52:51] but P01 at least works right now haha [18:56:52] :D [18:56:53] progress! [19:01:36] yep [19:01:40] I just copied over the CounterPINC, CounterMINC and UnprogrammedIncrement functions for the PIPA [19:03:47] alright well I'm going to keep on fixing RUPTCHK lol [19:04:32] haha ok [19:04:47] I'll try to understand this P05 code [19:13:58] lol apparently I had to fix CCS with overflow for Block II as well [19:15:04] was that the harmless program alarm during lunar ascent? [19:15:24] hmmm, might have been [19:15:30] either that or another weird DV case [19:16:34] I think it was this, I knew I had this on Imgur still: https://i.imgur.com/kl2pV95.png [19:16:44] but might have been a different bug [19:17:12] hah [19:17:17] yeah I think it was in that LIMIT [19:17:46] https://youtu.be/bT7JGyOae6U?t=321 [19:19:13] yeah that was DV [19:19:17] https://github.com/virtualagc/virtualagc/issues/52 [19:20:18] I'm sure we're going to have more fun with Block I DV before this is over [19:20:20] ah ok [19:20:25] I bet [19:20:37] and when that fun is over my fun begins [19:20:43] flying the mission [19:21:41] hehehe [19:24:18] lol well first I had to do it for DV, but now I'm going to have to write a control pulse implementation for CCS as well to study its behavior with overflow [19:25:51] I have never looked at the vertical erection subroutine, this is going to take a while... [19:26:51] take your time, SELF-CHECK is going to keep me entertained for a while :D [19:34:15] does Solarium have a full self check? [19:34:23] sure does [19:35:01] this would have been so much more annoying without it haha [19:37:50] hmmmmm [19:38:00] does TMZ look at both sign bits [19:38:06] need to consult the schematics... [19:41:34] okay yes it does look at all 16 bits [19:43:35] wow there's a CCS1 subinstruction? [19:43:38] Block I is so weird [19:43:43] haha [19:43:49] maybe I should check if the behavior of the gyro pulses is now different with the fixes [19:44:03] I checked it before that V42 does the same thing as in Block II though [19:48:41] just looking at the PIPA counters now. It does kind of behave like it can't find the acceleration axis [20:07:22] okay control pulse simulation of CCS is working [20:07:25] now how does it handle overflow [20:08:19] input is 077766 [20:09:41] okay cool, yeah, treats it as a positive number and decrements it to 077765 [20:10:07] yaAGCb1 is taking the right branch but turning it into 037765 [20:11:42] I think 037765 != 077765 [20:11:46] yeah I agree :D [20:11:58] oh man I need to change a lot about CCS for this [20:18:35] okay now it breaks sooner [20:20:28] AD actually does the right thing [20:20:53] SU -0 does not [20:21:26] that is sign extending when it should not [20:21:33] presumably [20:22:44] haha [20:22:57] I'm checking the padload. I know I had a few typos in the worksheet [20:23:38] right now I don't really like what Solarium has in DELV each timestep, accumulated delta V from gravity. But not sure if it's right or wrong [20:25:02] might have to compare to Block II. But P02 there only runs vertical erection every few minutes, might be tricky [20:34:52] !!!! [20:34:55] I fixed RUPTCHK :D [20:35:05] and the DSKY works when running SELF-CHECK again! [20:36:00] new R2 of N31 is 6605 [20:36:05] which means there's a problem in the CYCLSHFT test [20:36:28] some other instruction is probably not editing when it should be [20:41:04] indy91_: https://github.com/virtualagc/virtualagc/pull/1149/commits/9587743958db3c7f6dcf9cf4771d21dc3ef86468 [20:41:12] those are the fixes that get RUPTCHK working [20:43:19] awesome [20:43:39] I kind of doubt this is going to fix my current issue, but let's see... [20:44:02] haha also make sure you get 6605 in N31 if you do self-check, just to make sure we're fully synced up [20:45:21] will do [20:46:10] how would I stop the self check? V21N27E 0E? [20:46:20] yep! [20:46:55] So Stu would like to know how to compute the REFSMMAT for the CSM plane change [20:47:35] It doesnt look like its a P30 REFSMMAT but it is close [20:48:41] the actual FIDOs don't even know [20:48:51] hahahaha [20:48:53] haha really [20:48:54] that's my conclusion from listening to the Apollo 11 FIDO audio haha [20:49:03] amazing [20:50:07] they did a bunch of trial and error with plus and minus signs for a manuever, which then was used for the REFSMMAT [20:50:17] hmm, but how should it be done... [20:50:26] thewonderidiot, I do get 1102, 6605, 1 in N31 [20:50:35] perfect [20:50:43] and on that subject, my computed burn time is almost an hour before the actual [20:51:13] so the TIG-1h didnt quite work [20:51:14] for plane change? [20:51:17] yep [20:51:32] well there is a plane change opportunity twice per orbit [20:51:33] had to use TIG -45 minutes for it to give me the correct one [20:51:50] yeah, I think an hour before is too random, 45 minutes is better [20:51:58] because it's an hour between opportunities [20:52:25] CSM plane change REFSMMAT... for which mission? [20:52:26] Yeah agreed [20:52:30] Apollo 14 [20:52:54] ah, that Stu [20:53:00] yep [20:53:01] :P [20:53:11] Al and Ed are playing on the surface right now [20:53:50] flight plan has a definition of it, not sure if that is right [20:53:53] page 1-6 [20:54:46] thewonderidiot, ! [20:54:52] I think it fixed the P05 issue [20:54:55] so it is a P30 REFSMMAT it seems [20:55:09] did a tiny adjustment, now PIPA Y and Z are 0, so perfectly aligned [20:55:11] oh shit, no way! [20:55:27] N21 shows the PIPA since the last zeroing [20:55:35] R2 and R3 always zero [20:56:34] when it goes to P02 it does some more stuff, let's see if it stays the same as in P05 [20:56:37] :D [20:59:28] rcflyinghokie, Apollo 14 FIDO postflight report has some stuff [21:00:45] is that in the mission report or separate [21:00:52] "The LOPC-1 REFSMMAT was generated for a 0, 0, o heads up orientation at burn initiate. This attitude negated the use of the high gain - antenna during the maneuver and also had the optics pointed toward the [21:00:53] moon at the tine of the sextant star check in burn attitude. Since post-LOPC-1 lunar orbit activities were generated with gimbal angles relative to the OT REFSMMAT, the RFFSMMAT could not be changed; therefore, LOPC-1 was "rolled over" relative to the 0, 0, 0 heads up REFSMMAT and al-l criteriaia (pre and post-burn) were satisfied." [21:01:02] separate, got it from UHCL a while ago [21:01:16] thewonderidiot, P02 is happy too, no surprise at this point though [21:01:31] so seems like we got the two big issues I had so far solved! [21:01:51] hell yeah [21:03:06] ah it was generated heads up but burned heads down? [21:03:33] I guess so... [21:03:58] haha ok [21:04:06] Spacecraft attitude: Roll, 180°; Pitch, 354°; Yaw, 2° [21:04:13] for LOPC-1 [21:04:28] thats actually what the flight plan says pretty much [21:04:38] hmm, but the REFSMMAT might simply be the one in the operational trajectory [21:05:06] but I guess P30 heads up and then for the Maneuver PAD heads down will get you close [21:05:13] also, any idea why the mission report has a different TIG for the PC? [21:06:14] different from what. The flight plan? [21:06:19] yes [21:06:25] and the transcript [21:06:40] flight plan and transcript agree [21:06:50] Oh, regarding the SPS..."The maneuver was controlled by the guidance and control [21:06:51] system and resulted in a 2.0 ft/sec overspeed, which was trimmed to [21:06:52] 1.0 ft/sec. Subsequent to this maneuver, a change to the constants in [21:06:53] the command module computer short firing logic was uplinked by the Mission [21:06:54] Control Center." [21:06:55] yes they do [21:07:22] the mission report has 117:29 [21:07:50] very odd [21:08:02] yeah [21:08:05] that's very wrong [21:08:46] so the REFSMMAT thing works out [21:09:08] using a heads up P30 REFSMMAT with a heads down maneuver pad gives me the good angles [21:09:11] I guess they changed the cutoff bias. LOPC-1 is an 18 second burn, so not short burn logic [21:09:33] ETDECAY [21:10:13] for long burns that's the time it cuts off the engine early to account for the thrust decay [21:10:33] we use 0.6 seconds, that agrees with our engine [21:11:00] gotcha [21:11:46] thewonderidiot, I need to do a bit of programer work as I have partially implemented that now and some stuff relies on it. But I think tomorrow I can try a launch [21:12:14] great. I'll work through more SELF-CHECK errors tonight -- the 6605 error should be very easy [21:12:23] sounds good [21:12:25] so you'll have some more fixes ready for you in the morning [21:12:42] for once the time zone difference is a good thing [21:12:46] hehehe [21:14:09] there is more stuff in erasable memory in Solarium, so I have more control over them. I'm a bit worried about the IMU accuracy once in orbit. No astronaut to do a P52 [21:14:21] but I think the real Apollo 4 mission also had a misalignment [21:14:33] and they also did a state vector update which will help [21:14:41] was that not a problem with Sunburst? [21:14:50] good question [21:15:30] I didn't even have to think about vertical erection and gyrocompassing etc there [21:15:35] because it just worked [21:16:07] but yeah, it's probably about the same [21:16:24] at the end of the Apollo 5 mission we do get effects of a degraded state vector, but not too much [21:16:54] and Apollo 4 for example just targeted an extremely steep reentry angle to not be in danger to skip out at all [21:20:04] great [21:20:10] hopefully should be fine then :D [21:20:48] yeah, will be interesting to see when the next issues happen or if I managed to get to orbit without program alarms [21:20:54] manage* [21:21:09] I'm not holding my breath on that one yet :P [21:24:20] I don't even know yet what displays there are in P11 [21:28:28] well hopefully I get to see tomorrow [21:28:36] thanks for all the help, Mike! [21:29:16] good night! [21:59:13] SL wasn't working right for CYCLSHFT [21:59:15] easy fix [21:59:28] we passed the rest of the control pulse checks! [21:59:37] and memory checks I think [21:59:42] now on to extensive mutliply/divide checks [22:00:00] and we've got an error at 11,7321 [22:00:05] which is a DV case :D [22:00:56] hmm isnt E supposed to terminate your EVA [22:01:10] uh oh, did you get locked out? [22:01:35] haha not sure [22:04:10] lol, the failing case is 37776 / 37776 [22:04:15] seems like that should be an easy one :P [22:04:47] umm just reloaded and my LM is sliding :( [22:05:44] but reloading the scn let me board lol [22:06:16] Antares mad that it didn't get an LRV [22:14:27] lol [22:19:37] lol this testing is getting brutal [22:19:49] it's taking a couple of minutes to hit the point where it fails now [22:33:50] ! [22:34:03] that may have been the last thing required to pass SELF-CHECK though [22:35:58] hell yes [22:49:35] working? [22:50:11] yeah :D [22:50:28] it's gone through the full suite of self-tests 12 times without any errors identified [22:51:30] .tell indy91 SELF-CHECK passes now! SL was shifting slightly incorrectly and DV needed a bit of work for equal-magnitude numbers [11:11:31] good morning [11:11:35] hey [11:12:25] looks like you and Mike are making great progress [11:12:38] yeah, got the self checks passing on my side, too [11:12:56] but now the DSKY locks up after the AGC running for a long while [11:13:12] maybe something in the emulator doesn't like running for extended periods of time [11:13:25] currently checking if it's something on the NASSP side that goes wrong [11:14:35] I had saved two scenarios before I realized the AGC is unresponsive [11:15:13] and a lot of the AGC stuff in both is the same, so I at least have a rough idea where it got stuck [11:18:51] might actually be debugging code [11:35:40] always happens at the same time [11:35:44] about T-2:37 [11:36:02] one time I even got a CTD from it, or rather, the simulation hung [11:38:21] probably some time related counter overflowing or so [15:43:27] good morning [15:46:29] morning! [15:47:41] hey guys [15:47:46] So I am trying to work out a discrepancy in procedures here [15:49:08] Based on Apollo 14's transcript and lunar surface checklist, the LM repress goes 1) repress valve AUTO 2) cb ECS: cabin repress close 3) master alarm/cabin waring light/cabin begins pressurizing 4)pregs to cabin [15:49:37] however, based on our code (and frankly what I am reading in the AOH) the repress shouldnt start until the pregs are in cabin [15:49:58] that sounds familiar [15:51:44] so I am trying to decypher a bit in the systems handbook if the egress switch settings do indeed inhibit repress [15:52:21] in the systems handbook this all looks quite confusing [15:53:01] Egress positions give ground to the signal that would trigger the repress [15:53:05] is how I am reading it [15:53:11] same here [15:53:36] we have the actual schematics, but I don't know if they are much better [15:54:14] and in the LM 10 AOH, "When repressurizing, the CABIN REPRESS circuit breaker is [15:54:15] closed, the cabin relief and dump valve is set to AUTO, the PRESS REG A and PRESS REG B valves [15:54:16] are set to CABIN, and the CABIN GAS RETURN valve is set to AUTO. The CABIN warning light goes [15:54:17] on when the regulators are set to CABIN, it goes off when the cabin reaches the actuation pressure of [15:54:18] the cabin pressure switch." [15:54:36] which is in line with how we have it [15:54:50] could also be a difference between LMs [15:55:05] true [15:55:06] thewonderidiot, does Ron now have LDW330-55000 up on the website? I can't find it [15:55:08] not* [15:55:23] but the systems handbook (this is LM-8) has the egress position grounding out the signal from the switches as you said [15:55:24] I don't think he does [15:55:31] I'll get that sent over to him [15:56:11] was just going to do that haha [15:56:17] but the pressure switch closed also grounds the signal [15:56:22] but yeah, the wiring in that document should be closer to the true wiring [15:56:50] thewonderidiot, everything went well with Solarium... for 1 hour and 22 minutes [15:56:57] and then it just locked up [15:57:03] surely a timer or counter issue [15:57:20] hahaha interesting [15:57:23] 1 hour 22 minutes... [15:57:36] probably some fixed time since turning on the AGC [15:57:43] here some variables in the locked up state [15:57:45] INTERRUPTED 1 [15:57:52] ruptFlatAddress 1540 [15:57:58] ruptLastZ 1540 [15:57:59] overflowedTIME3 1 [15:57:59] overflowedTIME4 1 [15:58:03] downlinkReady 1 [15:58:23] one thing I noticed was, before the issue happens TIME3 and TIME are always close to 37777 [15:58:27] is that correct behavior? [15:58:30] TIME4* [15:58:39] and then they overflow to 40000 and stuff happens [15:58:51] once the issue happens they always get back to 0 and count up to 37777 [15:59:06] so that still works in the locked up state, but nothing else really [15:59:09] DSKY frozen [15:59:22] yeah being close to 37777 is expecteed [15:59:31] LNY-77 is what happens if TIME3 rolls over to 0 :P [15:59:35] haha [16:00:08] I do find the use of the counters slightly problematic [16:00:13] countMCT and nextTimerIncrement [16:00:23] yeah I was about to say [16:00:25] they really do have to be 64 bit or else it breaks [16:00:30] after some time [16:00:55] I'd put money on it being that logic for some reason [16:01:00] nextTimerIncrement actually gets close to the limit if it was uint32_t, but not exact [16:01:16] at the time of the problem [16:01:28] incTimerCheckOverflow returns normal int [16:01:32] could that be bad? [16:01:50] mmm I think that should be fine [16:02:09] oh and does LP have more bits than the rest of the memory [16:02:26] EMEM0003 176377 [16:02:28] I have this [16:02:31] could be normal [16:02:47] the timers really should be behaving like Block II, where there's a scaler counting at a fixed frequency and the timers increment when a certain bit transitions from 0->1 or 1->0 [16:02:51] yeah that's normal [16:03:10] that's the double sign bit that the registers have [16:03:49] if it were 076377 then you'd have positive overflow [16:04:04] or 136377 would be negative overflow [16:04:15] we don't have the core system for Block I yet, right? Otherwise I could probably give you a core file close to the issue and you could likely reproduce it [16:04:27] it's very reliable [16:04:40] interesting, Apollo 12 and before seem to have the pregs in cabin before the light, and 14 and later have the pregs after the light... [16:04:45] based on the procedures [16:05:32] doesn't look like there is a core system [16:06:15] also, instructionCountDown is something for debugging, right? [16:06:28] what should I set that to so that it doesn't get in the way... [16:06:41] 1? [16:10:28] I have scenario saved 2 minutes before the issue happens, so I can test anything that you come up with. Unless you just want to rewrite the whole timing thing already haha [16:11:21] haha you know me too well, I already want to :D [16:12:28] hmmm [16:12:33] I should change how I'm building it [16:12:36] mike@luminary:~/virtualagc/yaAGCb1$ file yaAGCb1 [16:12:37] yaAGCb1: ELF 64-bit LSB pie executable, x86-64 [16:12:47] because you're building it in 32-bit mode for Orbiter right? [16:12:54] yep [16:13:06] well I guess it's all 32bit... [16:13:09] hmm [16:13:42] if you define uint64_t or int64_t in a 32bit build, is that then 32 or 64 bit? [16:14:02] 64 bit [16:14:05] ah good [16:14:22] is this interesting at all: ruptFlatAddress 1540 [16:14:25] that's not octal btw [16:14:42] 3004 in octal [16:14:51] 3004 seems reasonable for Block I [16:15:36] ok, that's where it is stuck [16:15:45] if I continue the scenario it still has that value [16:15:52] nothing changes when it's stuck except for the timers [16:16:02] if timer interrupts aren't happening that won't update [16:16:08] right [16:16:18] it's something Ron has to back up like ZRUPT and BRUPT because of how he wrote the emulator [16:16:39] I guess overflowedTIME3 and overflowedTIME4 are also stuck... [16:16:55] but it doesn't process it [16:17:10] INTERRUPTED 1 [16:17:33] hmmmmmm [16:17:51] I hope it's not some debugging code getting in the way due to lack of variable initialization [16:18:22] that is weird [16:18:28] I feel like the timer thing won't fix it then [16:18:40] if overflowedTIME3 and overflowedTIME4 are stuck [16:18:50] is regZ moving at all or is that also stuck? [16:18:55] I'll check [16:22:47] everything I am seeing in the handbooks and AOH lends me to believe the procedure isnt correct [16:23:14] even the explicit statement in the AOH says the cabin light will not come on until the regs are in cabin [16:24:24] overflowedTIME3 and 4 are 1 [16:24:29] permanently [16:24:32] regZ is 2 [16:25:11] uhm [16:25:20] let me check something... [16:27:20] a few seconds before the issue happens the auto checklist is switching uplinks to block [16:27:29] that might still set a bad input bit [16:28:07] that causes the issue [16:28:08] oops :D [16:30:28] hahahah [16:30:29] nice! [16:30:51] and you have discovered that the Block I emulator doesn't have any hardware alarms yet... [16:31:13] I guess it wouldn't hang up like that [16:33:56] the UPTEL switch was still set to channel 33 [16:34:02] which is DSRUPTSW in Block I [16:34:05] set a bit there [16:34:11] ohhhhhhh [16:34:15] yes that is not good haha [16:34:59] wired it correctly now, should hopefully be safe [16:35:04] alright I'm headed to Marc's to possibly power on this transponder -- I'll be on and off depending on what we're working on [16:35:37] sounds fun [16:35:45] hopefully I can get to launch now with this haha [16:36:10] good luck [16:42:22] so where in the code inhibits the lock handle from being moved to unlock [16:42:31] the hatches should be able to be "unlocked" but not opened [16:48:37] oh [16:49:49] ah the hatch handles are in lemswitches [16:49:57] search for "0.08" [16:50:05] that's the pressure difference [16:50:23] I guess that needs to be moved to the hatches themselves then [16:58:10] yeah thats what I was looking for [16:58:22] the hatches themselves need the pressure condition, not the handles [16:59:13] I see the handle logic but not the hatch itself [17:00:24] ah found it I think [17:28:39] ugh building on the laptop takes forever compared to the desktop lol [17:34:59] hmm so I moved the pressure code to the hatch, but I am trying to figure out how this code works: [17:35:09] bool LMOverheadHatchHandle::SwitchTo(int newState, bool dontspring) [17:35:09] { [17:35:10] if (!ovhdHatch->IsOpen()) [17:35:11] { [17:35:12] if (state == 1) [17:35:12] { [17:35:13] return ToggleSwitch::SwitchTo(newState, dontspring); [17:35:14] } [17:35:16] } [17:35:18] return false; [17:35:20] } [17:35:24] I removed the pressure condition from it [17:36:23] can I just remove that whole section? [17:39:39] better yet I will draft PR this maybe it will be easier [17:45:19] ok its there, indy91 if you dont mind taking a look? [17:45:30] sorry, just came back from dinner [17:45:50] the !ovhdHatch->IsOpen() condition is so that you can't move the handle while the hatch itselfd is open [17:47:57] no worries :) [17:48:43] so what is keeping the handle from moving now [17:49:08] if (state == 1 || cabin->space.Press < 0.08 / PSI) [17:49:20] state 1 is unlocked [17:49:31] if it's unlock it always let's you move it to locked [17:49:47] but not the other way around [17:50:03] state 0 is locked so for that it needs the pressure condition to move [17:50:09] but I think now you don't want any condition [17:50:24] so that if (state) should just go [17:50:52] only condition is on the hatch [17:51:05] and then in the hatch code... [17:53:05] maybe put () around the new condition you added [17:53:15] otherwise that looks right [17:54:00] yeah I just did that [17:54:58] I will test it after it builds then update the PR [17:55:17] T-20min, only just had sunrise. Pretty early launch [17:55:31] I'm saving a bunch of scenarios if I want/need to go back [17:56:00] Smart [17:57:29] the only place where the programer is doing anything yet is SECS pyro and logic buses. I hope I get no countdown hold because of that haha [17:59:37] hatches work as intended now [18:00:29] time to see what happens at liftoff.. [18:01:11] *fingers crossed* [18:01:21] And the PR is up with the hatch code [18:01:32] GRR, Program 04 [18:01:52] P11 [18:02:05] no display at all, boo [18:02:13] COMP ACTY looks stuck [18:02:40] :( [18:02:53] but it's not completely stuck, DSKY works [18:02:56] so maybe ok [18:03:02] no alarm or so [18:03:09] if it gets to P14 it should be ok [18:03:40] FDAI error needles look kind of ok [18:04:15] COMP ACTY unstuck [18:04:44] hmm [18:04:51] did I wire the auto tower jettison... [18:04:59] P14 [18:05:18] nah, auto tower jettison didn't work yet, more programer work needed [18:05:26] but I think Solarium likes it so far [18:05:29] :D [18:08:32] I don't really have a way of knowing that though, aside from no program alarm [18:10:08] would need to check the state vector etc [18:12:15] so what would "zero pos/neg cells" mean in terms of a LM uplink? [18:12:49] not sure. Where is that from? [18:13:10] Apollo 14 flight plan [18:13:19] and the surface checklist [18:13:33] cutoff [18:14:27] at what time? [18:15:12] 140:50 or so it seems on the flight plan [18:16:20] hmm [18:19:44] I have never seen that before [18:21:40] I have seen it before, but don't think I ever figured out what it means [18:21:55] I also don't know how long Solarium stays in P14... [18:22:43] Sunburst switched to P00 between events [18:24:49] Does the MPT work for the LM on the surface? [18:26:10] that used to be quite broken, but I think I fixed it [18:26:13] I hope [18:26:31] I cannot seem to make an anchor vector [18:27:53] hmm, the anchor vector would just be a flag indicating the landed state of the LM I think [18:28:16] I am trying to generate a post insertion state vector [18:28:41] right [18:29:29] you get a vector ID when you update the DC vector? [18:30:36] no [18:30:39] thewonderidiot, I call it a success. Have to figure out if P14 should stop. But before I proceed I need to finish the work on the LVDC timeline and some more programer [18:31:24] wooohooo! [18:31:52] rcflyinghokie, ok that makes not much sense. There is nothing stopping an update of the ground tracking state vector [18:31:58] when you are landed [18:32:29] I just mean the vector ID displayed as the DC vector, not the anchor vector ID at the top [18:32:43] MPT is active, INI TAB is LM [18:33:10] ah now it worked [18:33:24] I initialized it again, maybe I missed something [18:33:53] I know it's realistic for the display to only update every 6 seconds, but I don't like that much haha [18:34:12] got me confused a few times [18:34:20] ok so what is the liftoff threshold time [18:34:53] short rendezvous profile targeting? [18:35:30] yes [18:35:34] Apollo 14 [18:35:44] (my first short rendezvous) [18:35:54] this one is much easier than the launch window one [18:36:11] threshold means threshold. It always finds a liftoff time after the input time [18:36:19] Ah ok [18:36:28] so you don't want a direct guess of the time, but some time earlier [18:36:58] got it [18:37:09] this and the LOI targeting are the only parts of the RTCC where both the calculation method and the display are 100% accurate [18:38:17] they use this launch targeting display in the renovated MOCR [18:38:28] but they filled it with numbers for Apollo 11 [18:39:13] takes a lot of research to figure out where they would have to put each number. It's just that this display wasn't available yet for Apollo 11 :D [18:40:08] very nice [18:40:32] ok so how do I find my sunrise time [18:40:54] TPI time is sunrise -18.5 minutes [18:41:03] right [18:41:20] that's just a check, right? [18:41:42] you don't have too much control over TPI time with the short profile... [18:41:53] ah the RTCC doc says to adjust to proper TPI time [18:41:58] hmm [18:42:05] I guess with the DT [18:42:09] from insertion to TPI [18:42:11] sure why not haha [18:42:15] yeah [18:42:17] as you are using the MPT, you can use the proper display for it [18:42:22] MCC display [18:42:23] so I need to know what my desired TPI time is haha [18:42:26] sunrise/sunset table [18:42:45] needs a MED input, but I don't think it's very complicated [18:43:20] trying to use REV [18:43:38] not working [18:43:44] right. REV is a bit inconsistent still if you aren't permanently using the MPT [18:44:01] and I don't have much confidence in it updating automatically yet, not enough testing done for that [18:44:02] GET worked [18:45:07] this was usually the job of the RETRO. Called up the display and compiled a list of TPI times that the FIDO could use [18:45:22] had the hard job of substracting the 18.5 minutes [18:46:41] or whatever it is for the coelliptic profile [18:46:57] I feel like the original DT from insertion to TPI should already be close [18:47:07] the numbers are mission specific [18:48:06] tpi was only off by 30 seconds haha [18:48:09] and I am kind of questioning the wisdom of changing the DT [18:48:24] you can sacrifice the perfect TPI lighting for a clearer timeline [18:49:07] or TPF lighting rather, TPI doesn't have much light [18:50:34] right as its before sunrise [18:50:41] Also, this is not very clear [18:50:42] *Note insertion GET (Checkout Monitor MVE)* [18:51:18] the next few steps are all new to me [18:51:42] hmm, so, on the checkout monitor page the MVE option shows you the conditions at the end of a maneuver [18:51:53] so it would have the GET of insertion then [18:52:10] after MVE what do I pick [18:52:15] uhh [18:52:16] 1? [18:52:19] let me check [18:52:37] yeah its not clear haha [18:52:53] just says "parameter" [18:52:55] if you just need the GET then you also need 1, if the ascent maneuver is maneuver 1 [18:53:00] yeah it depends on the option [18:53:07] for MVI and MVE it's the maneuver number on the MPT [18:53:15] and everything else is optional [18:53:25] so you can put the ; after the 1 and try it [18:53:35] it worked with the 1 [18:53:39] great [18:53:46] but I dont know what I am looking for [18:53:57] not that this will calculate all the displayed parameters in Earth centered, inertial coordinates [18:54:01] as that's the default [18:54:04] uhh [18:54:14] there should be a GET somewhere [18:54:18] maybe top left somewhere [18:54:20] yep [18:54:26] is that insertion? [18:54:34] I think so [18:54:38] looks right [18:55:15] now I have to prefill values? [18:55:20] MVE should be end of maneuver, end of tailoff actually. But I don't think that distinction exists for the ascent yet [18:55:38] prefill values where? [18:55:52] good question [18:55:53] *Before liftoff, pre-fill tweak-burn values below & set MPT to inactive, - TAR, REN, TI, DIS, MPT, THR: L2* [18:56:20] oh I think this sets up a two-impulse processor calculation [18:56:28] for the tweak burn [18:56:42] so that you have that all ready and once you get to orbit you just press CLC and have it [18:57:08] hmm there is no MPT [18:57:12] after DIS [18:57:39] I think I changed that [18:57:44] just ENG and CLC [18:57:49] I think it means ENG [18:57:54] the page where you choose the engine [18:58:05] so I dont calculate anything before that? [18:58:09] it used to be named MPT, but that page also gets used in non-MPT mode [18:58:16] and its not clear if mpt should be active or inactive before this [18:58:16] so it's now ENG for engine [18:58:20] yeah, nothing calculated yet [18:58:32] just pre-filled so that everything is quick once you need the tweak burn solution [18:58:50] inactive for this calculation [18:59:00] or else it will use the MPT state vector of the LM [18:59:03] which is the planned one [18:59:06] instead of actual [18:59:22] there is some real time processing that would actually go into the tweak burn calculation [18:59:23] THR:L2? [18:59:33] and a different display actually, but we don't have that [18:59:38] L2 is LM RCS +4 jets [18:59:43] 4 +X I mean [18:59:59] ahh [19:00:19] so I leave that page like that? [19:00:30] yeah and go back after insertion [19:00:33] go back to it* [19:00:46] just cuts down on time you need to spend on this calculation [19:00:47] what about - TAR, REN, TI, OPT: Both Fixed, T1: Insertion GET +3min, T2: Desired TPI Time, OFF: P51,15,1.7,26.6,130; [19:00:59] yeah that's all the options for the calculation I guess [19:01:06] so I do that before liftoff as well? [19:01:19] tweak burn is 3 minutes after insertion [19:01:44] not much time to play with the RTCC MFD I guess [19:02:15] I think that's why Alex wrote it that way. Only a CLC press once you get to calculating it, everything else already prepared [19:02:51] and I guess that's what you want the exact insertion GET for [19:03:05] so that you can now enter insertion + 3 minutes for the tweak [19:03:27] ok all that is filled out [19:04:17] did you go to the lunar ascent page once and updat the ascent numbers [19:04:22] and then back to the launch targeting? [19:04:43] " TAR, ASC, CLC - Go back to LLT and CLC again" [19:04:45] that part [19:05:01] that usually gets you accurate enough to not need a tweak [19:05:18] yeah I did that [19:05:51] oh and have you actually done an ascent yet since I implemented the variable center of gravity for the ascent stage? [19:06:46] yes [19:06:56] I believe so, lots of rocking [19:07:12] ok now I need an insertion +18 SV [19:08:26] MPT active with the ascent maneuver, LM nav update to CMC, load insertion +18, clc and uplink? [19:08:34] sounds right [19:09:45] ok CSM SV at liftoff time uplinked (with MPT inactive) and LM ins+18 SV uplinked with MPT active and surface flag reset [19:14:18] is the ascent pad not calculating the AGS values? [19:24:08] hmm, it should [19:26:53] no luck [19:27:10] all zeros [19:27:28] MPT on or off [19:28:12] if off, press TGT button [19:28:12] either [19:28:42] Antares is selected [19:28:57] did it calculate any numbers? [19:29:10] Or does it just show the ones that were already there before pressing CLC [19:29:11] yes [19:29:24] well it didnt change when pressing clc [19:29:34] it has everything through N76 [19:30:00] crossrange and below are zero [19:30:56] are you calculating from the LM? [19:31:47] yes [19:32:05] Antares is not the target for the ascent [19:32:17] the CSM is the target [19:32:23] no idea why it fails in MPT mode [19:32:26] oh [19:32:35] but with Kitty Hawk as the TGT it should work in non-MPT mode [19:32:39] still nothing [19:32:55] press CLC once more [19:33:02] nothing [19:33:04] oh [19:33:05] there [19:33:09] if it was stuck in a calculation pressing CLC kills the thread [19:33:11] took a second [19:33:30] weird, shouldn't take long [19:33:50] ohh [19:34:01] I was looking at the wrong thing the whole time [19:34:12] was looking at the lunar ascent processor [19:34:22] ah [19:34:25] seems like the ascent PAD isn't MPT compatible yet at all [19:34:29] gotcha [19:34:50] bad code, if no target is selected it will get into trouble [19:34:56] or if the wrong one is selected [19:35:01] needs some fixes [19:51:13] for dT TRANS (time from TPI to rendezvous) can I get that from RTCC? [19:53:59] yeah, do you need it before or after ascent? [19:54:33] before [19:54:36] setting it in AGS [19:54:54] 43 mins is the checklist value [19:56:32] hmm [19:56:42] was that number on the targeting table maybe? [19:56:49] I see a dT NOM in the LLTT [19:57:05] it should have a TPF time [19:57:13] yeah which is about 43 mins from TPI [19:57:15] TPF minus TPI if there is no specific DT [19:57:22] ok cool [19:57:26] thats what I figured [19:57:46] that should be consistent with the AGS [19:59:36] yep looks good [20:00:09] that time is the 130° transfer angle, so another way of getting it would be the two-impulse processor, calculating the TPI [20:06:24] hmm interesting, no flags when doing the aca cold fire test [20:06:41] huh [20:06:48] got one about a minute later while typing that [20:07:06] my least favourite code in the whole LM [20:07:09] haha [20:28:02] hmm I cannot get my V47 to work for some reason [20:28:11] it wont change 414 from 1 to 0 [20:29:09] wonder if its because of my timestamped state vectors? [20:30:07] or maybe I have to wait to do it later per the procedure (after a 400+4) [20:30:34] because of the surface flag maybe [20:33:09] I think V47 takes the state vector to current time, so that shouldn't be an issue [20:33:17] not sure about the surface flag [20:34:45] also theres a note that "the epoch time for LM navigation updates on the lunar surface should be within 0.5 hour of nominal liftoff time" [20:39:24] for the AGS? or where is that note [20:42:08] 563+0 is the fix for the stuck 414+1 btw [20:42:46] I don't know if this is a problem specific to your situation or if FP8 just doesn't like the way we do PGNS to AGS downlink [20:42:59] I know that the RR data transfer via downlink isn't working that way [20:48:51] night! [20:50:14] .tell indy91 the note is in the fp6 manual, looks like when I ran it with 400+4 active it worked properly [21:37:15] .tell indy91 but now having the same problem in orbit, so somethings up [13:27:06] hello [13:27:30] good morning [13:38:43] I think I found my AGS uplink problem [13:38:49] "NO EPOCH POINTS MORE THAN Ió MINUTES IN THE FUTURE [13:38:50] SHOULD BE ENTERED FOR THE CSM NAVIGATION UPDATE." [13:39:13] ahh [13:39:16] FP calls for this to be done at LO-17 (CSM SV is timestamped at LO time) [13:40:27] thats from the FP8 manual [13:40:35] and interestingly enough, from FP6: [13:40:36] NO FUTURE EPOCH POINT SHOULD BE ENTERED FOR [13:40:37] THE CSM NAVIGATION UPDATE. [13:41:21] so I am curious which limitation FP7 has [14:01:28] and now I cannot seem to calculate the LM INS+18 SV [14:09:04] hey [14:09:53] good morning [14:10:10] I think the AGS update thing was user error I will find out soon [14:10:25] having to do with the SV times [14:10:28] oh ok [14:10:58] how do I check the surface flag in the CSM or LM [14:12:06] there is a procedure to get the status of a flag. Of course it's usually easier to just do V44 or 45 again [14:12:49] what about the LM [14:13:37] hmm, in the LGC? [14:14:11] never thought about that. I assume it's set and reset automatically in P68 and P12 [14:15:10] in the CMC SURFLAG is BIT 8 FLAG 8 [14:15:14] SURFFLAG* [14:15:30] flagword 8 has address 104 [14:15:50] V1 N1E 104E [14:16:13] yeah I know its set and reset with the programs, I just meant as a sanity check here to make sure I didnt screw up any state vector uplinks [14:16:27] hmm ok [14:16:53] looks like it's the same address in LGC and CMC [14:17:52] So V1 N1E 104E. If the middle digit is 2, 3, 6 or 7 it's set [14:18:00] looks set [14:18:59] so you think you did a LM LGC state vector uplink that could have screwed something up? [14:19:19] I don't think that can reset the surface flag [14:19:24] so that uplink will just be ignored [14:20:09] yeah I thought I might have [14:20:18] but I guess not [14:20:35] the AGS update I think had to do with the CSM SV time [14:20:49] so maybe that was too far in the future after all? [14:20:52] FP6 has a warning not to uplink any future CSM SV times [14:21:03] FP8 has a 16 minute limitation [14:21:37] And I certainly uplinked before then [14:22:01] interesting [14:22:10] Interestingly though, the flight plan has the AGS SV update at LO-17 minutes...cutting it close to the 16 minutes [14:22:15] it probably has more to do with what the LGC is doing [14:23:20] hey Niklas [14:23:52] "EXTRAPOLATE LEM AND CSM STATE VECTORS TO THE PRESENT TIME" [14:23:57] hey [14:24:19] Luminary 178 does calculate the state vector for the present time before sending it to the AGS [14:24:28] so there really shouldn't be a problem caused by that [14:26:10] hmm [14:26:25] so I wonder what was causing the uplink to fail [14:26:41] PGNS to AGS downlink you mean [14:26:44] yes [14:27:04] maybe FP8 and Luminary 178 don't like each other [14:27:29] although I kind of doubt that the format of the state vector downlink had change [14:27:30] d [14:29:26] yeah I am at a loss as to why [14:29:41] going to try it per the timeline this time and see what happens [14:29:56] I guess it worked fine in orbit before landing? [14:30:04] yes [14:30:11] question, I have some telemetry parameter configuration files, that I want to load based on the mission. where is the best place to do that? mission files, like the agc software? I'd rather not save it to the scenario. [14:32:16] The RTCC config files are loaded in RTCC code and saved in the RTCC part of the scenario, but you can also add it to the mission file. Whatever makes more sense [14:38:55] yep, that makes sense. [15:03:27] coming up shortly on LO-17...we shall see what the downlink does [15:05:09] AGS and PGNS are slightly off from one another, I hope thats normal in lunar align mode [15:06:50] might fix itself, The AGS aligns itself to gravity [15:07:02] while the LGC alignment is for liftoff already [15:07:36] although the difference should be tiny for 17 minutes [15:08:04] yeah its small [15:08:07] and the downlink worked [15:11:59] hey [15:12:29] good morning [15:17:23] -7m lets see how this works out [15:19:45] hey Alex [15:20:18] hi alex [15:27:20] what's new? [15:27:25] interesting AGS and PGNS are off in roll and pitch haha [15:27:31] by a few edegrees [15:27:35] degrees* [15:27:50] *roll and yaw* [15:29:00] ah 623+1 fixed it [15:29:10] I think [15:29:43] still a little off [15:30:50] yeah AGS and PGNS not in agreement :( [15:31:31] unless they arent supposed to be for a direct ascent [15:40:42] no idea why they are so different [15:43:58] n7275, not much just starting a short stretch of days off, you? [15:49:32] indy91, same issue in orbit...no downlink [15:50:45] if it helps [15:50:46] https://www.dropbox.com/s/6nk79chnxh2rsgp/Apollo%2014%20-%20No%20Downlink.scn?dl=0 [15:54:06] All sorts of AGS problems here it seems, from alignment before liftoff, to PGNS and AGS not agreeing on ascent to not downlinking in orbit [15:57:26] AlexB_88, work mostly. working on telemetry in my spare time [16:01:40] rcflyinghokie, what about 047 and 053, did you enter those from the ascent PAD? [16:01:49] I did [16:02:16] would they be overwritten with a downlink? [16:02:21] nah [16:02:28] but they are important for the alignment [16:02:34] yaw angle of it at least [16:02:39] yep everything from the ascent pad was put in [16:03:05] I can take a look at the scenario later, right now I am trying to get the rest of the LVDC timeline working right for Apollo 4 [16:03:20] and my branch has no LM haha [16:03:41] ah ok [16:04:11] just completely deleted it, was easier to take out the Block II AGC completely [16:04:22] and you know how quickly rebuilding goes... [16:05:02] Well its swift on my desktop...not so much my laptop ;) [16:05:23] my PC is also not too quick about it [16:05:47] So the 3 issues I noticed were alignments differed, the AGS and PGNS VGx values were different, and the downlink would not work in orbit [16:06:04] in orbit? I thought on the surface [16:06:10] surface worked this time [16:06:13] orbit did not [16:06:32] hmm ok [16:06:49] also I did enter 514 515 and 516 values from the surface checklist [16:06:59] to be used with 623+1 [16:07:28] I think that is a pointing vector [16:07:45] for better antenna coverage the ascent is done with a yaw, or at least it can be [16:07:48] yeah its for the yaw [16:07:59] same reason as yaw angle for the descent [16:08:18] but other than that I followed the procedure step by step so I am a bit confused why things are messed up [16:08:25] right [16:08:35] oh the procedures are for FP7 [16:08:37] we use FP8 [16:08:39] maybe it's that? [16:08:53] could be [16:09:10] I will compare [16:10:03] Also here is a pre liftoff one [16:10:04] https://www.dropbox.com/s/emue7r4v1mr8ki3/Apollo%2014%20-%20Before%20LO%20AGS%20Issues.scn?dl=0 [16:12:38] one difference I see is 400+4 was called after AGS powerup instead of 400+3 [16:14:55] and no lunar align after the first 400+3 [16:18:45] wonder if thats the reason [16:19:18] ugh loaded a prelaunch scn and downlink isnt working again [16:20:19] this makes no sense [16:54:14] morning! [17:02:28] good morning [17:04:30] hey Mike [17:05:00] what's up? [17:05:20] working on the LVDC and programer to be able to continue with Apollo 4 [17:05:34] just wired the command that the LVDC can cause LV/CSM separation [17:05:40] :D [17:06:36] I can already tell that the "TLI" guidance presettings aren't very good [17:07:01] Apollo 4 had a shorter time between TB6 start and main engine ignition [17:07:36] kind of throws off my method to get the presettings from a TB6 start state vector and TLI cutoff state vector [17:08:37] 6 minutes instead of 10 minutes. And the ullage thrusters are firing for the whole thing [17:09:54] AlexB_88, did you have any trouble with FP8 and normal PGNS to AGS state vector downlinking? [17:10:54] hmm not that I can remember [17:11:38] I can't think of a reason why Luminary 178 and FP8 would dislike each other [17:11:59] I did have issues with the AGS automatic RR marks [17:12:46] right [17:17:48] if you haven't read it, Mike and I managed to get the Block I emulator working [17:18:10] I got up to orbital insertion so far, Apollo 4 software Solarium monitoring the launch [17:19:00] awesome! [17:19:39] not really sure if the AGC is doing much until it gets separated from the Saturn [17:19:42] and at the same time... damn! No I have to make a block 1 VC :D [17:19:43] yeah I am at a loss as to why the downlinks sometimes work and sometimes dont for me [17:20:04] AlexB_88, right now I am even using the Block II DSKY still haha [17:20:26] no bitmap or switch changes [17:20:33] if it works it works I guess lol [17:21:18] yeah, I guess some DSKY lights don't have a direct pendant to Block I, so e.g. I don't have the NO ATT light working at all [17:25:49] thewonderidiot, I'd still like to find out if the AGC does anything other than run P14 until LV/CSM sep [17:26:31] Sunburst went to P00. So I'm a bit worried something isn't working right if P14 doesn't terminate [17:28:12] GSOP suggests that it updates the state vector every 2 seconds for the whole time [17:29:07] But I doubt that it's Average G [17:31:06] Hi! [17:32:33] hello! [17:34:31] indy91: I'll take a look at the mission programs in a bit [17:34:45] hey Stevey [17:34:46] that should be easier to figure out from reading code than most of the rest of the problems we've had so far haha [17:34:51] yeah [17:35:23] just a quick check that it's doing the correct thing and I'm not wasting my time getting to LV/CSM sep when the AGC is already lost [17:40:50] Hmm I might have found something.. [17:41:11] 4I I MUST BE SET TO +OOOOO BEFORE ENTERING [17:41:12] ANY OF THE VALUES FOR A DEDA UPDATE OF [17:41:13] THE LM OR CSM STATE VECTORS. IF THIS IS [17:41:13] NOT DONE, AN ERRONEOUS STATE VECTOR [17:41:14] UPDATE CAN OCCUR. [17:41:29] the 14 flight plan has a 411+1 entered before the update [17:41:43] but that also might be for manual entry I dont know [17:42:21] yeah its for DEDA entry [17:43:34] huh [17:43:44] setting 411 to zero allowed the downlink [17:44:34] so if I set 411+10000, 563 changes to -02205 [17:44:58] I set 411+00000, 563 changes back to +00000 [17:45:03] I think thats the issue [17:46:20] ah [17:46:48] looks like they never set 411+1 according to apollo 15's timeline [17:47:10] it's probably not good to do 411+1 in NASSP right now [17:47:56] Well the reason is 411 in FP6 and 7 is engine select [17:48:08] so 411+1000 is ascent engine [17:48:08] oh haha [17:48:20] so thats the issue here [17:48:27] right, they removed the engine cant stuff in FP8 [17:48:48] so while I correctly followed the procedure, the 411 is what botched the update [17:48:59] someone needs to find us FP7 then haha [17:49:43] well at least I am happy I figured out the root cause [17:49:49] yes seriously I would love FP7 [17:50:43] "LM AGS Programmed Equations Document, Flight Program 7" will have the listing as an appendix... so we just need to find said document [18:00:51] hmm so I am reloading before launch and now I cannot seem to compute my ascent anymore [18:01:21] no vector available for LEM trajectory update? [18:06:46] also config update gets rejected [18:07:15] config updates only work when there is no maneuver on the MPT [18:07:38] "in-flight" config updates are done with manual input maneuvers, undocking [18:08:07] not sure about the other error [18:08:52] yeah I am trying to recompute my ascent [18:09:02] but nothing in LLTT will calculate [18:09:18] do you still have the ascent maneuver on the MPT= [18:09:19] this is after loading a scn [18:09:20] ? [18:09:26] I deleted it [18:09:35] got the config update working [18:10:16] CSM EPHERMERIS LIMITS [18:10:41] a bunch of those for CSM and LM as well as RMMASCND CONVERGENCE LIMIT [18:11:38] Evening! Back from camping again. [18:11:41] maybe I am too close to tig [18:11:46] hey Thymo [18:11:50] hey Thymo! Guenter survived this time :P [18:11:55] Wohoo! [18:12:47] I'm going again on Saturday. I don't expect him to drop again but you never know. [18:12:47] how was camping? [18:12:54] Wet, but fun! [18:13:47] at least there isn't a big heat wave right now, that would be worse than wet [18:14:10] rcflyinghokie, the ephemeris limits message is normal, that just tells the range of the ephemeris [18:14:13] Went with two mates from Scouting to Zeeland. Did some walking, went to see the delta works keeping the water out of peoples homes and did some boating. [18:14:50] indy91 so what is stopping the LLTP from computing [18:15:02] Saturday will be the cub scouts turn of whom I'm a leader. So another free vacation for me. ^.^ [18:15:16] "RMMASCND CONVERGENCE LIMIT" is usual for translunar coast at least. It tries to find the point where you cross the ascending node. Not sure why it fails here, maybe for the LM [18:15:59] what did it say for the limits? [18:16:05] and what vector time did you give the LLTP [18:16:42] 142:00:00 [18:16:53] I am using all the same parameters I used when it worked before [18:17:10] is 142h in the past? [18:17:23] from right now [18:17:28] yes [18:17:35] oh is that why [18:17:44] so, when you reload a scenario the MPT does a new trajectory update [18:17:56] ahhh [18:17:59] that process is always: bring state vectors to current time and start the ephemeris from there [18:18:27] so it's probably failing when it requests a vector time that is too early [18:18:28] got it [18:18:51] can be sometimes annoying to calculate something for the past in the RTCC [18:19:44] yeah I am about 3 minutes ahead of that vector time [18:19:47] so that explains it [18:20:39] there probably should be an error message of some kind for that [18:22:55] for this type of error it would probably be a small message on the LLTP itself [18:23:17] that's how it is handled for the few displays where I have the full display requirements of [18:24:59] ah [18:25:24] well things look a lot better now pre launch haha [18:27:03] thewonderidiot, I wonder if I could get uplink to work... Solarium takes the same signal for an abort as Sunburst [18:27:29] just need to change the uplink register to 41 [18:27:59] generate the uplinkReady signal [18:29:12] oh fun :D [18:29:32] in a way trying aborts first might be quicker to get every system connected [18:29:38] yeah for sure [18:44:03] ags is still about 1000fps less than PGNS in VGx [18:44:07] no idea why [18:44:50] unless its the direct ascent [18:46:12] it's not much of a direct ascent, insertion conditions are quite similar to coelliptic rendezvous [18:46:19] hmm [18:46:26] the AGS uses a different calculation method [18:46:41] might not have the same velocity-to-be gained until later [18:46:42] or [18:46:44] even so, 1000fps difference is not good [18:47:10] maybe the AGS also wants to insert you into a different orbit [18:47:18] maybe something set up for FP7 again where FP8 is different [18:48:04] yeah I am looking [18:48:23] the different orbit is what I was thinking though [18:49:34] maybe the variable insertion targeting for the descent abort isn't disabled [18:56:09] where is that [18:56:47] it's just done by setting two numbers to the same value [18:57:47] yeah that was done [18:57:54] 224 and 226 [18:58:10] I bet it's an address difference between FP7 and FP8 [18:58:29] nope they are the same [18:58:54] hmm [18:59:55] hmm [18:59:57] 225 [19:00:04] should that be the same as 226 [19:00:58] they don't even load it in the Apollo 15 checklists it seems [19:01:12] hmm, they do in the G&N Dictionary [19:01:39] hmm [19:01:47] your liftoff pad has 225/226 [19:01:52] I think it should be 224/226 [19:02:00] (RTCC liftoff pad) [19:02:19] yep [19:02:35] oh [19:02:40] wonder if thats what happened [19:02:47] I guess it's not mission specific. Or is it's the same in FP6? [19:02:50] I loaded 225 and 226 with that without checking [19:03:01] I will check but I think those addresses are the same [19:03:20] ah [19:03:28] apollo 12 has 225/226 [19:03:55] I have a list of things I need to check and fix in the Orbiter2016 branch already, I'll add it to the list [19:04:01] I think it is in fact a different address [19:04:20] I found a surprising amount of little bugs in the sequential systems when I revisited them for Block I [19:04:33] 225 is apolune radius/2 in FP8 [19:05:09] and its a lower limit in FP6 [19:05:30] ah, the comment in FP8 also still says lower limit [19:06:06] "one half lower limit of apolune radius" [19:06:19] for FP8 [19:06:31] you know what, that probably should be a fixed number [19:06:36] 224 is "term in O.I. semimajor axis" [19:06:38] might not be chaned [19:06:40] changed* [19:06:46] probably the 30NM limit [19:06:50] and 226 is "retarget value for 7J" [19:06:58] but what happened to you was that you loaded no 224 I guess? [19:07:14] nope I loaded 224 [19:07:21] but I loaded the same number in 225 and 226 [19:07:29] oh [19:07:39] that might screw it up maybe [19:07:42] yep [19:08:04] I bet you could safely use 0 for 225 [19:13:36] changing 225 to the pre PDI value worked [19:14:12] so what I changed in the RTCC MFD [19:14:16] chane* [19:14:18] change* [19:14:44] For missions using FP8 show 224 instead of 225? [19:14:48] yes [19:15:09] looks like FP6 has 225/226 for that pad entry [19:15:16] and FP8 has 224/226 [19:15:29] they are converging nicely now [19:15:44] about 100fps difference [19:15:48] thewonderidiot, got uplinks working in principle, right now it doesn't like the abort signal though. Gets me a uplink light but nothing else. [19:16:10] I tried the Block II clock update and it works well [19:16:12] well [19:16:14] and the error needle in pitch agrees with PGNS [19:16:20] it puts stuff on the DSKY, that works :D [19:16:21] before it was consistantly off scale [19:17:58] much better less than 20fps difference [19:18:02] converging [19:18:03] I guess it tried to give you a really high apolune [19:18:59] yeah [19:52:04] hmm well I guess my insertion didnt go well I cannot compute a TPI [19:52:48] probably one of the inputs [19:52:59] MPT mode off? [19:53:17] I mean in the LGC [19:53:21] oh [19:53:33] that's weird [19:53:36] some program alarm? [19:53:41] yeah I get an elevation of about 31 [19:53:49] for the computed TPI time from RTCC [19:53:58] and a 611 error using 2660 [19:54:13] Looking at the index of Don's stuff I see this Skylab CSM Indexing Computer. You guys have an idea what that was used for? [19:54:16] yeah on this trajectory it can't compute the TPI based on elevation angle [19:54:35] and I'm not sure the elevation angle is so bad [19:54:44] ok so I need to leave the elevation zero? [19:54:49] yes [19:54:51] ok [19:54:58] then it uses the input TPI time [19:55:14] also fo the tweak burn, am I burning those dvs from my current post ascent attitude? [19:55:16] for* [19:55:26] AlexB_88? [19:55:38] as in I hold that attitude and run P47 and match up the dvs [19:56:31] they did seem a bit high given the small residuals after ECO [19:59:03] I do the tweak burn usually in the post insertion attitude (hds-down) [19:59:14] how did you calculate it? [19:59:19] your steps in the manual [19:59:29] Thymo, no idea, but I'm interested in anything skylab related [19:59:40] Thymo: you looking at the spreadsheet or the photo album? [19:59:48] oh and its 0 elevation you use in P32 [19:59:58] P34? [20:00:01] P34* [20:00:03] yeah sorry [20:00:06] yeah Nik let me know :) [20:00:18] My first direct rendezvous [20:00:25] And first time on FP8 [20:00:46] So a bit of a learning curve especially considering I am using "FP7" procedures technically haha [20:02:01] Thymo: https://photos.app.goo.gl/55KwG7LLyyHN9FbG8 [20:02:04] thewonderidiot: Both. It's some of rotatable plastic disc to calculate some angle [20:02:11] oh cool yeah [20:02:19] Yes that one [20:02:54] I'm wondering when NASSP gets to Skylab if that's something we might need or if it's just a backup or mission planning thing. [20:04:38] yeah not sure [20:09:20] skylab missions would be fun [20:09:38] up until the part where you are just in the lab :P [20:11:44] ok did another insertion and tweak, lets see what elevation it comes up with [20:17:49] what kind of tweaks did you get, DV wise [20:18:41] -5.5 -5.5 -16.6 [20:18:50] thats after nulling residuals on P12 [20:19:28] P12 residuals are a weird thing [20:19:35] yeah they are a pain [20:19:46] my elevation angle again though is about 31.5 [20:20:04] because the guidance is still running you can really only reliably null the out of plane [20:20:51] that makes sense [20:20:59] and makes it a pain to null [20:21:22] at least AGS and PGNS agree on elevation angle for TPI time :) [20:21:25] so it might be that part of that tweak is fixing what the residuals nulling made worse [20:21:45] I don't think the elevation angle is too bad [20:21:46] ah could be, fewer maneuvers to correct it [20:23:46] maybe it also takes the LM slightly longer now to reach orbit because it's pitching up and down all the time [20:24:03] I'm pretty sure that we didn't need tweaks of larger than 10 ft/s anymore [20:24:07] also could be, I didnt look at the burn time [20:25:13] hmm so now PGNS has 32.5 and AGS has 31.5 as the angle [20:25:17] after a recycle [20:26:14] but the N58 values look good [20:26:42] smaller than the flight plan [20:38:24] hmm what burn attitude am I supposed to use [20:38:26] P42 [20:38:33] or my CSM LOS [20:39:22] ah found it [21:01:13] night! [14:44:45] Afternoon gents [14:45:10] hey [14:45:59] hey [14:49:24] morning :) [14:51:47] currently trying to make attitude control work for the Block I AGC [14:53:05] Just got back from the doc for a tetanus vaccine. Turns out it's not very healthy to have the pointy end of a rusty nail meet with the bottom of your foot. [14:53:30] ouch [14:53:38] getting vaccinated against that works after the fact? [14:55:26] for tetanus yes [14:55:37] ah [14:55:38] I think its more of a booster than a vaccine :P [14:55:51] which reminds me I am overdue for my booster [14:56:14] anyways, indy91, after all of the jumping between docs for 14, I finally got a good rendezvous haha [14:56:36] Yeah, the one I got is inactivated tetanus. I was vaccinated when I was twelve, just shy of the 10 years it works for. They wanted me to have a booster to be on the save side. [14:56:36] TPI burn led to only one tiny MCC [14:57:03] ah good [14:57:34] yep Thymo, had mine at 13 and then 23, so I need my next 10 year one...but they typically will give a precautionary one as well when you get that kind of wound [14:58:03] indy91, whats the status of being able to do the impact burns without being in the LM? I see P99 erasable uplinks? [14:58:14] I think my last one was 2009, so I am a bit overdue... [14:58:37] yeah the RTCC MFD has some hardcoded uplinks for P99 [14:58:43] but they are for Luminary 210 [14:58:54] I think we have a source for Luminary 178, too [14:59:06] Over here they generally only give it to you if you're a kid, travelling somewhere with a higher risk of infection or after an injury. You don't get it every 10 years by default. [14:59:16] But I guess they won't refuse if you ask. [15:01:17] so I should just put the P30 values from the RTCC doc? [15:06:51] hmm [15:09:05] https://www.ibiblio.org/apollo/Documents/LUM168-RC_text.pdf [15:09:11] this is for Luminary 177 [15:09:18] so just one revision short of 178 [15:14:01] but I guess you want the P30 values anyway, P99 is more like P41, the program executing the burn [15:15:25] so what's the best way to burn this [15:17:02] inputting the P99 uplinks manually sounds like a pain [15:17:13] so maybe just P30 and P41 [15:17:19] uhh [15:17:36] P42 without igniting the APS [15:17:43] hmm no, also not good [15:18:11] well maybe P41 and just manually doing the burn [15:21:07] yeah P41 is what I am going to do [15:21:33] did the LM remain in jettison attitude for the burn or did the auto maneuver get commanded? [15:24:06] P99 can do an attitude maneuver I think [15:24:13] ok [15:31:16] great, the AGC can now... point the CSM 180° in pitch away from where it wants the CSM to point [15:33:58] I guess that's progress [15:35:06] baby steps [15:36:37] and sometimes it is really unhappy and just goes to P77, which is basically the program where the software has given up doing anything useful [15:37:37] I still need to request cloaks for everyone that wants it. If you WHOIS Guenter you will see his cloak is "NASSP/bot/Guenter". What would you guys prefer? Simply NASSP/name or NASSP/role/name like NASSP/developer/indy91 for example. [15:38:44] In the latter case I could also request one for people that aren't developers but regularly hang out nonetheless if they want one. Take NASSP/user/Stevey for example. [15:42:56] hmm interesting, is the DEDA display supposed to be powered by the NUM LTG breaker? [15:43:21] I havent looked, but it the LM timeline asks to verify 500R on DEDA after pulling this breaker [15:44:26] yes, I think so [15:44:48] Thymo, cloaks would be cool. right now every time I log off/on the channel announces where I live/work...not that I care if you guys know, but others, not so much. NASSP/developer/user looks good [15:46:30] indy91 I am only seeing it get power from the AEA via the AEA and AGS cbs so far [15:46:31] I was thinking the same. I'll make a request for n7275 rcflyinghokie indy91 thewonderidiot (Alex when he's around) and anyone else that wants one unless there's an objection [15:46:57] no objection here [15:47:04] sounds good [15:47:09] rcflyinghokie, LM-8 Systems Handbook [15:47:14] on the lighting page [15:49:37] ahh missed it [15:52:42] oops, wasn't even launching on the right launch azimuth with Apollo 4 [15:54:39] haha how did that go [15:58:16] IMU looked weird. But I think it was because the Block I IMU is at an 33° angle in the CM [15:58:19] but it's not [15:58:28] I mean [15:58:34] the attitude shouldn't look weird [15:58:43] I was just launching to 60° instead of 72° [16:04:16] n7275 is n7275!~n7275@NASSP/developer/n7275 [16:04:20] Cloaks applied [16:08:49] Welcome to the national association of secondary school principals channel, shan. [16:09:19] thanks a bunch! middle schoolers are a challenging lot :p [16:09:42] jokes aside, i remember looking into the project a couple of years ago and i was incredibly impressed [16:10:09] cool stuff you guys are doing [16:10:17] indy91, have a moment to help me RTCC a TEI? [16:10:25] hey shan [16:10:29] rcflyinghokie, sure [16:10:31] looks like there are differences between the doc and the current RTCC state [16:10:36] sup indy91 [16:10:59] IRC is getting quite the influx haha [16:11:08] good morning :) [16:11:15] an impressive 12 people online yes haha [16:11:21] Thanks! It really has come a long way in the last years. We are probably gonna do a release of NASSP 8 in the not too distant future. So be sure to check it out if you want. :) [16:11:35] i don't have a windows machine anymore, sadly [16:11:42] might try running it in wine [16:12:03] rcflyinghokie: out of curiosity, what's an RTCC and a TEI? [16:12:04] maybe there will be a Linux version eventually, with Orbiter now also being open source. [16:12:33] shan so TEI is the trans earth injection maneuver (gets the crew out of lunar orbit and back to earth) [16:12:41] ahhh [16:12:58] and RTCC is the real time computing complex, its what computed all the maneuvers and such on the ground [16:13:12] we have an RTCC MFD in NASSP that allows those computations in the sim [16:13:14] and replicating those calculations in NASSP is kind of my job [16:13:22] ^ [16:13:45] (what's an MFD?) [16:14:11] Multi Function Display [16:14:45] ah alright [16:14:47] it's an Orbiter thing, there are lots of MFDs that shows you stuff, like, in what kind of orbit you are [16:14:51] that's awesome [16:15:12] ok indy91 I am on the Entry page [16:15:20] Just like in aircraft. You have a display with buttons alongside it that can be programmed. We have a couple of displays that do checklists, utility functions like moving crew between vehicles or calculating maneuvers as would be done by mission control. [16:15:21] is the RTCC emulated low-level or is it kinda like a black box? [16:15:38] I wished it was low level, but we don't have any original code for it [16:16:02] unlike for the Apollo Guidance Computer where we use the original software [16:16:08] but we have a bunch of RTCC documentation [16:16:22] so it's trying to get the calculation methods right from that documentation [16:16:26] but all C++ like NASSP [16:16:54] if we would find original code we would need to get some IBM 360 emulator going... [16:17:45] rcflyinghokie, have you done any return-to-Earth calculation yet with the new method? [16:18:24] nope [16:19:28] indy91: ah alright, thanks for the info! [16:19:33] no problem! [16:19:55] rcflyinghokie, the manual has a section that was updated with the new method [16:20:22] maybe read that first, should clear up a few things [16:20:41] I have [16:20:43] ah [16:20:47] But there is no RTM button [16:20:58] thats where I am stuck [16:21:01] yeah Alex' input guide is outdated [16:21:06] at least for this part [16:21:17] RTM was Return-to-Earth from the Moon, but it's now all one thing [16:21:39] so you start with the Abort Scan Table [16:21:41] right [16:22:05] "lunar search" option, that is specifically for TEI [16:22:26] ok [16:23:29] vector time and abort time, would that be to search for the TEI TIG? [16:23:31] one new thing is also, you also need to give it a guess for the reentry time [16:23:36] oh [16:23:50] yep I see that TZ [16:23:53] right [16:24:13] only needs to be accurate +/- 12 hours [16:24:22] because there is a landing solution every 24 hours [16:24:44] abort time is an initial guess I think [16:25:58] ok now the inclination [16:26:04] "40A" for 14? [16:26:14] hmm, I think it does that automatically now [16:26:17] limiting it to 40 [16:26:37] if you input nothing it finds the optimum within the limit [16:26:40] ok and the profile? [16:26:57] default option [16:27:01] ok [16:27:09] that's entry profile, so the reentry range could be different between the options [16:27:28] but for the steep reentry target line, which all missions used, only one of the options is working anyway [16:27:33] https://www.dropbox.com/s/ni796bpnvjojozn/Screenshot%202021-08-10%20102720.png?dl=0 [16:28:57] I wouldn't input anything for inclination (so 0), but you could check if it finds the same solution [16:29:17] ok [16:30:53] yeah the RTCC manual is way out of date for this method haha [16:31:26] whats next [16:31:49] got a solution? [16:32:27] where do I compute one [16:32:53] ah, top right button [16:33:00] AST for Abort Scan Table, that's the display [16:33:07] ok [16:33:26] ok I have one [16:33:39] inclination looks reasonable? [16:33:51] also, what does this mean in the manual "Apollo 14 -171.53 / 40A" [16:34:15] is the -171.53 the desired inclination? [16:34:16] I think that's the splashdown longitude [16:34:34] you don't directly specify that anymore [16:34:37] oh [16:34:45] you used the MPL option [16:34:47] Mid Pacific Line [16:34:53] haha yeah you can see my confusion here [16:34:55] which should get you a very similar longitude [16:35:17] https://www.dropbox.com/s/1hg8eveqfo8to8n/Screenshot%202021-08-10%20103505.png?dl=0 [16:35:38] hmm [16:35:41] 165 I know is the MPL target [16:36:36] right, but they changed the MPL to use a different longitude as a function of latitude [16:36:45] and I'm a bit confused why that is a fixed 165° there [16:37:09] no idea [16:37:22] oh [16:37:24] ... [16:37:30] they changed the MPL more than once [16:37:37] for Apollo 8 and 10 it was fixed 165°W [16:37:56] and then it was 175°W for northern latitude, 165°W for southern latitudes [16:38:14] but they changed it again it seems like [16:38:22] haha so what do I need to do here [16:38:41] I think right now there isn't really a way [16:38:51] you could edit the MPL numbers [16:38:57] but I haven't implemented that yet I think [16:39:24] ah ok [16:40:13] so I can just use this as is? [16:41:00] yes, just won't get you to the same coordinates as the actual mission [16:41:42] so would something need to be added to fix that? [16:42:15] a have to check if they actually changed the MPL or if they targeted that fixed set of latitude and longitude [16:42:23] ok [16:42:24] which is something that they could do [16:42:29] but we can't (yet) [16:42:51] ok no worries [16:42:55] I will run with this [16:45:24] https://www.dropbox.com/s/tgmkocg250hzb1m/Screenshot%202021-08-10%20104513.png?dl=0 [16:45:55] how does that look [16:46:00] good [16:46:10] what is GETR in the top left [16:47:14] a reference time [16:47:20] you can set that to e.g. 100 hours [16:47:34] and then some times are referenced to that [16:47:48] e.g. it says PETEI, phase elapsed time of entry interface [16:47:51] ah ok [16:47:57] and that would be relative to that GETR [16:48:08] probably mostly going to be 0 [16:48:13] like in this: https://twitter.com/poppy_northcutt/status/1210053922137821186/photo/1 [16:48:18] also the docking angle, will that need to be zero? [16:48:36] docking angle is inconsistent haha [16:48:41] I would just never touch it [16:48:47] 0° and 60° will usually mean it's right [16:48:52] today is her birthday apparently [16:48:57] ok [16:49:09] some things need 0° as input, some 60°. It's bad. [16:50:26] TRA button is the next step I guess [16:50:32] because this has two columns [16:50:42] I have it on the MPT [16:50:48] ah good [16:50:58] That page was pretty famillar [16:51:12] there is going to be a large DVY because of the inclination constraint [16:51:22] their solution for that for the next missions was. Drop the inclination constraint [16:53:07] haha [16:53:16] yeah that is a large dvy [16:55:10] Going to do some Apollo 15 Surface Ops today. [16:55:12] And then liftoff. [16:56:01] NIce [16:56:11] Well I have a grasp on the direct rendezvous profile now [17:11:24] morning! [17:12:13] good morning [17:16:04] hey Mike [17:16:12] what's up? [17:16:16] got an interesting new program alarm [17:16:18] 1101 [17:16:23] I know why it happens [17:16:50] it's caused by ERRUPT/RUPT2 [17:17:00] if any of 8 bits in IN2 are set then that interrupt happens [17:17:15] but IN2 is entirely different for Apollo 4 than in Ron's descriptions [17:17:21] hah [17:17:23] that's fun [17:17:38] so either that interrupt was disabled [17:17:46] or different so that only other input bits are causing it [17:17:53] and not the input bit for LV/CSM sep [17:18:02] ***NO ERRUPTS IN SYSTEM 5*** [17:18:04] says the code [17:18:14] System 5 is the name for the Apollo 4 PGNS? [17:18:49] mmmmm I don't think it was quite that simple [17:19:20] if I recall correctly, when they talk about "system X" they're referring to like the fifth one built, or the fifth series [17:19:37] ah, so Apollo 4 and 6 are system 5? [17:19:42] maaaaaaybe [17:19:50] let me look at the flown serial numbers [17:20:34] I only know e.g. Block I Series 50 [17:20:38] for AS-202 [17:21:26] the schematics are like that too, I think [17:21:32] talking about "system 5" and so on [17:22:39] https://archive.org/details/apertureCardBox439Part2NARASW_images/page/n619/mode/1up?view=theater [17:22:43] take a look at note #4 [17:22:50] and note #5 [17:24:06] yeah Apollo 4 and 6 were G&N 122 and 123, AGC 14 and 13 [17:24:07] hmm ok [17:24:33] so I think that's a holdover from early development [17:24:55] we could probably figure out by looking at the schematics if ERRUPT is even wired for "AGC 5" [17:25:19] right [17:25:25] I have just disabled it for now [17:25:37] trying to teach it attitude control right now [17:25:39] yeah that's probably the right thing to do [17:25:40] for aborts [17:25:55] the AGC doesn't do much for Mode I aborts [17:26:00] so I'm trying Mode IIs [17:26:16] I've seen a whole bunch of program numbers flash by so far haha [17:26:21] hehehe [17:26:25] but normally it settles on P61 [17:26:35] pretty normal reentry sequence [17:26:47] no idea what the display means though, N62 [17:27:13] "RE-ENTRY VARIABLES" [17:27:16] that's not helpful :D [17:27:22] yeah [17:27:31] R1 looks like a clock, it's counting [17:27:41] OCT 00000 # N 62 WAS 2COMP. CHANGED TO 3COMP. MOVED [17:27:42] OCT 00000 # TO END OF IDADDTAB TO PRESERVE TABLE. [17:27:43] R2 and R3 might be cross and downrange error [17:27:47] wow, Block I is hacky as hell [17:28:24] but there's nothing at the end of the table???? [17:28:50] oh it's listed as 06 I guess [17:28:57] TIME2, V, THETAH [17:29:01] ahh [17:29:19] that can make sense [17:29:27] I really have to check if navigation even properly works [17:29:43] so how was RCS firiing commanded from the ground in the LM [17:29:50] in the case of a deorbit [17:30:00] P99 was quite automatic I think [17:31:05] and Apollo 12 used P42 [17:31:15] just let it run the ullage burn [17:31:27] and then send a ENTR press to stop it [17:31:57] it would do ullage forever if you don't press PRO to start the APS burn [17:32:40] oh interesting [17:32:54] I'd love to see P99 working [17:33:09] you should do it :D [17:33:16] thewonderidiot, any erasable changes between Luminary 177 and 178? [17:33:22] we have a P99 version for 177 [17:33:48] unless you think the version for 210 might work, too, that's been hardcoded into the RTCC MFD [17:34:06] 210 probably won't work [17:34:16] actually it definitely won't [17:34:41] that's what I thought [17:35:11] I don't think we know what happened between 177 and 178, but I would be very surprised if it was incompatible [17:35:30] Ryan just has to punch in the uplinks manually :D [17:35:51] or edit the EMEM in the scenario [17:36:34] not too much quicker, one of the three uplinks is a V72 instead of V71 [17:36:42] Haha well I would love to know how it works [17:36:50] https://www.ibiblio.org/apollo/Documents/LUM168-RC_text.pdf [17:36:51] page 7 [17:36:54] is the uplink [17:37:35] mmm, how does V72 differ? [17:37:43] procedure starts on page 5 [17:37:53] well V72 is addresses spread all over the memory [17:38:00] and not in one place like V71 [17:38:12] gotcha [17:38:17] so that works about as quickly then using the DSKY instead of scenario editing [17:38:32] lots of scrolling [17:39:56] I will try and uplink it [17:40:00] *manually* [17:41:15] keep the order in mind [17:41:45] P30 first I guess [17:42:12] even with the correct P99 uplink I had only about a 50% success rate [17:42:23] probably because I did something slightly out of ordere [17:42:54] ok then [17:48:03] oh hah [17:48:15] I was wondering where they put P99 since I didn't see them marking a VAC area [17:48:29] turns out, over top of a whole bunch of padloads that they don't need anymore :P [17:50:35] ok all entered [17:50:40] \o/ [17:50:45] when should I command this [17:51:16] I am about 15 minutes from tig [17:51:37] I think whenever -- it'll put up a countdown [17:51:40] thewonderidiot, oh and the Apollo 4 and 6 mission reports of course have a list of programs used in order, shouldn't have checked that earlier. It's normal that it will stay in P14 until after CSM sep from the Saturn [17:51:47] should* [17:51:48] oh awesome! [17:57:09] damn program alarm [17:57:14] 21204 [17:57:38] negative delta time? [17:57:53] did it try to count backwards? [17:58:13] what do you mean [17:58:47] that means a waitlist task got scheduled with 0 or negative seconds [17:58:54] so it tried to run something in the past [17:59:16] how would that happen [17:59:25] did you run through P30? [17:59:29] maybe if the TIG was in the past? [17:59:30] maybe it was the time stamped stste vector? [17:59:56] yep ran through p30 [18:00:01] shouldn't be the state vector [18:00:52] trying again [18:01:09] checking p30 [18:02:08] times are correct [18:02:10] no slipped tig [18:03:20] hmmmmmm [18:03:26] https://www.dropbox.com/s/ze4rhjg9e8tkpyb/Apollo%2014%20-%20P99%20Test.scn?dl=0 [18:03:28] if it helps [18:04:09] LGC clock time is correct and P30 tig is after the current time [18:06:41] unless I had to do P30 after the "uplinks" [18:07:20] nope no difference [18:08:16] thoughts? [18:09:58] state vector time tag was TIG-10? [18:10:16] no, that was for the CSM [18:10:19] CMC* [18:10:23] ah [18:10:27] same for LGC [18:10:36] maybe call P99 after TIG-10 [18:10:59] let me double check addresses against 178 [18:11:11] I really don't think there was a change [18:11:18] I am about 3 minutes before the burn [18:11:26] so I am within that window [18:11:47] try a V96E before entering P99 [18:11:50] ok [18:14:31] that worked [18:15:13] yeah all addresses check out [18:16:24] so the V96 made the difference [18:16:40] the memo mentioned that on page 6 [18:16:54] yeah I thought that was after [18:16:56] not before [18:17:10] but rereading it I see [18:18:19] ah look at the astronaut card, a V96 is in there before the V71 [18:19:47] lets see if this works [18:21:01] avg g [18:22:14] oh this is cool [18:22:31] :D [18:22:51] eco [18:23:13] almost no residuals [18:23:31] And P00 [18:23:55] EMPs are awesome [18:24:54] that worked like a charm [18:26:24] V82 is in TFF is active, down she goes [18:27:29] another successful mission for Luminary 178 :D [18:29:05] 19 more minutes at least [18:29:13] then le smash [18:29:30] french for lunar impact ;) [18:30:57] by the way [18:30:58] https://www.ebay.com/sch/m.html?_nkw=&_armrs=1&_ipg=&_from=&_ssn=eddieb1961&_sop=10 [18:31:13] a huge lot of Apollo Experience Reports went up on ebay last night [18:33:09] ohh interesting [18:34:41] adding a few LM ones to my watchlist [18:35:15] would anything be of use in here I wonder [18:35:24] I know we already have scans of a lot of them from NTRS [18:35:34] but there might be some new things [18:35:35] yeah thats what I was assuming [18:40:09] impact 8 minutes, flying low over Descartes [18:40:21] wonder where she will end up [18:45:10] I think we have almost all Apollo experience reports [18:51:57] rcflyinghokie, ascent stage I presume? [18:56:34] haha yes [19:09:51] ah I wish I could participate in some of that just to be there [19:12:27] lol it's hours of tedium (building the harnesses, triple checking connections, etc.) followed by huge spikes of excitement when stuff finally works :D [19:12:48] oh I am sure [19:12:50] dragging around the uplink frequency and watching it change its downlink frequency after lock was so much fun lol [19:28:19] 5.9% remaining SPS after TEI [19:29:18] Not sure if I recall it that low before lol [19:29:27] but then again I haven't flown 14 and later [19:35:34] I guess thats on par per the mission report :) [19:47:13] you also burned a longer MCC-2 [19:47:43] and I think the lunar geometry wasn't very good for flying to Fra Mauro on Apollo 14, so more DV on LOI and TEI [19:51:48] and DOI and circ burn done by the CSM [20:01:14] mission report has about 4.7% remaining at SM Jett [20:01:49] 3.6% usable [21:55:23] thewonderidiot: Any plans on hooking it up to an antenna (perhaps with a transverter to get it in a HAM band) and try out voice over some distance? :D [21:55:28] yep! [21:57:52] Awesome. I'm sure you can get a nice pileup of contacts once words gets out. [21:58:47] Too bad that frequency is waaaay to high to even have any chance of hopping over to me. Would have loved to work it. [22:01:30] yeah transmitting S-band with much power is a big no-no lol [22:02:39] I mean, I'd like some popcorn. [22:04:31] Looking forward to the new video "Apollo S-Band Transponder Restoration: We built a microwave" [22:09:06] Not sure if you have line of sight but QO-100 is a geostationary sattelite with a 2.4Ghz uplink. I'm sure you can upconvert to that. https://en.wikipedia.org/wiki/Es%27hail_2 [22:13:22] Doesn't look like it unfortunately: https://i1.wp.com/hamnieuws.nl/wp-content/uploads/2014/03/DARC__AMSAT-transponder.png?w=640&ssl=1 [22:30:12] hmm anyone know how the RTCC works with TEMCC computations? [22:30:38] I need either a corridor control or impact point burn and havent a clue how to do them since the new method was implemented [22:40:34] thewonderidiot: If you want to go fully historical you might be able to convince the FCC to waiver the frequency of the transponder so you can transmit on the historical frequency. Provided nothing else is actively using it where you're at. https://www.ecfr.gov/cgi-bin/text-idx?SID=38c1ec51405ebfc2477c5d380a94a460&mc=true&node=se47.1.1_1925&rgn=div8 [23:01:49] guess I am bugging Nik in the morning :P [09:59:18] Morning Nik [09:59:57] hey [10:00:48] got some time this morning, I have a list of bugfixes to do that piled up while I was working on Block I stuff :D [10:02:38] so far when I try to let the Block I AGC steer the CM during an abort and reentry it commands lift vector down. Gets me 20 Gs. Not sure what it's really trying to do [10:04:38] Nice. I'm still working today, but I have the rest of the week off. Hope to squeeze some NASSP time in between Scouting and Red Cross stuff. Might wanna get the wiki going and work out a todo list for NASSP 8 release and how to proceed afterwards. [10:04:53] Doesn't sound good. It's just down all the way without any other guidance? [10:05:13] it kind of feels like guidance [10:05:31] It has a small roll angle like Block II usually does [10:05:54] what I was expecting it do to was try to reach the east Atlantic abort zone [10:06:06] but it would have to fly a lot of lift vector up to get there [10:06:32] Apparently there is also an abort program that does a small SPS burn to get to that abort zone [10:06:55] Maybe the state vector is off making it think it is way higher than it is? [10:06:56] but I doubt that's working yet, AGC is not integrated enough yet into SCS and SPS [10:07:09] yeah, I really have to check if the state vector is any good [10:07:45] probably my next step [10:09:09] the way it sequences during the programs mostly makes sense [10:09:17] it's basically like Block II with the entry programs [10:09:24] starts in P61 and ends up in P67 [10:10:12] I already don't like the attitude it uses for the CM before entry interface [10:11:32] off in pitch from what I thought it would use [10:12:02] I'll get there, step by step [10:13:17] Different question. Does MCC already calculate N69 loads before PDI? I put it on my list but I have no idea if it's already in or not. [10:14:26] Apollo 12 is the first mission that had N69 [10:14:32] MCC support goes up to Apollo 11 [10:15:24] Right and RTCC? [10:15:35] we do kind of have a method to calculate N69 with a vector comparison display. You basically would compare the onboard state vector to a "ground tracking" one and the display shows a downrange error. [10:16:13] I can come up with a procedure for it and put it in the manual [10:16:43] because of the limited complexity of the lunar gravity model in Orbiter that is only really relevant for Apollo 12 [10:16:57] later missions don't do DOI shortly before PDI [10:17:15] so there is a state vector uplink before PDI and no maneuver in between [10:17:28] When I check the state vector I always got less than 100 feet error then [10:17:42] Apollo 12 a bit higher due to Average G during DOI etc. [10:18:45] Ah yeah I suppose that would work. 8 only promises support up to 11, but doesn't sound like much work to add an entry in the manual. [10:19:04] yeah, I think I want to add some examples to the manual in general [10:19:24] it's fairly up to date with general descriptions of display and calculation methods, but it would help a lot to add examples [10:20:57] Did you make that manual in LaTeX? [10:21:05] yes [10:23:58] Nice, I've been trying to use it more lately. Would you be willing to commit the source files too? Techincally a PDF is a binary distribution and being in the GPL repo would also require the source to be distributed. If not it would need to be placed under a different license. [10:25:40] no problem, that makes sense [10:25:51] I wanna do the same with the ropes we have in the padloads repo. Those are all binary right now. Although I'm not sure we still have the source for every one of them. [10:26:20] did I put the experimental ones in there too... [10:27:08] yeah [10:27:14] like Luminary099_THROTLAG.bin [10:27:32] only a single number was changed for that [10:27:41] so maybe we don't need the complete source code of it [10:30:21] Same with the changed epochs. I need to do a bit of digging if I still have it otherwise I have some reverse engineering to do. So I might need those numbers from you again if I can't find them. [10:30:46] I read something about only providing deltas under GPL a while back. There was a catch, have to look it up again. [10:35:03] https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#DistributingSourceIsInconvenient [10:36:15] That's it. You should still be able to produce the source in the unlikely event virtualagc disappears or something. So if you only have the delta you can't do that. [10:36:32] Besides it's way more convenient to have everything in one place where people can just build it. [10:38:18] hmm right [10:44:20] The RTCC MFD manual contains a bunch of pictures of MFD pages [10:44:26] I guess I have to add those as well? [10:46:52] Yeah [10:47:18] I guess they can go under Doc/Project Apollo - NASSP/src maybe? [10:47:50] Doc/Project Apollo - NASSP/src/RTCCMFD? [10:48:00] yeah something like that [13:38:25] hey Ryan [13:38:34] Hi Ryan! [13:39:16] Thymo, I checked the state vector, looks very good [13:39:22] Block I navigating right [13:39:52] I just found some more input bits that Solarium wants [13:39:53] Hmm weird how it still wants to go in so steep then [13:40:00] maybe that makes behavior better [13:40:28] the description on the Virtual AGC page really doesn't apply to the Apollo 4 AGC [13:40:51] found a second case where even an interrupt is being triggered in a different way [13:41:13] KEYRUPT, from the DSKY [13:45:12] maybe the CG offset in the CM is on the other side in Block I lol [13:54:03] haha that would make sense [13:55:26] it does have a different lift-to-drag ratio at least [13:55:34] 0.36 instead of 0.3 in Block II [13:58:05] nah, if the coordinate system hasn't changed, too, then the CG offset is on the same side [14:05:03] Good morning! Sorry logged on and got dragged into a meeting haha [14:06:13] the difference in L/D is more than I would have guessed [14:07:43] rcflyinghokie, in the RTE it's just a change of terminology. Corridor Control is now Fuel Critical, Unspecified Area (FCUA) [14:08:01] oh and I found a solution for you problem with the splashdown site [14:08:37] The actual TEI will have targeted not one of the longitude lines like the MPL [14:08:45] but a specific End-of-Mission latitude and longitude [14:09:01] our RTCC can't do that yet, but I am using that input method [14:09:14] so I have preloaded the EOM targets for Apollo 13-17 [14:09:32] and if you now specify EOM instead of MPL it will target at least that longitude [14:10:00] Afternoon! [14:10:05] hey [14:14:11] so if I used the original target for TEI, would my MCC-5 be able to change that IP enough? I know Mcc5 and 6 for 14 could be used to change that [14:14:49] you can try, it's going to be some DV [14:14:57] I will play with it in a few [14:14:58] but definitely MCC-5 [14:15:09] yeah it will be too expensive later I am sure :P [14:15:15] That would be Specified Site, EOM [14:15:29] the old corridor control is now the option: Unspecified Area, FCUA [14:16:40] it's going to be like 10-50 ft/s, no idea how much really [14:16:57] ok downloading and rebuilding [14:39:43] so by typing EOM does it pull the mission specific values? [14:39:47] ah yes it does [14:40:55] 66.6 fps [14:41:56] so what does save splashdown coordinates do [14:45:17] saves them for the Entry PAD [14:46:12] and uplink [14:46:58] and the splashdown update page, I still don't quite get the actual vs desired range and how to use that [14:48:30] hmm [14:48:53] yeah it's a weird system with the range [14:49:12] The page will change or go away entirely [14:49:23] I guess you just put in some range until you are happy with the coordinates [14:49:55] lol ok [14:50:26] So I see those coordinates got uploaded when I used SPL [14:50:48] if I dont do anything on the splashdown update page, will entry update load those coordinates? [14:51:11] yep [14:51:55] SPL button basically moves the coordinates from an RTE internal place to the MFD where it can be used otherwise [14:52:29] with a Retrofire External DV Uplink you also get the splashdown coordinates uplinked [14:53:00] so if you do MCC-5 with a specific site then you also have the new coordinates anyway [14:53:04] in the CMC [14:53:05] ok so I dont have to mess with the range [14:53:16] how do I have the new coordinates? [14:53:43] Retrofire External DV Update uplinks TIG, DV and splashdown coordinates, all from the RTE [14:54:05] SPL button was useful so that the Entry PAD can use the coordinates, too [14:56:46] oh so I use retrofire external dv for my TEC MCCs? [14:56:59] yeah [14:57:07] ahh [14:57:12] all RTE calculations should probably use that uplink type [14:57:19] good to know lol [14:57:27] can you even do a normal External DV uplink with them [14:58:23] yes [14:58:34] I had already for TEI and previous MCC5 [14:58:51] ah right, you can transfer the solution [14:59:02] and that stores it in the generic TIG and DV in the MFD [14:59:11] in non-MPT mode that is [14:59:48] I guess this worked in the real RTCC, too [14:59:55] you would have the maneuver on the MPT [15:00:03] and uplink the External DV update from there [15:00:40] but I think they always used Retrofire External DV uplink, it's a convenient way to get the splashdown coordinates consistent with the burn into the computer [15:00:59] for all RTE and deorbit burns [15:10:23] makes sense, good to know [15:22:06] ok lets see if this puts me on course :) [15:43:27] looks like it workd [15:43:29] worked [15:45:48] =D yay [15:49:20] extrapolating out I will need 0.7 fps for MCC6 or 5fps for MCC7 [15:54:06] morning! [15:57:32] hey mike [16:06:22] morning [17:08:00] time for a nice small MCC6 and I will see what corridor control looks like for MCC7 [17:23:10] 0.6 for a corridor control at MCC7 [17:23:22] too small to worry about? [17:24:41] also can I compare entry with and without that burn? [17:27:30] yeah, you can use the RTE manual input page with a 0 DV burn [17:28:31] it needs lat and long as input, but there is a button to load the numbers you saved earlier [17:28:53] thewonderidiot, not even KEYRUPT is the same in the Apollo 4 AGC vs. what we have in the emulator lol [17:29:02] hahahahahaha how? [17:29:19] a specific input bit causing the interrupt is what the emulator has [17:29:27] but on Apollo 4 it's more like Block II it seems [17:29:59] that specific input bit is the same as uplink block for Apollo 4... [17:30:34] bit 6 of IN0 [17:31:08] indy91 for the FCUA, do I leave the TDV at the default 10000 ft/s? [17:31:22] yeah, I think that is just a maximum DV for the maneuver [17:31:26] ah ok [17:31:27] not even sure FCUA uses it [17:31:29] TCUA uses it [17:31:32] time critical [17:31:41] more relevant for TLC aborts [17:31:43] gotcha [17:31:54] and for the REF, I can use ROZ to use the entry REFSMMAT? [17:32:02] if you get 10000 ft/s for fuel critical you have a problem [17:32:05] lol [17:32:50] yeah I think ROZ is the normal lunar entry REFSMMAT [17:33:21] I hope... [17:33:31] Haha thats what I assumed from the descriptom [17:33:34] description [17:33:36] you will probably be able to tell by the IMU angles [17:33:45] ah no [17:33:53] those are of course for the burn [17:33:57] not angles at EI [17:34:47] ok looks like with the CC burn, my Gmax will be 6.12 and angle is -6.5 (as expected) [17:34:57] without, 6.41 and -6.57 [17:35:14] so slightly shallow [17:35:17] uhh [17:35:18] steep [17:35:21] yes [17:35:27] oh and... ROZ is not the right type [17:35:31] need to change the description [17:35:32] haha ok [17:35:44] so what do I need to put there to use entry REFSMMAT [17:35:57] REFSMMAT page still [17:36:08] but I have the calculation method already in there [17:36:15] that REFSMMAT did come from the RTE [17:36:27] What about the RTE REF [17:36:39] is CUR whats loaded in that page or whats in my CMC [17:36:57] CUR is what is loaded in the MFD [17:37:09] you can downlink the one in the AGC on the REFSMMAT page [17:37:11] DWN button [17:37:18] might or might not already be the same [17:37:47] the IBM RTCC document didn't have the calculation of the entry REFSMMAT yet [17:37:52] but the input guide for Apollo 11 did [17:37:57] at least it had additional types [17:38:19] I need to use the entry one in here [17:38:23] but the CMC has PTC [17:38:31] so just Lunar Entry on the REFSMMAT utility? [17:38:42] yeah [17:38:46] ok [17:39:43] so I might as well just burn it haha [17:39:44] there is "DEI" and "REI", REFSMMAT types the RTE can calculate but for which I have no reference what they are [17:39:46] but they have EI In it [17:39:57] so they sound useful for that haha [17:40:09] I would guess deorbit vs lunar reentry? [17:40:27] well, for deorbit, Apollo 7 and 9 and least, use the deorbit type REFSMMAT [17:40:33] 180°, 180°, 0° at ignition [17:41:14] that's ROY [17:41:17] ROP is 0°, 0°, 0° [17:41:32] and I think ROZ is for a RCS deorbit, gives 0°, 180°, 0° at ignition [17:41:41] need to clean up the naming etc [17:41:43] which it did in the RTE [17:42:15] yeah I think all these REFSMMAT types associated and used for reentry came from the RTE [17:42:32] RTCC didn't have a central place to calculate REFSMMATs, is was a bit all over the place [17:43:54] the RTCC operations support plan document could really use some descriptions of acronyms used in MEDs... [17:44:35] I'm completely lost when it comes to the inputs for the GUIDO optics support table for example [17:46:21] thewonderidiot, Block I AGC attitude control works ok I think. For entry guidance it always flies lift vector down though, have to check why it does that. [17:46:45] it should do a simple Mode II abort normally, I think [17:46:56] hm, interesting [17:46:57] but lift vector down seems wrong [17:47:14] for later aborts where it has enough time until reentry it will try a SPS burn [17:47:28] to get to the Atlantic recovery zone at about 20°W [17:47:39] have to rewire the SCS a bit, doesn't work yet [17:47:45] got as far as a 1402 alarm [17:47:49] in P73 [17:50:28] oh and I missing a few input bits still, hopefully I'm not getting too many complete failures anymore where it just goes to P77 [17:50:31] I was* [17:51:59] I think that is my first goal to get something fully working, that abort burn and reentry to the Atlantic recovery zone [17:53:28] navigation looks really good, I checked [17:54:00] can't argue when Surface MFD and state vector in Solarium both show 7793 m/s... [17:55:45] :D [17:55:47] yeah that's very good [17:59:00] not too shabby [18:07:31] interesting the 14 flight plan doesnt show the uplink for entry orientation [18:07:41] it shows the P52 for it, but no desired REFSMMAT uplink [18:09:08] 212h? [18:09:13] just before that [18:09:17] DESIRED ORIENT (ENT) [18:18:11] oh my pdf is missing a page [18:18:30] I am missing 211h to 212h [18:18:34] weird [18:25:57] short on consumables, just delete an hour from the flight plan [18:28:55] haha thinking like an engineer [18:37:55] and I wasn't missing a page, 2 were just out of order [18:41:14] and even for a corridor control burn I should be using the retrofire uplink? [18:43:03] yeah, you would probably want to use the updated splashdown coordinates [18:43:15] I think, that's a very confusing topic [18:45:21] yeah thats what I was wondering since I technically dont want to change the splashdown point with a corridor control burn [18:45:36] or do I haha [19:06:28] well, they do that [19:06:31] TEI: 27.03° south, 171.51° west [19:06:39] MCC-5: 27.03° south, 172.62° west; [19:07:10] normally you want the ideal range from EI to splashdown [19:07:19] so you adjust the landing target [19:07:28] what I tend to confused by is, what is the cutoff time [19:07:40] at some point they have to commit to some coordinates [19:07:55] as long as it isn't unsafe [19:09:43] MCC5 was allowed to be a coridor control or an IP burn [19:09:50] Mcc6 as well [19:09:54] but 7 was resreicted [19:09:59] restricted [19:10:28] so I am wondering if, its a corridor control burn only, would they update it or let the CMC try to maintain its target [19:11:09] that MCC-5 was corridor control only [19:11:34] which is why the landing point changed [19:11:44] and not the original End-of-Mission target anymore [19:11:49] to achieve that you need more DV [19:12:22] ah ok [19:13:17] I think they would only have done a midcourse correction targeting a specific site if the current trajectory lands somewhere far off [19:15:53] similar to what I did :P [19:15:57] yeah [19:16:14] but if you decide to scrub the last MCCs, which coordinates do you target then... [19:17:11] I would guess whatever was previously targeted? [19:17:37] yeah, but you would have to make sure your reentry isn't perturbed too much for that to be a problem [19:18:18] that was the idea behind the splashdown update page, giving you ideal coordinates for the current trajectory [19:19:15] true [19:19:35] I really need to listen to that part of the Apollo 11 MOCR audio [19:19:43] because that's a process they went through [19:19:56] deciding where to land, how much range is good etc [19:23:50] would be the same kind of idea for later missions I suppose [19:24:45] thewonderidiot, how related are the virtualagc scaler logic pull request, and ggalfi's pull request to NASSP? [19:32:03] indy91 whats the best way to monitor my current entry trajectory? [19:36:36] n7275: Last I heard one isn't finished and the other is supposedly finished but not committed to the right project. [19:37:33] Mike is/was working on magc which is a completely new emulator that'll most likely incorporate this too. Of course I'll thewonderidiot say anything about that [19:38:36] rcflyinghokie, what specifically do you want to monitor [19:41:19] honestly just anything really [19:41:35] wondering if there were any MCC displays that would be useful before and during entry [19:42:11] yeah there are a bunch of displays that I haven't implemented yet [19:42:32] with the MPT you could do e.g. a checkout monitor for EI [19:42:51] space digitals column 3 also has EI conditions [19:43:48] the missing displays are specficially for the RETRO [19:44:31] RETRO High-Speed Entry Digitals has splashdown coordinates calculated with MPT, AGC and current tracking state vectors [19:44:45] would have* [19:44:57] n7275: kind of related... ggalfi was laser-focused on the CDU simulation to get the 1201/1202 alarms to happen, and made changes at the expense of emulator accuracy (self tests couldn't fully pass anymore) [19:45:26] the scaler pull request goes all the way, and would require all systems in NASSP to communicate with the AGC via pulses instead of the current methods [19:45:52] but it hasn't been merged because Ron is big on backwards compatibility, and doing this necessarily broke everything, and I just haven't had the time/willpower to go and fix everything [19:46:09] same lack of willpower on my part haha [19:46:20] I feel a bit more confident now that I understand some of the connected systems better [19:46:25] I made magc as a possible workaround for that... an even more accurate emulator than virtualagc, without the backwards compatibility baggage [19:46:32] at the time I never really had touched anything about our IMU [19:58:33] thewonderidiot: Is magc up and running already? [19:59:01] it'll run programs fine -- but I haven't implemented all of the counters and I/O channels yet [20:03:13] indy91 also, in Apollo 13 there is an interesting moving plot but I dont know if it was real...it was geodetic altitude vs range to go [20:04:11] Nice. I might try to implement the aux memory on yours once you get channels going. [20:04:36] I ran into the same backwards compatability programs when I tried it on yaAGC [20:06:30] Thymo: there's nothing stopping you from doing it now [20:06:45] channels work, I just haven't implemented all of the bits that are actually used in the computer [20:07:10] https://github.com/thewonderidiot/magc/blob/main/src/control.c#L223 [20:07:30] currently all of the channel logic is in the RCH and WCH control pulse implementation functions [20:07:37] so it's just be more cases there [20:09:12] Oh sweet. That looks very clean. I might take a look then. [20:09:38] I take it you're also gonna add a way for say NASSP to add it's own channel behavior through some API? [20:12:25] the plan is to expose pins and pulses, just like the real AGC, and that's it [20:12:31] NASSP should not need to have its own channel behavior [20:12:44] rcflyinghokie, yes that's a real plotboard display [20:13:13] hmm, I think [20:15:08] also, what was the purpose of the RSI alignment prior to entry? [20:15:28] if the lift vector arrow is already pointing up, what does slewing it to 45 and back do [20:18:19] I guess making sure it works correctly [20:18:38] maybe it drifted a bit over time and wasn't perfectly straight up at reentry [20:19:20] cya! [20:19:59] ah makes sense [20:20:01] night! [21:38:27] would be awesome to have magc in NASSP [21:39:12] .stoplogging [21:39:17] .endlogging [21:39:17] Log ended by Thymo, total logging length 606968 seconds