[12:58:44] NASSP Logging has been started by n7275 [12:58:46] Thymo, any idea what github is doing "under the hood" when you use the "fetch upstream" feature. up until a few days ago it was getting my branches ahead of upstream with merge commits, now it just makes it even. [13:31:26] good morning [13:37:08] hey [13:37:25] hey [13:37:57] preliminary LOI Maneuver PAD I guess [13:38:29] rcflyinghokie, as it turns out the whole RTE issue was a lot simpler. There was a missing GET to GMT conversion for the estimated time of landing. [13:39:06] that's why it ran into the reentry velocity constraint, tried to return 13 hours quicker than the input estimate [13:39:12] Ahh [13:39:21] What about the TZ being read from another method? [13:39:27] also fixed [13:39:33] excellent [13:39:51] I burned that correction and I am doing an FCUA at MCC7 its about 1.8 fps [13:40:31] which reminds me, when doing an FCUA, should I update the splashdown coordinates as well? Or let the computer target the original planned ones [13:41:19] updating them is better I think [13:43:19] unspecified area and FCUA, correct? [13:44:03] to target MCC-7 yes [13:45:44] looks like LNG T is now 158.25 [13:46:02] or 158:25W [13:46:29] So I save that splashdown target and it gets uplinked with a retrofire uplink? [13:47:15] saving it is just for the Entry PAD basically [13:47:20] looking at 26.015 and -158.410 [13:47:32] on the splashdown update screen [13:48:13] Retrofire uplink for unspecified area will use the actual splashdown coordinates [13:48:32] whatever the target is on the RTE digitals is getting uplinked for all modes [13:48:56] ok [13:50:15] I think I have talked about it before, the decision process for the splashdown coordinates isn't quite clear to me [13:51:00] yeah [13:51:05] coupled with the actual range thing [13:51:14] *desired [13:51:23] its still pretty enigmatic for me on using that [13:51:42] hmm? [13:51:46] splashdown update page? [13:52:36] that page is probably going to go away, the only use for it is replanning reentry range for weather avoidance [13:52:57] but that can be done with changing the number on the RTE constraints, too [13:53:25] I wouldn't really use that page anymore [13:53:53] haha ok [13:55:34] also something that the RETRO audio can tell me [13:55:39] how was that all done [13:55:57] which reentry range was used for the weather avoidance on Apollo 11 [13:58:13] oh I know actually [13:58:28] 1285 nominal, 1500 for weather avoidance [13:59:05] and that's a consistent number unlike the splashdown page [14:02:04] would that be the desired range input value? [14:02:39] no [14:02:47] that's the problem with the splashdown update page :D [14:02:56] it's a weird range related to some CMC calculations [14:04:11] but that's the range to input on the RTE constraints page [14:04:17] which then get used by all RTE calculations [14:05:17] ahh [14:46:08] MCC7 pad angles are identical to actual [14:46:21] makes sense since its a FCUA on Entry REFSMMAT, but still nice to see [15:22:33] nice [15:22:53] it should be fixed, but be prepared for the entry guidance to do nonsense [15:23:01] so remember your EMS reentry training :D [15:23:23] oh man I have only done that once ages ago [15:23:39] what kind of nonsense? [15:24:15] difficult to say, the thing that you fixed might have tried to make it do lift vector down at the beginning instead of up [15:24:51] and I guess navigation was fixed as you got a good P21 [15:24:59] so should all work right really [15:25:04] yeah I hope so :) [15:25:30] I mostly know how to fly the EMS scroll so worst case I can keep them alive! [15:26:30] ok might seem silly but what the difference between 3 axis and vecpoint maneuvering [15:26:51] VECPOINT is what you are used to [15:27:18] P40 for example, if you are in some attitude then P40 will calculate an attitude that is the shortest way to the desired pointing attitude [15:27:37] 3-axis is some added constraint in roll essentially [15:27:49] so not just pointing you in the right direction, but also right in roll, all 3 axis [15:28:04] I am attempting a p23 with the new optics right now [15:28:13] ah right [15:28:18] the 3 axis put me in what I think is an incorrect orientation [15:28:25] I think the logic P23 uses is 180° rolled relative to Earth [15:28:40] the flight plan angles have the moon where it should be but the 3 axis maneuver did not [15:28:46] so that the LM isn't in the way of doing the sextant stuff [15:28:58] oh the Moon [15:29:07] yeah these are MFH marks [15:29:17] potentially the lunar ephemeris is broken [15:30:14] maybe try a P52 with the Moon to confirm that [15:30:23] ah good idea [15:31:15] yep you are correct [15:31:22] its pointing me where my P23 pointed me [15:32:11] P23 does this. "compute a CSM attitude... where the sextant shaft angle will be 180 degrees (e.g. so as to prevent an attached LM from occulting the SXT star line-of-sight when it is pointed at the star)." [15:33:25] the ephemerides are in locations EMEM 2033 to 2147 [15:33:37] so maybe there is some problem there [15:34:02] I'll take a look [15:35:21] yeah some differences [15:35:59] ah sorry, I had taken a quick look, but only at some examples [15:36:29] no problem [15:37:11] 2040 2041 are different [15:39:12] also won't have been good for your state vector integration [15:39:25] the closer you get to Earth the less it is relevant though [15:39:47] maybe thats why other P23s were awful lol [15:39:56] looks like just those two though [15:41:17] I tried some P23s shortly after MCC5 time and they were very bad [15:41:52] that did it [15:41:55] the reference switch from Moon to Earth will also have been bad [15:42:07] P52 is on the moon now [15:42:16] good to hear [15:42:32] hopefully the last surprise [15:44:57] running a P52 and uplinking a good state vector then I will try again [15:45:53] oh about that S-IVB "fuel injector temperature ok bypass". on the S-II stage, with similar electronics, that signal is actually coming from a temperature sensor [15:45:57] and no bypass [15:46:19] and in the AS-503 Saturn Systems Handbook there is both a bypass and a normal temperature sensor input for the S-IVB [15:46:33] so is there 2 sensors or 2 signals [15:46:43] 2 signals [15:46:48] one sensor, one bypass [15:46:52] S-II only has the sensor [15:46:59] later S-IVBs only have the bypass [15:47:09] Apollo 8 S-IVB has both [15:48:14] but even the Apollo 8 LVDC was setting the bypass signal [15:48:26] so maybe they already didn't use the signal from the sensor anymore [15:50:37] Apollo 6 LVDC already send the bypass signal [15:50:47] I mean a lot of changes were made after 6 [15:51:25] but I couldn't find when they removed the signal from the temp sensor [15:52:57] Apollo 4 also already had the bypass [15:55:29] for the P23, am I making multiple marks by marking then rejecting? [15:56:59] don't think so [15:57:11] but I'm not sure about the right technique [15:57:22] It asks for 3 marks on each in the FP [15:57:38] However it only lets me mark once [15:58:10] I only have the option to reject or terminate marking [15:58:49] also getting pretty awful N49s lol [15:59:09] not sure if its me or possibly more bad erasables [15:59:31] oh you have to just recycle P23 [16:00:20] PRO on the 00016 [16:00:21] so go through the whole thing again [16:00:28] I think so [16:00:39] there doesn't seem to be an option to go directly to marking again [16:00:46] yeah thats what I am seeing as well [16:01:02] well, PRO on the 06 49 [16:01:13] and then do it all again [16:01:15] and then call P23 [16:01:16] yeah [16:01:25] but you can bypass attitude maneuvers etc. [16:01:28] these N49s are very large :P [16:01:41] what did you get? [16:02:37] contingency checklist says to reject about 50NM and 50 ft/s [16:02:41] above* [16:02:51] 91531 14847 [16:02:55] that would be +05000 and +00500 [16:03:05] yeah that can't be right :D [16:03:09] yeah [16:03:16] I am marking the correct place I am pretty sure lol [16:03:26] the opposite horizon from the star [16:03:29] I didn't check the P23 erasables, didn't know you were doing them [16:03:49] probably W-Matrix broken [16:04:33] I figured I would try with the new optics :P [16:04:38] yeah it's broken [16:04:43] haha ok so its not me [16:04:45] 3000, 30001 [16:04:48] 3001* [16:05:18] best check 3000 to 3006 against the padload [16:05:59] wilco [16:06:23] and then V93 before you try P23 again [16:09:20] horizon altitude for P23 is fine [16:10:29] hmm its better but still high [16:10:36] 31529 37001 [16:11:00] call V67 [16:11:04] what does it show? [16:11:14] without incorporating that mark [16:11:58] 52043 00520 00000 [16:12:24] hmm, shouldn't be that large [16:12:31] not after a V93 [16:12:39] thats with a fresh state vector and a V93 [16:13:36] hmm [16:13:38] no idea really [16:13:48] no worries :) [16:13:58] It's probably another erasable [16:14:08] I wish I could just uplink the padload [16:14:20] looking at one specific part in the control electronics for S-II and S-IVB, both AS-503 and AS-508 Handbooks. So 4 sources for essentially the same logic. How likely do you find it that it's wrong in 3 places and correct in 1? :D [16:14:46] hmmmm odds not in favor [16:14:57] unless it was a "copy paste" style error [16:15:22] yeah could really be copy & paste [16:19:35] unless all of the delay timers work differently than I thought [16:20:07] https://i.imgur.com/igdXwda.png [16:20:22] how does this behave... [16:21:38] 1.0 +/- 40? [16:21:48] I think it means 0.4 [16:21:58] yeah I would hope so lol [16:22:03] haha [16:22:23] thats a large deviation if not [16:22:30] the AS-503 one shows them in a weird way [16:22:35] not e.g. 20.5" [16:22:38] uhh [16:22:41] "0.5" [16:22:43] but instead [16:22:46] "0 5" [16:23:00] maybe the decimal ran out of ink [16:24:03] this is the same thing for the S-IVB: https://i.imgur.com/AlWdM1B.png [16:25:44] how I interpreted this is: If input is true, then output is true [16:25:50] after 1 second the output becomes false [16:26:43] but that can't really be the case. It should really be: stays false for 1 second, then true [16:26:48] so just a delay of the input [16:28:32] and that applies to all of the timers in the schematic it seems [16:42:39] interesting logic [17:16:59] EI-30, brushed up on my EMS entry ;) [17:17:04] just in case [17:21:46] don't burn up or skip out [17:23:56] good advice ;) [17:24:49] don't do what my Apollo 4 mission did before I had the entry mode of the CDUs figured out :D [17:33:08] morning! [17:36:57] hey good morning [17:37:24] what's up? [17:41:51] found more bad EMEMs from the restarts :P [17:42:03] hoping there arent more bad ones as I am approaching EI [17:43:25] hey Mike [17:43:31] the Saturn Systems Handbook has tricked me :D [17:44:02] the way it shows delay timers is not like in the CSM or LM Systems Handbook [17:44:07] quite the opposite actually [17:44:24] https://i.imgur.com/AlWdM1B.png [17:44:55] oh? [17:45:17] how would you interpret that [17:45:41] if an input becomes true [17:45:46] the input* [17:46:04] I'd say if the input becomes true, then the output will become true for 1 second before going false again? [17:46:11] yep [17:46:19] that's what I thought [17:46:21] but it's false [17:46:30] that whole thing is the delay [17:46:36] O_o [17:46:38] so output stays false for one second [17:46:40] and then becomes true [17:46:48] that makes absolutely no sense lol [17:46:52] there are three more of these timers, they all look like that [17:47:30] but I know it 100% now [17:47:55] there is another timer that looks the same and starts at engine cutoff [17:48:30] and it's 100% doing something once the time delay has passed [17:49:41] https://i.imgur.com/9pcvK68.png [17:49:48] this doesn't really say much either haha [17:50:01] but it kind of confirms that it's meant to be one logic building block [17:50:51] very strange. But everything works right when that outputs true after the delay time, so, I'll just go with that :D [17:57:15] n7275: "git fetch " simply downloads any new objects (commits, tags, etc.) from the remote repository. It doesn't touch your current branch untill you use pull/merge/et. al. to fast-forward to the new HEAD. [18:06:07] PNGS entry worked just fine :) [18:06:12] *PGNS [18:08:31] Woohoo [18:08:52] awesome [18:08:53] what's next? [18:09:07] 16 [18:10:11] Mike, do you know if there are scans of emergency erasable updates for any other missions than the one you scanned for 15 at Don's? [18:10:29] that would be nice to be able to uplink as I stated earlier :) [18:11:50] I mean, it's just variations of the padload, which we have anyway [18:13:23] The differences probably wouldn't be too different mission to mission, but they made them for a reason. It'll be very useful for people dealing with corrupt memory or otherwise messing up their AGC. [18:13:24] and the document has a list of which erasables go with what emergency update type [18:13:41] we still have some differences to the actually flown padload [18:13:48] so we can't use it 1:1 anyway [18:13:58] but we can of course come up with our own emergency updates [18:14:30] I'll take a look, might be a side benefit when I work on automating padload generation, which I want to do [18:14:33] Would be useful as addition to RTCC/MCC or kept separately on a wiki page [18:15:38] I would imagine the loads to be in the RTCC on tape or so [18:15:47] or punch cards [18:16:01] would be cool to see a V74 compared to the padload as well [18:16:02] so maybe they could be added in the Config/RTCC folder [18:17:15] V74 is basically like reading the scenario haha [18:18:37] oh wait we actually got the document with the Apollo 15 loads [18:20:14] Thymo, which day is that from? What is it called? [18:20:44] Day 3 [18:20:53] ap15_emergency_loads [18:20:59] Single document not in a sub folder [18:21:02] lol I'm going to start processing these scans this weekend [18:21:53] oh I thought that actually had all the erasables as well [18:22:11] there is a similar document from day 2 [18:22:52] I think that is actually the same document and Mike might have scanned it twice [18:22:56] ah ok [18:23:04] the number of words is useful [18:23:22] I think an automated padload creator could just create the emergency loads as well [18:23:42] what's it called in day2? [18:23:49] has its own folder [18:23:58] emergency_updates [18:24:13] oh hah [18:24:22] I guess both George Silver and Russ Larson had copies [19:05:44] indy91 should I just let TLI ride for 16 or push an IU SV update? [19:09:50] n7275 are the FC lights normal pre launch after hatch closing [19:10:31] Are you running his radiator update? [19:10:47] yes [19:10:54] rad temp low tb is bp [19:12:18] What are the outputs of system test 3B,C and D [19:15:49] 0.1 or so [19:17:06] Would be around -40 to -50F. You sure you're running the patch? It's in his own branch still, not merged to Orbiter2016. If you are there's an issue with them. [19:17:15] oh [19:17:21] I didnt know it wasnt merged [19:17:37] https://github.com/orbiternassp/NASSP/pull/636 [19:17:51] Other than the J mission changes I am up to date with the orbiter2016 branch [19:18:01] You could change to that or go to emergency bypass until you are in orbit. [19:18:25] So that means they are broken in the main branch right now? [19:18:26] First one is preffered since he wants some confirmation its good [19:18:28] Yes [19:18:30] ok [19:19:18] try without a IU SV update first I would say [19:19:25] indy91 sure [19:20:34] Thymo how do I merge that draft PR into my branch [19:21:09] You need to add his repository as a new remote and then a regular checkout will do the job [19:21:31] git remote add n7275 for example [19:22:00] git checkout n7275/convectiveRadiators [19:23:04] might not have my latest RTCC updates though [19:23:35] I don't think so [19:23:37] I just want to merge those changes, not check out the branch [19:23:45] I am running my j mission branch currently [19:24:10] Same way. Add the remote, do a checkout -b to a temp branch you can fly in and them merge it [19:24:49] and clone url? [19:25:59] Go to his fork and click the clone button to get it [19:26:24] Or "Code" as they now like to call it [19:26:35] It'll be green [19:27:26] yep got it :) [19:28:18] merged and we will see what happens [19:28:51] I'll fly the whole mission with them to look for ill effects [19:32:54] lights went right out [19:34:19] Cool. System test meter should indicate just past halfway [16:12:22] morning! [16:33:16] hey [16:34:21] what's up? [16:36:31] oh didn't do much, a few finishing touches on an update I somehow stumbled into, S-IVB engine control electronics [16:36:45] the one with the counter intuitive delay timer logic [16:36:51] and you? [16:40:29] messing around with different PDF tools [16:40:47] my usual process for processing scans involved like 3 different tools across 2 operating systems [16:40:53] which isn't going to work for this amount of stuff lol [16:44:45] I mean, even that process could probably be quite automated haha [16:50:36] I almost deleted the whole S-IVB update again because I overcomplicated it [16:50:50] haha oh no [16:50:51] as I tend to do... [16:51:07] but I think it's ok now, just needs a bunch of testing [16:53:23] and when I have that and the LVDC acceleration filter done I can finally try Apollo 6 again [16:54:57] ohhhh that's how you got here [16:55:04] a tangent from Block I :D [16:55:45] yeah [16:56:01] I didn't like a few things when I saw how it behaved with the two engine failures [16:56:18] so I fixed a few things related to that [16:56:36] and saw a bit of bad LVDC and S-IVB code [16:57:04] and then when I fixed the bad code I saw a bit that wasn't so easy to solve unless I rewrite the S-IVB engine start logic a bunch [16:57:07] that's how I got here :D [16:57:15] hehehe [16:57:27] I saw a bug* [17:02:31] indy91: MCC can do nav check PADs right? I didn't get any during Apollo 8 TLC [17:02:57] don't think the real mission got any [17:03:03] It did [17:03:31] It's in the flight plan and checklist mfd. Usually before every MCC or so [17:05:18] Or rather after every set of P23s it seems [17:06:54] what is in the flight plan? [17:06:59] I see P21s [17:07:03] Yes [17:07:37] How do you know a P21 is good if you don't have a nav check pad? [17:07:40] they would do P23s and then check that onboard state vector where it ends up at pericynthion I think [17:07:50] So no PAD? [17:07:59] I'm not seeing it in the transcript, no [17:08:45] I think Jim Lovell manually found the pericynthion altitude with P21 [17:09:21] the Nav Check PAD is really to confirm that a state vector uplink was successful [17:09:51] but that's not what these P21s were used for [17:09:55] And how would he verify it was any good? Against what data? [17:10:29] they did get info like this [17:10:30] 021:13:45 Carr: Apollo 8, this is Houston. We are showing your pericynthion 64 nautical miles. [17:11:21] this is probably interesting to see if you could safely navigate around the Moon with just P23 [17:11:40] but the real measure of good P23s is if the N49 converges [17:12:59] the Checklist MFD probably only has the generic P21 procedure [17:13:11] and not a technique to find pericynthion with it [17:13:39] Right. An opinion should be formed wheter or not NASSP is 100% going to strictly be orignal FP conformant or if some extra bits like nav check pads can be added. There obviously isn't a CAPCOM that can tell you the pericynthion, so should an extra pad get sent or the P21 be scrubbed. [17:14:10] lol, but be careful with P21 [17:14:12] 007:57:43 Mattingly: Okay. On P21, the thinking runs that you had a slight error in your state vector at the time you started, and when that was integrated out, it intercepted the lunar surface where it locked up and this is contained in a fairly recent program note. [17:14:33] This question arised from someone on Discord that is doing the P21 and has no clue what he should verify it against [17:14:43] also Apollo 8? [17:14:46] Yes [17:14:59] I mean sure, but this is such a Apollo 8 specific thing [17:15:16] they never did that thing with P21 again [17:15:20] they did a lot less of P23 [17:17:11] but something like a nav check PAD with the pericynthion state could be useful [17:19:46] or something in the CAPCOM menu that tells you some general trajectory numbers [17:26:18] a nominal pericynthion is 60NM [17:26:30] so that's what you should get with P21 [17:26:49] once you have iterated for a while to find the closest approach [17:27:37] Nav check is probably best IMO as that is already implemented, the rest would all be special cases just for Apollo 8. [17:32:12] this will already be a special case as it will have to calculate the nav check for pericynthion [17:32:18] and not an input time [17:32:49] The P21s are all targeted at GET 69:10:00 in the checklist mfd [17:33:03] right, that's an estimate from the real mission [17:33:18] Wouldn't that work? It's around LOI-1 time [17:34:12] sure, but altitude changes quite rapidly at that time [17:34:29] if you are off by more than a minute or two of actual pericynthion time then P21 is pretty meaningless [17:35:26] If the times are both the same the altitude should also be the same. Or is the P21 also meant to check if the trajectory is still good? [17:37:17] it's a check if the CMC thinks the trajectory is good [17:37:32] that's why you search for pericynthion and not some random time [17:37:49] just a general confirmation that the CMC can navigate safely around the Moon [17:40:12] Hmm makes sense. Alternatively we could add an instruction to the checklist MFD to calculate it with the RTCC MFD. [17:40:24] Don't know if you can also calculate pericynthion time using it [17:41:08] you can of course, but I'm not sure it's one of the easier functions of the MFD... probably not [17:41:21] you can of course do the same nav check calculation as P21 [17:41:24] and very quickly [17:43:02] Yes, but as you said that needs to be at pericynthion so you need to know when that is [17:43:28] well roughly [17:43:34] and then you can vary the input time [17:43:52] P21 takes minutes to integrate to that time, so it's "a bit" quicker in the RTCC MFD haha [17:44:17] So you're essentially suggesting a binary search to find a nav check pad with the lowest altitude? [17:44:38] I think that's the easiest method in the RTCC MFD right now [17:44:59] we also have the actual display with that information [17:45:10] but that only works with the MPT which you need to initialize etc. [17:45:35] Yeah, initializing the MPT while flying on MCC sounds too hard. I don't even know how to do that. [17:45:55] Adding a binary search option to the MFD should be easy. [17:46:34] Then the question still remains to either diverge from 100% checklist accuracy to describe the RTCC steps or to add the behavior to MCC [17:46:37] oh I have much better methods than that to find the pericynthion through a calculation, this would be the MFD user doing the binary search by hand [17:47:50] hmm already found a problem with that [17:47:56] Oh please no haha. They'd be going on for so long [17:48:15] nav check PAD doesn't calculate altitude relative to the landing site radius [17:48:28]