[23:30:25] NASSP Logging has been started by thewonderidiot [23:30:29] GuenterWendt! [23:31:37] GuenterWendt! [23:32:39] Ryan! [23:32:42] oh wait.. [23:33:01] I didn't know you were a Pokemon :P [23:33:58] lol [23:35:49] I uh, didnt either? [23:36:58] guys I think at long last, like 4 months later, I might finally finish making all of the parts I need to assemble 19 buttons for the DSKY [23:37:02] minus painting for the keycaps [23:37:18] going full DIY was truly a dumb idea lol [23:40:39] last thing I need to do before I start assembly is bend all of the leaf springs [23:43:21] well you learned from going fully DIY [23:43:25] so not a bad thing [23:46:45] man I learned so much about making fiddly little things [23:50:20] good [11:18:15] Back from vacation. Gonna try to build Orbiter in a little bit. [11:18:52] Nice to see XRSound being open source. Gonna see what needs to be done to get it working with NASSP. It'll solve our license woes with OrbiterSound [11:19:58] n7275: If you have those IRC logs for me I'll skim through and replay them into Guenter so they are archived. :) [11:23:45] hey [11:23:51] sure [11:43:03] it'll be later today before I can get to them, but I'll send them over. [12:05:02] Sure. No rush. [12:20:53] GuenterWendt! [12:21:05] Hey [12:21:53] hey Thymo [12:22:02] seems like your server didn't sink in the floods [12:22:30] Nope. It was still on when I got back. It just was completely frozen, I had no way to find out what happened unfortunately. [12:22:49] ah damn [12:22:53] But at least it's not broekn [12:22:55] broken* [12:23:43] Guenter probably just missed you [12:24:21] Probably haha. At least that machine has now damaged my trust. It better keep working to rebuild that trust. [12:34:58] indy91, almost think we should revert the EL color update [12:35:55] ok [12:36:34] so why do you think the actual DSKY appears fairly blue in Marc's video? [12:36:40] and in Mike's eyes haha [12:46:11] I'm just trying it. The horizontal lines on the DSKY are very much in your face now. They used to be thinner [12:49:08] And the digits look weird: https://puu.sh/I0HA2/53f6ab5916.png [12:51:06] I think I mixed up what was "simulated halation" and when was "anti-aliased" pixels [12:52:22] what would be great, is filming one of the displays on an equivalent filmstock and looking at the color it captures [12:53:38] I can push an update later that fixes the digits and lines. the color I'm still on the fence about [12:54:17] right [12:54:23] maybe talk to Mike about it a bit more [12:56:05] I thought I came up with a fix for the socket issue, but now that I'm home I'm having trouble reproducing it. [12:56:15] Looks like sometimes it is cleaned up [12:57:21] you get it if you load NASSP then exit, but not completely exit Orbiter and start another scenario [12:59:19] I made sure that on scenario exit orbiter is set to dealloc and go to the launchpad instead of respawning. However I see the socket is being closed. [13:03:39] Now the port is open [13:10:18] I closed a scenario and then quickly started another and that caused it to stay open [13:14:12] but it only happens with scenarios with a LM [13:39:19] Do you guys ever use the socket debug menu in the PA MFD? [14:49:14] I dont think I have [14:54:37] IRC related question, I get this everytime I log into Libera and the nassp channel: This nickname is registered. Please choose a different nickname, or identify [14:54:55] I have done it each time and it says it was successful, but each log off and log on it comes back [14:55:55] You need to identify with NickServ each time you login. If you haven't set up SASL you will need to enter your password manually. [14:56:11] Do /msg NickServ identify [14:56:36] https://libera.chat/guides/registration#logging-in [14:57:14] as I said I have done that each time [14:57:31] Yes. You need to log in each time you connect. [14:57:46] You can automate it if you setup SASL [14:57:54] I have SASL set up [14:58:11] thats why I am confused, it worked for a while then this just started back up last week [14:58:47] If I WHOIS you I don't see your fingerprint so you might have messed something up in your client. You're not connected with SASL right now. [14:59:09] If you WHOIS me you'll see my certificate fingerprint [14:59:29] hmm thats weird [15:00:27] I guess I had to just re enter my password [15:00:29] weird [15:01:12] hexchat cleared my password from my saved servers list haha, oh well all is working now [15:02:09] Unrelated. Are you connecting via SSL on port 6697? You might also be on a plaintext connection [15:02:56] how would I check [15:03:26] Server connection details in your client [15:04:25] not sure where those are [15:06:10] "o ensure that you are connecting via SSL you can enable the checkbox named Use SSL for all the servers on this network, and disable Accept invalid SSL certificate by editing the network details in the network list. Make sure that, if HexChat is set to connect to a specific port that it's either 6697 or 9999" [15:07:01] yep those check boxes are as described [15:07:14] not sure about making it connect to a specific port [15:07:30] You are on a secure connection now apparently, you weren't earlier. [15:07:47] only thing that changed was the SASL [15:07:57] oh well [15:08:41] I think SASL imples SSL then [15:08:46] ah [15:08:58] haha well seems to be normal on the laptop now, thanks! [15:13:22] looks like someone is questioning the DSKY color change in the work thread [15:14:22] yeah, probably going to revert it, want to talk to Mike again, first though [15:14:23] n7275 might need to jump in and defend :) [15:14:33] yeah absolutely [15:19:12] Could it also be possible that over the years it got discolored? It might originally have been green. [15:24:56] weird thing to me is some flight videos show it the teal color and some show that green color [15:25:02] could be the cameras as well [15:47:30] morning! [15:48:27] good morning [15:48:31] Morning mike [15:51:02] hey mike [15:51:04] I rewrote how the PCM sockets get closed. The TELECOM bind failed error is now fixed. PR incoming. [15:51:42] have you looked at my display color update? how far off am i? [15:52:25] Whoever implemented the PCM on the LM stored the LM socket in the CSM variable, so the CSM socket never got closed. But the whole way it was done was unneeded anyway. [15:52:46] oh god [15:53:01] that's bad [15:53:06] I told you the other day it was dumb [15:53:14] haha [15:53:43] We were resolving function symbols across 3 DLLs just so we could have that SOCKET menu in PA MFD. [15:53:46] That's gone now. [15:56:30] n7275, I think you are less far off than we were originally [15:57:07] but I don't know how to capture it well lol [15:57:42] the weird thing is, I would describe it in real life as a mix between green and blue [15:57:59] but when you mix green and blue light, you get cyan [15:58:06] and I would *not* describe it as cyan [15:58:20] which is part of why I was saying my eyes don't really know how to process it [15:59:29] nor do cameras [16:00:52] n7275: Added you to the PR. Could you check it for me? It shouldn't mess with any of your stuff, I thought you mentioned some concern about that. [16:04:20] these two pictures were taken of the same panel, under different lighting conditions with different cameras: https://i.imgur.com/ssQaU3U.png [16:04:42] ahh [16:04:48] hahaha [16:05:25] thewonderidiot would you mind posting that image on the discussion in the forum? [16:05:26] so there isn't really a wrong answer about the color [16:05:39] thats what I am thinking [16:05:46] we just have to choose one [16:05:56] the only wrong answer is using V55 in P65 [16:05:58] Make it both. Change the color depending on the angle you look at it. [16:06:03] I will say that it has never looked that green to my eyes [16:06:20] but who knows lol [16:06:23] maybe under the right light it would [16:06:41] or make it one color in the 2d cockpit and the other in 3d? :P [16:07:57] haha [16:08:27] or randomize the color [16:09:39] that would really throw people off haha [16:14:53] yeah, wasn't a serious suggestion [16:16:15] thewonderidiot, I wished we had something like the LM G&C Data Book for Block I, it has such great explanations... [16:16:39] hahaha [16:17:00] well [16:17:27] if you didn't notice, one of the items I marked for scanning this trip is the "Spacecraft 012 G&C Data Book" [16:17:53] right, I did see that and already had forgotten again [16:18:14] lol [16:18:29] no idea if it will be as good as the LM one, but it seems promising based on the title similarity [16:19:45] https://i.imgur.com/VykNYKP.png [16:22:02] I'm sure it's good. Of course from NAA instead of Grumman, so probably very different [16:54:02] Thymo, I'll check it out. [16:55:46] thewonderidiot, what would be cool, is taking some pictures of the display on some peroid-correct filmstock and comparing with historic pictures [16:58:17] Thymo, "Please file a bug if this message persists" [16:58:40] is that correct english or should it be bug report [17:01:55] also, can you check if you can still access the LGC menu in your PR? I think you removed the RegisterPage for the socket but PROG_LGC still points to page 7 of the MFD, so debug menu might lead to the LGC page and LGC page nowhere [17:01:59] not quite sure though [17:18:30] "bug report" would be correct [17:49:58] I guess 'filing a bug' is only really used in some places. Regardless the idea is to make it understandable to the uninitiated so I'll change it. [17:53:55] I think It's pretty unambiguous, so no big deal. In the short time I've spend in The Netherlands, I can definitely say you guys average better english than most Americans [18:01:35] indy91: Good catch. That's messed up now. Any idea if those constants can be replaced so they always match instead? [18:02:20] just make PROG_DEBUG = 5 and PROG_LGC = 6 [18:02:54] you removed PROG_SOCK which was 5, but the RegisterPage always adds one page [18:02:56] That's the easy approach. It would be kind of nice to directly couple them to the vector from the library. [18:03:24] no idea, I've just been using the library this way for all the MFDs I have worked on [18:03:39] library is from the Launch MFD [18:04:07] I definitely thing that 6->5 and 7->6 is the easiest solution :D [18:04:18] think* [18:05:34] you could have also left the RegisterPage as it was [18:05:46] then it's an empty, unused page but in the same order [18:06:26] Strive for the best solution not the easiest. ;) [18:06:35] Could work [18:07:08] I mean, trying to manipulate the inner workings of a library you are using is probably not the best solution [18:07:46] I'm manipulating the inner workings of the addon I'm using. It's all the same. [18:07:51] haha [18:08:21] would have been nice if RegisterPage was returning an integer that you can assign or so [18:09:16] I don't think the MFDButtons class has any Get functions like that sadly [18:22:48] I'm cooking something up. [18:25:51] Thymo: https://drive.google.com/file/d/1ogVk5Qe5ive-rGRmYSwbVd3UhdJDqZSp/view?usp=sharing [18:25:56] Thanks! [18:27:00] I should note, the times are all EDT (UTC-4) [18:27:23] That's alright. [18:38:08] n7275: Your PR still has the fat horizontal lines between the registers. Do you want to keep those? [18:51:21] whoops. nope [18:53:56] TBH the lines on the video are bigger and squarer(?) than what we used to have. Maybe if they're a couple of pixels thinner than the new ones it's perfect? I dunno [19:03:17] Thymo, oh you did choose the solution with keeping the RegisterPage [19:03:45] uhh [19:04:05] ah no [19:04:11] you just fixed the message [19:04:16] not the MFD page stuff yet [19:04:21] Yes, I'm not done yet [19:04:49] I'm returning the index from RegisterPage locally. Figuring out how best to use it. [19:05:42] do you have to change the MFDButtons code for that? [19:05:53] Probably gonna add a setPage function in PAMFDButtons and make PAMFD call into it to change a page so it doesn't need to know ids. [19:06:06] MFDButtonPage.hpp [19:06:28] It was a void function. Now it return the page element index from the vector. [19:07:45] https://www.youtube.com/watch?v=8DAwMC6tc7g [19:08:48] you really want to rewrite an external library just so you don't have to change a 6 to a 5 and a 7 to a 6... [19:12:33] https://www.youtube.com/watch?v=lCFyJIDGztA [19:12:57] Launch MFD is GPL it seems, so I guess there isn't really a problem on that side [19:13:18] LGPL but we already distribute it as source [19:13:50] right, I remember having a few discussions with dseagrav about that when I wanted to add it [19:14:00] when the number of pages in the RTCC MFD got out of hands haha [19:15:10] might have even been when the RTCC MFD got first added to NASSP, we had to check what external code I was using [19:15:18] and it was only this library [19:39:32] Got an idea, best solution without rewriting half of the MFD. Still want to be compatible with RTCC [19:39:50] I'll send you the commit after I test [19:53:58] sure [20:12:11] It works. But the CLR FRZ and BCK buttons are off by one. I think I missed a line somewhere [20:15:12] what are you changing that affects the buttons vs. the pages? [20:15:34] I think it was from the original removal of the SOCK page [20:17:52] ah that sounds familiar [20:18:08] a RegisterFunction too much or so [20:19:26] you always define a MFDBUTTONMENU, then RegisterPage, and then RegisterFunction for all the buttons [20:19:50] in your current PR you for example didn't delete [20:19:51] RegisterFunction("BCK", OAPI_KEY_B, &ProjectApolloMFD::menuSetMainPage); [20:20:01] that was the one button defined for the socket page [20:20:06] but you did delete the socket page itself [20:20:19] maybe something got confused there then [20:21:43] Hmm [20:21:55] For some reason the GNC and Debug page get the same page inde [20:21:56] x [20:23:19] The assinged indexes go: 0 4 1 2 3 4 5 6 [20:23:32] Oh lol [20:23:52] I accidentally replaced RegisterPage(mnuGNC... with (mnuGNC... [20:24:03] Thanks VisualStudio haha [20:24:25] Somehow that syntax was valid and resulted in 4 [20:25:24] Works now [20:26:58] indy91: https://github.com/orbiternassp/NASSP/pull/628/commits/e496f76e40c90325c7bcb3a37aae655264f64abc [20:28:33] there still is the back button for the socket page [20:28:47] https://github.com/orbiternassp/NASSP/pull/628/files#diff-cce8664001ad093a71d953bc802fb72b21e2f14296c275bea4b1ac29e0e42b2fL146 [20:29:35] hmm [20:29:40] wait a minute... [20:30:53] Looks like a leftover. I'll remove it [20:31:14] no wait [20:31:25] something is screwed up with the telemetry page even before your PR [20:31:51] ah no haha [20:32:09] I thought the telemetry page was missing a function to return to the main menu [20:32:18] but the function to do that is called "menuAbortUplink" [20:32:30] I thought that meant "uplink something for an abort" [20:32:40] like some other button uplinks that to Sunburst [20:32:50] but it means "abort the uplink" haha [20:32:55] and it does go back to the page before [20:33:15] so all good, that RegisterFunction should be removed [20:33:16] Yep lol [20:33:49] I like the change [20:34:01] quite simple and user friendly when handling the different pages [20:34:18] not sure I'll add a struct like that for the 100+ pages in the RTCC MFD though lol [20:35:05] The only problem is that the struct is not initialized until the pages are created. So that's why I initialized some variables to 0 instead of PROG_NONE. [20:36:11] right [20:36:37] Not a problem as long as you don't try to set a page before you create them. [20:36:50] yeah, it's unlikely that pages wold be created dynamically or so [20:37:26] I would initialize it to an invalid value and check it, but that would require more changes in the library. [20:38:00] And I want change as little as I can to make sure I don't break RTCC. [20:38:32] I do wonder why I had to add this: https://github.com/orbiternassp/NASSP/pull/628/files#diff-cce8664001ad093a71d953bc802fb72b21e2f14296c275bea4b1ac29e0e42b2fR167 [20:38:37] Was that already wrong? [20:38:52] the MFD Buttons does complain when you try to set an invalid page at least [20:39:37] hmm, that's right below the extra RegisterFunction... [20:40:16] but probably was already wrong yeah [20:41:15] 9 empty button descriptions, but only 8 empty buttons [20:41:28] maybe happened when I converted the PAMFD to use this system [20:42:24] Thymo, just looking at your work, this will have no affect on the telemetry work I'm doing. [20:42:48] static const DWORD btkeyDEBUG[12] = { 0,0,0,0,0,0,0,0,0,OAPI_KEY_C,OAPI_KEY_F,OAPI_KEY_B }; [20:42:55] that was the buttons before [20:43:03] I count 9 zeros [20:43:17] so I did indeed miss adding one empty button [20:44:43] Yep it's there on the main branch [20:45:06] Wouldn't have found that if I simply changed the constants :p [20:45:44] Pushed a commit to remove that extra back button. Happy with everything else? [20:46:17] yep [20:46:37] Merged [20:46:41] Thanks! [20:46:49] Thanks! [20:52:29] and good night [22:07:47] .shrug [22:07:53] .help [22:08:00] https://sopel.chat/usage/commands/ [22:08:14] .shrug was on there. Maybe I should update [22:08:41] .at 19:00 Check restart light [23:53:35] I swear, 10 years from now, people are still going to be finding bugs in my HGA logic... [13:42:13] good morning [13:44:50] hey [13:45:34] hey [13:49:23] HGA fix looks good. At least I see no obvious coding error. [13:53:34] is it ready to be merged? [14:11:37] yes. it can be merged. [14:13:23] done [14:13:43] you still wanted to think about the DSKY stuff, right? [14:29:26] Good morning [14:33:38] hey Ryan [14:34:46] I'm finally understanding the Block I CDU... did I mention that it was great timing that I started work on Block I stuff just one day before Orbiter became open source? :D [14:35:28] haha awesome [14:35:59] it does work different than Block II [14:36:09] the Block I AGC software has no DAP at all [14:36:15] yikes [14:36:56] that would have been interesting, but then again it was never meant to go to the moon [14:39:08] indy91, you can merge the dsky PR. it fixes the digit style. I may/will work on color separately. [14:39:24] ok [14:39:42] oh, whats the state of the SIVB and evasive maneuvers and such? Is that functional for all missions or just some? [14:40:03] AGC positions the CDU to the desired attitude. The difference between IMU and CDU is then an attitude error that gets sent to the SCS. So works kind of like the AGS. [14:40:48] that works correctly for all missions, but in non-MCC scenarios you have to remove inhibits via the PAMFD [14:41:05] the only thing that doesn't exist yet is a calculation method for lunar impact APS burns the S-IVB does [14:41:21] but you can already uplink to the IU the numbers for a impact burn [14:42:23] Mind walking me through it for say 14? [14:42:42] yeah it's quite different between missions [14:42:45] let's see... [14:43:28] I think it's pretty much as in the flight plan [14:43:32] there are two ground commands [14:43:49] yaw maneuver is first, send that at the specified time. I think it's called yaw maneuver in the PAMFD [14:44:02] for the evasive burn, that is enable time base 8 or so [14:44:17] hmm no... [14:45:14] ok, if you read the flight plan it's confusing haha [14:45:22] but I am using the right Saturn terminology [14:45:43] "enable evasive maneuver" in the PAMFD is actually the yaw maneuver the S-IVB does after CSM/LM ejection [14:45:55] so for Apollo 14 that would be the ground command at 4:09 [14:46:15] And then "Timebase 8 Enable" is the signal at 4:19 [14:46:23] just send them at those times from the flight plan [14:47:00] and you first need to tell the PAMFD which vessel the S-IVB is [14:47:17] SRC button [14:47:46] I should make it so that it says "No vessel!" if that wasn't done yet [14:48:13] ok so the yaw maneuver is enable evasive [14:48:18] yep [14:48:52] and the TB8 signal starts the signal for the burns [14:49:13] so what do I need to do first in PAMFD (I have never messed with the IU page [14:49:35] SRC button to tell the MFD which vessel has the IU [14:49:43] type in the name of the S-IVB [14:50:20] done [14:50:35] TYP button to cycle between the different types of uplinks [14:50:41] so evasive maneuver first [14:50:53] what about remove inhibit? [14:51:14] I think that is something for Apollo 9 only [14:51:20] ah ok [14:51:31] "Remove Inhibit Mnv. 4"? [14:51:37] yes [14:51:49] ok so I have evasive maneuver enable selected [14:51:56] I think that allows the S-IVB to move away from the TD&E attitude in Earth orbit [14:52:06] the inhibit maneuver 4 [14:52:12] ah ok [14:53:16] the S-IVB will maneuver immediately if you send that [14:53:25] so it better not be with the CSM/LM still attached :D [14:53:36] haha nope I am on the FP timeline [14:53:46] so I select it and then just hit UPL? [14:53:49] yes [14:53:55] it will give a response if it has worked [14:54:03] Ok and this was sent at 4:09 correct? [14:54:12] yes, like in the flight plan [14:54:18] ok 1 minute to go [14:54:32] "Uplink accepted", "Vessel has no IU", "Uplink rejected" [14:54:35] of course, the actual command wasnt sent then :P [14:54:40] I hope you get the first message :D [14:54:57] true [14:55:13] good that they had this system with the inhibits and time base 8 [14:55:18] uplink accepted [14:55:21] great [14:55:45] shes maneuvering [14:55:50] Apollo 8 didn't have that. If Apollo 8 had delayed their CSM/LV separation it would have been a bit messy to stop the S-IVB from maneuvering [14:56:17] at least apollo 8 wasn't docked [14:56:23] they would have had to send timebase updates, so make the LVDC think it is e.g. 1 hours into time base 7 and not 2 hours :D [14:56:38] oh yeah that would have been a messy separation [14:57:06] would be a busy time for the booster systems engineer [14:57:34] if you send the TB8 signal the S-IVB will immediately started a APS burn, I think [14:57:38] and then a bit later a LOX dump [14:57:55] ok so TB8 is the APS burn [14:58:06] well a whole sequence of events really [14:58:07] or "evasive burn" [14:58:19] So what all does TB8 entail? [14:58:22] evasive burn using the APS [14:59:25] fires the APS, starts the LOX dump [14:59:33] and then an attitude maneuver for optimal comm [14:59:48] and the impact burn is different? [14:59:50] and then waits to get commands for a course correction with the APS, for lunar impact [14:59:54] yeah that is later [14:59:55] gotcha [15:00:04] 1 or 2 APS burns were usually done for that [15:00:05] so how do I know when the maneuvers are complete? [15:00:13] which one? [15:00:14] besides looking out the window lol [15:00:18] the yaw in this case [15:00:50] hmm, no idea. You could switch to the S-IVB and look what it does for example [15:01:13] did MCC still have TM on the SIVB for this? [15:01:20] so they could see it's attitude? [15:01:28] Or was it done with timing and crew observation only [15:01:50] they still had telemetry [15:02:13] so they could have observed the whole thing with that [15:02:45] If it was at 40° it will maneuver to -40°. So 80°. And the rate limit is 0.3°/s I think [15:02:51] so should take about 266 seconds [15:03:27] do you have the Apollo 15 Saturn V Flight Manual? [15:03:33] I believe so [15:03:48] page 10-7 [15:03:59] attitude timeline for the S-IVB [15:04:05] I think it's the same as 14 [15:04:34] ah its on the desktop [15:04:36] not the laptop [15:05:02] downloading now [15:05:44] in the mean time time to enable TB8 [15:06:03] there she goes [15:06:20] I love watching it slowly being pushed away [15:06:29] and then later the large LOX dump plume [15:07:13] morning! [15:07:18] hey Mike [15:08:29] what's up? [15:08:31] haha yep moving slowly [15:08:40] I think I finally understand the Block I CDU haha [15:09:08] awesome :D [15:09:20] what I don't understand is why Solarium switches to attitude control mode and already sends commands to position the CDU, before the coarse align to the prelaunch alignment... [15:09:43] it doesn't really hurt, but it's weird [15:11:48] I'm sure I'll find out [15:12:37] now just waiting for the prop dump attitude [15:13:24] flight manual says that is at TB8+0:09:40.2 [15:13:59] pretty close to the 10 minute delta in the FP [15:15:41] right on cue [15:17:56] I'm not quite sure if the first lunar impact burn is automatic or not [15:19:39] don't think so [15:20:30] ok so after TB8 finishes I need to set that up? [15:22:59] and is the H2 venting visible or only the LOX [15:23:49] H2 is not visible [15:23:52] also not propulsive [15:24:07] but it does make the mass smaller [15:24:26] nothing to set up after sending the TB8 signal [15:24:41] unless you can magically come up with the right numbers for the lunar impact burn :D [15:24:53] you could command one just for fun [15:25:03] Yeah I would like to [15:26:16] cycle through the uplink types for "S-IVB/IU Lunar Impact" [15:26:30] you need to input TIG, burn time, LVLH pitch and yaw [15:26:36] TIG is in time base 8 time I think [15:27:55] we have the numbers from the actual maneuver [15:27:59] where? [15:28:27] Saturn flight evaluation report [15:28:34] thought so [15:28:35] haha [15:28:36] but it's a lot later than I thought [15:28:43] TB8 + 10558 seconds [15:28:54] about 6h GET [15:28:59] yep [15:29:04] thats what the FP says 6:30 [15:29:15] so the actual numbers to use are [15:29:19] TIG: 10558 seconds [15:29:23] duration: 252 seconds [15:29:26] pitch: 222° [15:29:30] yaw: -14° [15:29:47] quite long [15:29:48] do i need to wait for the dump to finish [15:29:48] 33 ft/s [15:29:56] yeah I would [15:29:58] ok [15:30:10] I think it would start maneuvering to that attitude immediately when the command is sent [15:30:42] ok no problem [15:31:29] wow the lox dump imparts 28fps [15:33:06] says it ended at 6:26:08.5 [15:33:09] long dump [15:34:59] hmm? [15:35:17] LOX dump was less than a minute [15:35:29] this is probably the actual time [15:35:31] with the delay [15:36:26] actual start time will also be a lot later than planned [15:36:47] hmm [15:36:58] where did you get 6:26:08.5? [15:37:13] oh right [15:37:23] I was looking at the TB8 start time [15:37:25] oh it says "lox tank dump was initiated at 6:25:20.5" [15:37:41] yes, because of the docking problem [15:37:43] that makes sense because it was delated [15:37:46] delayed* [15:37:47] yeah [15:37:51] that makes sense [15:37:52] everything a lot later [15:38:18] so this impact burn is probably not super good for your closer to actual trajectory [15:38:23] closer to planned* [15:38:47] but should still impact [15:39:14] and they had a launch delay, too [15:40:36] yeah well the actual sivb was what 150 miles off target? [15:40:56] so the dump is complete, I can send the lunar impact uplink? [15:43:49] yes [15:44:02] I hope that still works haha [15:46:47] says accepted [15:47:01] SIVB is maneuvering [15:52:53] thewonderidiot, I thought I need to set register OUTCR1 to 0 to simulate the pulses having been send out, but apparently the AGC then never puts anything in that counter anymore [15:53:01] for coarse aligning [15:53:54] and I think I have everything working well enough no to try a launch. Still have the interface to the SCS to do, but I want to see what happens when Solarium get the liftoff discrete [15:53:58] now* [16:17:44] so I am maneuvering to PTC attitude, still waiting for the SIVB burn, and I figure I can go ahead and compute MCC-2 now for the hell of it [16:17:53] is it just option 4 as is with the MCC-2 tig? [16:19:56] hypothetical question: when Orbiter (x86 2021) and required dependencies "release". Do we know what we'd want to finish for an 8.0 release? [16:20:38] I'd like to see the power situation improved [16:20:52] ECS is in a decent state to move forward [16:22:09] option 4, yes [16:22:52] I probably want to finish my drag update and do a few improvements for the Apollo 7 and 8 MCC [16:22:54] mainly 7 [16:23:09] but other than that I could stop making major updates and work towards a release [16:26:31] 89.5 dv [16:26:47] little high compared to actual [16:27:35] LOI 82:15:34 [16:27:38] thats late [16:28:29] oh actually its early compared to the FP [16:28:33] by 15 minutes [16:29:00] FP TIG 82:38:14 [16:30:51] you can constrain the LOI TIG [16:31:42] but that is likely going to make the DV even larger... [16:32:19] ok should I leave as is? [16:32:46] you will want LOI to be on time [16:33:07] I made it a bit easier to add the constraints for that [16:33:15] side note, I dont have V79 in this mission do I? [16:33:19] no [16:33:28] you can use P20 though [16:33:34] as you have a Artemis derived version [16:34:23] wheres a good procedure for P20 PTC [16:34:49] AOH? [16:34:57] Or apollo 15 g&c [16:35:08] Apollo 15 G&C [16:35:48] got it [16:36:09] and you want [16:36:13] N78: 0,0,0 [16:36:20] N79: -0.3500, 000.50 [16:36:24] N34: 0,0,0 [16:36:28] P20 option 2 [16:36:53] that's 0.5° deadband, -0.35°/s PTC roll rate [16:36:57] got it [16:37:19] after maneuvering to the PTC att [16:38:06] all set [16:39:05] and I can just go to P00 from here [16:40:55] I think so. After disabling thrusters? [16:42:57] yeah disable RCS and Term P20 [16:43:35] ok I have my LOI matching my FP [16:43:39] 97 fps [16:44:59] https://www.dropbox.com/s/2khzd38vlszqvjm/Screenshot%202021-08-02%20104441.png?dl=0 [16:49:54] hmm, not sure why the DV is higher [16:50:03] is this a fresh launch scenario? [16:50:12] yes [16:51:11] 1.4fps at LM ejection was my only translation [16:52:30] TLI cutoff bias should be good [16:52:39] and we use the actual guidance presettings for 14 [16:53:37] no idea really [16:54:00] Actual MCC2 was 70 something I believe [16:54:02] LOI DV is smaller than the flight plan at least [16:54:09] so total DV isn't too far off [16:54:11] 71.1 [16:54:22] yeah, but that's with a late launch [16:54:23] how does everything else look [16:54:26] ah true [16:55:36] have you saved/reloaded since TLI? [16:55:41] yes [16:55:45] ok [16:56:05] then the lvlog for TLI is gone, might have had a clue, if the problem was with the LVDC [16:56:15] I have saves back then [16:56:50] I will try to get you one [16:57:02] first you could check your pericynthion altitude [16:57:19] needs the MPT though [16:57:33] or give me a scenario [16:57:40] sure [16:58:29] https://www.dropbox.com/s/fsbixm8a8el9tvs/Apollo%2014%20-%20Launch%200009%200001%200014.scn?dl=0 [16:58:53] For the lvlog do I need to burn TLI again? [16:59:47] yes, but let me check this scenario first [16:59:50] TLI could have been good [17:04:52] indy91: huh that's weird [17:05:25] yeah, maybe I have something else screwed up because at first I didn't get that... I think [17:07:24] Thymo, I get a build error right now. I still seem to have the original version of MFDButtonPage.hpp [17:09:42] I had LaunchMFD in the additional includes and it was using that version of the file [17:10:41] I have a other TLI in work for you just in case [17:10:42] probably needs to be changed. All people who have the LaunchMFD itself installed could get this error [17:10:44] another* [17:10:47] oh ok [17:10:49] thanks! [17:12:14] rcflyinghokie, you have the MPT active in this scenario... [17:12:27] I activated it right before I saved [17:12:39] all the MCC calcs were done with it inactive [17:12:51] ok, so can't have been the cause [17:12:54] nope [17:13:20] I was going to calculate the PC but exited to give you a save instead haha [17:13:30] and then found a pre TLI to burn for you [17:15:42] hmm that's already weird, I can't initalize the space digitals display... [17:15:54] Evening! [17:16:40] ok for the TLI, it just finished [17:16:45] can I close and give you the log? [17:16:50] yes [17:17:31] https://www.dropbox.com/s/vs881vdreffkh4u/lvlog.txt?dl=0 [17:17:55] on my MPT there still is a TLI [17:18:02] indy91: The file I changed is from src_rtccmfd. Maybe VS is misconfigured to not use it explicitly? [17:18:29] yes I need to remove the additional include directory so that it doesn't look for the Launch MFD file [17:19:28] rcflyinghokie, 2680.8 NM is the pericynthion [17:19:46] planned is 2000NM [17:19:52] I'd call that an underburn [17:19:59] uhh [17:20:03] overburn :D [17:20:55] uff [17:20:55] SV Accuracy: -9372.761579 100.579538 -1661.023471 [17:21:04] that's already fairly bad [17:24:07] T_CO = 9386.726928 [17:24:11] T_CO = 9386.837848 [17:24:15] T_CO = 9386.750523 [17:24:19] T_CO = 9386.776020 [17:24:27] time of cutoff [17:24:34] has converged nicely over 4 iterations [17:25:08] maybe the IU state vector is to blame [17:26:43] Haha so it was a TLI issue [17:27:02] not with guidance, but maybe with navigation [17:27:06] Thymo, this is what I mean: https://github.com/orbiternassp/NASSP/commit/f1fb211e1602d23b2bea030468d7eb4f1ea22472 [17:27:43] rcflyinghokie, you could try a IU state vector uplink [17:27:51] before TLI [17:29:34] ok [17:29:45] I mean, this number doesn't exceed the mission rules [17:29:46] indy91: Oh lol. I was just about to commit exactly the same [17:29:53] beat you to it [17:30:07] either way though I am going to just burn the larger MCC2 lol, but I am curious to see if TLI improves [17:31:39] rule of thumb is, 1 ft/s changes the perilune by 26 NM [17:31:47] at the time of MCC-2 [17:31:58] sounds about right for a nearly 700NM difference [17:32:19] RTCC to uplink an IU SV?> [17:32:24] yes [17:32:42] instantaneous? [17:32:44] and you need to choose a time at least 10 seconds in the future [17:32:51] or else the LVDC rejects it [17:32:57] oh [17:32:58] better a minute or so [17:33:05] hope this isn't too close to TB6 [17:33:12] about a minute lol [17:33:34] I have an earlier one [17:33:36] sounds like there is a window [17:34:05] I don't get why it would overburn unless it's a state vector issue [17:34:09] have one 5 minutes before [17:34:31] there isn't much feedback from the LVDC, only in the lvlog [17:35:10] when you send it it says "Navigation update received!" [17:35:36] and when it gets implemented, at the time tag of the state vector, it says "Navigation Update implemented!" [17:37:02] looks like they are in there [17:37:19] and then the SV accuracy will magically be small! [17:38:02] that SV accuracy is still only 1/6 to the limit I think [17:38:37] I will shoot you the log after this TLI [17:38:54] log doesn't tell me much, that was only for the cutoff [17:39:06] as long as it has implemented the state vector that part should be good [17:39:12] pericynthion height will be interesting [17:39:18] it says implemented in there so I assume it worked? [17:39:23] yes [17:39:27] SV accuracy is now small? [17:39:32] after implementing [17:39:37] so a scenario after TLI is what I need to check [17:40:01] log fills new lines at the bottom, correct?> [17:40:05] yes [17:40:06] SV Accuracy: 671.031014 -43.261832 0.171663 [17:40:11] good enough [17:40:19] the SV accuracy check itself isn't perfect [17:40:57] oh and while we are at it, for comparison, maybe also a scenario after your previous TLI? [17:41:14] sure [17:41:15] then I know for sure if that update made the difference [17:42:37] I think this is right after ECO [17:42:38] https://www.dropbox.com/s/o9rfmvf8bnmtvsd/Apollo%2014%20-%20Post%20TLI%20%28old%29.scn?dl=0 [17:42:51] let me know if it isnt [17:43:12] I feel like I have gone through this before and thought I saw that there must have been some thrusting event between TLI and the MCC-2 calculation [17:45:05] 2798 NM [17:45:12] so too high already [17:45:31] 100 NM difference to the later scenario, probably due to ejection or so [17:45:51] yeah I ejected a few minutes late with 1.4fps [17:46:13] instead of the expected 12 [17:46:14] at TLI the pericnythion sensitivity is 279 NM per 1 ft/s thrusting in the worst direction [17:46:15] 1.2 [17:46:41] which is along the velocity vector [17:47:10] so 1 ft/s too much shortly after TLI costs you 10 ft/s at MCC-2 [17:47:43] yeah I burned 1.4 at about 4h [17:48:39] ok TLI with updated SV is underway [17:49:50] in reality there was some venting just after TLI [17:50:21] which should push the pericynthion even higher I would think [17:52:19] about a minute left, do you want a scn and the log? [17:52:59] don't need the log [17:53:06] just the scn [17:53:24] ok [17:54:11] if that burns to the same pericynthion then I will be very confused :D [17:54:21] https://www.dropbox.com/s/zc9bofz2jd0jh5f/Apollo%2014%20-%20Post%20TLI%20%28new%29.scn?dl=0 [17:54:56] I might need to check the cutoff DV then again [17:55:04] currently we use 3.7 m/s [17:55:10] maybe it's off still [17:56:13] hmm [17:56:17] 2511 NM [17:56:51] I mean, by my rule of thumb, that would only be an error of 0.6 m/s [17:57:02] 2 ft/s [17:58:35] I'll check with the mass and thrust in your scenario [17:58:53] thanks for the help! [18:00:41] How do I know my AGS time bias in the Apollo 11 Before PDI scenario? [18:01:31] The time bias is 90h [18:02:42] I get almost exactly the 3.7 m/s bias, so that seems right [18:02:43] Oh. I suppose it would indeed be in already. [18:02:55] its in the activation checklist I believe, so it should already be in V47 [18:03:07] you can compute the k factor as well to improve it [18:03:27] yeah, that option is hidden in the RTCC MFD :D [18:03:44] I use it every time I change the time bias :) [18:05:05] indy91 I am going to press on with the mission with the higher MCC-2 I think, did the maneuver targeting look ok otherwise? [18:05:06] I don't need the AGS as I intend to land [18:05:22] blasphemy! [18:05:29] that's what Apollo 11 thought [18:05:51] then they went into gimbal lock [18:06:18] yep! [18:06:35] should be good if the LOI TIG is right [18:06:47] 240+ then (231 RLS). I must say as someone that does this for the first time in a long time that doesn't really give me an idea what I'm doing [18:06:58] Enter the value of 231 in 240? [18:07:04] yep [18:07:05] yes [18:07:22] Oh wow I guess I do know what I'm doing. [18:07:37] Famous last words [18:08:22] there always is the abort stage button [18:08:41] or the abort button, if you are feeling heavy on DPS propellant ;) [18:08:44] Switching to manual throtle and ATT HOLD. I'm doing it manual [18:10:04] Luminary 99 is more fun, when those buttons are the "maybe do a flip" buttons [18:10:38] Hold on, help me understand. According to the training card 231 is landing site radius. 240 is my initial position vector X. Why would I put 231 in 240? [18:10:39] haha that was hilarous to watch [18:11:02] you are basically telling the AGS where the bottom is for an abort [18:11:42] because you are doing a cheaty state vector update for the AGS on the lunar surface [18:11:43] Is 11 FP6 or 8? [18:11:45] 6 [18:11:58] Gonna look up the procedure in the manual [18:12:02] for what [18:12:10] abort? [18:12:10] you basically put in the nominal landing site state vector in 240 etc. [18:12:30] and once you are landed that is apparently more accurate than the current AGS state vector lol [18:13:49] as you get closer you also "update" the state vector with address 223 [18:13:53] The manual usually also explains why you are inputting those numbers. [18:13:55] then you stop the update with 413 [18:14:01] Your explanation makes sense though [18:14:20] I know 413 by now. [18:15:33] totally unrelated to everything, I just learned that I can ban people from orbiter-forum [18:15:44] I didn't realize being a mod of the NASSP section gave me that global power lol [18:15:53] haha uh oh [18:16:01] dont make Mike mad [18:16:13] somebody registered, and then immediately PM'd me a "see my naked pictures at this dating website" message [18:16:18] which apparently was a bad move :P [18:16:27] well then... [18:16:28] Oh yeah. I've done that [18:16:44] I think you have permission to the moderation queue [18:16:47] indy91, I cannot seem to delete my TLI from my MPT [18:17:15] it's a maneuver from the past [18:17:24] so its stuck? [18:17:26] "history delete" instead of "delete" [18:17:29] DH [18:17:33] instead of [18:17:34] D [18:17:35] Ah thanks! [18:17:36] in the MED [18:18:05] I got some message last night that just said "hi" [18:18:12] but this morning I couldn't find it anymore [18:18:18] maybe that was the same person lol [18:18:23] not there anymore because banned [18:19:40] hahaha [18:22:09] I dont think my SIVB burned [18:23:18] it would just be with the APS [18:23:24] ran out of prop already maybe? [18:23:33] which prop value [18:23:46] main prop? [18:23:54] nah, there is two APS tanks [18:24:00] maybe 2nd and 3rd tanks [18:24:02] same size [18:24:21] haha, I got the same message last night on OF. [18:24:38] rcflyinghokie, lvlog also has messages [18:24:50] Lunar impact burn started [18:24:54] Lunar impact burn stopped [18:25:31] not in there [18:26:13] hmm [18:26:23] you sure it got accepted? [18:26:27] yes [18:26:37] at least PAMFD said so [18:26:44] check the scenario [18:26:54] ImpactBurnEnabled [18:27:08] would be 0 if the burn has already happened though [18:27:18] LVDC_ImpactBurnEnabled 1 [18:27:19] LVDC_ImpactBurnInProgress 0 [18:27:31] oh ok [18:27:41] check a few more [18:27:42] dT_ImpactBurn [18:27:58] T_ImpactBurn [18:28:15] LVDC_dT_ImpactBurn 252.000000000000 [18:28:25] LVDC_T_ImpactBurn 10558.000000000000 [18:28:42] 262-00150 is the rotational speed of the moon? [18:28:49] It's the Z componenet of velocity [18:28:55] yep [18:29:05] also part of that state vector update [18:29:36] rcflyinghokie, and TB8+10558 has already happened? [18:29:45] oooh [18:29:54] that is from the actual mission [18:29:58] which had TB8 delayed [18:30:29] oh [18:30:36] so I still have more time to wait [18:30:38] the docking again [18:30:39] check [18:30:40] LVDC_TB8 [18:30:46] that is the start time of TB8 since GRR [18:30:54] LVDC_TB8 15560.659991848253 [18:31:01] We have 317R and 440R in the checklist to check range and range-rate to the CSM. But the checklist lets you discard it. I suppose it's just for informational purposes but wouldn't you want to note that? [18:31:30] its just a quick check between PGNS and AGS [18:31:49] showing that the CSM and LM SV's agree [18:31:59] about 7.25h GET [18:32:03] You know that. People going of the checklist mfd don't [18:32:36] thats coming right from the procedures, which is why its written the way it is [18:33:34] adding a note about it would be possible of course, but it doesnt exist IRL, and would open a can of worms to do that for many procedures [18:34:17] I am open to suggestion on improving it though, but again those were just directly out of the procedures [18:35:21] Maybe when the wiki is up we will have pages for procedures to give context and have the mfd purely as a reminder [18:35:35] I'd love to get a list of AGS addresses up there [18:35:46] BAsically a copy of the AGS section of the GN dictionary [18:36:12] It would be useful to have our own list of recommended documents to read. The training card can be one of them. [18:37:06] 2 very useful ones of course are the CSM GC checklist and the LM G&N dictionary as they have all the primary computer programs and such defined [18:37:21] I always have those open when I run a mission [18:38:19] Maybe categorize them on level of detail or something? Most detail would be stuff like the AOH [18:38:39] Leaved ICDs and other specifcation documents out of the equation, even I barely read those. [18:38:51] s/Leaved/Leaving [18:39:56] oh man speaking of ICDs and other specification documents, Marcel gave me a fascinating binder to scan that I'm going to start on tonight/tomorrow [18:40:22] it's an early (~1963ish) Grumman guidance development notebook [18:40:29] and has a huge section on AGS requirements and early design [18:40:43] including a big section on the "DEDU" :P [18:41:33] Back when assemblies were mere units lol [18:43:54] hehehe [18:47:17] N20E V40E. That needs a V06E before it. [18:47:42] When the checklist calls for it at PDI-6 you are at F 50 18. [18:49:19] not according to the LM timeline [18:50:24] "+54 N20E V40E 400+3 400R+0" [18:51:36] Oh you know what [18:51:48] I already proceeded out of V83 by accident [18:52:04] So I'm back at the P63 screen [18:52:16] ah [18:52:25] those procedures are quite weird, back and forth between verb and noun and you have to do it without deviating for it to make sense [18:52:43] What's OHW? [18:52:46] Outer ? ? [18:52:50] overhead window [18:52:54] overhead window [18:52:59] overhead window [18:53:06] overhead window [18:53:33] seems like we agree on something [18:53:47] hmm I am past the time it is supposed to burn and no burn [18:53:53] AGREED: overhead window [18:54:58] rcflyinghokie, 7:15h? [18:55:12] currently 7h20 [18:55:15] hmm [18:55:20] anything in the log [18:55:34] init complete [18:55:35] LoadState() called [18:55:40] oh no [18:55:40] thats it, for the last 20 minutes [18:55:48] LVDC already disabled itself lol [18:56:07] umm did I do something to do that? [18:56:08] probably at an too early time [18:56:14] nah, happens on its own [18:56:24] haha well then [18:56:29] /For now, disable LVDC at TB7+11,729 seconds [18:56:30] if (LVDC_TB_ETime > 11729.0) [18:56:31] { [18:56:31] LVDC_Stop = true; [18:56:32] return; [18:56:33] } [18:56:40] ah wait, that's TB7 [18:56:44] /For now, disable LVDC at TB8+10,000 seconds [18:56:45] if (LVDC_TB_ETime > 10000.0) [18:56:46] { [18:56:47] LVDC_Stop = true; [18:56:48] return; [18:56:48] } [18:56:59] so I am just beyond it [18:57:00] didn't want to run the LVDC for a whole mission [18:57:09] but that's probably early, yeah [18:57:14] should be changed [18:57:32] to the time when the earlier missions lost power [18:57:33] Well whenever the second APS burn is slated to complete should be a good time, correct?> [18:57:42] hmm, I guess [18:57:51] sometime between that and power loss [18:58:00] I think most IUs lost power at about 11h-13h GET [18:58:07] the last IUs had extra batteries [18:58:12] ran until lunar impact [18:59:06] so maybe 9 hours of TB8 time [18:59:08] 14's 2nd MCC was slated for approx 9:30 [18:59:11] so more like 30k instead of 10k [18:59:12] mission time [18:59:23] SIVB MCC [18:59:26] yeah [19:00:48] anything I can do to change that on the fly? [19:01:06] well it's now already been disabled [19:01:14] after that the LVDC can't recover [19:01:21] you could change the code and use a scenario from before [19:01:38] I have a scn before it disables [19:01:45] LVDC.cpp line 5653 [19:03:00] 30000? [19:03:51] //For now, disable LVDC at TB8+30,000 seconds to allow lunar impact burns [19:03:52] if (LVDC_TB_ETime > 30000.0) [19:03:53] { [19:03:53] LVDC_Stop = true; [19:03:54] return; [19:03:55] } [19:03:57] break; [19:04:00] yeah, sounds good [19:04:03] cool [19:04:14] that will give it "power" until nearly 13h GET [19:04:34] reasonable time when the LVDCs usually gave up [19:04:42] sounds good to me [19:05:01] Oh joy I just had a CTD [19:05:04] uh oh [19:05:21] And no message from Winblows allowing me to attach the debugger [19:05:46] I see what you did there [19:06:27] It may have happened while switching panels in the 2d cockpit [19:06:32] Not entirely sure [19:07:50] Hm I havent seen an issue with that in a very long time [19:16:25] Thymo, ah damn, I hate these undebuggable CTDs [19:17:06] rcflyinghokie, at TLI cutoff you have about 1.5 Gs. An overburn of 0.6 m/s already happens within 0.04 seconds [19:17:12] so surely this is some cutoff time delay [19:18:19] would this impact other IUs? [19:18:26] probably the same for all, yeah [19:19:08] could depend on unlucky timing [19:19:34] I have to revisit how cutoff is done in the LVDC, I believe it basically drops all tasks to do it on time [19:19:51] in your lvlog for example I see [19:19:51] T_CO = 9386.776020 [19:19:56] as the last calculated cutoff time [19:19:57] but then [19:20:02] SIVB VELOCITY CUTOFF! TMM = 9386.809995 [19:20:26] already a 0.03 seconds difference [19:20:33] ASC PRES on CWEA before PDI is fine right? [19:20:37] yes [19:20:41] for early LMs, yeah [19:20:48] it will be on until the ASC tanks are pressurized in early LMs [19:20:50] later they changed it so that light wouldn't be on all the time [19:21:04] APS is burning :) [19:21:05] Good [19:21:17] rcflyinghokie, yay, it didn't get broken haha [19:21:23] haha nope [19:21:27] My DES will be burning in 60 seconds [19:21:48] DPS ;) [19:21:57] Average G is on [19:22:01] DPS* [19:22:05] go for PDI [19:22:24] Ullage [19:22:34] pro [19:22:36] ignition [19:22:52] 10% [19:22:58] throttle up [19:23:10] make sure des eng cmd overide is on [19:23:17] It is [19:23:20] Per the checklist [19:23:24] haha good [19:24:40] "LPD ALT CHECK" Still flying. Not crahed. Checked? [19:25:21] I need to revisit that but I believe the altitude check is checking landmarks [19:25:36] which I think is when they discovered they were long [19:25:40] My dog ate my homework I don't know the landmarks [19:26:05] compared current altitude to the landmark below or something of that nature as a cross check [19:26:14] Master alarm [19:26:18] Lost the CSM [19:26:19] because at that time it was only PGNS altitude not landing radar [19:26:23] Ah yeah [19:26:37] RR to slew [19:27:06] Yeah, SLEW won't cause any problems. [19:27:20] Certainly don't want it on LGC to overload it right [19:27:49] indeed [19:28:08] ALT light is out [19:28:24] LM face up? [19:28:46] Yes. Yawing around made me lose the lock [19:28:48] check that N68 [19:29:03] and get that sweet LR data in there [19:29:38] -3297 feet [19:29:51] Gonna incorporate [19:30:40] PGNS and AGS look good [19:31:59] watch that DH decrease [19:32:17] throttle down right on time [19:32:29] I also like to put my tape on LR and compare it to the PGNS alt in the DSKY [19:32:34] watch them converge [19:33:33] rcflyinghokie, so how it should work, 60ms before cutoff, the LVDC does nothing anymore except trying to cut off on time. [19:33:38] They converged a while back [19:34:07] I can work on that as my side project from my side project... [19:34:19] P64 [19:34:33] indy91 sounds good [19:34:41] Also, any good way to see if my SIVB will impact? [19:34:49] Thymo, almost there! [19:36:07] rcflyinghokie, you could use the MPT. The Space Digitals display I was just using to determine the pericynthion can be used [19:36:43] in the CSM or over on the SIVB [19:36:46] How do I know my horizontal LPD angle designation? [19:37:04] It's not in N64 [19:37:07] doesn't matter, you just need to use the LM MPT and give it a S-IVB state vector [19:37:30] Thymo, you are pointing at where it will land [19:37:38] k [19:38:00] it will immediately yaw if you do LPD commands, to point you back where you will land [19:38:24] although the commands are done in the roll axis [19:39:31] I totally forgot to update AGS altitude lol [19:39:43] lol its ok [19:39:45] 9 percent fuel at 220 ft [19:39:53] you can always just do it at say 1000 [19:39:56] *100 [19:40:06] Or 0 [19:40:09] lol [19:40:30] If I abort I'll update it when I'm back at 2000 [19:40:39] indy91 havent played with the LM MPT yet, do I use the LM side of the VPS page as well? [19:40:45] yep [19:40:53] What are the ROD keys? [19:41:11] googles dutch keyboard [19:41:14] minus and equals [19:41:23] indy91: We use US like normal people [19:41:37] lol [19:41:44] It's either US Intl or US Intl plus euro key on 5 [19:41:50] people who don't have QWERTZ aren't even real [19:42:34] But can you do qwertyuiop by sliding your finger in a horizontal motion? I wouldn't think so. [19:42:52] I also don't try to break my keyboard [19:43:06] No need, it's broken by design [19:43:10] true [19:43:32] I wonder who came up with this Y/Z being exchanged nonsense [19:44:22] ok I have the LM side initialized with the SIVB [19:44:30] where am I looking for PC [19:44:31] Question [19:44:38] My x pointer doesn't do anything [19:44:56] switch it to low maybe? [19:45:02] It is [19:45:10] hmm it should [19:45:24] silly question, is the breaker in? [19:45:37] It worked earlier [19:45:38] what position is the mode select switch in? [19:45:39] and are you in LDG RDR/COMPUTER mode [19:45:57] ah if it worked earlier you were likely in RR mode [19:46:01] right, could still be in RR mode, the RATE/ERR MON [19:46:02] Both are in [19:46:32] MODE is LDG RDR [19:46:45] the mode select to the left of the CDR FDAI? [19:46:56] fixed it [19:47:08] quantity light. [19:47:17] I need to null rates. Bare with me [19:47:56] Shutdown! [19:48:09] aca out of detent [19:48:14] des eng cmd ovrd off [19:48:17] 413 [19:48:37] engine arm off [19:49:02] rcflyinghokie, actually, different display [19:49:05] checkout monitor [19:49:15] There you can enter altitude = 0 [19:49:18] that gives you impact [19:49:33] MED code is [19:49:42] Why does it want me to switch to the CM? [19:50:06] to stop the LM SV update [19:50:19] I would guess that bu the checklist MFD is in the middle of P20 [19:50:41] so the CSM/LM is VERY hard to line up with the checklist MFD [19:51:15] Can't we make the MFD force the CM MFD into a checklist when you get to that step? [19:51:26] And return to where it was when you complete it? [19:52:01] I have no clue [19:52:31] but P20 shoudlnt be running [19:52:41] you should have done a V56 before leaving that procedure [19:53:05] then a V44 after touchdown [19:53:06] Unless the person making the scenario got lazy keeping the CSM up to date with the flight plan [19:53:28] yeah I cannot speak for that part :P [19:54:09] rcflyinghokie, on checkout monitor page: U02,LEM,ALT,0,20:0:0,MCT; [19:55:05] U02 = MED code for that page. LEM = to use LM MPT. ALT = to find the state at an altitude. 0 = altitude. 20:00:00 = random GET where it takes the state vector from the ephemeris. MCT = moon centered, true coordinate system [19:55:37] I hope that works [19:55:45] nope [19:55:54] nothing computes [19:55:56] Stay for T1. Thanks MCC :) [19:56:04] excellent! [19:56:18] ah damn. Can you check the online monitor for error messages? [19:57:04] 0.69 23.72 [19:57:06] lat long [19:57:22] indy91 https://www.dropbox.com/s/ojb7rz6lobwroh7/Screenshot%202021-08-02%20135704.png?dl=0 [19:57:25] sounds right [19:57:27] I redesignated a lot for funsies so it'll be off [19:57:39] uhh [19:57:46] I also landed on a crater. That's fne [19:57:53] a lot of the errors were me trying lol [19:57:59] but the last ones were with what you gave me [19:58:12] I see some LOI targeting errors [19:59:35] hmm [19:59:40] I think I need a scenario [19:59:57] did it show an error message on the checkout monitor page itself? [20:00:10] if it didn't find altitude = 0 it would say [20:00:11] "Error 10" [20:00:29] https://www.dropbox.com/s/jvwd1wukmng28hv/Apollo%2014%20-%20Launch%200009%200001%200014%200003.scn?dl=0 [20:01:30] it's fairly easy to break something in the RTCC. If I change 1 thing 5 other things could break... [20:02:06] and you use the S-IVB name to get the SV for the MPT? [20:03:17] yes [20:05:54] it doesn't even let me get a new state vector, what is going on... [20:06:27] ah some calculation was running and failing [20:06:29] nice code [20:06:44] yeah me either [20:08:51] hmm, I think the S-IVB isn't even entering the lunar SOI [20:09:22] nah, some calculation seems broken [20:10:17] uh oh [20:11:03] have to check, maybe it doesn't like the LM MPT [20:12:55] and that's why the MPT isn't in the RTCC MFD manual yet, very experimental [20:13:03] understood haha [20:13:11] oh well I will check on the SIVB later :) [20:14:53] when I debug it works of course [20:18:21] figures [20:23:07] ok it seems buggy, but I think I found the impact [20:23:14] because it does impact [20:23:31] have to check why the space digitals display couldn't find the switch to the lunar SOI [20:23:49] glad I could find bugs today :P [20:24:33] https://i.imgur.com/B5vlpRM.png [20:24:41] look at the 2nd column [20:24:48] V = inertial velocity [20:24:54] PTH = flight path angle [20:25:02] then azimuth, latitude, longitude, height [20:25:16] upper left has the GET of impact, 82:54:33 [20:26:16] actual planned was 83:07:46 [20:26:20] not bad [20:27:27] it stops building the ephemeris when it impacts the Moon [20:27:48] so some of the issues weren't bugs at least, it just didn't have any state vectors from after that time [20:28:24] ah [20:28:29] there seem to be reference switch difficulties. That U02 input I gave you, it works with 80h GET [20:28:31] but not 20h [20:28:39] shouldn't make a difference, but it does [20:29:39] Guys. Smithsonian has a CAD model of the CM hatch [20:29:41] https://3d.si.edu/object/3d/hatch-crew-apollo-11-cad-model:936d1822-b237-4431-bb3f-a1f9d39a2e90 [20:29:51] It's CC-0. Public domain. [20:29:57] and the whole CM I think [20:30:07] they also have some switches or so [20:30:15] Is this importable to the VC? [20:30:33] no idea [20:34:14] ooooo that would be a bit of an upgrade if it works [20:34:29] bug 1 has been found [20:35:14] I don't really know CAD stuff. Can you just willy nilly convert stuff to Orbiter meshes? [20:36:28] I would imagine it could be imported into Blender and then theres a Orbiter mesh export plugin [20:42:11] actually, it looks like theres a native blender format download [20:50:50] woah, a pretty fundamental RTCC function is having a problem. Must be a super rare bug [20:51:18] uh oh [20:57:17] close to parabolic, but not quite in the tolerance where it uses parabolic calculations [20:57:21] maybe that is the issue [21:08:56] so I am still looking at this burn, do I need to tweak the REVs to make DOI dvz zero for this MCC? [21:09:53] all I have done is the option 4 and I adjusted the LOI time [21:16:43] the REVs should already be adjusted so that it at least gives a small DVZ [21:17:48] also, I have quite a difference between option 4 and 1 for MCC4 [21:18:22] https://www.dropbox.com/s/q0lzzs4j91g302w/Screenshot%202021-08-02%20151804.png?dl=0 [21:22:55] https://www.dropbox.com/s/zk7rh8297t4qv9r/Apollo%2014%20-%20MCC%20Computation.scn?dl=0 [21:22:57] what's that mode 1 calculated with [21:22:58] if it helps [21:23:05] what do you mean [21:23:17] did you move the MCC-2 data to SFP table 2? [21:23:30] and then choose table 2 as the source for the MCC-4 calculation? [21:23:42] That I did not [21:23:51] I guess I thought that was only 12 [21:23:56] always [21:24:10] this mode 1 will have used the prelaunch nodal target [21:24:19] from table 1 [21:24:22] so I need to recalculate MCC-2 in here [21:24:58] so you are already past MCC-2 now? [21:25:45] no [21:25:49] oh ok [21:25:55] still a few hours out [21:25:57] then just recalculate it [21:26:13] so this is using the MPT with MCC-2 on it? [21:26:33] yes [21:26:48] yeah, so get rid of that MCC-2, then recalculate it [21:27:34] and then on the midcourse tradeoff display use the F30 button [21:28:17] F30,1 [21:28:26] yep, if you have MCC-2 in column 1 there [21:28:30] and then when you want to calculate MCC-4, using the nodal targets from MCC-2, you need to choose table 2 [21:28:31] yep [21:28:36] ok [21:28:59] "1 (Preflight)" = large DV [21:29:06] "2 (Nominal Targets)" = small DV [21:29:07] haha [21:29:24] you want 2 [21:29:43] 0.1 dv [21:30:27] LOI time still good [21:30:37] great [21:30:38] Hp 59.916 [21:30:53] do you know what exactly the nodal target is? [21:31:07] In general or in this case [21:31:11] in general [21:31:56] kind of? A specific node where the spacecraft needs to cross haha yeah super general [21:32:15] yeah, the point in space that gets targeted by the Mode 1 [21:32:18] and time, too [21:32:33] where the incoming trajectory and desired lunar orbit intersect [21:32:46] in the old version the page directly displayed all those numbers for mode 1 [21:33:02] but now it needs more initial guesses than just those, so it's a bit hidden away in the skeleton flight plan table [21:33:32] I tried to make it at least a bit better by adding "Preflight" and "Nominal Targets" [21:33:37] and not just 1 or 2 [21:33:50] but I think it needs to be more obvious what the mode 1 will target [21:35:28] Ah I see what you mean in there [21:35:33] very rarely will you want to use the preflight nodal target [21:35:46] for mode 1 [21:36:00] always better to re-optimize the mission with modes 2-5 [21:36:05] makes sense [21:36:34] So I am going to go ahead and compute the LOI and DOI burns now as well to see what happens (and to practice) [21:36:41] right [21:36:50] the initialization parameters should be ok? [21:37:31] for LOI? [21:38:05] yeah [21:39:22] yeah, you won't change those very often [21:39:51] well [21:39:52] and for LOI2, I am using the LM maneuver seq? [21:39:55] REVS1 etc are there [21:40:04] yeah I havent touched those this mission [21:40:33] DOI as LOI-2 gets calculated like a normal DOI yeah [21:42:40] DOI DVz 4.3 [21:43:08] https://www.dropbox.com/s/c2se1q4s15vcfx8/Screenshot%202021-08-02%20154211.png?dl=0 [21:43:10] can't complain about that [21:43:30] nice and full MPT [21:44:00] I think that will get me where I want to be haha [21:44:14] yeah [21:44:18] what kind of DOI DVz values would I want to adjust REV1 for? [21:44:26] hmm [21:44:51] maybe 10 ft/s [21:45:00] but if it's a bit above I still wouldn't really bother [21:45:15] ok [21:45:39] and there is not that much you can do after MCC-2 [21:45:40] so if I want to burn this MCC2, what is the best way to do it now, deactivate MPT and go back to maneuver targeting? [21:47:16] you would have to use the detailed maneuver table instead of the Maneuver PAD [21:47:36] I still need to add a good method for calculating the Maneuver PAD with MPT data [21:47:41] wouldn't really be too difficult [21:47:57] and you can uplink the P30 data from the MPT [21:48:01] ok [21:48:19] I will give that a whirl [21:49:10] sounds good [21:49:18] and I know some RTCC and LVDC fixes I have to do [21:49:28] good night! [21:49:36] night! [21:52:48] Same for me. Good night! [08:14:03] Morning! [11:15:22] morning [11:15:47] what's up [12:36:43] Working [12:37:30] Spend all morning and yesterday afternoon walking someone through setting up a new hypervisor and build chain [13:05:46] hey [13:08:11] hey [13:09:50] decided to practice my landings last night [13:09:54] https://media.discordapp.net/attachments/809545464331370506/871963088511983686/unknown.png [13:12:03] something fell off [13:13:32] Generally you try to point the flamey bit at the thing you want to move away from not the other way around. [13:14:39] tell us the story how this happened :D [13:17:27] looks like an attempted abort about 1 second before impact, with a decent vertical rate [13:17:58] yep, and abort stage, in att hold [13:19:10] the ascent stage just flipped and landed on its head [13:20:29] So do this prove the AGS is capable of landing the LM or nah? [13:20:41] Any landing you walk away from... [13:21:06] I mean, as long as the door still opens... [13:21:13] long walk home tho [13:21:27] Do they have shovels? [13:32:14] it flipped before impacting? [13:32:43] yes, when I pressed abort stage [13:32:55] under PGNS control or AGS control [13:33:43] pgns [13:34:13] and it immediately switched to P71? [13:34:52] I mean, since the CoG update the ascent stage really likes to flip because of the offset thrust vector, but normally the RCS should prevent it [13:37:15] yes, P71. did I need to be in auto for that to work? [13:37:47] did you do V77 at some point? [13:37:51] back in a bit [13:37:55] yes [13:44:51] I also had a massive angular rate at the time [14:19:48] I bet [14:22:53] the APS tends to do that when the RCS doesn't fight back [14:32:19] Done with work. NASSP time. :D [14:36:54] amateur, I am working and flying NASSP [14:36:56] ;) [14:37:17] PTC/sleep periods make for productive work periods [14:37:27] Landings don't [14:39:45] I'm using the external MFD for checklists and flying in the VC with TrackIR. This is pretty nice. [14:41:17] The buttons don't work when in the AOT view. Might need to add those. It centers you view so that you can easily work them all without switching [14:52:48] somehow I dont think my employer would let me download Orbiter, or i definitely would [14:55:09] Where can I find the procedures in case of an aborted PDI? [14:55:18] They're not included in the AOH we have [14:57:22] for detailed procedures there is a Rendezvous Procedures document for each mission [14:57:26] which mission? [14:57:34] 11 [14:57:57] I had to abort PDI after like five seconds because my throttle immediately went to 100% on start [14:58:27] So I hit engine stop. What would be done next to make sure I don't crash. [14:58:35] Abort on AGS? [14:58:37] interesting scenario [14:59:19] you could press the abort button, even that early [14:59:30] that would set you up for a rendezvous [14:59:59] Right. Would there be an option to slip PDI by one orbit since it was so early? [15:00:36] I suppose have MSFN verify my orbit, go to P00H and maybe do an update of the AGC? [15:01:36] good question [15:01:50] sounds too risky really [15:01:55] but there might be a mission rule [15:02:50] Never mind I guess https://puu.sh/I1cB6/10bebca3fd.jpg [15:03:54] ah fun [15:06:00] I never know if this is an Orbiter problem, a DX9 Client problem or a NASSP problem... [15:06:44] "failure of the DPS to throttle" is one of the abort criteria [15:06:57] Okay. I did have a quicksave. I switched to AGS, let it orient and pressed abort. The engine didn't even fire. I guess orbit is fine [15:07:00] so even if the burn was super short you probably want to press abort or abort stage [15:07:29] I think it wants an ullage burn [15:07:42] but that is strange [15:08:04] Ullage should reset if I stop the engine [15:08:08] Hold on [15:08:12] There's an adress for that [15:08:31] yeah, I remember something about this [15:08:46] Mike had some issue and it turned out to be something significant [15:09:10] but I think it was a bug with AGS memory which has been fixed [15:09:50] https://github.com/orbiternassp/NASSP/commit/fe155c21597ac133a13cd4a6d670c415b110b9a0#diff-90a663161049da0511978fc49890205183339ab5d6da67d4a8764c714b7aad45 [15:10:07] this bug reset the ullage counter to what's in the FP binary [15:10:14] but that has been fixed [15:10:31] ullage is 0 [15:10:32] yeah you need to set the ullage address to zero before PDI [15:10:37] It was [15:10:45] DPS armed? [15:11:52] maybe you had disabled the DPS already [15:12:23] 400+1 and 410+0 selected? [15:13:18] yes yes [15:13:28] Abort stage did fire APS weirdly enough [15:13:40] In PGNS or AGS [15:13:44] AGS [15:14:13] Probably need a scn to replicate and investigate [15:14:50] https://puu.sh/I1cJX/12ccd28f36.scn [15:14:55] This is after I shut down the engine [15:15:18] I flip guid cont to AGS. Wait for it to get to its attitude and hit abort [15:17:05] AGS abort on APS works [15:17:36] I think you have the engine stop button pressed [15:19:14] yeah, when I press that again it works [15:19:18] D'oh [15:20:02] Yeah that's it [15:20:04] how that gets overriden for the APS though [15:20:12] engine control electronics are weird [15:24:10] I didnt pull up the scn, what was the issue?> [15:24:21] Engine stop was still pushed [15:24:46] ohh haha [15:24:47] Now the question is why my throttle was fucked lol [15:25:04] I enabled it in the PA configurator [15:25:09] do you have a joystick connected? [15:25:23] Yes. But I don't know why it reads as full throttle. [15:25:43] It's set at ID 0 [15:25:46] maybe you need to move it once so that it recognizes the throttle position [15:26:03] It might be the wrong axis [15:26:08] that's an issue I had not only in NASSP [15:26:09] I have like 8 [15:26:25] yeah that was my problem with sticks, too many devices and too many axes [15:26:51] I wanted to try VESIM but it's a bit obscure to set up [15:27:24] I got it working [15:27:43] its a bit better now but still a bit unintuitive right now [15:27:56] https://www.overclockersclub.com/siteimages/articles/saitek_x52_joystick/11.jpg [15:28:04] It's that linear thumb slider [15:28:12] That's what it was set to lol [15:28:28] indy91, are the computations for DVC changed with the SPS thrust changes? [15:28:32] yes [15:28:34] Orbiter reads it inverted [15:28:52] My MCC2 I had -4.5 on the EMS after the burn [15:29:02] that sounds right [15:29:04] ok [15:29:08] it should read 0 at cutoff [15:29:18] ok cool [15:29:22] for the SCS [15:29:30] so that it cuts off the burn correctly [15:29:40] and my MCC4 here is a 3.1 fps burn, dvc is 0.2 [15:29:49] SPS too? [15:29:52] yes [15:30:03] short burns are still a bit of a problem [15:31:23] and that burn is extremely short [15:31:27] yeah [15:31:34] very close to the 0.5 seconds mark where you would use the RCS instead [15:31:54] yeah the actual MCC4 for 14 was 3.5 [15:31:58] so certainly on the cusp [15:32:46] uhh wait a minute [15:32:57] the -4.5 was in the EMS after the burn [15:33:02] after MCC2 [15:33:03] but the 0.2 ft/s was on the PAD? [15:33:05] I just got that confused [15:33:07] .2 is MCC4 [15:33:13] right [15:33:18] but is that the EMS value [15:33:21] on the PAD [15:33:24] or after the burn [15:33:38] -4.5 was the EMS reading after the MCC2 burn [15:33:43] 0.2 is the DVC for MCC4 [15:33:52] pad value [15:33:55] aaaah ok [15:34:03] I thought that was your EMS reading after MCC4 [15:34:07] haha no no [15:34:10] that sounds about right then [15:34:17] I will let you know what it is after MCC4 shortly though [15:34:41] Apollo 14 also had 0.2 ft/s DVC for the actual MCC-4 [15:35:13] make sure to only use one bank [15:35:22] for the SPS [15:36:13] that agrees fairly closely with the AGC short burn logic [15:36:25] using both gives you an overburn [15:36:55] will do [15:38:20] if the DVC value was exactly right you would get 0.2 - 3.1 = -2.9 on the EMS [15:38:43] sounds about right, but these very short burns will always have a bit of residuals [15:39:31] total tailoff impulse will be smaller because the cutoff has already been commanded before the thrust has even started [15:41:34] so that part of the delay in cutting off the engine isn't full thrust like with a longer burn [15:41:41] ah that makes sense [15:46:01] -2.9 [15:46:03] EMS [15:46:42] I should play the lottery [15:46:56] N85 +00000 +00002 +00000 [15:48:05] neither the AGC nor Orbiter with its finite frame rate would be 100% able to get the timing this good, so it is a bit lucky, not me implementing it super accurately. But I'll take it :D [15:48:24] haha absolutely [15:58:13] after the larger MCC2 these numbers are very very close to the flight plan [15:59:11] and I have a good what is causing that [15:59:25] working on it right now [16:00:41] ah the TLI thing? [16:00:44] yep [16:00:50] two things delaying the cutoff [16:00:57] only by 0.04 seconds [16:01:01] but that's enough [16:01:06] and the LVDC is more precise than that [16:09:52] I'd like to check the LVDC listing if the LVDC really puts itself into a state where it does nothing but check the time for cutoff and run minor loops. But of course I can't. [16:10:37] there is also a 20ms delay that cutoff after launch doesn't have, so I need to account for that as well [16:10:56] some weird difference in issuing the cutoff command for S-IVB first vs. second burn [16:11:58] morning! [16:12:00] hey [16:12:57] that problem I had yesterday with the RTCC was in a function equivalent to the Kepler routine in the AGC. It was a very special state vector that caused very special problems. But the AGC routines can handle it, I checked. [16:13:25] RTCC routines can handle it, too, but I wasn't using that. But some very old code I got from a text book instead. [16:17:36] but it was fun seeing how the AGC solve the problem of this really not wanting to converge [16:17:43] solves* [16:21:22] oh man [16:21:35] that's really interesting haha [16:21:58] never gets old when flight plan angles all work [16:22:16] moon in the hatch and HGA angles facing earth [16:26:06] is the landing site REFSMMAT time supposed to be touchdown? [16:29:09] the defining time of the LS REFSMMAT is the time of landing, if that is the question [16:29:28] a more precise time is used later when that REFSMMAT gets updated on PDI day [16:29:46] but that REFSMMAT update tends to be small [16:30:12] ok so I should use the default now before LOI and update it with the TLAND on PDI day? [16:31:04] yeah, well, the DOI calculations comes up with a new TLAND, too [16:31:20] ok [16:31:27] that will probably be the major update of that time [16:33:13] I think that happens automatically [16:33:55] yeah, haha, we saw that. When you use the wrong number of revs in the DOI calculation it comes up with a wrong TLAND [16:34:07] and when you uplink that P63 has a long while to iterate... [16:34:24] thats right [16:35:25] which is a feature of the RTCC MFD only. In the real RTCC the TLAND for the uplink is always a manual input, not automatically taken from some table. [16:37:20] but GUIDO would know that number from the descent planning display and command that number to be used [16:38:00] and same for the LS REFSMMAT calculation using the same time [16:38:06] also, did they pulse torque when switching to and from PTC REFSMMATS? [16:38:17] just seems like a very lengthy wait for it [16:39:49] no idea [16:40:41] I have the feeling long pulse torquing isn't as accurate for our IMU as in reality. I think I got some larger torquing angles at the end of the P52 [16:43:59] I get small ones with a coarse as it is haha [16:44:26] yeah, if the attitude rate is 0 then coarse align is perfect [17:13:16] Ok LOI time [17:21:16] indy91 https://www.orbiter-forum.com/threads/apollo-8-run-ruined-or-not.40055/ [17:21:25] I pulled the scn looks like MCC is hung? [17:22:38] hmm [17:28:12] the MCC-2 was really bad and is not recoverable I think [17:29:10] -600NM pericynthion [17:29:20] and like 10 hours too early [17:29:54] how did MCC2 get a dv that high I wonder [17:31:53] no idea [17:45:00] he posted some earlier scns [17:46:27] those should help [17:46:48] post LOI EMS -6.0 [17:47:28] N86 -00004 -00000 -00001 [17:47:42] R3 + not - but still [17:47:52] SPS is looking good [17:47:54] looks normal [17:48:53] his MCC-1 would be 3.8 ft/s [17:49:02] guess that's why it was scrubbed [17:49:57] that MCC 2 though lol [17:50:45] maybe it's a problem with the SFP tables like we talked about yesterday [17:50:58] the MCC always calculates MCC-1 and saves the data in SFP 2. [17:51:05] MCC-2 then uses that table 2 [17:52:03] oh no [17:52:13] it doesn't do that transfer if MCC-1 is scrubbed [17:52:22] so MCC-2 was calculated with an empty SFP table [17:53:06] that's probably what happened [17:53:22] ahhh [17:54:01] Well wait though [17:54:34] what about say 12 or 14 where MCC1 is scrubbed [17:54:44] And MCC2 is used in the SFP [17:55:04] Is it because the targeting option is different for 8? [17:55:05] pretty sure they still updated the table 2 on Apollo 13 [17:55:42] well [17:56:07] for MCC-2 it doesn't really matter if you use table 1, preflight [17:56:15] or a table 2 updated with scrubbed MCC-1 data [17:57:00] it does matter though if MCC-1 was done [17:57:21] then MCC-2 should be calculated with table 2 from MCC-1, even if it's just for the better initial guesses of some values [17:57:54] so maybe to fix it I should make it check if there is anything in table 2 [17:58:00] if yes use that [17:58:03] if not use table 1 [17:59:03] table one is the prelaunch target? [17:59:06] yeah [17:59:31] they did already save something in table 2 on Apolo 11 before TLI [17:59:39] I remember that from the FIDO audio [18:00:15] ah interesting [18:00:24] 8's trajectory was almost the same right? [18:00:43] also, SIVB impact 82:58 haha [18:00:55] 9 minutes early compared to the FP [18:00:57] not bad [18:01:38] RTCC was predicting 82:54:33, I wonder what made the difference [18:05:35] time accel maybe [18:05:51] also I couldnt tell if it was impacted yet it just stopped moving at 82:58 [18:05:57] so it very well could have hit on schedule [18:06:15] I just didnt check until about 82:57 [18:08:21] ah ok [18:10:22] lol [18:10:24] "//For the MCC-1 evaluation store new targeting data, so even if we skip MCC-1 and MCC-2 these numbers are generated" [18:10:29] this is from Apollo 10 [18:10:37] so I had already fixed this exact bug for Apollo 10 :D [18:10:49] haha [18:10:56] 11, too [18:11:01] but not 8 [18:11:23] Hmm I cannot delete my DOI from my MPT [18:11:43] history delete? [18:11:50] ah no, you aren't there yet [18:12:09] what maneuver number is DOI? [18:15:46] well now its the only one [18:15:55] so 1 [18:16:55] any error messages? [18:17:08] M62 has plenty of them potentially [18:19:02] maneuver does not exist [18:20:40] also how do I use P20 for orb rate? Trying to figure out the values [18:20:50] N78 and 79 [18:23:16] ah damn, that sounds like the MPT got desynced, display vs. number of maneuvers in table [18:23:38] look at the Apollo 15 flight plan, should have good numbers for P20 [18:25:01] option 5? [18:29:05] I dont see any option 2 numbers after LOI [18:29:22] yeah [18:29:28] I think option 2 is just PTC [18:29:34] option 5 is relative to some body [18:29:36] the Moon in this case [18:29:51] I don't know what exactly Apollo 14 tried to do [18:31:08] they used V79 [18:31:12] for just a rate [18:31:25] I think option 2 can do a rate in pitch or roll [18:33:03] but I need to change the V78 values [18:33:09] I dont quite understand those [18:33:38] ah [18:33:46] yeah N78 is basically a body relative attitude [18:34:11] in option 5 it means which part of the CSM gets pointed at the Moon [18:34:20] usually the SIM bay for Apollo 15+ [18:36:20] I guess we have to translate Apollo 14 number for use with Artemis [18:38:05] I'm not quite sure yet what that V79 option code is [18:38:15] R3 of N79 [18:39:28] AOH Volume 2 has V79 procedures [18:39:52] ah yes, option 1 is roll, 2 is pitch rate [18:39:54] and now my last save wont load haha [18:39:58] or no [18:40:13] let me see whats causing it [18:40:20] option 0 is PTC, anything else is orbrate [18:40:41] probably the MPT... [18:42:12] yeah that was my guess [18:43:52] related to why you couldn't delete the maneuver [18:44:09] if it at least saved the scenario correctly you might be able to delete the MPT from the scenario or so [18:44:15] if that is really the problem [18:45:38] nothing attaching it to VS either [18:45:46] just a crash on launch [18:46:08] I can check the scenario, to see if it's the MPT [18:46:15] sure [18:46:44] oh and I just pushed some RTCC fixes [18:46:56] and a fix that makes the LVDC cut off TLI 40ms earlier haha [18:47:00] https://www.dropbox.com/s/kfrmcz08k5g31jy/Apollo%2014%20-%20Crash%20on%20Launch.scn?dl=0 [18:47:15] ok cool I will also PR the LVCD change as well I forgot about that [18:48:09] hmm? Which change? [18:48:14] oh right [18:48:22] the time when it shuts itself off [18:48:24] yep [18:49:08] no maneuvers on the MPT in the scenario anymore [18:49:54] but it does of course the anchor vectors for the MPT saved, so a bunch of processing is done with that during scenario loading [18:50:04] have* [18:50:37] interesting [18:50:42] it's stuck loading for me [18:50:49] no crash, but doesn't load either haha [18:50:52] yeah thats what happened [18:51:04] if I tabbed out and back in I got the not responding message [18:51:15] probably the MPT [18:51:20] I'll check in debug mode [18:53:26] deleting the lines [18:53:26] RTCC_MPTCM_ANCHOR [18:53:28] and [18:53:33] RTCC_MPTLM_ANCHOR [18:53:41] might fix it, but I haven't tried that yet [18:54:37] yeah, during loading, the LM MPT state vector is the issue [18:54:55] oooh [18:55:04] that is probably below the surface [18:55:04] worked [18:55:17] oh because I had the SIVB in there? [18:55:19] or something like that :D [18:55:22] yeah [18:55:55] it probably can't create an ephemeris for it [18:58:23] I'll look for a bit where exactly that fails [19:01:07] can I delete an anchor vector? [19:18:00] and I gave up on the orb rate and did it manually haha [19:42:43] you just did the only way to delete an anchor vector haha [19:43:11] and I think the problem with the scenario loading was that the S-IVB got close to the core of the Moon [19:43:30] which is somewhat of a bug, the non-spherical gravity calculations don't work right below the surface [19:43:46] a similar RTCC routine sets the non-spherical gravity to 0 for that [19:44:36] So computing the DOI it comes out 6 minutes earlier than the flight plan [19:44:51] LOI time was 3 seconds off [19:45:04] yeah that's probably due to the shape of the orbit [19:45:11] is there anything I should be tweaking? or is that normal [19:45:16] and the lunar gravity that we don't simulate right in Orbiter [19:45:23] I think it's normal [19:45:27] not much you can do [19:45:52] ok [19:46:27] LOI TIG being on time is more important for later timing [19:46:42] DOI TIG is a function of geometry between two orbits [19:47:31] DOI being off in TIG will throw your mission a little bit off from the flight plan, but not too much I think [19:48:26] not as much as LOI being off would [19:49:09] yeah landing time is only 2 minutes different [19:50:05] so no complaints here [19:51:45] lol, that S-IVB state vector in your scenario had a perilune of 12km [19:51:47] in radius [19:51:49] not altitude [19:52:07] lol [19:52:47] I have a fix for it. And the function that even allows that will also get retired at some point [20:13:05] hmm well this landmark is totally obscured by the LM lol [20:13:16] Trying to P24 on Mosting A [20:15:13] ah here it comes [20:17:08] and there it is :) [20:23:56] ! [20:24:17] got that RTCC system parameters document I had requested from UHCL [20:24:23] sweet! [20:24:23] let's see if it is good... [20:27:43] oooooooooooo [20:27:47] yeah, it has the stuff I was expecting [20:27:54] is that good? haha [20:28:10] yeah really good [20:28:20] a little shorter than I was expecting, but it's Apollo 7 [20:28:23] no lunar stuff [20:28:29] 65 pages [20:28:34] :D [20:28:49] I was requesting it for the thrust parameters the RTCC uses [20:28:58] and I am seeing all of it [20:29:31] CG tables [20:29:55] hell yeah [20:30:38] "The follow reentry parameters should be taken from Internal Note 68-FM-26..." I don't like that if we don't have it :D [20:30:42] following* [20:32:04] some numbers for rendezvous [20:32:21] all in RTCC units, so Earth radii etc. [20:32:28] oooooh [20:32:33] S-IVB area data [20:32:41] the stuff I was struggling with in my drag branch [20:34:10] an blackout entry/exit polynomial for reentry [20:34:12] very intersting [20:34:47] station characterists for all the ground station, makes sense [20:35:19] https://archive.org/details/NARASWSelectedApolloBoxes/page/n69/mode/2up [20:35:41] not that it helps in the short term but that one is at least at NARA [20:36:48] I wonder how that differs from the RTCC Requirements for the Reentry Phase [20:38:22] probably some equations to simulate the reentry [20:38:33] that RTCC Requirements only really has stuff for the guidance [20:38:36] AGC and backup [20:39:01] archived NTRS doesn't have 68-FM-26 [20:39:38] only at NARA it seems [20:39:40] oh well [20:40:25] and then the system parameters document has some samples of other documents [20:40:31] "system parameters listing" [20:40:39] that one also has the value in octal [20:41:42] so all in all, really good [20:41:49] a lot of numbers to work through [20:42:00] and for the other missions this document might even be better [20:42:05] I think UHCL has them all [20:42:08] through ASTP [20:44:24] what I wanted from this was being able to replicate the RTCC thrust model, and that I can now do [20:48:02] :D [20:48:06] excellent news [20:48:12] poor UHCL doesn't know what they've done. lots more scanning ahead :D [20:51:36] in a limited capacity this also has numbers that are saved in RTCC data tables and not directly system parameters [20:51:56] if that applies to other missions they could have the full TLI guidance presettings [21:03:20] night! [13:58:13] hey [14:05:31] hey [14:06:36] Block I emulator was always stuck on scenario reloading. Turns out I had to fix some bad code by Ron, but now saving/loading seems to work. [14:06:51] nice [14:07:22] you're probably giving his code the most thorough test it's ever had [14:07:44] yeah, I doubt anyone has gotten into P01, P05 and P02 yet [14:08:13] gyrocompassing in P02 doesn't look all that good for some reason, it doesn't seem to stay at the same attitude [14:08:21] have to figure that out [14:08:32] I was trying to get to launch and see what happens [14:10:15] ah have to start from scratch anyway, didn't have CDU saving/loading implemented yet. Didn't get that far yet anyway [14:31:29] morning [14:33:31] I am waking up on PDI day for 14 thinking of how we could implement the abort failure [14:33:43] Some kind of random on and off code for the switch itself? [14:33:58] to simulate the solder ball [14:36:43] constantly applying the input bit should be easy [14:36:53] and that's all it was, right? No abort signal to the AGS [14:37:09] yeah it was the switch itserlf [14:37:16] itself* [14:37:37] so that should be simple to make on or off [14:37:59] I think it would be fun to play with that and have to do the workaround [14:38:19] maybe make a hidden click spot to "tap" the panel" [14:38:51] not the button I think [14:38:55] just one connection of it [14:39:00] the abort signal to the PGNS [14:39:01] but no the AGS [14:39:04] not* [14:39:19] that makes sense [14:39:47] so the easiest solution would be this [14:39:51] in lemswitches.cpp [14:39:57] LMAbortButton::SwitchTo [14:40:16] there is [14:40:17] lem->agc.SetInputChannelBit(030, AbortWithDescentStage, true); [14:40:21] and below it set to fals [14:40:24] false [14:40:36] just set it to true in both switch positions [14:41:14] I will play with that when I power up the LM [14:42:06] like this? [14:42:07] bool LMAbortButton::SwitchTo(int newState) [14:42:08] { [14:42:08] if (TwoPositionSwitch::SwitchTo(newState)) [14:42:09] { [14:42:09] Sclick.play(); [14:42:10] //AbortWithDescentStage gets inverted in ApolloGuidance::SetInputChannelBit [14:42:11] if (state == 0) { [14:42:13] lem->agc.SetInputChannelBit(030, AbortWithDescentStage, true); [14:42:15] lem->aea.SetInputPortBit(IO_2020, AGSAbortDiscrete, false); [14:42:17] } [14:42:19] else if (state == 1) { [14:42:21] lem->agc.SetInputChannelBit(030, AbortWithDescentStage, true); [14:42:25] lem->aea.SetInputPortBit(IO_2020, AGSAbortDiscrete, true); [14:42:27] } [14:42:29] return true; [14:42:31] } [14:42:33] return false; [14:44:05] maybe tie this into our "failure" system? [14:48:00] yeah, just that one false changed to a true [14:56:56] I will see what happens :) [14:57:09] Also, my TLAND should have updated after I did my DOI calculation, correct? [14:57:48] looks like it did [14:57:59] yeah I think so [14:58:03] good to be uploaded I guess [14:58:13] just check that's on the correct revolution ;) [15:00:34] time on the REFSMMAT page should be TLAND, correct? [15:02:41] yeah, I think for the LS REFSMMAT it uses that number [15:03:38] ok it is close to the FP touchdown time so I think the REV is good [15:04:43] does the RTCC CMC update liftoff time not work [15:08:36] also, any idea what "REFSMMAT 00 time" is? [15:10:20] doesn't work yet, but PAMFD has that option [15:10:47] maybe that time is even TLAND? [15:11:59] liftoff time is lunar liftoff in this context, correct? [15:12:20] or is it earth [15:12:26] I think "REFSMMAT 00 time" is simply the TLAND used in calculating the LS REFSMMAT [15:12:32] ah [15:12:40] maybe for the case you need to recover it with P52 option 4 [15:12:51] makes sense [15:12:58] theres a spot to write it in the flight plan [15:13:01] "CMC liftoff time update" is TEPHEM [15:13:04] the launch time [15:13:07] oh ok [15:13:11] that should be good then [15:13:12] CMC has no TLAND [15:13:45] if I did want to update my TEPHEM where would I go [15:21:28] PAMFD uplink page has it I think [15:21:43] I only see clock [15:22:24] SV, sunburst items, clock, AEAA [15:22:38] maybe... [15:22:49] I did go to RTCC config and "update liftoff time" [15:23:09] right, that syncs the CMC/LGC with the RTCC [15:23:12] it changed by 0.01 seconds :P [15:23:14] yeah [15:23:22] that's downlink from AGC to RTCC [15:23:35] but doesn't touch the TEPHEM in the AGC [15:24:33] not that the difference is significant here, but if I wanted to fly 14 with a delayed liftoff I would like to know how to do it if possible [15:24:52] ask Alex :D [15:25:31] seems like the PAMFD doesn't have Verb 70 for the liftoff time increment [15:26:16] ok [15:26:55] I don't know how Alex did it then [15:27:46] but in the RTCC MFD that uplink type will get added [15:28:38] sounds good [15:29:01] just waiting for sunset to run a P52 with the new LS [15:29:09] then getting into the LM [15:55:49] morning! [15:56:05] good morning [16:02:55] what's up? [16:10:10] hey Mike [16:10:17] https://github.com/virtualagc/virtualagc/blob/master/yaAGCb1/executeOneInstruction.c#L533 [16:10:20] not good code :D [16:10:38] hahaha [16:11:39] I am saving/loading agc.countMCt [16:11:53] *countMCT [16:12:13] but with nextTimerIncrement being static and resetting to 1280 [16:12:26] it just locked up completely when I reloaded a scenario [16:12:40] when it didn't even increment the timers then I got suspicious :D [16:12:48] hehehe yeah makes sense [16:12:59] just moved that into the struct with AGC data [16:13:19] now I am debugging gyro torquing, might have the axes wrong [16:16:40] hmm looking at the LM suit ISOL valves, I am wondering if the actuator overide switch requires power [16:17:01] I know the pressure switch disconnect does but I think the switch itself forces to disconnect without [16:42:58] ok Mike, powering up the LGC in Antares ;) [16:46:41] rcflyinghokie, I wouldn't think so, but I am not sure [16:48:11] :D [16:51:05] hmm, when I try V42 I am only getting half the amount of gyro torquing I would expect [16:51:23] maybe that, too, is different in Block I... [16:52:28] interesting the activation cb chart has the RR stby heater turned off and the opr heater on alone [17:01:59] maybe saves some power [17:48:28] so I know I'm piling myself up on projects -- but I'm going to give reconstructing Luminary 1C another go over the next week [17:48:55] I had partly forgotten that that is another thing to research while at Don's, heh [17:49:25] I'm really hoping there will be some relevant info in Russ Larson's phone logs and notebooks [17:52:59] sounds easier than Skylark at least [17:55:03] hmm, this P05 gyro torquing doesn't make any sense yet sadly [17:55:21] but it might be using the PIPAs to find "up" [17:55:49] and if I got the coordinate conversion wrong for the IMU then it won't make any sense [18:20:13] at least I have gyro torquing working the same as Block II if I test V42 [18:21:25] have you tried any of the V57 IMU things? [18:22:22] not enough haha [18:22:28] hehehe [18:23:50] we had procedures for that, right? [18:24:01] I'm almost positive we do somewhere [18:24:22] I've looked at some at least [18:24:33] always have to find them again... [18:26:55] JDCs are probably the best bet [18:27:00] and luckily we have a handy index for those [18:29:13] I am finding some procedures, but definitely not for Solarium [18:29:32] V57 option 5 is a gyro torquing test [18:29:36] it has V21 N30 [18:32:23] nice gyro torquing test, starts with coarse aligning [18:36:30] I think I found the V57 option procedures [18:36:50] seems like a lengthy IRIG test [18:41:35] oh nice [18:53:25] hmm, what P02 does still not make any sense. Must be a problem with the PIPAs or the coordinate stuff with the Block I IMU [19:14:16] could the PIPA scaling be different? I feel like we lack documentation we that kind of thing is written... [19:14:22] where* [19:24:28] hmmm [19:26:48] hmmmmmmm [19:26:51] yeah where would that be [19:27:38] if I google the Block II scale factor and PIPA I find Block I documentation that also has the 5.85 cm/s number [19:29:42] so it's probably the same [19:33:54] ok pretty sure I got the IMU orientation wrong for Block I. IN the launch attitude there is still a lot of PIPA activity in the Z-axis, which shouldn't be [20:01:21] ah [20:02:12] Nope. Still not free. [20:11:55] Dropped and now registered to my name. Libera.Chat staff is so kind. :)