[04:23:39] NASSP Logging has been started by n7275 [04:23:41] Thymo, ah ha. https://github.com/orbiternassp/NASSP/commit/55254914e5cac39c29812fb943fc711d3d09a64c [11:12:58] "convective heat transfer, useful for preventing the radiators from cooling to 0K on the pad". Yeah, that sounds about right from what I saw haha [11:13:47] Weird that I haven't heard anything about it since it's been in for a couple of months. [11:14:01] Looks like people are not flying enough prelaunches :p [11:18:42] aparently. I'm working on a solution that keeps eps and ecs radiators happy on the pad. [12:32:24] and yeah, after I merged that update I've been waiting for someone to find at least one bug [13:33:45] hey [13:34:52] Thymo, at what T minus time did you start having fuel cell temperature issues? [13:37:53] we have done prelaunch stuff in the last few months and I am not convinced that this happens if you e.g. let the auto checklist do the prelaunch procedures [13:38:06] but I am trying it right now, want to test an Apollo 8 launch anyway [13:39:19] could also have been hidden by the CWS being in ACK [13:39:29] hey Nik [13:39:35] https://github.com/orbiternassp/NASSP/commit/55254914e5cac39c29812fb943fc711d3d09a64c [13:40:14] oh, now I remember [13:40:22] you added some code to improve the prelaunch temps [13:40:25] but it was buggy [13:40:30] so we don't use it right now [13:40:49] it broke Ryan's ecs update so we agreed to comment it out for now [13:41:06] and "for now" has been a few months now [13:41:10] and I was like "I'll fix that this week" [13:41:22] look at that, I get FC lights now that I am not in ACK :D [13:42:18] I guess I can go to a T-60s scenario for a launch test then... [13:42:42] I'm working on a fix [13:44:15] with the issues I have seen on Apollo 6 I have a fairly big LVDC update soon [13:44:39] just have to do a few more launches [13:45:26] including a feature that I thought was unnecessary because our S-II and S-IVB engines are perfectly straight in their null positions [13:45:35] but it's actually quite necessary for engine failures [13:45:55] and might even improve steering accuracy in a normal case [13:48:25] oh nice [13:50:27] a steering misalignment correction [13:50:50] it basically tries to align the actual acceleration vector with the desired attitude [13:51:04] and not just point the nose of the Saturn to that attitude [13:52:09] accounts for engines being misaligned and engine failures making the thrust vector assymetric to point through the CoG [13:52:48] but I am also getting a 0.2° difference in pitch when everything is normal [13:53:23] I wonder if that sees the actual pitch attitude lagging behind the desired one during a normal launch... [13:54:22] only during S-II and S-IVB flight though [14:19:00] good morning [14:33:40] morning! [14:36:24] hey guys [14:41:04] last morning of scanning, unless this hurricane decides otherwise [14:42:25] ah it's just a tropical storm by now, big difference :D [14:45:12] haha [15:08:43] indy91: T-3:30:0 or something? I dunno, I wasn't too far in, I did everything manual, so no auto execution by the mfd [15:09:06] yeah I checked, seems normal to get the fuel cell lights [15:09:30] I probably didn't notice because the CWS was in ACK mode, so you only see the lights when you press the master alarm button [15:09:46] just some random alarm I ignored :D [15:10:55] You missed the wailing master alarm? [15:12:23] well I pressed the button to make it go away, but wasn't interested in the cause of it [15:12:33] I also very rarely do the prelaunch manually [15:12:37] missed =/= ignored ;) [15:14:44] I bet you're also driving with a check engine light on then lol [15:16:03] oof [15:24:32] so what eva functionality is in place currently (old or otherwise) I see I can get one crew on the surface and plant a flag and ingress...anything else for grins? [15:24:33] nah I just didn't care for problem A if I was testing stuff for problem B [15:24:42] it would be different if I was trying to properly fly a mission [15:24:58] rcflyinghokie, on Apollo 15+ you can deploy the LRV! [15:25:08] oh how? [15:25:36] V [15:25:56] using the astronaut in EVA [15:26:06] haha magic [15:26:35] I don't think you can do anything else with the LRV right now [15:26:38] hmm [15:27:10] just deploy it? [15:27:18] and turn the wheels [15:27:59] you might be able to drive it [15:28:12] trying to figure out how [15:28:45] numpad + - [15:29:24] haha [15:29:52] CTRL for finer steering apparently [15:30:03] 1 and 3 on numpad for steering [15:30:09] yep and 2 to center [15:30:59] Would moving all engines currently in the THRGROUP_MAIN, HOVER and RETRO to THRGROUP_USER cause any issues? [15:33:02] yes [15:33:04] sound issues [15:33:15] we have to manually play the engine sounds then [15:33:19] like we do for the RCS [15:33:30] but it can and eventually should be done [15:40:15] oh to address that AGS scaling, I have added to the Apollo 9 checklists "1 fps" next to the 450 451 and 452 entries [15:40:36] I think that could be useful, I never thought about it because its engrained haha [15:57:02] Right now I can load a prelaunch, hit + and launch an unguided rocket. So we probably should haha [15:57:41] I also had to abort because of that. I hit - and my engines didn't start again. Got some Mode III practice that way haha [15:59:04] some people don't pay attention to master alarms, other people press random buttons during launch [16:01:15] https://en.wikipedia.org/wiki/Monkey_testing [16:07:49] Is it only sound? Shouldn't be too big of a deal right? [17:16:29] probably not too bad yeah [17:16:40] fairly sure it's only sound [17:36:05] rcflyinghokie, I can't remember, is there any kind of ecs chiller running during prelaunch? [17:46:32] n7275 yes [18:00:17] https://drive.google.com/file/d/1i5OiIUHBEV5my0sRV7jUF099IqOkSWj_/view?usp=sharing [18:00:42] I think I made it less bad [18:04:34] indy91 is the MPT in any shape to compute my lunar ascent before the CSM plane change? (storing the CSM plane change in MPT then using that for the LM) [18:06:01] launch targeting uses the input vector time for the CSM [18:06:08] so if that time is after the plane change [18:06:33] then it should be good [18:06:47] ascent processor uses the liftoff time for that [18:07:34] was that a problem last time? [18:07:37] I think so? [18:08:00] something related was a problem [18:08:39] or was that only the ascent pad [18:09:03] So what am I using for the MPT [18:09:28] I need to put the plane change of the CSM on the CSM MPT? [18:10:00] yes [18:10:25] launch targeting always uses the CSM MPT for the CSM SV [18:11:39] ok [18:19:13] n7275: +53 is certainly less bad than -50 [18:20:11] I'm at -5 min now, things look much more realistic for temps [18:20:28] up to 59F with the sun up [18:20:44] ecs rad out temp is 66F [18:21:12] GETLOR is that my predicted ascent time? [18:21:50] I don't think I had a lot of trouble with the ECS RAD, I did with the FC RADs [18:24:06] Are there any differences to the update forms on Apollo 8? We have them checked in for 7 but have none for 8 specifically. [18:24:29] In the past we had the Excel flightplans that included them and could make pretty nice graphs, looks like those are gone now. [18:25:21] rcflyinghokie, yes. I think that's a terminology from Gemini launches, "GET of liftoff, recommended" [18:26:03] Thymo, there is a difference between Earth orbit vs. lunar missions when it comes to the PADs [18:26:25] https://www.ibiblio.org/apollo/Documents/A8-Updates-1004.pdf [18:26:51] indy91 ahh ok that makes sense I was thinking "lunar orbit rendezvous" [18:28:45] yeah the RTCC Requirements document also calls it "recommended lift-off time" [18:29:16] Should've been more specific. I meant to record the consumables as part of the periodic system checks. I'll just write them down on someting as my printer is broken so I can't print forms ATM. [18:30:12] This should work on 8 for that purpose https://github.com/orbiternassp/NASSP/blob/Orbiter2016/Doc/Project%20Apollo%20-%20NASSP/Flightplans/Apollo%207/Apollo%207%20Update%20Forms.doc [18:31:03] hmm right [18:31:16] I'm not sure they really wrote that down periodically on 8 [18:32:43] Checklist MFD calls for it. Besides, it will be nice to see some graphs at the end [18:32:45] there was also a crew log [18:34:58] LMP Checklist has graphs of expected consumables during the mission [18:35:51] I'll just write stuff down and I'll figure it out. Shouldn't be too hard to dump them into a spreadsheet a plot a graph over time [18:37:06] might need to look back at some of those and remove the record steps if they are unnecessary [18:37:18] I know there are a few especially post insertion that have those from copy paste [18:51:26] They are in all the periodic checks I've done so far [18:56:06] yeah they were copy paste I am pretty sure [18:58:47] https://github.com/n7275/NASSP/tree/convectiveRadiators [19:15:49] a bit of an annoying discovery that the parameters in the Apollo 11 LVOT are not as flown. Most of the numbers were generated without the early S-II inner engine cutoff in mind. [19:16:26] we have so few LVOTs anyway, why can't they at least be as flown... [19:42:47] how early were they generated? [19:46:29] the LVOT is from April [19:46:54] the document does mention the change, but also says it doesn't use it for the simulation of the trajectory [19:47:06] so e.g. the graphs are still without the S-II inner engine cutoff [19:48:19] and it seems like the guidance presettings are, too [19:49:48] the Apollo 12 LVOT for a September launch already has the changes [19:49:58] that document is from June 1969 [19:50:12] very similar to the Apollo 11 document otherwise [19:52:43] so maybe the change to do the cutoff was fairly recently as of April 1969? Maybe [19:53:49] May 2 [19:53:50] A temporary fix to provide for an S-II-stage early center engine cutoff was made for Apollo 10 and 11. Purpose was to eliminate oscillations of the center engine and sympathetic structures. (See March 28, 1969, entry.) Meanwhile, plans were being made to incorporate a permanent fix into Apollo 12 and subsequent vehicles to eliminate the oscillations. [19:58:31] permanent fix was change nothing anymore and hope the early cutoff is good enough [20:07:16] there is nothing permanent than a temporary solution [20:14:11] There's only IU uplink and no downlink yet right? [20:15:02] I want to check what TB the IU is in to be sure [20:32:02] yeah no downlink [20:32:13] there is the lvlog [20:33:32] Aight. I went to play with SIVB takeover briefly but I wasn't 100% it went into orb rate again. [20:33:38] Looks it did though [20:35:36] [5+8307.970002] ORBITAL NAVIGATION [20:35:43] there will stuff like that in the lvlog [20:35:48] the 5 at the beginning means TB5 [20:36:05] It spammed a bunch of "Maintain orb rate" so I'm good [20:36:47] Now it's time to squeeze in P51 before TLI because I misclicked closing the switch cover in the VC [20:36:51] facepalms [20:37:44] what did you click? The IMU switch? [20:38:48] Yeah, I wanted to close the cover, forgot to close it earlier. But the click spot is in front of the switch suspended in the air in the VC, so if you right click in slightly the wrong place you turn it off [20:39:09] yeah I really don't like the clickspots for the switch covers [20:39:11] in the VC [20:39:24] if you do P51 you will loose the launch REFSMMAT [20:40:09] but you could do P51, then the RTCC MFD should still have the launch REFSMMAT for you to uplink and then do a P52 option 1 [20:40:35] Hmm [20:41:00] What about if I set the REFSMMAT flag and then do a P52 option 3? That should work [20:41:26] should work [20:41:39] but P52 probably won't find good stars [20:41:45] and the torquing angles will be large [20:41:59] yeah you probably will have to bypass PICAPAR [20:42:16] if you are really tight, you can just run it after TLI [20:42:45] I'm 10 minutes before the scheduled P52 so fine time wise [20:42:53] oh yeah no issues [20:43:03] Basically pulling an Apollo 12 :P [20:43:07] I'm 99% sure there is something about this in the emergency procedures mike scanned the other day [20:43:28] Stuff like accidental P01 is covered and it mentions how to get the platform back [20:43:35] And when you can skip P51 [20:49:30] It was the Apollo 8 CMP checklist on no comm fresh start recovery [21:00:33] night! [21:01:06] Got it. V41 to GDC angles, V42 to release the platform. Set REFSMMAT flag and on to P52 [02:24:57] saw this the other day https://www.facebook.com/groups/vintageibm/permalink/3927026004093409/ [13:37:18] hey [13:37:42] good morning [13:37:49] I think kuddel was searching for the NASSP installation instructions in the NASSP git repository [13:38:01] "Can you point me to a place where to find it? I'm unable to find it in the git repository." [13:38:14] yeah i see that [13:38:44] he found it before I could reply it seems haha [13:38:46] maybe we should link to the Orbiter Forum post about it in the readme on github [13:39:02] probably a wise idea [13:39:40] the NASSP subforum is linked to there though [13:40:51] and the installation instructions are at the top of that [13:41:04] I would think that's enough...but some people don't read :P [13:42:14] oh, another topic, can we add back the LM ejection force? [13:45:52] sure [13:46:02] right now it's 0, correct? [13:46:11] because docking port gets deleted and not normally undocked [13:47:11] yeah zero currently [13:47:12] CSM Data Book doesn't have a specific force value [13:47:22] but some numbers that could be used to derive that [13:47:29] we need a force that imparts approximately 0.8 fps on the CSM haha [13:49:12] I'll look through the documentation, I'm sure we have some force [13:49:21] number for the force* [13:51:22] or maybe it could simply be done by undocking like before [13:57:07] ah I can search in the Orbiter code itself how that works with DelDock :D [14:04:11] I havent been brave enough to go into the orbiter code lol [14:04:42] I've looked up a few things I always wondered [14:05:26] slightly annoying to do the undocking because I can't undock via the docking handle, only with the docking port indexs [14:05:28] index* [14:05:33] for (UINT i = 0;i < DockCount();i++) [14:05:34] { [14:05:35] if (hDock == GetDockHandle(i)) [14:05:36] { [14:05:37] Undock(i); [14:05:38] } [14:05:39] } [14:05:45] should work [14:06:03] Undock(hDock) would have been easier, but there is no way to do it like that it seems [14:06:14] No way to do it.... yet [14:06:36] I'll try it that way, might not work because it's the same timestep as docking port deletion [14:07:37] hmm, that's strange [14:07:48] apparently the Undocking function has a separation velocity input [14:07:56] we don't have that though [14:08:02] maybe it's a super recent Orbiter Beta feature [14:09:48] how recent, it hasnt been updated in a bit has it? :P [14:11:43] martins said there are some changes to the last Beta SVN snapshot [14:12:25] is it on the SVN? I still am on rev 90 as the latest [14:13:02] yeah, I just checked, no update [14:13:18] hey guys [14:16:13] hey Matt [14:16:56] hmm, I need to search if the previous revision history of Orbiter exists in the repo [14:17:45] sent a draft PR for the radiator fix. I'm not in a hurry to merge it. some one else should test it too. [14:18:42] oh you know what it is. The "Vessel" class is not the public class with accessible functions [14:18:55] The "VESSEL" class has accessible functions via the Vessel API [14:19:20] and that Undock function doesn't have the option [14:22:05] n7275, looks quite nice and simple [14:22:40] :) [14:28:17] rcflyinghokie, it works, I even made it to complicated. So I can simply undock before deleting the docking port and we get the velocity added to it like before [14:28:20] 0.2 m/s [14:28:22] close enough [14:28:47] too* [14:29:30] a touch slow but certainly not bad [14:30:08] better than having to burn 0.8 fps of RCS [14:30:20] extra fps [14:31:46] and super easy [14:40:03] Fun fact: I just port forwarded my PCM telemetry port and Steven was able to connect to it from his computer. He even did a V35 on my DSKY and turned on the crew alert. [14:40:42] So I now need to be extra careful to block updates so he doesn't upload bad state vectors or something haha [14:40:51] hahaha that's awesome [14:41:21] I would uplink a large IMU bias compensation to really confuse you [14:42:51] nice [14:44:13] one thing I got from working on the programer for Apollo 4/6 is that I really want to improve our Updata Link equipment [14:44:18] adding a proper relay box for it [14:44:35] and make UP TLM Reset switch actually reset all the relays [14:44:44] UP TLM CMD* [14:49:19] Yeah. I couldn't reset the crew alert he turned on. That should be resettable I think [14:49:27] yep [14:49:32] I'll work on it [14:49:56] it's only like 10% as complicated as the programer and all its ground uplinks haha [14:52:24] doing lots of S-II engine failure tests right now for the LVDC update for that [14:57:12] very cool [15:00:31] dual engine failures are still not treated correctly for Apollo 10+ I think [15:02:14] for Apollo 8 and 9 the same problem as Apollo 6 experienced was still present [15:02:44] second failure isn't detected, vehicle goes into att hold for S-II/S-IVB staging, but that happens much later than expected [15:03:05] so a large altitude rate and too high altitude happens [15:11:41] looks like I have another stuck maneuver on the MPT [15:14:33] fun [15:14:37] how do I manually remove it? [15:15:37] you can't remove it the normal way? [15:16:21] with the MED [15:17:45] the delete button in the MPT? [15:17:48] yeah [15:17:55] thats what I mean by stuck [15:18:10] wont delete that way "maneuver does not exist [15:18:39] well manual method is editing the scenario [15:18:50] yeah thats what I mean [15:18:51] which maneuver is it [15:18:59] LM ascent [15:19:00] and are there other maneuvers on the MPT? [15:19:02] nope [15:19:07] of course it's the ascent haha [15:19:34] MPTCSM_BEGIN [15:19:42] that's where MPT part of the scenario starts [15:19:53] or I guess rather MPTLEM_BEGIN [15:20:12] if you delete everything between that and MPTLEM_END then the LM MPT is completely cleaned out [15:20:20] ok cool [15:20:30] is this after ascent [15:20:32] or before [15:20:48] before [15:21:17] so probably a failed scenario reload [15:21:27] yeah it happened on reload [15:21:40] I think I know what to check at least [15:21:59] it tries to bring the LM state vector to current time when reloading the scenario [15:22:07] but it's a landed "state vector" [15:22:18] so that's probably not working right [15:24:15] ahh that could be it [15:25:41] oh and if it says "maneuver can't be deleted", then you have already partially deleted it on a previous deletion attempt [15:25:54] but something failed and the displays weren't updated [15:26:02] display update always happens last [15:26:11] so if something goes wrong then that doesn't happen [15:36:50] do I need the MPT active to to MVE on the checkout monitor? [15:38:33] probably [15:38:41] although the checkout monitor only works with the MPT [15:38:49] might not check if it's active or not [15:46:35] hmm now I cannot calculate my ascent :( [15:46:40] bunch of nans [15:47:32] LM MPT is active and initialized [15:47:48] what did you all delete [15:48:04] MPTLEM_BEGIN to MPTLEM_END? [15:48:15] hmm [15:48:25] I cleared all of the MPT [15:48:26] maybe you should also delete the LM anchor vector [15:48:40] it seemed to update properly [15:49:13] RTCC_MPTLM_ANCHOR [15:49:29] and then start fresh with the LM MPT [15:49:57] ok [15:53:03] RTCC_MPTLM_ANCHOR 9 APIL004 -1 -1 0.000000000000 0.000000000000 0.000000000000 0.000000000000 0.000000000000 0.000000000000 0.000000000000 1 [15:53:31] yes [15:53:39] lots of zeros [15:53:49] yeah, but crucial is the last number [15:53:50] 1 [15:54:02] that is the lunsr surface indicator [15:54:04] lunar* [15:54:17] so if that is a 1 then there doesn't have to be any other number [15:54:27] it just uses the landing site coordinates stored elsewhere [15:55:07] try deleting that [15:56:11] it worked after deleting that [15:57:07] yeah the bug is probably unrelated to this "state vector", but deleting it stops the ephemeris from being generated [15:57:23] and that's probably where the issue is [15:58:41] and the parameter is 1 for the checkout monitor and MVE? [15:59:27] 1 for the first maneuver on the MPT [15:59:35] same number as is displayed on the MPT for it [15:59:36] and then GET in the top left is insertion GET? [15:59:39] as partof the maneuver code [16:00:28] GET on this display is always the GET of the state vector used to calculate all the numbers on it [16:00:46] and MVE is maneuver end [16:01:13] and insertion is the end of the ascent maneuver haha [16:01:19] so yes? [16:01:22] in this case [16:01:58] yes [16:02:11] :P [16:02:23] you've asked this already before, just trying to explain the logic of the display [16:03:48] if your request was for altitude = 0, so like a lunar impact, then it's the GET of the state vector at altitude = 0 [16:04:12] specificaly for MVE, it's the end of the thrust tailoff phase [16:07:28] always useful if you e.g. wanted to calculate the orbital parameters as a direct result of a maneuver [16:08:33] but just getting the GET of the end of the burn is useful, too. For TLI for example, as a reference time for abort maneuvers [16:08:48] definitely been used that way by the FIDOs [16:25:15] morning! [16:30:20] right I just had only done it once so it escaped me [16:30:23] hey Mike [16:47:35] rcflyinghokie, yeah no problem, I can't say the MPT is well documented :D [16:47:44] thewonderidiot, how is the tropical storm treating you? [16:48:18] well, it cancelled my flight so my travel home got messed up lol [16:48:26] didn't get home until 2am or so [16:55:56] ah damn [16:56:13] can you hear the storm whisper "Mike, scan all of the LM Data Book now that you have more time" [16:56:36] hah, the LM data book is a problem for future Mike [16:57:03] it and all of the amendments for it take up more than half of that box [16:57:34] and since it's in a museum, using the auto feed scanner isn't an option, they'd have to be scanned on a slow flatbed one at a time [16:57:37] it would probably take weeks lol [17:00:11] oh it's in a museum? [17:00:23] I think it was just something freshly discovered [17:00:31] well, in the MIT Museum's collection [17:00:32] can't remember it being on the list of documents that Don has [17:01:04] ooh [17:01:07] MIT Museum? [17:01:13] we knew that they had this [17:01:51] yep [17:05:34] oh wanna see something else fun that Don had upstairs? [17:05:41] not really useful, just interesting [17:06:24] https://i.imgur.com/689CNbw.png [17:06:27] one page of DIGFLY [17:07:49] "DIGFLY BY WIRE", that is a very clever author name and now I understand why they named it that lol [17:15:11] one page out of at least 623... I'd say it's a start for the reconstruction process :D [17:15:20] lol [17:15:57] 1971, for some reason I thought this was much later [17:16:26] who even worked on this, they had 4 version to support at the same time ouch [17:16:36] Luminary, Artemis, Skylark, Digfly [17:16:45] yeah I thought it was later too [17:25:57] hey Mike [17:26:31] yo [17:52:31] I am trying to get P20 setup for rendezvous in the CSM, and I cannot seem to get it to mark [17:52:37] my marks number is 78 00 [17:53:08] trying to let it VHF mark [17:53:10] MINKEY or no MINKEY [17:54:03] ah wait [17:54:18] you don't start MINKEY until you actually call one of the rendezvous programs P3X [17:54:49] P20 option 0 or 4? [17:54:57] zero [17:55:05] I am still not well versed in this P20 haha [17:55:42] and you did V87? [17:55:45] yes [17:55:49] and you locked on [17:55:51] EMS is counting etc. [17:55:52] yep [17:56:02] still just +78 00 [17:56:31] did you manuall call 16 48? [17:56:39] 45 [17:56:40] ? [17:56:48] uhh yes, 45 [17:56:54] yeah [17:57:04] also had it up in P34 as well [17:57:33] I mean, before it does any marks the mark counter might be random [17:58:11] oh wait... [17:58:21] I MIGHT have forgotten to reset the surface flag... [18:01:09] that could do it [18:02:38] it did [18:23:57] man it really wants me in a an odd TPI attitude [18:25:24] its hell bet on having my roll at 180 [18:25:26] bent* [18:32:40] option 0 does that? [18:32:54] I thought only option 4 would do that with the specified angle [18:44:58] this is the LM P20 [18:45:05] sorry LM P42 for TPI [18:46:13] oh [18:46:34] so I am not sure when I was supposed to initially set roll to 180 [18:47:09] oh is this the infamous "yaw roll maneuver" [18:47:31] is that what that is on the lm timeline? [18:47:43] I have no idea what that is haha [18:48:55] hmm well I think it's a maneuver to avoid breaking radar lock [18:49:08] because the TPI attitude is in any case far off the tracking attitude [18:49:12] yeah it was [18:49:23] interesting [18:49:44] I would still think P42 tries to go the shortest way, attitude maneuver wise [18:51:28] yeah I can see how manually maneuvering I could have maintained radar [18:53:03] but I still think I should be heads up not down [18:54:49] even when i maneuvered heads up it still wanted to change my attitude [18:55:39] OT has IMU angles 100.2° pitch, others roll [18:55:43] others zero* [18:55:53] pitch way of course vary [18:55:55] may* [18:56:42] what if you manually maneuver to the attitude? [18:56:50] Does P42 still want a 180° roll maneuver even then? [18:57:22] Otherwise it should choose the shortes attitude maneuver. If you are further away from the target than maybe 90° then it probably wants to do more of a yaw than a pitch [18:58:10] yeah I need to play with it [19:02:26] I really wish i knew if I was supposed to be heads down or up [19:14:57] you are supposed to be roll angle = 0° [19:15:04] according to the OT [19:18:47] OT? [19:19:55] operational trajectory [19:20:19] I usually say SCOT and LVOT to separate the two documents for spacecraft and launch vehicle haha [19:21:12] in the MOCR they definitely use OT, because they don't really care for the LVOT. That's a Marshall only thing [19:42:39] haha gotcha [19:45:47] I'm doing so many launches today and yesterday, all because I am not 100% sure that I like a 0.2° steering misalignment correction :D [19:46:05] hahaha [19:47:32] I think what the calculation there sees is the vehicle lagging behind the desired attitude, because there is a near constant pitch rate during S-II flight [19:48:19] the attitude error cycles between 0.17° and 0.34°. When a new attitude just got computed (happens every 1.7 seconds) it jumps up to 0.34°, and goes down to 0.17° in the minor loop (25 times per second) [19:49:31] just looking if that 0.2° is actually in the direction to make the error 0.2° smaller [19:52:03] the behavior can be a bit random if the direction of the steering changes, e.g. when it's transitioning to terminal steering during TLI [19:52:22] but even if that looks random, it's quite small angles. So I think I am fine with it. [19:55:44] yeah I think it's biasing the steering in the right direction. That's good. [19:56:19] and the main purpose of implementing this, when there is a S-II double engine failure then the thrust vector is about 12° away from the direction in which the Saturn actually points. Significant difference [19:56:31] double engine failure on the same side* [19:56:46] indy91_: Does the RTCC MFD do a V35 when it can't get a connection? [19:57:03] no [19:57:08] Hmm [19:57:20] at the end of an uplink there always is a V33 though [19:57:42] but nothing in the RTCC MFD should do a V35 [19:58:04] I had the telemetry client connected while uplinking and when I disconnected it it started sending keypresses in the middle of the uplink. Somehow it managed to get a V35E during that [19:58:25] weird [19:58:32] It really could use a sanity check in case it can't connect to the socket at the beginning of an uplink. [19:58:40] maybe telemetry client send a Verb and RTCC MFD a 35? [19:58:58] I didn't press anything in the client so it didn't [19:59:31] Maybe I had pressed verb earlier and I disconnected the client when it was sending 35E or something. [19:59:43] maybe the RTCC MFD did V.... 35 but couldn't send the stuff in between? [20:00:51] I probably pressed V minutes earlier. When I disconnected it might've been uplinking XXX35E as state vector data [20:01:20] Nevertheless it's probably a good idea to cancel the uplink instead of trying to reconnect each keypress [20:01:24] but yeah, the RTCC MFD and PAMFD (and I guess the MCC?) are just sending stuff even if the uplinked is blocked or so [20:01:53] oh reconnect [20:02:15] Yes, the telemetry client was blocking the socket. [20:02:15] speaking of uplinks, I need the P99 loads for Apollo 15 [20:02:36] well I just copied the code for this from the PAMFD to the RTCC MFD way back in the day and never looked much at it. [20:02:41] but I probably should :D [20:05:10] I'll take a look sometime. Might be better to allow multiple connections so you can have both. [20:05:34] rcflyinghokie, the RTCC MFD has those preloaded [20:06:38] Utilities, Erasable Memory Programs [20:06:44] oh perfect! [20:07:13] that's the one I had a 50% success rate with, but probably user error [20:07:25] I think we have more than one version of the EMP for this [20:08:28] ok P30 is uplinking now, then I will try it [20:09:32] it's 4 uplinks of course [20:10:04] I used the version in the GSOP section 7 [20:10:11] should definitely be a good version [20:11:47] so I just do uplink 0 then 1 then 2 etc?> [20:11:51] yep [20:12:28] does it really start counting at 0 [20:12:31] oh well [20:12:39] yes lol [20:13:50] hmm [20:14:22] oh never mind [20:14:43] haven't tried it in a while [20:14:46] did it get broken? [20:14:47] I thought it stopped at 2 but it just was my computer being silly [20:14:58] all 4 uplinks complete [20:15:41] Don created a "EMP For P47 Ascent" [20:15:57] "If a breakdown in communications makes it impossible to target [20:15:58] P12, and it is urgently necessary to get off the moon, P47 may be used [20:15:59] to monitor the ascent burn." [20:16:27] I was just about to say there is no way this is any useful [20:16:31] but [20:16:35] AGS ascent [20:16:40] monitored by P47 [20:17:27] with P12 displays available [20:18:10] I thought this was all about a manual ascent. If the LGC is working in any way then that is preferable to manual [20:21:09] yeah absolutely [20:21:21] but why would the EMP be needed [20:22:25] "the EMP given here enables displays of [20:22:26] forward and lateral velocity, altitude, and altitude rate instead of the [20:22:27] standard display of accumulated delta-V in noun 83" [20:23:23] so just enables just more displays from P12 [20:23:39] but I found it unlikely that you would do a ascent with p47 [20:24:17] would still be fun to try [20:25:18] yeah, AGS ascent, P47 and the EMP [20:25:59] and the EMP has the extra feature of "resets SURFFLAG as soon as average-G starts." [20:26:08] I guess P12 normally does this at liftoff [20:27:12] maybe P20 should also reset the SURFFLAG when it starts :D [20:27:16] in the CMC [20:27:21] haha [20:28:43] You can totally write an EMP for that. [20:32:14] even I could do that [20:32:39] hehehe [20:32:50] there is BON and BOF in interpretive [20:32:58] uhh [20:33:06] that's not what I meant [20:33:22] IIRC interpretive can't be called from EMEM [20:33:55] yeah I would be very surprised if you could call the interpreter from an EMP [20:34:06] We could code golf an EMP. Whoever comes up with an EMP containing the least instructions wins. :p [20:34:14] guess I can't do it anyway if I forgot that BON and BOF are just switches [20:34:37] wasn't there instructions to set a flag on and off? [20:35:30] How about SET :P [20:35:35] SET, CLEAR, SETGO, BONSET, BOFSET, BONINV, INVGO, BOFINV, INVERT, BONCLR, CLRGO, BOFCLR [20:35:37] there are many options [20:35:39] lol [20:36:00] set, clear, invert, and ways to combine those with jumps [20:36:27] right, just SET and CLEAR [20:37:23] in basic you'd use UPFLAG and DOWNFLAG [20:41:38] little subroutines, right? [20:41:53] well so are SET and CLEAR I guess haha [20:45:47] yeah haha [21:04:15] night! [21:10:40] thewonderidiot: Is there anyway to get a BBCON of an alarm in Luminary 99 or is it just on a fresh start? [21:11:00] Someone got a 1210 and I'm not sure from where [21:13:11] noun 08 [21:14:22] Sweet [21:16:16] One of those nouns I pretty much glaze over in the G&N dictionary :P [21:21:57] Got a 2CADR 3722 70000 for Luminary099 [21:22:26] First one is adres second one BBCON right? [21:23:35] looks like it [21:25:14] so it was the RADSTALL at the beginning of LRHJOB [21:25:27] at 34,3720 [21:29:00] How do you know it's LRHJOB? [21:31:51] because that's the label right above address 34,3720 lol [21:32:12] Oh duh [21:43:57] This 1210 alarm is fun. P63 is doing loops at the end of the braking phase and then slams into the surface [21:44:13] He's rerunning from scratch to see if we can find what caused it [21:51:35] Looks like it's his laggy PC corrupting the AGC. It's the same issue we see at high acceleration causing restarts and 1107s. I really can't figure out how lag can cause these things to happen. [22:03:12] some sort of threading bug probably [22:05:52] It's always a concurrency problem https://i.imgur.com/RbelQBq.png [22:16:20] There might indeed be a case where the agc timestep is run without acquiring the lock. I'll add some debug code and we'll see if it's triggered [07:28:38] morning! [11:00:25] good morning [11:28:03] Hey [13:50:37] hey [13:50:45] good morning [13:51:04] your MPT bug is super simple. Remember all the zeros in the state vector? well the logic for generating the ephemeris when loading a scenario checks if the GMT is zero. Then it doesn't generate the ephemeris [13:51:33] so it didn't generate the ephemeris, but there was still the ascent maneuver on the MPT [13:51:48] and then bad things happened when you try to delete the maneuver [13:52:33] oh interesting [13:52:44] so why would GMT be zero [13:53:00] because it doesn't save one for a landing site vector [13:53:13] it uses the landing site coordinates saved elsewhere [13:53:26] so the landing site "state vector" only consists of an indicator that you are landed [13:54:19] but there should be a check for this condition, it shouldn't fail [13:54:29] there even is a status message for this case [13:54:57] MPT REFLECTS REQUESTED CHANGES - NO VECTOR AVAILABLE FOR LEM TRAJECTORY UPDATE. [13:55:06] that should happen if you delete the maneuver [13:55:53] glad its a simple one then [13:56:19] ok it does write this message [13:56:26] but MPT display doesn't update [13:56:33] so some additional bug [13:58:44] always something [14:00:00] hmm [14:00:05] the maneuver is deleted [14:00:11] scenario looks fine [14:00:26] can you remember, when you deleted the stuff after MPTLEM_BEGIN [14:00:31] was there actually a maneuver there? [14:00:49] something like MAN1_BEGIN [14:00:52] yeah there was [14:01:29] weird [14:01:35] all I got was the display not updating [14:02:20] have to try that again [14:10:11] is there anything different about the SCS lately? I cannot seem to go into min DB hold without it almost constantly firing the roll jets back and forth [14:10:24] light CSM? [14:10:33] have you all roll jets on? [14:10:34] even with a heavy stack, its been my whole 15 mission [14:10:39] hmm [14:10:43] all 16 jets on [14:11:10] Don't think the SCS likes to have all roll jets on [14:11:49] so best to only have them all on during maneuvers [14:12:10] procedure says to have them all on for this hold [14:12:23] which hold? [14:12:29] auto rcs (16) mna/mnb [14:12:32] pre lm jettison [14:15:11] And yeah I had roll jets off for much of my SCS use with the solo CSM (per the procedures) and it helped a lot but with the LM and all roll jets on it just pings off the deadband [14:15:32] I just dont remember that happening on 12 or 14 when I flew through them recently [14:16:55] no changes to the SCS in many months [14:17:36] I have to check, the moment of inertia for roll might have to be mass dependent [14:17:50] probably a bit too small for light CSMs [14:18:51] but I remember it always being like this will all roll jets on and CSM very light [14:18:54] with* [14:18:55] ah ok [14:19:27] our CSM RCS doesn't have the logic for the small impulses like the LM RCS [14:19:31] SM RCS* [14:19:43] so maybe that is a contributing factor, too [14:19:59] falcon is going bye bye [14:20:54] lots more roll firing now lol' [14:22:33] are you in SCS att hold? [14:23:17] yes [14:23:36] att1 rate2 on the bmags, min db and low rate [14:24:04] back to cmc now post sep [14:25:42] where does it say that is the control mode for jettison? flight plan? [14:26:16] yes [14:26:30] "pre jettison checklist" [14:26:38] indy91: Are you familiar with the Windows threading library? I want to do a try lock on a mutex but couldn't really figure out how I'm supposed to on Windows [14:28:59] not really [14:29:22] but seems like that could be the cause of the weird memory randomizations of the AGC, right? [14:33:06] rcflyinghokie, there is one thing, Apollo 15 has a custom set of LM ascent change moments of inertia and CG location [14:33:36] I still need to do the other missions, but right now there is only numbers for Apollo 15 and all the other missions uses a different set of numbers [14:33:44] but it shouldn't be a huge difference really [14:33:58] could play a part [14:36:13] moment of inertia isn't a huge factor [14:36:24] we use 1.62, for a near empty CSM it should be 1.67 [14:36:45] I mean, I can look into the SCS control logic and see if there is an issue [14:37:02] but I think it's just the RCS firing full power for one timestep [14:37:07] and that is already too much [14:38:02] this should be with 60 fps, right? [14:38:30] how do i bring up frames again? [14:38:35] but ideally yes [14:38:55] performance meter [14:39:08] a module you can active [14:39:11] like the scenario editor [14:40:21] oh ok [14:41:42] forgot that was a module, wasn't enabled on the laptop [14:42:39] getting about 20 in the 2d [14:42:52] ouch [14:43:04] that would definitely be bad enough [14:43:08] to cause RCS trouble [14:43:21] that could explain it then haha [14:44:12] I guess its a power saving thing [14:44:26] just plugged it in its up to 35 in cockpit [14:44:40] 60 external [14:44:57] yeah it's the 2D panel being bad [14:45:25] having the VC really destroyed any motivation of fixing 2d panel performance [14:45:39] I would suggest though to use the split main panel [14:45:43] that helps a lot [14:47:45] might not be a bad idea for the laptop [14:47:53] indy91: Yes. My theory is that when very long timesteps happen the AGC is still doing cpu cycles in the other thread while the next timestep already starts and does timesteps without checking the mutex [14:48:05] hoping to have my desktop setup soon again lol...masive tetris game in this small rental right now [14:48:23] To confirm this I want to do a try lock and log a message if it tries to step while the mutex is still locked [14:48:37] I just don't know how WaitForSingleObject is supposed to work with a Mute [14:48:38] x [14:49:04] The documentation says it should work. In reality I get a complaint that I can only use a handle and not a mutex [14:53:46] really no idea how that works [14:55:20] so like 14, I will just have to use the DSKY for the P99 execution in 15? [14:55:58] you mean to start the program? [14:56:16] should work just like 14 I would expect [14:56:42] yeah [14:56:56] I mean I cannot uplink the commands :P [14:57:26] you could if my telemetry client for the LM would support that haha [14:57:30] https://www.ibiblio.org/apollo/Documents/R-567-GSOP-Luminary1E-Section7-ErasableMemoryPrograms.pdf [14:57:36] PDF page 11 [14:57:45] there is the detailed procedures for this EMP [14:58:39] includes the V96 :D [14:59:07] I couldn't reproduce a failure to delete the ascent maneuver [14:59:14] only that it didn't update the display [14:59:25] so if you would save/reload everything was fine in my case [14:59:43] let me see if I can find the scn [15:00:06] so I pushed a fix for the ephemeris generation with just a lunar surface indicator [15:00:10] and the display thing [15:01:43] I can easily disable the fix to test a scenario, if you find one [15:02:00] not if, when :P [15:02:49] https://www.dropbox.com/s/19dod3s4uxe43dw/Apollo%2015%20-%20Lunar%20Liftoff%20Prep.scn?dl=0 [15:03:50] also we need to do something about the sband in the LM and transients on large timesteps causing the cw light to turn on, n7275 can you look into this? seems to lose track easily in the LM when switching vessels or saving and reloading etc [15:05:48] that scenario is still good. So I should try loading, deleting the maneuver? [15:05:55] and then see if it's still there [15:06:07] I just loaded it and tried deleting [15:06:17] still on the MPT [15:06:29] yes [15:07:13] but I guess you haven't updated your NASSP yet with the fix I pushed a few minutes ago [15:07:27] nope [15:07:52] yeah for me it is now gone [15:07:57] ok so it worked [15:08:00] I had disabled the fix for the ephemeris generation [15:08:05] but left the display update in [15:08:22] so I think it was just the MPT display not updating in a case where no ephemeris could be generated [15:11:16] so what do I do next... Apollo 6 flying or some updata link work... [15:11:32] hmmm thats a tough one [15:11:45] I think whichever is more enjoyable right now :) [15:13:52] I also have to make the UDL future proof, it has different functions for the J-type missions [15:14:24] LM UDL? [15:14:45] CSM [15:14:57] I don't think there is much to do in the LM [15:16:01] I guess when I hear updata link I think of the LM haha [15:18:13] actually got the same name in CSM and LM for once [15:18:55] well, the switch at least [15:19:10] the system in the LM isn't called UDL, but DUA, at least for the later LMs [15:21:02] Ah true [16:01:18] rendezvous radar and getting the P20 tracking is hard to explain sometimes [16:49:39] morning! [16:50:55] Morning :) [16:51:11] I have another EMP 99 to try soon [16:55:29] woo! [16:55:40] this time you don't have to type it in manually right? lol [17:02:27] haha no thankfully that one is in the RTCC [17:02:39] But I have to still use the DSKY to command it haha [17:12:41] so the EMP doesn't seem to be working [17:13:34] V33 to command the attitude maneuver and nothing [17:17:34] hmm flipped the main SOVs open again and it worked [17:17:47] very odd they were left open and breakers pulled when I let the LM go [17:18:59] yet they somehow closed [17:22:17] rcflyinghokie, MAINSHUTOFFVALVE_ISOPEN if you want to check in scenarios [17:22:32] thewonderidiot, I see you are in the Luminary reconstruction business again [17:22:43] :D [17:22:56] thanks [17:22:58] we're getting extremely close to having every Luminary ever built [17:23:23] only LUM131 rev 9 and LM131 rev 1 are left, as far as versions that actually got manufactured [17:23:38] and I have more information about those now too [17:23:48] yeah, one flown one still missing [17:23:59] but getting closer indeed [17:31:52] yeah odd I opened them and had gray flags before pulling the cbs but they show as closed in the scn [17:32:41] maybe their default state is grey [17:32:45] if they are unpowered [17:33:18] the TB [17:35:26] yes [17:35:36] the TBs are wired to RCS_B_TEMP_PRESS_DISP_FLAGS_CB [17:35:49] if that CB is pulled the TBs appear grey [17:36:34] indeed it is [17:36:36] like they are grey in the closeout pics [17:36:57] I just explicitly remember opening them before closeout [17:37:04] so I dont know when they closed [17:37:14] but the EMP worked perfectly [17:37:32] maybe you also had the CB pulled that allows opening the valves? [17:38:11] that would be the A and B Main SOV CBs [17:38:33] or report a double valve failure to Grumman :D [17:40:31] hahaha [17:41:15] Very easily could have been a mistake on my end (likely was) [17:42:46] would be a funny bug if Apollo 15 accidentally had a programer [17:43:14] and some channel 10(?) output from the LGC was doing it :D [17:50:04] haha [17:51:41] just look at what it all can do: https://github.com/orbiternassp/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_lm/lm_programer.cpp#L59 [17:51:50] you can blame nearly anything strange happening on it [17:52:14] man Apollo 5 is so cool [17:53:15] I implemented it this way for the LM because there would be programer code all over the place [17:53:25] just for one mission [17:53:42] so instead of closing contacts parallel to the actual switches I let it use the switches themselves [17:53:54] also a fun demonstration during the flight [17:54:00] so that you can see what it does [17:54:36] for Block I I didn't have to care about other missions [17:54:42] so there I implemented it "properly" [17:56:36] yeah that makes a lot of sense [17:56:58] and I agree changing the actual switches is more fun :D [17:57:41] Solarium doesn't directly switch many things [17:57:49] programer is a lot more powerful itself, without the computer [17:59:21] it can really only: arm the SPS gimbals, choose the attitude control mode for the SCS, RCS +X translation, CM/SM separation [17:59:26] 0.05g indication to the SCS [17:59:36] some antenna switching I haven't implemented [17:59:42] that's about it [18:01:44] the SPS gimbal motors aren't all switched on at the same time to avoid a power load spike [18:02:03] in the LM that timing would probably done by Sunburst [18:02:16] but in the Block I CM it's delay timers in the programers [18:02:22] programer* [18:03:09] the SCS was a lot more powerful in general in Block I, right? I had the (maybe incorrect) impression that it was always in control and the AGC was merely giving inputs to it, rather than doing everything directly itself [18:03:43] it works like the AGS or the LVDC [18:03:48] CMC outputs an attitude error [18:04:06] well [18:04:12] it outputs a desired attitude to the CDU [18:04:21] IMU/CDU difference gives the attitude error [18:04:28] and that attitude error is send to the SCS [18:04:40] and works like an SCS internal attitude error from the GDC [18:04:46] interesting [18:05:19] I haven't properly adjusted it. The SCS in Block II is really only used to hold attitude when using the attitude error [18:05:37] so actually doing maneuvering with this gives a bit too high attitude rates [18:05:43] will have been a bit different in Block I [18:06:46] the SCS is about the same in terms of features, even fewer switches in Block I than in Block II [18:07:03] it just takes an additional input from the AGC [18:07:27] or the PGNS I should say, indirectly from the AGC [18:25:44] rcflyinghokie I can look into LM s band tracking [18:27:25] cool [18:27:32] seems to have timestep issues [18:37:50] Thymo, how hard do you think it would be to switch to a post-C++11 way of doing things with std::thread and std::mutex? [18:41:10] indy91, what resources should I be using for this "orbit shaping" burn (prior to the SS launch and TEI) [18:48:48] that document that had all the RLS and N69 stuff [18:48:56] PDF pages 229 and 230 [18:49:44] so probably the general purpose maneuver processor [18:56:50] actual shaping maneuver had no DVY component [18:56:56] that makes things a little bit easier [19:00:05] maybe that most complicated option that worked so "great" on your Apollo 9 mission [19:00:27] Maneuver type: "Apo/Peri Change + Apsides Shift" [19:00:37] haha [19:00:50] maneuver point: "Optimum" [19:01:19] longitude = -48° [19:01:26] that's the desired perilune location [19:01:35] HA = 75, HP = 55 [19:01:58] N = 0 probably [19:02:14] might not work because of your initial orbit, not sure [19:03:16] and time... [19:03:25] Well I had a restart due to time acceleration (probably what Thymo was referring to before as well) so I am trying to verify what broke and clean things up first :P [19:07:28] GDC to IMU alignment saved a lot of time [19:08:52] yeah the procedure that Thymo used on Apollo 8 is quite nice [19:14:04] ok plugging this in [19:14:28] gives me a time much later [19:15:48] I used the flight plan GET on there [19:16:56] https://www.dropbox.com/s/ik3fcie83a7e2si/Screenshot%202021-08-24%20131641.png?dl=0 [19:20:37] might work a bit like a threshold [19:20:41] try an earlier time [19:22:02] nah it doesnt [19:22:15] even if you use much earlier? [19:22:24] yeah I used a few hours [19:22:36] hmm, then you have to do it manually [19:23:08] option: "Apogee and Perigee Change" [19:23:33] maneuver point: Time [19:23:43] and I guess play with the time [19:23:58] goal seems to be that the perigee following the maneuver is 48°W [19:24:03] I can also use longitude [19:24:18] true, but doesn't change much really [19:24:29] also needs trial and error [19:24:45] because that's the maneuver longitude [19:24:51] not the longitude of the perigee following the maneuver [19:25:07] so maybe try the flight plan TIG [19:25:14] and then change it and see what it does [19:25:37] maybe you can get "LONG P" to get close to 48°W [19:26:45] ahh [19:32:28] with your initial orbit being quite circular it should be possible [19:32:37] just not necessarily with a TIG close to the flight plan [19:41:59] oh wow [19:44:03] reading through some things I scanned some more [19:44:04] https://drive.google.com/file/d/1kLptMI85rGYUiqu3nWa3MYagZjt5iA2V/view?usp=sharing [19:44:07] how does the LM antenna even work [19:44:08] this report is very interesting [19:44:52] I forgot to multiply by dt in the control equation, lol [19:45:01] indy91 https://www.dropbox.com/s/t3skdt7nivfsjy4/Screenshot%202021-08-24%20134415.png?dl=0 [19:45:28] flight plan TIG was 221:25:52 [19:45:37] hmm [19:46:31] there could be a solution closer to the planned TIG, but later than it [19:47:00] thewonderidiot, yeah that is good stuff [19:47:19] yeah I am iterating that now [19:47:26] OH SHIT wait [19:47:59] "For the LM, prelaunch activities for us consisted of LGC E-loading during the CDDT and one week later reloading after flight ropes were changed." [19:48:04] I read right past that at first [19:48:08] iiiiiinteresting [19:48:11] when was CDDT? that might be 99R1 [19:48:55] July 2 CCDT(Wet) [19:48:59] hah wow [19:49:01] July 3 CCDT (Dry) [19:49:06] yes that is absolutely 99R1 [19:49:12] a week after that??? that is so late! [19:49:27] one week before launch [19:49:42] well [19:49:50] one week later was the E-load update [19:50:07] true [19:50:11] but it definitely happened after the CDDT [19:50:27] so sometime between July 3 and 10 [19:50:31] that week [19:50:34] that's nuts [19:51:06] fixing the bug that has the potential of making the 1202 alarms much worse [19:51:17] now that's a story [19:51:31] I seriously cannot believe that it's a completely untold story [19:51:51] that is insane [19:52:57] looks like TIG forward is further haha [19:53:04] and Mike that is crazy [19:53:17] would changing the rope destroy the erasable and that's why they have to reload it? [19:53:35] Might just be procedure. The bug fix didn't need a different padload or so [19:53:40] no, changing out the rope would have no impact at all [19:54:07] it may have been that they were doing basic tests with the new rope and had e-load changes they wanted to make anyways? [19:54:35] depending on the test they could have overwritten the padload [19:54:44] very true [19:55:03] George Silver wrote in his notebook what test he wanted to run after the change [19:55:56] "If they are installed after system power down does MIT require IMU performance test -- I said no -- just operational test." [19:57:25] there is also numbers set to 0 in the padload [19:57:35] those could have overlays as well [19:57:47] from a system test [19:57:50] yeah [19:58:58] I'm sure they had some reason and it's not that the padload was different with the fixed rope [19:59:14] yeah definitely [20:01:34] as we wondered before, the question is what kind of documentation exists about the rope change [20:01:39] KSC? MIT? Grumman? [20:02:00] We've probably exhausted most MIT documentation now [20:03:28] yeah [20:03:41] even the FSRR probably is too early, I think [20:04:55] but we have it pretty close bracketed now :D [20:11:36] yes, which makes searching easier :D [20:15:25] FSRRs were July 1/2 [20:18:23] only 157 records at UHCL in that date range [20:19:18] LM ( LUNAR MODULE ) MONTHLY MASS PROPERTIES STATUS REPORT PERIOD COVERING JULY THROUGH DECEMBER 1969  from July 1 [20:19:44] that could possibly be interesting, MIT included weird things like serial numbers and whatnot in their mass properties reports [20:20:19] WEEKLY ACTIVITY REPORT from July 2 [20:20:32] I might start requesting some of these now that we have it narrowed down enough [20:21:14] yeah I was also searching a bit there [20:21:19] I found [20:21:20] 02/07/1969 AS-506 ( APOLLO SATURN 506 ) / LM-5 ( LUNAR MODULE 5 ) CHANGES REQUIRED BY MAP 6/31 APOLLO 071-11 [20:21:26] but I don't know what MAP means [20:21:33] hahaha I was about to ask [20:29:37] oh [20:30:09] I think you were not using American date order (month/day/year) there [20:30:18] 02/07/1969 would be from February [20:30:28] ... [20:30:29] n7275: Shouldn't be too hard I think. It looks like it's just a simple mutex guarding the AGC thread so we can totally swap that [20:30:35] that doesn't make searching there easier [20:30:42] Probably better even. I'm all for cross platform implementations [20:31:15] 06/30/1969 APOLLO 11 LM-5 ( LUNAR MODULE 5 ) DCR ( DESIGN CERTIFICATION REVIEW ) [20:31:16] here's what you do: "APOLLO" in field Program, specify 07/01/1969 to 07/10/1969 in the date range, and then order results First by: Date (ascending) [20:32:00] oh we know what that is now, fun :D [20:32:35] I haven't read the LM-3 DCR yet but I'm excited to. it looks super interesting [20:34:24] Thymo, yeah that's what I was thinking too. the less windows specific stuff, the better, if Orboter goes cross-platform down the road. [20:41:43] Taking a look now [20:51:19] *Orbiter, haha [21:01:47] night! [21:09:12] Doesn't look like cpp threads have a 1 to 1 equivalent of a windows event object. Condition variable should work in its place though [21:35:44] n7275: Do you know if I can mix a guard_lock and shared_lock? [21:35:49] On the same mutex [23:23:35] .tell indy91, not sure if its an RTCC bug or user error, but throwing my orbit shaping burn on the MPT is yielding a nan for dv remaining [01:47:00] .indy91 also so I don't forget, I just did the shaping burn and now targeting TEI, but I am not getting the same splash coordinates nor am I getting any dvy which 15 had a very large component of...thoughts? [01:47:15] .tell indy91 also so I don't forget, I just did the shaping burn and now targeting TEI, but I am not getting the same splash coordinates nor am I getting any dvy which 15 had a very large component of...thoughts? [03:07:11] Thymo, I do not know [12:38:40] hey [12:39:25] Hey. I opened a PR for that long ongoing AGC bug. [12:39:48] looking at it right now [12:40:05] any potential downside to using C++14? [12:41:06] any potential downside to using C++14? [12:41:35] Not that I could tell. If there was an issue it wouldn't have built. [12:41:58] I mean more like, compatibility etc. [12:42:21] I don't know of any backward compatibility issues either [12:42:28] right [12:42:50] It is explicitly set now. It used to be determined by Visual Studio [12:43:30] So if we let it unset and upgrade it will change it by itself. Cpp14 was the lowest option available anyway, but I also need it for the lock_guard [12:43:47] I guess the crucial change is in the else clause when multi threading is off in 1.0x time acceleration [12:44:01] doing "std::lock_guard guard(agcCycleMutex);" [12:44:57] Yes. In certain cases the thread was still running the AGC when the main thread also does it. [12:45:26] good find. Looking forward to doing 90% less scenario editing of poor people who suffered from this bug :D [12:46:05] Yeah, once it happened the results were undefined. So full state refresh to recover. [12:46:29] the code looks good to me. Would it be useful if I do a bit of testing on it or do you think you already got that covered, CMC and LGC, time acceleration or not, multi threading disabled etc [12:46:29] Don't merge it back yet. I want both mine and Matthews in the same build and a forum post [12:46:35] ok [12:47:12] I'll do that when I get back from the office if you approve them. [12:47:17] how do you even get it into the same build haha. In the past when I have merged two PRs within seconds it still gave two new builds, I think [12:47:42] Guess I'll open two windows lol [12:48:26] I wanna overhaul the build pipeline soon. I'd like to have a stable supported version, a beta, and a nightly snapshot for each commit. [12:48:51] that sounds useful. Don't have to have 10 builds in a single day, just because it was an active day [12:49:02] Because technically NASSP 7 is THE supported version but it's so different I don't even recognize it anymore [12:49:17] so have you done a bunch of testing on it in CMC and LGC? Or could it use some more [12:49:31] just from looking at the code I would approve it [12:50:49] hey guys [12:51:07] hey [12:51:15] I'm positive the bug is fixed. Don't know what more I can test, it's quite a rudimentary locking issue really. They are just hard to find if you don't know you have one. [12:51:40] yeah [12:52:58] oh and I did the quick project of working on the UDL yesterday [12:53:12] two things are probably interesting for you, Thymo [12:53:23] 5 relays are exempt from being reset by the astronauts [12:53:42] among them Abort Light A and the Crew Alert [12:53:51] not Abort Light B for some reason haha [12:53:58] Oh. Good to know. Nice find [12:54:13] Any alternate way to turn it off? [12:54:35] hmm good question, have to look for that [12:54:48] and the other thing, some of the uplinks actually consist of two commands [12:54:58] and what I have noticed is that there can be a systems timestep between them [12:55:12] one of the things I implemented is the S-band power amplifier switching [13:48:22] Good morning [13:48:49] hey Ryan [13:49:02] hey [13:50:04] NaN for DV remaining might be because there is more SPS propellant than CSM total mass. The propellant masses in the RTCC are only properly maintained when you use the MPT the whole time and don't delete maneuvers, so that easily happens [13:50:22] probably should be displayed differently though [13:50:43] maybe set to 99999 of DV remaining for the display or something [13:51:41] ahh that makes sense [13:51:56] for your TEI, is the maximum inclination set to 40°? [13:52:02] on the RTE constraints page [13:52:08] it should be 40° still for Apollo 15 [13:52:14] let me check [13:52:40] RTCC config file has no entry for it, so it should default to 40 [13:52:51] yes [13:53:21] weird [13:53:28] it should run into that constraint [13:53:35] which makes DVY larger [13:53:36] let me make sure I am using the correct number though [13:53:45] which one on the table should be 40 [13:53:51] IRMAX or so [13:53:52] IRMAX [13:53:54] ok [13:54:02] and that would then also appear in the AST [13:54:13] if it runs into the constraint [13:54:22] otherwise a smaller number [13:54:27] if it's a larger number there is a bug [13:55:13] hmm wont calculate now after loading [13:55:41] is MPT active? any maneuvers on it? [13:55:45] inactive [13:55:52] no maneuvers [13:56:12] what kind of inputs are you using? [13:56:28] saved this scn last night after computing it, loaded this morning everything in RTE is default [13:56:34] worked fine yesterday [13:57:17] oh wow [13:57:51] I typed 223:46:26 instead of 223:46:06 in the tig [13:58:01] that 20 seconds allowed it to calculate [13:58:31] apparently it didnt like 223:46:26 [13:58:33] and actual TIG did it result in? [13:58:39] maybe it was far off? [13:58:47] 20 seconds [13:59:08] 223:46:26 didnt work, but 223:46:06 (FP TIG) worked [13:59:32] no I mean, what is the actual TIG from this. Your input is an initial guess [13:59:42] at least if you are using the lunar search option [13:59:47] 223:45:51 [14:00:13] interesting. I think I want your scenario, the lunar RTE has been very reliable so far [14:00:31] sure [14:01:01] also one thing I just noticed. Even if MPT mode is inactive it generates an ephemeris if there is an anchor vector saved in the scenario [14:01:06] https://www.dropbox.com/s/1ou98qll660dh74/Apollo%2015%20-%20TEI%200001.scn?dl=0 [14:01:17] yeah I saw that on the online monitor [14:01:38] the "MPT mode active" flag is in the MFD only code [14:01:47] I probably need to move that to the RTCC class [14:01:58] and then it can check if that is active or not [14:03:07] just reloaded to check, it wont compute with the 223:46:26 [14:03:20] and I used 295 [14:03:26] 295:00:00 for landing time [14:03:33] EOM target? [14:03:37] MPL [14:03:40] ok [14:04:48] also this is after my "shaping orbit" burn [14:05:21] I think 15 had 151.2 for inclination where I have 151.09 on PAMFD after it [14:05:42] but the Ha and Hp are good [14:06:04] great, I can't input a inclination on the AST page... [14:06:42] ah [14:06:47] just was using the wrong option [14:07:24] but there was still a little bug with that [14:09:40] what was it [14:10:06] and could you duplicate the lack of computation with 223:46:26 as the TIM? [14:10:39] just a wrong check which MED is currently being used [14:10:55] no I couldn't. Let me check if I have the exact same inputs [14:12:34] now I could replicate it [14:13:30] I am surprised that the 20 seconds makes a difference [14:13:45] I'm also getting rid of the inputs for each MED [14:13:53] there really is no good thing about that [14:14:08] like, there is a separate variable for TIG for each of the three MEDs [14:14:18] and when you accidentally use the wrong MED [14:14:24] you have to input everything again [14:14:38] the wrong calculation type I mean [14:15:53] Ah yeah [14:16:12] Theres no need to store all of them [14:19:43] and I do get a result easily within the inclination constraint [14:19:46] that is quite weird [14:20:00] have to check if this TEI, when it comes up with one, is actually good [14:20:23] TEI seems to happen near apolune [14:20:32] wonder if that plays any role [14:22:26] also I am not sure how well my shaping burn played out either [14:22:44] I mean, it didn't change the orbital plane [14:22:52] so it shouldn't really change much for TEI [14:22:53] right [14:23:15] And my inclination is only a little different than actual after the shaping burn [14:23:36] one thing that could be possible is that they didn't use the optimum DV solution for TEI [14:24:29] because it's an undesirable EOM target [14:25:06] SCOT has it as a 40° ascending return [14:25:21] maybe the trick is using that [14:27:11] ok, let me try it in debugging mode [14:27:20] haha ok [14:29:07] hmm, when I calculate it the first time it usually works [14:29:15] then I tried some 40° inclinations [14:29:30] and then when I said I was checking for the exact same inputs it didn't work again [14:29:39] have to try that again, maybe it stops working again [14:35:24] ok, can replicate it [14:35:28] deep debugging now haha [14:36:15] good luck! [14:39:10] found it I think [14:39:15] stuck in a while loop [14:39:24] where it tries to converge something to 0.1 seconds [14:39:33] but it jumps back and forth between -0.12 and 0.12 [14:39:36] so never gets there [14:40:18] maybe some tolerance is too large inside the while loop [14:40:23] so that it can't converge that far [14:40:37] to the RTCC Requirements document I go... [14:40:43] huh interesting [14:41:05] it tries to converge on the landing site with a given return inclination [15:09:45] any luck? [15:14:47] yeah, I'm using code there that is a bit different from the RTCC Requirements [15:14:54] trying to find out why [15:15:05] my instinct is to just make the tolerance larger [15:15:16] 0.1 seconds is very small [15:17:43] what would be a reasonable increase [15:22:12] well it's stuck at 0.12 seconds [15:22:18] I think 1.0 would be ok, too [15:26:50] maybe that whole iteration is unnecessary [15:29:03] Home sweet home [15:31:11] Now I have 3 merge buttons to press. Let's see if it goes in the same built [15:31:45] Thymo, if you have a minute, would you mind testing my radiator update branch? [15:32:38] Yeah nah, I merged too quickly and it gave an error. Probably gonna be 3 builds. Oh well [15:32:42] n7275: Sure! [15:32:48] I don't mind [15:34:08] awesome, thanks. [15:44:37] morning! [15:45:14] hey Mike! [15:45:41] Hey Mike [15:46:00] TIL that the telemetry client doesn't work if the computer breakers aren't in [15:46:03] I found another really fascinating memo that I scanned without reading last night [15:46:52] PCM timestep is done in the AGC timestep. So the sockets aren't even handled... [15:47:01] https://drive.google.com/file/d/1qdqsgKbdKG4Y0In4t-WTactRhXtO4SGX/view?usp=sharing [15:48:42] Thymo, it would be nice if it just sent zeros, or random noise. [15:49:05] While at the very least connecting, yes. [15:49:37] I guess I finally found a way to turn the PCM off then. Since the PCM is not actually hooked to its own breaker [15:50:17] oof [15:50:40] Yeah, sometimes the CSM is very messy in that aspect. [15:51:11] it has a lot of cleanup necessary, and I can say the ECS needs it as well I just am almost afraid to go poking through yet [15:51:35] I should check if GaugePower still exist. That used to be an infinite source of power for the instruments, so you had perfect readings if you shut down the fuelcells, disconnected the breakers and pulled every single breaker. [15:52:11] Anyway, I pretty much shut down all fuel cells except closing the reactant valves and while the cells are cooling the FC RADS are staying at 51°F. That's what you intended right n7275? [15:52:21] The air keeps them warm? [15:53:38] yes [15:54:44] Even though I'm completely unqualified to check the math it looks good to me otherwise [15:55:14] also, the fuel cell project was a tangent I went on after finding GaugePower hooked to the HGA signal strength gauge, lol [15:56:15] If you find an instrument connected to something it shouldn't be you have a 90% chance it should go to FakeInstrumentBus [15:56:47] Thing about fixing all that is that you need to trace a shit ton of breakers on the diagrams [15:57:20] I have my UDL update still to push, had to connect that breaker to flight bus [15:57:56] And we have multiple releases... Buildbot is bothering me [15:58:14] yeah we should switch to nightly builds, if there was any update on that day [15:58:24] I agree [15:58:33] Nightly builds probably shouldn't even go to github [15:58:57] I don't want people complaining the second a broken PR is merged lol. [15:59:19] who would ever merge a broken PR :D [15:59:21] I'll look for suitable replacements [16:00:23] We only merge /special/ PRs. Nobody is broken or defective, just special in their own way. [16:00:39] bugs have feelings [16:00:44] devs don't [16:00:53] Feelings will be punished by death [16:01:17] I just don't create PRs but push directly. Best method to prevent broken PRs [16:02:04] https://i.kym-cdn.com/entries/icons/original/000/028/207/Screen_Shot_2019-01-17_at_4.22.43_PM.jpg [16:02:13] speaking of pushing directly, did anything help fix my TEI computations? [16:03:08] yeah I made the tolerances slightly larger [16:03:31] what about the inclination change [16:03:33] in the RTCC Requirements that works a bit differently, have to revisit that some time [16:03:48] I can only imagine that they did a suboptimal TEI for better splashdown coordinates [16:04:11] so you have to input an inclination [16:04:16] -40°, or 40A [16:04:19] yeah the pad had Expected splashdown point (Noun 61): 26.11° North, 157.97° West. [16:04:20] for ascending [16:04:34] actual tei pad [16:04:37] that's also not even on the MPL [16:04:42] so maybe use the EOM target [16:04:50] with the inclination constraint [16:04:55] like I did with 14 [16:05:34] I don't even remember that [16:05:41] was that because of a calculation issue? [16:05:47] oh [16:05:51] you mean the EOM target [16:05:55] not the inclination constraint [16:06:02] or did you have to do both there, too [16:07:35] UDL update and RTE fixes pushed [16:09:31] n7275, "Q3 = (float) (q * pow(runner->Temp - 2.7, 4));" what is the change from 3.0 to 2.7 based on? [16:19:33] I only had to do the target [16:19:47] I think i left the inclination alone at 40A for 14 [16:27:19] more accurate background radiation temperature [16:27:43] more precise, I should say. [16:29:57] will result in ~0.4% more radiative heat at 300K [16:37:24] ah ok [16:40:16] Is your PR good to go then? It's still marked as draft. [16:49:13] it worked for me. I just wanted someone else to run through prelaunch day/night with time compression, on a different computer than mine and confirm no issues. [17:18:05] question of the day for me: how much can I trust the systems handbook, and is there any chance that the excitation signals for the 1x and 16x resolvers were different, and only 1x gets the voltage/phase shift in AUTO TRACK/SLEW [17:24:30] I mean they are bound to have errors I am sure, I would err on the side that they are correct but seek a second opinion or source to confirm lol [17:30:47] indy91 so I just use EOM instead of MPL in lunar search? [17:33:30] https://www.dropbox.com/s/8svs5mb7g3g8oax/Screenshot%202021-08-25%20113252.png?dl=0 [17:35:08] https://www.dropbox.com/s/9tfvtqqyua9ybkf/Screenshot%202021-08-25%20113457.png?dl=0 [17:35:15] that looks a lot better [17:41:35] yeah I think using the EOM instead of MPL with 40° ascending for inclination is the way to go [17:45:48] thewonderidiot: I don't know how much you can trust it. They tried to keep them up to date but since it's such a large aggregate it's likely some things got changed after it was created. NASSP is based mostly of the AOH and systems handbook because it is a very complete resource. For anything more authorative I'd go to the ICDs but even those have been proven to not always be 100% accurate. [17:45:59] Take the Apollo 11 throttle lag constants for example. [17:46:17] yeah [17:46:28] I thiiiiiiink I have all of the ICDs and level 3 drawings that are relevant [17:46:29] One number was supplied in the ICD but in the mean time they improved the response time and it was lower than in the ICD. [17:47:26] If the LGC had used the number supplied by the ICD, Apollo 11 would have aborted due to an unstable throttle. [17:47:59] Luckily Don made it lower (by accident) and the throttle was less unstable. [17:49:21] yup [17:49:30] I scanned a whole folder of memos about that last week :) [17:54:38] thewonderidiot, if I have the surface flag set via V44, will a V66 reset it? [17:54:59] luminary 210? [17:55:09] CMC [17:55:50] any of them, but in this case Artemis [17:56:18] 44 is set. 45 is reset [17:56:22] yes [17:56:28] but I am asking if V66 also resets it [17:56:35] 66 is transfer state vector to other slot [17:56:42] I know :P [17:56:52] It shouldn't touch that flag AFAIK [17:57:55] I am asking because I have a V44 in the flight plan shortly after LM jettison [17:58:01] yet no V45 [17:58:31] I'm not immediately seeing anything in the V66 code that would reset the flag [17:59:08] so without one, would my V66 just transfer and not integrate? [17:59:13] *without a V45 [17:59:14] Yes [17:59:16] we can check after you do it [18:01:08] I have already [18:01:24] not checked though [18:03:22] how do I check [18:04:05] V01N01E 104E [18:04:31] I think if you have the surface flag set then the LM state vector is just sitting there idle [18:04:35] what does that give you? [18:04:59] 56200 [18:05:22] SURFFLAG is bit 8 there, so it is set (it's the 2 in the middle) [18:05:24] so I suppose a V45 is missing from the flight plan [18:05:42] so that means the CM SV I just transferred to the LM slot isnt integrating [18:06:37] yeah [18:07:05] I wonder if there is even any downside to that [18:07:25] hmm, your backup state vector isn't being integrated then I guess [18:07:36] its there and V66 updates it [18:11:08] ah found the V45 [18:11:16] right before the shape burn [18:11:39] ah [18:11:41] nicely hidden [18:12:55] the V44 stands out as its by itself [18:13:04] the V45 is in a busy phase [18:13:18] so disregard :P [19:00:46] lets see how this TEI ends up [19:09:20] or where, rather :) [19:10:38] let's hope E stands for Earth [19:11:03] Trans Enceladus Injection sounds also good though [19:16:08] Haha [19:18:36] hmm this is odd [19:18:46] not only did my SPS not keep me on course [19:19:02] but reloading my save at t-1m is CTD [19:20:25] any idea what causes it? [19:20:30] Exception thrown at 0x740DB1B2 (msvcp140.dll) in orbiter.exe: 0xC0000005: Access violation reading location 0xA5002A04. [19:21:47] I can check the scenario for RTCC issues [19:21:58] I also can't say I properly tested UDL saving/loading [19:22:05] I hope it's not that [19:22:30] https://www.dropbox.com/s/fnicm8htgejh1om/Apollo%2015%20-%20TEI%200001%200003.scn?dl=0 [19:23:27] your descent stage is in a bit of a crazy orbit [19:23:38] maybe it doesn't like loading that, have to try [19:23:43] uhh really? [19:24:58] RPOS -19194612221429995122203180685852672.000 -464552849011626599078663853403275264.000 -788793183586877200845264840745287680.000 [19:24:59] RVEL -111782580373767652245076180992.0000 -2705390220101887595609057132544.0000 -4593650365290434928612397285376.0000 [19:26:13] still can't load it when I delete that [19:27:02] so every save I have after I merged the new updates won't load [19:27:17] hmm [19:27:56] uh oh [19:28:01] I think it's UDL loading [19:28:07] the file I sent you earlier loads [19:28:11] ahh [19:30:16] fix pushed [19:30:23] that simple? [19:30:39] void UDL::LoadState(FILEHANDLE scn) [19:30:59] I didn't supply the scenario FILEHANDLE to it but the current line from the scenario instead [19:31:04] which is a character array [19:31:09] ahhh [19:31:14] how that doesn't give a build error or at least warning... [19:31:34] rebuilding now, do those scn files need edits to load or should it be ok? [19:31:36] sorry, at least it was simple :D [19:31:42] nope, saving was ok [19:31:46] so should be good [19:31:54] great [19:32:04] https://github.com/orbiternassp/NASSP/commit/f04846a4f26e746caad85e14fba59caeaf3b51d9 [19:33:37] but that shouldn't be the cause of the SPS issue [19:33:48] hmm [19:34:01] unless you "successfully" loaded a scenario [19:34:06] so I am going to double check my configuration, but I did have a computer restart [19:34:33] the thing that Thymo pushed a fix for, but I know when I ran a V48 after that my SPS angles were all sorts of weird numbers [19:34:51] I of course zeroed them but I dont know if I have any messed up memory locations [19:34:54] ah you could load an earlier scenario because it had no UDL section [19:39:13] oh [19:39:31] looking in your scenario I noticed a padload mistake [19:39:57] ah no [19:40:06] seems like it's only a padload worksheet problem :D [19:42:52] rcflyinghokie, uh oh [19:43:01] I see some randomly moved erasables [19:43:13] already in your earlier TEI scenario [19:43:26] but not yet in the Lunar Liftoff Prep scenario you gave me [19:43:48] before: [19:43:49] EMEM3014 123 [19:43:50] EMEM3015 175 [19:43:51] EMEM3016 17433 [19:44:00] after: [19:44:02] EMEM3016 123 [19:44:02] EMEM3017 175 [19:44:03] EMEM3020 17433 [19:45:03] starting with EMEM3032 it's good again [19:45:36] up to EMEM3013 it's also good [19:45:44] so 3014 to 3031 are bad [19:46:01] the same section that always had this problem [19:46:08] sometimes it's more, sometimes less [19:46:50] and that is TVC stuff [19:46:54] so burns can't be good with that [19:50:07] "I didn't supply the scenario FILEHANDLE to it but the current line from the scenario instead" -- And that is why we make Pull Requests to be reviewed by people [19:51:18] indy91 yeah the restart happened between those two, the coming out of time acceleration [19:51:25] well if I am testing some code from other people I probably wouldn't even think about saving and loading again for testing [19:51:36] I guess my shaping burn was short enough I didnt see any issues [19:51:44] but I've done saving/loading errors in the past, really dumb mistake [19:51:58] Hence code reviews were invented [19:52:12] did the restart happen before you updated to Thymo's fix? [19:52:17] But yeah I thought those would be an issue especially when I saw the really random numbers in my V48 [19:52:20] yes it did [19:52:33] then hopefully you are the last ever person to suffer from this issue :D [19:52:50] its funny its the first time its ever happened [19:52:52] to me [19:52:58] right before it gets fixed :P [19:53:25] Open the time acceleration windows and click the 1x and 100x button rapidly. You'll get it after a couple of tries. [19:53:40] Before the fix that is [19:54:06] mine was just going from 30 to 1, but I am on my laptop normally I am on a much beefier computer [19:54:24] right [19:54:31] I think that's why I could never reproduce it [19:54:35] As long as it's rapidly switching out of acceleration with a decent timestep length it has a pretty high chance of triggering [19:54:52] The more CPU load the likelier [19:55:07] I hate low frame rate, so I'd rather use e.g. split main panels or spend all my time in the LEB, if I really have to [19:55:22] never using time acceleration on the main panel [19:55:50] If I want to warp for an extended time I put my computer to standby [19:56:06] so what you do to fix this is replace EMEM 3014 to 3031 with the padload, CMPAD [19:56:22] and hope no other section is broken haha [19:56:33] that will fix the TVC at least [19:56:51] Build question. Can I make a distributable build of NASSP locally the way they are put on github? [19:57:15] so theoretically if this would have happened during a mission, I assume they would do a V74 and have the EMEMS checked? [19:57:27] Yes [19:57:50] They would restore it from the emergency erasable update document [19:57:57] and then to fix them? would that be an uplink [19:58:02] yeah, it's in the G&C Checklist [19:58:05] or manual entry [19:58:08] could be manually [19:58:17] they might have it ready for uplink though, too [19:58:23] or create an uplink [19:58:51] https://drive.google.com/drive/u/0/folders/1iomkMAk2XU7Y_Xgmdtkud4Hfi-XMTwHx [19:59:03] well since this last save is t-1m from TEI I am going to edit the scn :P [20:00:10] General procedure is : uplink, statevector, P52 [20:00:30] yeah that document even lists the things you have to fix [20:00:42] in the checklist it would be columns K and L [20:00:55] yep did the uplink SV and P52 [20:03:20] do the CMPAD correspond with the EMEM numbers? [20:05:10] yes [20:05:22] so just copy them over and replace CMPAD with EMEM for each [20:05:38] overwriting the old values [20:06:00] what about ones in between [20:06:10] like 3015 [20:06:19] it is a CMPAD but no EMEM [20:06:59] ah, then EMEM3015 was 0 [20:07:08] so save on scenario lines it doesn't it save it then [20:07:17] to* [20:07:29] but you want all the CMPADs [20:07:30] ok [20:08:33] my EMEM editing technique is. Make an empty line above and below the section I want to replace. Copy and paste over the block from the launch scenario. Copy and replace CMPAD with EMEM. Remove the two empty lines. [20:09:27] I just copied them over and use "find and replace" CMPAD with EMEM [20:09:47] yeah [20:18:14] n7275: The patch you submitted for the LM S-Band antenna today, you think something similar will work for the hi gain in the CSM? [20:19:43] absolutely. was planning on doing that next [20:22:03] Sweet. I notice it losing lock at 60x [20:22:24] What checklist has that chart you use to determine SPS vs RCS burn? [20:24:03] Found it in the A15 G&C one [20:27:17] the guideline is 0.5 seconds of SPS burn, not including ullage [20:27:42] but that is not always so easy to determine [20:31:11] is that for Apollo 8? [20:31:16] MCC-1 or so? [20:31:26] MCC3 [20:31:41] DVT 8.3 0:01BT [20:32:27] how did the mission so far go? [20:33:00] I've made endless fixes to the LVDC TLI cutoff logic, so I'm always afraid something is still off with that... [20:34:05] with such a large MCC-3, did you even have MCC-1 or 2 at all? [20:34:21] Yes [20:34:31] I just want to be sure. MCC3 lists HP as -88.5. Is that right? [20:34:38] I would smash into the moon [20:34:39] Earth referenced [20:34:53] MCC-3 is still outside the lunar sphere of influence [20:35:33] Gotcha [20:35:55] hmm, that doesn't really sound normal. If you did MCC-1 or 2 then you should not get any MCC-3 [20:35:58] and a small MCC-4 [20:36:08] and only a* [20:36:19] I messed up my MCC1 because I had SC CONT set to SCS so the computer couldn't start the burn. Ryan helped me recalculate it and then MCC2 was pretty small [20:37:08] are you flying with or without the MCC? [20:39:02] With MCC [20:39:08] hmm [20:39:37] so you did MCC-1, MCC-2 was scrubbed or not? How large were the burns? [20:41:14] MCC1 was 36.4 because I cocked up the evasive maneuver. Corrective MCC1 I calculated was 9 feet in the other direction because I overburned MCC1 on SCS. MCC2 was no more than 10ft/s I think, didn't write it down. MCC3 is what it is now [20:42:17] I don't like it haha [20:42:24] http://vanbeersweb.nl/share/Apollo%208%20MCC3.scn [20:42:26] Have at it [20:43:26] little more residuals than I would have liked [20:43:34] 1.4 .3 .2 [20:43:47] TEI? [20:43:53] yes [20:44:16] with a 13 sec 4 jet ullage [20:44:26] you didn't touch EMEM3013, right? [20:44:32] only 3014 and so on [20:44:46] well, you wouldn't have used the G&N Checklist value anyway... [20:44:49] G&C* [20:45:04] EMEM3013 is the tailoff time bias [20:45:07] 3014 through 3031 [20:45:23] dual banks? [20:45:55] yes [20:46:03] EMEM3013 74 [20:46:06] yeah [20:46:14] I'm pretty sure I am accounting for the right amount of tailoff thrust [20:46:31] I did leave those zero ones in there should I have removed? [20:46:42] nah, EMEM loaded as 0 is ok [20:47:00] if there is any time delay in the CMC or so then we would have seen it before, with tailoff and its padload equivalent being zero [20:47:34] it could be a suboptimal frame rate [20:47:53] Could be, I am going to burn it again watching the performance [20:47:58] slightly delaying the cutoff more than before [20:48:12] maybe use 0.1x time acceleration for cutoff as a test [20:48:15] So am I good on this MCC3 or is something broken [20:48:21] should be ok [20:48:24] k [20:48:35] but it's still too large, something isn't quite right. Not sure if it's targeting or what [20:48:50] you aren't trimming the EMS to 0 are you? [20:49:25] oh and the Maneuver PAD actually tells you what to use [20:49:27] at the top [20:49:30] it says SPS/G&N [20:49:40] it checks on the 0.5 seconds burntime [20:49:45] otherwise it would be RCS [20:50:09] and because we now simulate tailoff thrust you always have to use DVC for the EMS [20:50:12] not DVT [20:50:22] but you are probably doing that already [20:50:28] 35fps in cockpit [20:50:35] I am going to use external for the burn [20:50:49] trim is on the DSKY not EMS [20:50:52] it's really only the cutoff that might be affected [20:50:55] I meant Thymo [20:50:57] sorry [20:51:45] Yeah I'm doing all that already [20:52:14] rcflyinghokie, if you want to see if the tailoff thrust is affected by frame rate try 0.1x time acceleration for the cutoff. Rest of the burn doesn't matter. If that still gives 1.4 ft/s residuals then it was something else. [20:52:40] So I just tested in external view, solid 60fps [20:52:50] residuals -2.0 -.3 0 [20:53:07] I'll try the 0.1 this time [20:53:10] minus now, huh [20:53:15] seems a bit random [20:53:21] it was -1.4 before [20:53:23] oh [20:53:52] pretty sure [20:54:00] let me try your test [20:54:29] that test is basically just to simulate 10x the frame rate [20:57:18] Thymo, can't tell too much from your scenario, but if I let it reoptimize the mission (TLMCC option 3) then it still gives a 7.8 ft/s burn at the MCC-3 time. So it definitely needs this DV. [20:58:06] it could have been that your current trajectory was already good and MCC-3 just wants to move it a bit where it still is good. That wouldn't have been right of course. [20:59:26] +1.8 [20:59:37] so the first one I think was plus afterall upon checking that save [21:00:06] that +1.8 0 +0.1 was with 0.1 acceleration for the last 150fps [21:00:08] we invented a random number generator between -2 and +2 [21:00:25] I'll try to make it. I'm trying to teach DDsang the concept of GDC alignment at the same time. haha [21:00:27] going to do one more in cockpit [21:00:52] you are welcome to the scn if you wish to see anything deeper [21:01:19] nah, I don't think it's anything in the scenario [21:01:46] CSM is very light [21:01:55] any small difference makes a large DV [21:02:09] one thing to keep in mind though, the residuals numbers in the transcript seem to be after trimming [21:02:22] "No trim" [21:02:23] or not :D [21:05:09] a positive number in X means underburn [21:05:53] I might do a few TEIs to see if I notice anything [21:06:53] -1.6 [21:07:05] maybe I have to do it like the LM RCS, calculating the total impulse required over a span of time [21:07:14] instead of a thrust value for the next timestep [21:07:45] if that is the issue then it would be as random as you are experiencing [21:07:55] ah ok [21:07:57] https://www.dropbox.com/s/podjrgpbcgpwi2c/Apollo%2015%20-%20TEI%200001%200003%200001.scn?dl=0 [21:08:04] if you want one ready to go [21:08:09] right before avg g [21:08:21] thanks! [21:08:47] I probably have to make a MATLAB script like for the LM RCS [21:08:55] and then simulate different frame rates [21:09:24] it definitely should be better with a higher frame rate though [21:09:53] so if anything I trust the +1.8 the most [21:18:33] -1.6 that time [21:18:47] so both in cockpit gave -1.6 haha [21:19:04] yeah that's a slight overburn [21:19:07] yep [21:19:10] I would expect that with worse framerate [21:19:20] yeah the in cockpit [21:19:34] or in 2d panel rather [21:21:48] let me do one with 0.1x [21:24:43] I'm more confused about the +1.8 with good frame rate than the -1.6 with bad one haha [21:26:58] I got +1.4 [21:27:21] another underburn [21:30:18] ah [21:30:27] but I forgot to enable the second bank [21:30:48] I'll do another one [21:30:54] might get it up to 1.8 [21:36:11] well, it couldn't do that haha [21:36:18] 1.8 would be more of an underburn [21:36:32] but dual banks has more tailoff thrust [21:36:36] I got +0.3 [21:36:55] which would be acceptable [21:36:58] I used 0.1x [21:37:07] at 60 fps [21:38:20] How accurately will the MCC give me burn angles? It's 4 degrees off from the CMC [21:39:02] in something other than roll? [21:39:27] hmm [21:39:59] I think this could be a REFSMMAT issue [21:40:08] pitch [21:41:05] so the MCC used to downlink the REFSMMAT from the CMC for every calculation [21:41:14] I'm still on the launch refsmmat. I uplinked it once using the RTCC [21:42:25] hmm [21:43:04] I did a P52 just before my P30 and it was all balls [21:43:08] well I'm probably going to change that back, but because there is no expected REFSMMAT change until before LOI the MCC doesn't sync with the REFSMMAT in the CMC for a long time [21:43:32] I can probably figure out if that is the issue with your MCC3 scenario [21:44:09] it is not [21:44:15] MCC knows exactly your REFSMMAT [21:45:01] in your scenario, had you already done the MCC-3 uplink? [21:45:09] Yes [21:45:32] At least I have now. Not sure if it's in the one I sent you [21:46:46] I love the vector compare display :D [21:46:56] I can see that the LM slot has a perfect state vector [21:46:59] CSM doesn't yet [21:47:10] Apollo 8 is weird [21:47:21] Jim Lovell wanted to have the LM slot for uplinks [21:47:22] Oh did I not V47 yet [21:47:31] that could be it, yeah [21:48:47] https://i.imgur.com/LMxbvlL.png [21:48:59] left column is orbital parameters of a "ground tracking" state vector [21:49:17] 2nd column is the CSM state vector in the CMC and it shows the differences to the left SV [21:49:26] 3rd column is the LM SV in the CMC [21:50:04] U, V, W are position differences to the base vector [21:50:08] in feet [21:50:22] so the CSM one is a few hundred thousand feet in error [21:50:32] while the LM one is only like 26 feet [21:53:46] In my current scenario range and range rate are 0 but I don't know if I did the V47 before or after P30 [21:54:46] why do I get a 220 alarm when I call P40 in your scenario [21:54:52] "IMU orientation unknown" [21:55:05] I was in standby. Set the refsmmat flag [21:55:16] V25N07E 77E 10000E 1E [21:55:20] following the preliminary flight plan, I see :D [21:55:32] I wanted more time acceleration :p [22:00:03] I get the right attitude now [22:00:14] CMC agrees with the Maneuver PAD [22:00:48] did V47, the REFSMMSAT flag and a bunch of housekeeping of course. Auto RCS, V48 etc [22:00:57] P30 [22:01:19] I guess it was my state vector then [22:01:42] probably [22:02:20] maybe some other forgotten V47 lead to the slightly larger maneuver DVs you had [22:02:35] well have fun with MCC-3 [22:02:46] good night! [22:02:52] Night [22:03:19] Shouldn't be teaching this kid P52s and doing MCC3 at the same time I guess [12:39:11] Hey [12:41:26] hey Thymo [12:41:45] Working on MCC4 [12:41:54] It gave me 0.5 ft/s on RCS [12:42:39] sounds reasonable after a 8 ft/s MCC3 [12:42:53] Apollo 8 MCC logic never scrubs MCC-4 [12:43:57] on a usual mission you will get MCC-1, MCC-2 and 3 scrubbed and then MCC-4 is larger, a few ft/s [12:44:17] MCC-1 not scrubbed* [12:44:41] I don't think I've done a P41 before. Gonna be fun [12:45:15] just remember that the burn is not automatic haha [12:45:47] RCS has to be done manually. Guided RCS burns aren't invented until they start smashing ascent stages into the lunar surface with the P99 EMP [12:46:40] It's basically the same as nulling residuals after an SPS burn I guess [12:46:48] yep [12:47:43] working on the LVDC acceleration filter: https://i.imgur.com/9uTcSqy.png [12:47:59] Blue line is measured acceleration during Apollo 11 S-II flight [12:48:23] orange is the smoothed version [12:48:30] Nice [12:49:20] ever since I started running the LVDC on a fixed time cycle instead of Orbiter timesteps I had to do a bit of trickery to measure stable acceleration for the LVDC [12:49:27] our AGCs have the same issue actually [12:49:54] the exact 2 second guidance cycle of the AGC can included randomly one more or less Orbiter timestep [12:50:15] you can see that effect in the blue line a bit, a small peak up and then down [12:50:25] the filter is pretty good at accounting for that [12:50:34] Looks even more impressive if I add random noise to the signal [12:51:46] I'm just not 100% sure about the behavior at inner engine cutoff and mixture ratio change... [13:12:11] That's MCC4 done. Next up LOI [13:20:06] nice [13:43:23] good morning [13:53:57] hey [13:55:26] any further thoughts on that SPS? [13:55:47] Just seems weird my residuals were pretty low until TEI on that mission [13:55:58] unless there is something else wrong in my EMEMS [13:57:23] I mean it's also the CSM being the lightest [13:57:42] I want to do a few more tests, but right now I am getting close to what I expected actually [13:58:02] close to 0 residuals with dual bore, 0.1x time acceleration [13:58:12] with changes or as is? [13:58:20] no changes [13:58:32] huh [13:58:33] I got -1.0 with 1.0x time acceleration [13:58:49] I did it twice at 0.1 and still got the residuals [13:58:53] so with larger timesteps there is a bit of a delay in the shutting down [13:59:25] wonder if it is just my computer [13:59:34] your laptop? [13:59:37] yeah [13:59:42] maybe [13:59:47] I mean its not bad but not beefy like my desktop [13:59:55] desktop is very powerful [14:00:11] I do not really understand how a +1.8 is possible [14:00:22] so an underburn [14:00:46] yeah [14:01:07] I had underburns with both 0.1x cutoffs [14:01:30] I only got that with only one DV Thrust switch [14:01:55] I had both banks open [14:07:37] so very well could be the system [14:07:45] yeah but why [14:07:58] if you were in external view for example you had a stable framerate [14:10:58] I have to do it a few more times to see if I get the same [14:11:07] if I can replicate the underburn once [14:11:40] the overburn it easily explain by the calculation method for the thrust, just predicting a thrust for the next timestep and not the total necessary impulse [14:13:00] will always be slightly random and have a tendency to overburn a bit that way [14:16:43] I was in 2d cockpit when I did those 0.1x tests [14:16:58] I can try in external [14:17:58] not necessary, I have your scenario and I know when I get a stable framerate, so I can try it myself a bit more [14:18:14] ok then :) [14:18:31] everything we are talking about is about 1/10 of a second worth of thrust only [14:22:26] on another note, didnt many missions fly P270 for PTC on the return trip? [14:22:38] 15 used 90 I see [14:23:16] maybe due to the sim bay? [14:23:35] could be, maybe some thermal constraint for it [14:23:45] although I don't see how it would make much of a difference haha [14:25:05] yeah I dont either [14:25:16] its still normal to the suns radiation [14:25:25] just an observation [14:25:59] CM is pointed in a different direction of course [14:26:03] maybe it's that [14:26:12] or antenna coverage or so [14:36:41] speaking of, we dont have an sband squelch enable switch do wel [14:36:44] we* [14:37:03] panel 180 in the LEB for SC 106 and 107 [14:37:09] and panel 3 for 108 and sub [14:40:29] probably not, our cockpit is mostly based on the CSM-104 Systems Handbook [14:42:30] oh I just learned something interesting about the S-IVB [14:42:48] whats that [14:43:07] I was always confused why the time it takes between engine start signal and actually developing thrust is so different between Saturn IB, Saturn V first burn and second burn [14:43:57] it's like 1 second for the Saturn IB [14:44:02] 3 seconds for S-IVB first burn [14:44:07] 8 seconds for second burn [14:44:38] but there is a signal that I hadn't really considered before that seems to be the deciding factor in the timing [14:44:49] "fuel injector temperature ok bypass" [14:44:57] doesn't sound like much, right? :D [14:45:18] but I think that is really what the timing of the S-IVB thrust going up needs to be based on [14:45:34] that seems to allow the start procedure to really kick in [14:47:32] I was just working on something for the LVDC and noticed how much later the S-IVB starts on the Saturn IB than it should [14:48:16] well "much" about two seconds too late, but in that phase it already starts measuring acceleration and the lack of it throw something off a bit [14:52:42] what an obscure little signal [14:53:07] and an additional 1.4 seconds difference between Apollo 7 that I am launching and Skylab 2, for which the LVDC numbers are [14:53:41] so 100% thrust was about 3.5 seconds later the LVDC thought [14:53:48] later than* [14:54:25] I think that's a really important discovery for our S-IVB. Guess I'll have to make that new signal do something :D [14:54:38] wonder if that will have TLI impact? [14:54:55] nah, just that I can remove some bad code [14:55:24] oh and looks like on 15 and later the sband squelch switch it in the blank slot next to VHF ranging on panel 3 [14:55:29] is in* [14:55:30] there is a "first burn relay" and "second burn relay" that I am right now using to decided if the thrust should happen early or later [14:55:46] but those are just for some LOX pressurization thing [14:55:48] ah [14:56:01] so no influence actually on the ignition delay [14:57:09] and the Saturn IB uses the "first burn relay" logic even if it has no such thing [14:57:34] so that makes the burn work like the Saturn V first burn [14:57:44] which is the 2 seconds later than it should for a Saturn IB [15:01:52] so what difference overall would this make in say guidance or trajectory [15:02:17] none for the Saturn V, because we have some hacky code making the timing work as it should [15:02:49] haha [15:02:57] the "first burn relay" thing [15:03:07] for the Saturn IB the timing will be a bit better I guess [15:03:11] earlier ignition over all [15:03:41] and for any mission really, when the correct signal is used for the engine start then the timing is then correct [15:04:12] and doesn't depend on some assumption that the thrust will develop X seconds after engine start signal [15:04:53] engine start signal will still be required, but the important thing timing wise for thrust seems to be the fuel temp ok bypass thing [15:12:02] so a check on fuel temp essentially? [15:12:49] bypassing a check on fuel temp I think [15:13:20] but I have to check the logic for that in the Saturn Systems Handbook, what that really does [15:20:12] I don't know where the name comes from, but there is no fuel injector temp measurement that would do the same as this bypass signal [15:36:48] yeah judging by the Saturn Systems Handbook that signal is what allows power to the start tank discharge control solenoid [15:38:05] where is the sensor itself? the injector? [15:39:24] I haven't even discovered if there is a sensor haha [15:39:37] it's just a signal to the control electronics as far as I can see [15:40:10] if that relay is set, by command from the LVDC [15:41:04] haha gotcha [15:41:21] maybe it's like a secondary function of that relay or so, but haven't found it yet [15:42:51] do we actually lose consumables (O2 H2) during a purge? [15:43:17] I think so, the flows go up a lot during it [15:43:36] Hmm I left it on for 10 hours and I see no significant loss :P [15:47:11] Thymo and/or n7275 might know more [15:56:35] Yes it does pull from the tanks [15:56:49] Esystems.cpp:344 [16:03:23] interesting [16:08:59] indy91, can you give me a reminder on computing MCCs during TEC? [16:09:21] FCUA only or should I also do one using EOM again? [16:10:10] you can do a specific site one as a test [16:10:20] but usually it should be corridor control only, which is FCUA [16:11:38] EOM is 74.2 fps [16:12:20] MCC-5? [16:12:42] 6 [16:12:46] ah ok [16:12:58] I accelerated through 5 by accident [16:13:02] haha [16:13:03] MCC-5 can target a specific site [16:13:04] but still that seems high [16:13:10] MCC-6 is too late for that really [16:13:20] it seems large, but not extremely large [16:13:26] Surprised I need a correction there anyways [16:14:11] FCUA is 0.2. has my IP as 25.58/155.37 [16:14:29] hmm [16:14:36] EOM is 26.05/158 [16:14:40] that's quite far off the EOM yeah [16:14:44] yeah [16:15:03] I wonder if there is some inconsistency with reentry range [16:15:24] but I also wouldn't 100% trust your CMC haha [16:15:30] maybe the clock is off for example [16:15:49] clock is good [16:16:19] on the splashdown update page I have the EOM on there from my TEI but the desired and actual ranges are zero [16:17:11] you would have to input something for it to not be zero [16:17:23] more relevant is the reentry range bias on the RTE constraints [16:17:24] what would be appropriste [16:17:27] RRBIAS or so [16:17:27] appropriate* [16:17:39] 1190 [16:17:42] yeah [16:19:33] I don't really know what kind of TEI error causes what effect for reentry [16:19:50] but such a small corridor control burn but such a large longitude error is interesting [16:20:08] morning! [16:20:14] hey [16:20:36] Hmm I just computed an EOM for a time closer to current, and the dv is 5763? [16:20:55] whoa the latitude is very wrong [16:21:28] computing an MCC for 243h results in 15.31/158 (specific site EOM) [16:21:45] inclination constraint is 0? [16:21:49] 40A [16:22:08] don't think the Earth centered targeting can use that anyway haha [16:22:15] yeah it changes nothing [16:22:16] and a good TZ is loaded? [16:22:18] yes [16:23:03] https://www.dropbox.com/s/8odyvbsofa66nzt/Screenshot%202021-08-26%20102247.png?dl=0 [16:23:42] it found the return 24 hours earlier [16:23:43] notice the GETI at 270? [16:23:46] yeah [16:23:49] GETEI yeah [16:24:02] used the same entry time [16:24:22] that seems really weird [16:24:32] I wonder if it runs into some other constraint or so [16:24:45] which TZ estimate did you use, 295h? [16:24:53] yes [16:25:01] I think I want a scenario :D [16:25:26] yep already copying it [16:26:03] https://www.dropbox.com/s/3scgc39ys31k55h/Apollo%2015%20-%20TEC%20EVA.scn?dl=0 [16:27:18] I can only imagine some bug with the new logic for EOM targets [16:27:39] what does MPL with the same TIG give? [16:30:40] 26.14/175 with 163 dv [16:35:01] aah [16:35:25] I think I broke it with the change that made the inputs for the three calculation types more of the same [16:35:41] haha oops [16:36:39] nope, was already a bug before [16:36:44] it basically ignored your TZ time [16:41:47] well thats not good haha [16:42:12] and it still finds the wrong solution... [16:45:44] very interesting [16:45:53] the conic solution runs into the reentry speed constraint [16:46:01] that is normally set to 36323 ft/s [16:46:09] if I make that 36500 ft/s then it works [16:47:22] huh [16:47:47] but it falsely thinks that's an issue, I don't think the actual velocity is close to the limit [16:47:51] yeah my EOM at 243h is >37k [16:48:27] hmm, but if anything it should make it slower [16:48:36] have to do some more checking [16:48:55] but I think, even before I come up with a fix, you might be able to get a good solution if you change the constraint [16:49:02] Al is just hanging outside anyways ;) [16:49:23] CO1 button on RTE constraints page [16:49:42] VRMAX,36500 [16:50:46] it doesnt like lowercase lol [16:51:08] no luck [16:51:25] ah haha, the TZ bug was, it uses the TZ of MED F77 [16:51:29] that is unspecified area [16:51:33] ohh [16:51:36] its using zero then [16:51:40] yep [16:51:49] so if you input your TZ there and with the updated constraint [16:51:53] it might work lol [16:52:02] I had 20 ft/s then [16:52:12] back in a bit [16:52:17] there is no TZ for unspecified [16:52:29] oh its hidden haha [16:52:55] no luck [16:53:33] but if I enter it in lunar search it worked [16:55:31] is there an issue with fuel cell purging? [16:56:03] honestly I dont know, I left an o2 purge on for >10 hours but saw no significant decrease in quantity [16:56:42] it might just have not been enough to make an observable impact, but I didnt dig...simply a broad scope observation [17:10:25] okay, I'll look into it [17:16:49] rcflyinghokie, I got my MEDs wrong. It uses it from F77, which is lunar search [17:17:14] so the bug is that with specific site or lunar search it right now uses the TZ for lunar search [17:17:50] so here is the computation now, can you kind of explain the differences in EI T and IP coordinates? I am assuming entry interface, targeted, and impact point, but they seem odd [17:18:01] https://www.dropbox.com/s/h2gs4lmq6p6tpgo/Screenshot%202021-08-26%20111138.png?dl=0 [17:18:24] unless that range is what comes into play here [17:18:50] IPB is impact using the backup method [17:18:51] I would have assumed the target was the splashdown point [17:18:55] ohh [17:19:02] 4g constant reentry [17:19:09] ok never mind that makes more sense [17:19:16] so, this display does not have your actual splashdown coordinates [17:19:23] but it has miss distances to it [17:19:30] the "T" values are the target [17:19:46] MD is miss distance of actual splashdown (full simulation of reentry) to the target [17:20:08] with how it works right now 1-2 NM off is normal [17:20:19] not sure if it should be even more precise, might have to work on that [17:20:35] ML2 and ZL2 only apply to a skip reentry [17:20:42] that's why they aren't shown [17:20:45] ah [17:20:50] ML2 is maximum lift of the second entry [17:20:56] so first entry guided, then a skip [17:21:03] and then maximum lift [17:21:10] ZL2 is the same but zero lift [17:21:14] which is ballistic [17:21:17] rolling reentry [17:21:39] so basically shows, after the first entry and skip, which range of longitudes you can get then [17:21:59] who knows, maybe they deleted this from the display at some point because it wasn't really used [17:22:03] they still had it on Apollo 8 [17:23:14] makes much more sense now [17:23:26] so that burn should put me where I need to be [17:23:28] I was also confused about IPB at first, I thought this backup technique should get you to the same coordinates [17:23:49] https://pbs.twimg.com/media/EMr5n6FXUAESgMJ?format=jpg&name=large [17:23:54] but as you can see, different coordinates [17:24:15] this does show ML2 and ZL2 though haha [17:25:30] That's apollo 8, correct? [17:27:56] yes [17:28:03] actual TEI-10 and 11, the backup [17:50:52] I won't have a fix immediately, trying to solve the issue with the reentry speed constraint first [17:54:22] no problem I have my workaround [17:54:38] Going to have to use a P30 REFSMMAT though :P [18:02:02] I have not uplinked a new SV since after TEI, all uplinks to the LM slot [18:02:08] My current SV is pretty bad [18:02:49] must be the timestep thing [18:03:39] hmm maybe not [18:03:49] the nav check pad is very different than both [18:06:07] am I missing something? https://www.dropbox.com/s/3m1j0hstu76an4b/Screenshot%202021-08-26%20120550.png?dl=0 [18:06:17] thats with a current SV [18:09:44] maybe some more stuff is broken in the erasable [18:10:59] wonder if that played a part in needing the larger MCC [18:11:23] TEPHEM itself is good, but I see bad stuff after that [18:11:33] which would be relevant for P21 [18:12:01] ahh [18:13:19] EMEM 1711 to 1715 [18:13:59] well [18:14:00] not even [18:14:31] EMEM1711 is 40000 and should be 0 [18:15:13] EMEM1715 is 7033 and needs to be 37777 [18:15:15] only those two [18:16:09] especially the second thing might break P21 [18:16:19] well both are bad haha [18:21:02] I'm checking a few more things in the scenario to avoid surprises... [18:21:07] 40000 is just about as far away from 0 as you can get lol [18:24:20] yes but what are the chances, that is an angle, it seems to be -360°, instead of the normal 0.002345° [18:24:33] so... actually ok? :D [18:24:35] oh hah [18:25:30] man that restart really messed things up [18:26:16] found more [18:26:17] EMEM3007 11463 [18:26:30] I am fixing them without editing this time [18:26:32] uhh, that is what it should be [18:26:37] EMEM3007 42757 [18:26:40] this is the bad version [18:26:53] reentry will be bad with 42757 [18:26:55] so I guess I just need the address and correct number [18:26:59] yeah [18:27:13] V21 N01E I guess [18:27:15] yep [18:29:25] do I have you check the entire lunar and solar ephemerides... [18:29:56] P21 is happy again [18:30:06] haha whatever you think I need to Houston [18:31:13] looked at a bunch of numbers of them, not all, look good [18:31:29] I think the rest is ok [18:32:55] the 3007 is the lift-to-drag ratio of the CM [18:33:02] for the reentry programs [18:33:10] instead of 0.3 you would have had a negative number [18:33:15] I wonder what that would do :D [18:34:37] haha oh dear [18:38:32] maybe lift vector down when you need lift vector up [19:34:25] rcflyinghokie, all that I can tell so far is that the conic solution actually runs into the reentry velocity constraint and that conic vs. integrated solution are quite far apart [19:34:38] even did a P37 to confirm that haha [19:34:45] 42 ft/s for conic, 2 ft/s for precision [19:36:36] P37 fuel critical [19:37:20] wow [19:37:23] thats a difference [19:46:59] from what I have seen of the real RTCC RTE stuff it might suffer from the same problem. I need to listen to more RETRO flight controller audio, maybe they had the velocity constraint set to a higher number than what they actually want [19:56:22] I put mine to 37k [20:47:24] night! [22:42:10] .ask indy91 On Apollo 8 you only get a PAD for LOI-1 and no target load uplink. Is that correct? [22:44:32] .ask indy91 I can't read, it does. False alarm :p [22:48:49] :P