[17:17:01] NASSP Logging has been started by indy91 [17:17:03] they forgot the standard issue on soviet spaceflights, the survival gear for -30°C [17:28:45] AlexB_88 yeah thats the one thing I havent solved quite yet [17:29:26] With the changes to keep the LM stable with a crew on board, it can lose too much heat when not in the sun [17:47:44] Other than guess and check I haven't found a reliable method to tweak this [17:54:10] right [18:21:25] Is it possible to manually enter a REFSMMAT instead of getting it via P27? [18:24:59] the actual REFSMMAT? Sure, it's just an erasable location [18:25:20] but the normal procedure for entering such data manually would use P27, too, just no uplink [18:25:42] Ah ok just entering all the addresses via P27 [18:25:56] yeah, I think the uplink page shows all the octals [18:26:14] just V71 and then the octals [18:26:46] So start with V71? [18:27:18] let me check if the page shows everything you need [18:27:48] Ok [18:28:47] it does [18:29:08] so just V71 then 24 because that's the total numbers of values (in octal) you are entering [18:29:17] then 1735 or whatever the actual address is [18:29:47] uplink page in the RTCC MFD shows all you need [18:30:02] So V71 [18:30:12] V71E 24E and so on [18:30:20] 24 is the first octal the page "calculates" [18:30:57] So V71E 24E 306E etc [18:31:02] yep [18:31:03] going down the list [18:31:05] awesome [18:31:10] and after the last one, V33E [18:31:16] which is equivalent to PRO [18:31:50] what you can't do this way is convert a REFSMMAT from e.g. the SCOT to octal [18:31:58] I need to add that capability [18:32:03] they had a MED to do this [18:32:23] Ahh [18:32:24] pretty sure they pre-calculated the Apollo 11 PTC REFSMMAT and then manually entered it into the RTCC [18:32:35] Thats why the refsmmat page has one value and the uplink another [18:32:38] because the REFSMMAT type they had for it is MED [18:32:51] there is another difference [18:32:53] coordinate systems [18:33:01] the RTCC uses ecliptic coordinates internally [18:33:06] the REFSMMAT uses that, too [18:33:21] for uplink it gets converted to the Earth equatorial coordinate system [18:33:29] the basic reference coordinate system (BRCS) [18:33:34] so the SCOT values are what [18:33:45] already in the format as it should be uplinked [18:34:12] Oh the SCOT values are the uplinked values? [18:34:16] yes [18:34:29] that's exactly the REFSMMAT as it would be in the AGC [18:34:50] I think I'll add a place on the uplink page to enter a manual REFSMMAT there, from the SCOT or other places [18:34:53] converted to octal though [18:34:58] yeah [18:35:11] after the uplink you can then sync the RTCC with the DWN button on the REFSMMAT page [18:35:17] that button does a coordinate transformation [18:35:56] especially the later missions rather used the SCOT REFSMMAT than re-calculate it and invalidate flight plan angles [18:36:25] for PTC REFSMMAT but probably some others, too [18:37:22] hmm so trying to get this here... [18:37:55] Apollo 15 PTC REFSMMAT in the SCOT [18:38:24] If I wanted to enter that manually [18:38:37] you wait until I add that capability :D [18:38:56] I am just trying to figure out how these conversions work [18:39:06] there are only what, 9 values [18:39:13] yeah, 9 double precision values [18:39:15] so 18 words [18:39:52] for the AGC [18:40:26] So XIX would be 2 entries [18:40:32] yeah [18:40:36] 0.93969232 [18:41:07] 0.93969262* [18:41:11] there was also a generic uplink display with MEDs that could do any desired conversion [18:41:25] that would also help [18:41:39] need to add that, too [18:41:58] I guess I dont understand the double precision thing and how to generate 2 numbers [18:42:20] maybe with the help of a padload worksheet [18:43:29] use a Luminary one [18:43:46] Ah [18:43:50] it has not a complete REFSMMAT, but you can use one line for the 9 conversions [18:43:58] just look for REFSMMAT in it [18:44:12] and then copy your number in [18:44:29] where are they saved now [18:45:09] hidden :D [18:45:41] Thymo_ in our repo for the padload stuff, the "main" branch doesn't have the files yet I had added a long time ago [18:45:46] it's only in "develop" [18:45:55] rcflyinghokie, https://github.com/orbiternassp/padloads/tree/develop/Padload%20Worksheets [18:46:25] Ah [18:47:03] So what is +2 and +4 [18:47:18] just the 2nd and 3rd number [18:47:27] with double precision it's basically [18:47:30] REFSMMAT+0 [18:47:36] REFSMMAT+1 being the second word [18:47:53] so REFSMMAT+2 is the first word of the second double precision number [18:48:50] ah no wonder you asked me to wait lol [18:48:59] I dont have a great grasp on this conversion [18:49:14] indy91: Ah yes. I thought I had a reason for that but I can't think of any. If I don't remember today I'll merge it to master [18:49:50] well you can re-use the same converter in the padload worksheet [18:50:01] copy in your number, then read the two octals on the right [18:50:11] enter in P27, then next number [18:50:25] but I can definitely make it easier [18:50:27] so where does the 24 come into play [18:50:28] in the MFD [18:50:36] I see it goes to 24 under OID [18:50:39] that just tells P27 how many numbers you are entering [18:50:55] thought I was entering 18 [18:51:02] octal 24 is decimal 20 [18:51:10] Oh thats octal too duh [18:51:11] and I think it counts itself and the address [18:51:14] yeah [18:51:17] that makes sense [18:51:19] so 24, address, then 18 numbers [18:51:28] total 24 (octal) [18:51:37] REFSMMAT is the longest uplink type [18:51:42] state vector is shorter [18:52:10] state vector has 21 there [18:52:22] External DV update 12 [18:52:29] landing site update 21, too [18:52:31] and so on [18:53:42] got it [18:56:13] other than actually converting it all makes sense [18:58:28] thanks for the explanation [19:05:46] sure [19:06:01] I made it one step more complicated than necessary with the two coordinate systems :D [19:13:16] I'll start with the internal logic, which works like the G01 MED [19:13:25] for manual REFSMMAT input [19:13:49] you can enter all numbers in one go if you want to [19:14:08] G01,CSM,MED,Num1,Num2,Num3,Num4,Num5,Num6,Num7,Num8,Num9; [19:14:34] the internal logic is smart, it checks if the matrix is orthogonal to see if all numbers have already been entered [19:14:46] I guess you can also do [19:14:53] G01,CSM,MED,Num1; [19:14:55] and then [19:14:58] G01,CSM,MED,,Num2; [19:15:01] etc [19:15:15] but above that I can add a MFD page to make it easier [19:15:33] that is my current approach. Internally the MED logic, but not necessarily make the user have to go through that [19:19:55] yeah might be too much haha [21:33:46] ok, MED logic for it is implemented [21:34:16] the online monitor shows the REFSMMAT in ecliptic coordinates when it gets saved in the RTCC [21:34:26] but then on the uplink display it's like in the SCOT again [21:34:32] just fewer digits [21:35:27] maybe it should show more [21:43:25] I mean shouldnt it show how many were in the SCOT? [21:44:11] yeah, that probably makes sense [22:02:24] night! [14:20:03] good morning [14:21:05] hey [14:23:36] you need to type faster [14:23:44] at least you know the RTCC MFD better than me [14:28:22] hey guys [14:30:47] hey Matt [14:36:58] I am confused about Open Orbiter [14:37:09] Haha I think you just got on before me ;) [14:37:24] I don't think martins wants to be the github maintainer in the long term [14:37:37] that's about as much work and less fun than being the sole developer [14:37:50] so what is/will be the official version going forward [14:37:56] I see lots of ideas, but not very organized [14:38:08] Hmm that could be dangerous [14:46:42] morning! [14:47:17] hey Mike [14:47:26] very early! [14:47:53] time zones! [14:49:07] there are many of them [14:49:38] mountain time here! [14:50:16] I'm over to eastern time for a bit [14:52:06] been a while since I left my time zone haha [14:53:09] but there are a lot of countries in it [14:56:52] oh wow yeah [14:57:01] and you're more or less in the middle of it [14:59:02] indy91 if you get the chance to come to the states we all need to have a meetup I think [15:00:58] that would be fun [15:03:38] add some more US states to my list [15:03:44] I am up to... 4 [15:04:27] counting the 5 minutes I drove through South Carolina while going from NC to Georgia [15:07:50] I'm only at 3 European countries. [15:08:12] I am at 15/16 German states, but that is not so hard haha [15:08:24] I have never left North America :( [15:09:58] tiny Saarland at the French border, no reason to go there [15:09:59] I've been to all 16 counties in my state, granted it's a small one [15:11:23] I still have a lot to explore in my new state [15:12:29] hmm, my state has 37 Landkreise which would be the equivalent to counties. Never tried counting where I have all been haha [15:13:01] pretty sure I at least drove through most of them [15:13:52] Maine has a song...for some reason...about its counties. [15:14:30] hmm, why did the auto checklist fail to cause LV sep... must have pushed the button for too short of a time or so [15:15:23] That sounds likely [15:15:31] I think we fixed that hold on other checklists [15:18:29] ah yeah [15:18:35] "1H" will work [15:18:39] instead of "1" [15:19:20] yep [15:19:44] 7 is the only one I have not combed through haha [15:20:45] yeah, because I said I would be working on it [15:20:49] which I am finally doing [15:20:51] I know :P [15:21:10] Feel free to steal sub checklist tabs from other missions as well [15:27:03] yeah [15:27:08] Apollo 8 might be useful [15:27:50] but most of the generic checklists are already fine [15:28:59] I think some might need some tweaking so just double check haha, notably TurreyBoeing made some comments on his thread about possible errors as well [15:31:34] yeah, found some already [15:58:22] regarding OpenOrbiter, I agree that it's a bit of a mess. it needs a roadmap and a maintainer. we could obviously spin off our own fork, but theres no need to turn it into the mess that is linux distros [16:07:59] yeah I wouldnt be opposed to having a fork for NASSP [16:19:25] we have a pretty clear idea of what features we want/need. and I dont see those as having a downside for other devs/users [16:45:54] the gravity would be a simple change in theory [16:46:04] shape of the Earth... probably not [17:25:15] indy91, we have a long one about LM attitude control and rates, I'll defer to you :) [17:25:20] https://www.orbiter-forum.com/threads/a11-mcc-scenario-nassp-v8-rev-1756-general-checklist-items-questions-from-82h-to-98h-get.40233/#post-588966 [17:25:35] oh, fun [17:25:38] You have a better understanding of how it all works and its implementation [17:29:43] I'll answer it [22:02:06] Hey guys, I am alive :D [22:03:31] that's good to hear :D [22:06:18] I'm flying Apollo 7 [22:06:31] Realtime? [22:08:36] Tomorrow I will start preparing Apollo 8, will update to the latest NASSP release [22:08:47] definitely not real time :D [22:08:49] just fixing things [22:09:11] and flying it with realistic simulation of drag which needs a few tweaks [22:09:34] Yeah, I saw your posts [22:09:52] I want to send you and process the names for the 7´s quicksaves I took [22:10:06] Sometimes I pressed Control+S 5 times in a second xD [22:10:22] impressive [22:10:25] (I also do that when coding) [22:10:57] I have broken old scenarios with my MCC changes, so I don't think it's going to help me much :D [22:11:08] Oh [22:11:27] I mean "broken", would just need one number changed [22:11:36] Well, I share them anyway. After that I will update NASSP to start practising for Apollo 8 [22:11:46] sounds good [22:11:53] And By the way: Is the Apollo 9 EVA supported? [22:11:55] and I haven't broken anything yet, just locally [22:12:06] not really [22:12:29] at least you can't control an astronaut during the EVA [22:12:36] Many miles on the road left for that, right? [22:12:39] but you can do all the procedures of course [22:13:01] Procedures on the CM and LM, but not with the astro [22:13:07] yeah [22:13:22] I don't know actually. We have two old Visual Studio projects for EVA. [22:13:27] one for the lunar surface [22:13:30] which somewhat works [22:13:41] but also one for EVA in space [22:13:49] Aha [22:13:50] not it's definitely not working right now [22:15:11] but* [22:17:35] What is your GET on Apollo 7? Or you are just testing specific things? [22:18:25] I'm going through the whole mission, but not very far yet [22:18:30] at the first phasing maneuver [22:18:35] Aha [22:18:40] Just S-IVB sep [22:18:47] and t&D demo [22:19:16] yeah. I added the schedule for the manual S-IVB takeover test [22:19:26] the Checklist MFD didn't have anything for it yet [22:19:39] and the final flight plan differs from the preliminary one [22:20:02] but it's roughly the same, a bit of movement in each axis [22:20:21] Yeah, as I said on the debrief I prefer to start ChecklistMFD just prior to the S-IVB sep preps [22:20:27] By the way: [22:20:34] Uploaded file: https://uploads.kiwiirc.com/files/ff5f7376565d4a8f1bfbd26bcb293750/imagen.png [22:20:52] For after rendezvous, if succesfull, indy91 [22:21:18] looks good [22:21:55] or during [22:22:00] for increased difficulty [22:22:13] Don´t think as a good idea :S [22:22:57] I haven't failed an Apollo 7 rendezvous since 2014 [22:23:02] ... but I had bad ones [22:23:56] Prior to the P34´s and P35´s, wich I first did for this Apollo 7 run, i did it on 2013, with Rendezvous MFD [22:24:00] Big fail [22:24:19] Cannot remember what happened, but it didnñt work out [22:24:34] I think I screwed the first phasing maneuver on that 2013 run [22:25:01] oh yeah and there was no good way to set up the orbit prior to the P34 yet [22:25:02] *didn´t [22:41:08] night! [22:45:29] Leaving too guys. Night! [16:33:24] good morning [16:34:44] morning [17:09:54] is there any way to check TLAND and RLS in the LGC via the DSKY? [17:17:46] ah found it [17:20:10] morning! [17:21:00] hey Mike [17:25:10] indy91 is the RLS target for Apollo 15 in RTCC MFD supposed to be different from the padloaded RLS? [17:49:53] I didnt realize that Hadley scenery existed. now I need to fly 15. [17:55:02] uhh, maybe [17:55:33] LSLat 26.0739 [17:55:34] LSLng 3.6539 [17:55:35] LSRad 936.573520518 [17:56:39] that's the same as in the flight plan [17:59:40] and that's the same as in the padload document [18:00:33] and also the same as in our padload [18:00:38] so it's not different [18:01:17] but those are all different from the actual landing site, especially in radius [18:01:37] or rather, the RLS that was uplinked to the LM after P22 but before landing [18:50:12] Hmm [18:50:35] He is having the same issue I had though, after pitchover the LPD is targeting the rille [18:50:41] I had to N69 to avoid it [18:51:16] on your flight or in his scenario? [18:51:45] did you have the issue [18:52:45] I had it when I flew 15 [18:52:48] I don't think it's the RLS that would take you into the rille, must be another issue. The RLS, if not modified, should be fine [18:53:37] Using the RTCC RLS and the padloaded one, both flights took me to the rille, so I used a N69 to change that [18:53:58] So I am not sure whats going on, I need to find a scn and get his for comparison [18:54:07] it's a different issue surely, state vector, correction vector etc. [18:54:09] clock [18:54:13] could be many things [18:54:30] libration vector* [18:55:00] yeah I would like to look at a scenario where it happens [18:55:17] I posted asking for one and I will try to find one [18:56:09] I don't remember you mentioning it when you flew 15, but I was maybe busy with something else [18:56:34] so an auto landing would land in the rille? [18:59:00] the coordinates I wrote above are fine, I just put a DG there [18:59:03] far from the rille [18:59:36] on one of my first attempts I thought it was going to land in the rille, but that was just because the final descent trajectory is quite steep :D [18:59:38] Yeah the coordinates looked fine as well on google moon [18:59:54] I let autoland take me and I recall it going right in [19:00:07] I think we were talking about it as you sent me the targeting documentation [19:00:20] And I changed the RLS to the final uplinked RLS they received [19:00:25] ah [19:00:33] but that's mostly a change in radius [19:00:36] not lat/long [19:00:46] I don't think that could have made the difference [19:01:02] speaking of targeting, UHCL just never send you that one document, did they [19:02:21] I don't think the libration vector could be the cause of any such issue [19:02:47] the one in the launch scenario is too small for any problem caused by it [19:03:19] when our LGC used to have the bug that the clock was running slow (or fast?), I landed beyond the rille due to the clock being 3 seconds off [19:05:11] yep no replys back [19:05:15] they ghosted me [19:05:21] I even sent a few followups [19:05:37] very strange [19:05:41] indeed [19:05:59] UHCL Archives & Special Collections will be closed to onsite research and incoming donations from January 3 – March 1, 2022. [19:06:21] covid precaution? [19:06:57] yeah, but that sounds like they do all requests virtually now haha [19:07:31] but all can be none [19:07:35] lol [19:07:49] do you not have a pre PDI scenario from you Apollo 15 ready? [19:07:57] Are you one of these scenario deleters like Alex? :D [19:09:33] I have post TLI from you and then Lunar Liftoff Prep as the next one [19:11:51] No I have them, I just need to find which one was which (I didnt label 15's well) [19:12:04] Apollo 12 - Launch 0005 0010 0003 0005 0003 0003 0007 0005 0016 0002 0006 [19:12:30] .scn [19:12:44] yeah haha [19:13:03] For some reason on 15 I didnt change names until after landing lol [19:13:12] Normally I am good about renaming them [19:15:12] Hmm they are CTD [19:16:55] fun [19:17:15] was that the mission where the S-IVB impacting caused some MPT issues? [19:18:08] It may have been, but this is complaining about a boiler [19:18:13] ah [19:18:24] are you in your branch with the big CSM ECS update? [19:18:50] no [19:19:23] I can load the few Apollo 15 scenarios I have from you [19:21:22] While I wasnt in the branch I forgot to build lol [19:21:47] that could do it haha [19:22:00] haha yeah oops [19:25:12] Found some pre PDI, I just dont know if the RLS was updated or not on these saves [19:26:18] ah yeah I updated the landing site on these [19:26:43] https://www.dropbox.com/s/j6qwqy9z7xx8zca/Apollo%2015%20-%20PDI.scn?dl=0 [19:26:59] you can play with it uplinking the old RLS/TLAND and see what it does [19:27:04] Thats about PDI-7m [19:40:15] great, thanks [19:48:16] clock and SV seem fine [19:49:18] I changed the RLS to the padload [20:00:29] indy91: I fast forwarded the padload master branch to the last state of develop [20:02:09] ah great, thanks [20:05:07] rcflyinghokie, I landed where I normally landed, too [20:05:52] maybe 300 feet south of the Hadley marker [20:06:02] 300 meters* [20:08:55] hmm interesting [20:09:04] Hopefully we can get his scn as well [20:09:20] I remember it taking me to the rille [20:11:57] maybe you somehow got a bad RLS? [20:12:07] I can try again with the RLS that was actually in this scenario [20:12:24] Yeah i dont remember what exactly I did [20:12:36] or I can reconstruct which coordinates this has [20:13:06] the RTCC seems to have saved the padloaded one [20:13:08] in the scenario [20:16:28] basically no difference [20:19:42] odd I cannot recall what was causing it [20:20:02] But again, hopefully wedge's scn will help [20:27:01] you just wanted to explore the rille, admit it [20:27:22] Well it seemed like a good idea at the time... [20:27:43] valley practice for Apollo 17 [20:28:44] And one upping Apollo 12's pinpoint ;) [20:31:26] Apollo 18, landing ON a surveyor [20:31:53] Psh take that Pete Conrad [20:38:36] when it comes to debugging these kinds of problems, I think I need to implement a tool in the RTCC MFD that tells you how accurate the current IMU alignment is [20:42:52] that along with the SV? [20:46:14] yeah, I looked at the SV in the vector comparison display [20:46:49] I didn't look at the TEPHEM [20:50:56] Should be the same as the CMC [20:57:31] it is [20:57:43] but also always a potential error source for downrange issues [20:57:54] same as clock [21:06:50] you said TLAND looked ok? [21:08:58] I don't remember saying that, but as P63 ignition algorithm works and converges, it has to be good :D [21:10:17] Can't it converge even if TLAND is off? [21:11:53] it could converge on the next rev [21:12:02] but then TIG would be 2 hours off [21:13:40] I mean what if TLAND was say only a minute or two different [21:14:00] Say a minute late, couldnt it still converge but result in a later TIG? [21:14:14] And potentially a long landing? [21:17:20] nah, it starts with the TLAND and then calculates an initial guess for the TIG [21:17:32] that's the only thing TLAND is used for [21:17:46] and then it goes through the guidance equations and converges on the actual TIG [21:17:53] all in the ignition algorithm [21:17:55] Ah ok [21:18:02] So if it converges thats all that matters [21:18:09] yeah [21:18:12] *on that rev [21:18:14] after ignition actually happened it iterates on the time-to-go [21:18:22]