[15:17:20] NASSP Logging has been started by n7275 [15:17:22] hey guys [15:17:48] hey [15:18:32] morning [15:19:14] noticed something with 8 yesterday, 8's post insertion checklist has the pyro seq cbs pulled shortly after insertion but then does an EPS monitoring check. [15:19:26] If those breakers are out pyro bats dont read on the DC meter [15:23:03] huh. that's odd [15:23:51] our checklist or The checklist? [15:25:15] both [15:25:35] And if I am reading the schematics correctly, that is also the correct behavior lol [15:26:00] The 8 TLI checklist has 2 hand written arrows by that step but I have no idea why [15:28:47] Ahh [15:29:15] Found the clue, also hand written in the 8 CMP checklist they squeezed in closing those before the pyro volts check then opened again [15:31:54] okay. that makes sense then. [15:32:10] should probably add them to ours [15:33:11] I think I've discovered an issue with our Apollo 10 CSM REFSMAT [15:33:28] Yep adding it now to the EPS checklist in Apollo 8 [15:33:44] With the one MCC uplinks? [15:33:55] yes [15:35:19] Hmm whats up with it [15:35:47] in lunar orbit there are a number of instances where you orient to 000 092 000 with a HGA angle specified. this is in the final flightplan [15:36:17] that puts the HGA 180° away from the earth [15:37:09] rolling to 180 it locks on instantly [15:38:15] https://drive.google.com/file/d/13wdVrYdTmcDtboWpwhY45PvfM84CesHe/view?usp=sharing [15:39:32] did you check thr transcript for any changes? [15:39:48] havnt looked yet [15:40:18] ORDEAL is being weird too [15:40:48] it's going the wrong way... never had that happen before [15:42:13] do you have a retrograde REFSMMAT? [15:42:30] ORDEAL can only rotate one direction [15:42:54] Nik and I talked about this and it was an actual observation on 9 at least [15:43:57] didnt look into it much last night. was pretty late when I stopped. [15:44:23] can probably just uplink a new one [15:46:42] right but we need to figure out if the correct one was computed by MCC lol [15:46:50] Need Nik to look at it [15:57:58] here's something random: Apparently Jack Black's mother worked on the Abort Guidance System [15:58:17] Haha yes! [15:58:28] Fascinating stuff actually [15:58:56] https://en.wikipedia.org/wiki/Judith_Love_Cohen [16:00:28] its funny that popped up on my computer just as I was deep in AGS procedures study [16:01:03] did the AGS MCC procedure work for you? Changing the 373? [16:02:53] I ended up following the procedure in the G&N dictionary [16:03:27] 400+3, 307+02800, 410+time to TIG, 400+4 [16:04:10] ah the retarget [16:04:44] good dVs? [16:04:52] yeah [16:05:05] did V47s before each MCC [16:11:23] Ah didnt use radar marks or trust the AGS SV? :P [16:18:29] I was initially, but I want to get my understanding of how to operate all the AGS routines squared away, and I find doing the manual marks just gets in the way for now [16:19:26] I think I will try a full AGS ascent + rendezvous today [16:19:46] I will use PGNS just for the V47s [16:40:06] Haha awesome [16:40:23] I will say the AGS SV is good enough for a rendezvous [16:40:53] I did one simulating a primary glycol loop failure, so bye bye PGNS, ran the secondary glycol loop and AGS to a rendezvous [16:41:10] Just AGS and the RR [16:45:12] right [16:45:23] but I dont think that would fly in RL haha [16:45:45] our perfect ASA certainly helps [16:45:59] Haha yeah very true [16:46:06] Maybe with the RR marks it would work [16:46:13] Im sure it would [16:46:27] its just that you have to take a lot [16:46:43] Yeah it would be a 2 person job for sure [16:50:46] somewhere down the road it would be fun to add noise to all our perfect sensors. as an optional checkbox of course. [16:51:24] maybe a checkbox with a switch guard lol [16:53:51] Haha "are you sure?" button [16:55:50] Was P37 designed to be used in LEO? [16:58:13] morning! [16:59:50] And in the case of Apollo 9, was the block data designed for an SCS deorbit in a pinch or was it supposed to be used in P30/40 and or P37 [17:03:34] hey Mike [17:25:35] hey [17:25:53] I looked at the scenario, it looked correct. What am I missing? [17:27:51] rcflyinghokie, Apollo 8 checklists have the pyro CBs normally pulled. DC voltage/amperage check closes the CBs and the opens them again after the check [17:28:39] due to that handwritten note [17:32:23] hey Nik [17:33:09] so the flightplan says orient to 000 092 000 and gives HGA angles [17:33:46] in order for those angles to work though you'd have to be at 180 092 000 [17:34:15] have not looked at transcripts yet [17:34:27] indy91 yep confirmed that this morning haha and fixed the checklist to incorporate it [17:35:17] Also, regarding the P37 and Apollo 9's block data, was the block data for a SCS or G&N deorbit and was P37 utilized at all with block data (looking at the forum post question) [17:38:49] it could even be done without the GDC [17:38:59] 31.7° line on the horizon [17:39:10] so essentially SCS [17:39:29] and I think only NASSP ever used P37 in Earth orbit [17:39:39] in some old flight plans of ours [17:39:43] the Excel flight plan [17:39:51] Thats what i thought [17:42:56] n7275, I don't think there even is a REFSMMAT change [17:43:06] so I am confused why the flight plan angles don't work [17:43:39] did the angles work before the rendezvous? [17:48:13] if I calculate a LS REFSMMAT with the RTCC MFD then it's 180° rolled from what CMC currently has [17:49:11] that's what I expected but I dont see why [17:49:53] did you fly this mission from scratch? [17:49:59] Or is it based on a mission scenario [17:50:20] it could also be off in pitch by 180°, that would give the same effect [17:50:30] ORDEAL was always working? [17:50:53] so maybe you somehow got a LS REFSMMAT with a wrong landing time [17:50:59] yes from scratch [17:51:13] ORDEAL is moving backwards [17:52:15] I cant remember if I had this issue prior to rendezvous. I'll have to look back at old sceneriaos [17:52:28] so wrong? I don't even know what type of REFSMMAT this would be, the RTCC can't come up with this haha [17:52:35] I dont think so though [17:52:50] yeah, in theory this should be the same REFSMMAT as uplinked a lot earlier [17:53:46] hopefully I did something wrong and it's not a bug [17:54:09] at 94:30 [17:54:34] if you still have that same REFSMMAT it's a bug [18:00:48] yeah I am very confused by this REFSMMAT [18:00:54] it can't be a landing site one [18:01:18] even if the time tag is off exactly so that the LS is on the other side of the Moon it wouldn't be rolled wrong for the ORDEAL [18:01:23] same for a LVLH REFSMMAT [18:03:06] one possible solution [18:03:13] MCC uplinks REFSMMAT [18:03:24] you have a retrograde burn and load P40 after the uplink [18:03:29] overwriting the desired REFSMMAT [18:03:36] and then you do P52 option 1 [18:04:15] if it keeps the numbers from LOI-2 loaded maybe [18:04:29] then calling P40 by accident between uplink and P52 could cause this [18:07:02] hmm I'll have to look back at those earlier ones [18:08:06] is it odd that I was able to do P22 without issue? [18:08:24] nah, you have a valid alignment [18:08:35] just not the one you want at this point or one that the ORDEAL likes [18:08:55] ahh okay [18:09:46] I guess you didn't do P52 option 1 by accident when you wanted to do option 3 [18:09:53] that's a fairly obvious difference [18:10:24] so it probably was the last option 1 you did 30 hours earlier. Or not haha [18:10:33] You can check with the RTCC MFD [18:10:41] Utilities, REFSMMAT [18:10:49] let it calculate a landing site REFSMMAT [18:11:01] and then DWN to downlink the current one and compare the two [18:11:20] what I am seeing there is the 6th number switches between 0.99999 and -0.99999 [18:11:34] that's the main difference [18:11:43] hmm [18:13:24] ah yes, and the first number too [18:13:28] also close to 1 and switches sign [18:14:35] yeah uplinking a new one is pretty easy. was more concerned that MCC was missing an uplink or something [18:15:01] but it sounds like I messed it up after LOI-2 [18:17:01] oh that wasn't for uplinking a new one, but how you can find out when the REFSMMAT changed, if it changed since the uplink [18:17:48] I'm checking if the MCC uplinks the right one in the mission scenario [18:21:15] seems like it [18:21:35] but that is weird [18:21:52] did the docked alignment for the LM work? [18:22:00] it shouldn't with the wrong REFSMMAT [18:22:17] yeah the LM was fine. [18:22:19] after undocking the LM does a P52. [18:22:24] That had small errors? [18:22:36] correct [18:23:01] hmm, then the REFSMMAT must have somehow changed [18:23:15] That's what you have to check in your scenarios I guess, if/when that happened [18:23:54] during rendezvous the CMC also calls P40 as backup for LM maneuvers [18:24:22] if you would then do a P52 option 1 it could use that burn for the alignment [18:25:09] did the HGA angles in the sleep attitude work? [18:26:10] I think so [18:27:48] but there isn't a P52 option 1 at all between 94:30 and then, you would have noticed if you did one haha [18:28:23] or does the Checklist MFD have one by accident... [18:29:25] I suppose it's possible that I did option 1 if I hurried through it at some point, but I'm positive that the one before the landmark tracking was option 3 [18:29:45] very strange [18:29:54] I'm not seeing one in the Checklist MFD [18:29:59] next one is PTC REFSMMAT after TEI [18:30:08] makes sense [18:30:17] I'm sure we can track it down, just have to figure out when the REFSMMAT changed if it did [18:30:51] I'll dig through my hundreds of scenarios tonight and see if I can find it [18:34:04] EMEM1735 60031 [18:34:12] that is the first number of your current REFSMMAT [18:34:17] that should be fairly unique [18:34:36] if you don't find that in the scenario then it's not the same REFSMMAT as you currently have [18:35:01] the LM in that scenario seems to have a correct REFSMMAT just judging by the first number [18:43:12] looking at checklist MFD there is a preferred after the LLS2 REFSMMAT uplink, but the next one is 138:00 [18:43:23] The ones in between are option 3 [18:45:58] yeah [18:46:08] still scared to change REFSMMAT too often :D [18:46:17] not like later missions [18:52:46] haha yeah its amazing how conservative they were with that at first, but it makes sense [18:54:29] I think 8 changed REFSMMAT what, twice? [18:56:51] Launch -> LOI2 -> Entry [19:00:15] Yep [19:21:32] I'm quite happy with the CM aerodynamics, it seems to work correctly. Also a good indication, the 0.05g time is exactly right still [19:21:37] even in Earth orbit [19:22:26] the only thing I don't like is that it has to do the same interpolation for the coefficients twice [19:22:31] in each airfoil [19:23:10] it calculates the coefficients in the same axis-symmetrical coordinates [19:23:35] and then just differs in rotating them into the vertical or horizontal axis for Orbiter [19:24:34] I should be able to give it a test in a few days on my way back from the moon if you want [19:24:40] sure [19:25:44] I should be flying an Apollo 11 re-entry myself soon [19:28:29] one thing I also looked at was SetRotDrag, so how resistance against angular rates [19:28:38] I think Orbiter doesn't properly calculate this [19:28:58] in the literature, and in the CSM Data Book, the value given for this is a function of velocity [19:29:14] in Orbiter it is a function of dynamic pressure, so velocity squared [19:29:38] this is probably the reason why, even with a quite small resistance value, we can't really perform rolling reentries right now [19:29:48] because that rotation always gets stopped after a bit [19:30:00] in reality, at least in roll, it should be minimal [19:30:15] SSU actually has their SetRotDrag commented out, so they use 0 for that [19:30:27] no additional code for attitude rates in their airfoil either [19:30:47] so maybe I'll comment ours out as well, or at least set it to 0 for roll [19:31:08] as that value should be very small and Orbiter isn't calculating it correctly anyway [19:32:17] oh wait, commented out doesn't mean 0. I think the Orbiter code said 0.01 if you never call SetRotDrag. So small, but still there [19:34:24] can you set it to 0? [19:35:27] sure [19:35:47] Orbiter just has 0.01 as the default value [19:35:57] but if you call SetRotDrag it can be anything [19:37:52] you could make it proportional to 1/velocity [19:39:29] by changing the value on every timestep? [19:40:56] I think I'd rather set it to 0 or extremely small, I don't think it really contributes much in terms of dampening rates. But I should be careful I guess, could make things less stable [19:41:30] very small would probably be better [19:41:33] the CSM Data Book doesn't even give a value for roll, so maybe I'll just set that to 0 and leave the current number for pitch and yaw [19:42:34] as long as there aren't runaway oscillations we're fine [19:45:26] yeah in roll there is no problem as there aren't moments acting on it really [19:48:17] while I'm thinking of it. for mcc ground stations, do you see any issue with the most recent station in AOS being the "active transmitter"? [19:50:10] you mean for stuff like HGA pointing? [19:50:24] yeah [19:51:59] hmm, we could implement something like that I guess [19:52:22] but I feel like that should be something outside of the MCC vessel [19:52:37] in Apollo 12+ scenarios it doesn't exist until you open the RTCC MFD [19:53:37] maybe another vessel that gets added to all scenarios [19:53:42] for MSFN [19:53:55] and that would have a function to call to get the current station or something like that [19:54:39] The MCC is really meant for the automated ground calculations, I don't like the idea of it being required for actual system simulations like the HGA [19:54:49] but some code similar to it, sure [19:57:02] yeah I think some of the functionality of our MCC should be in all scenarios, but the parts that automate calculations should be separated eventually [19:58:15] yeah. dseagrav implemented that AOS/LOS stuff in the MCC. The real thing this was based on is RTCC calculations using the MPT and the CSM/LM ephemeris which generates these AOS/LOS times [19:58:24] and sends data to each ground station when it has AOS and LOS [19:58:55] so if the MPT and ephemeris ever become standard and integral parts of how our RTCC works then those AOS/LOS messages will be based on that [19:59:12] instead of as it is right now, using the actual position of the CSM [20:00:38] but of course that is mostly separate from the actual MSFN operation [20:51:01] https://github.com/indy91/NASSP/tree/ImproveCMAerodynamics [20:51:05] if someone wants to try it [20:52:08] don't want to make a PR quite yet, haven't decided if I want to change the calculation for the coefficients [20:53:09] oh what I really need to test is how it behaves near 0° angle of attack now [20:53:14] instead of the normal 160° [20:58:13] it's indeed stable [20:58:14] at 16° [21:04:51] :D [21:07:17] creates a nice amount of lift [21:07:31] doesn't go beyond the 12G that we have set which kills the crew [21:07:51] if it wasn't for the lack of heat shield there you could fly a reentry like that [21:13:40] What do you need tried out? Sorry just catching up [21:16:54] nothing specific really [21:19:20] just fly some reentries if you want and look if anything unusual happends [21:19:22] happens* [21:22:48] Sure I can do that [21:32:23] Flying a 9 entry first [21:34:36] The only difference in behavior I really noticed was that the trim angle of attack didn't change so dramatically in the transonic region [21:34:49] we had that a bit over the top before [21:35:32] and if you look at the rate needles it oscillates more dynamically than before, looks a bit more realistic [21:35:45] only small rates of course [21:38:00] Hmm loading the Apollo 9 deorbit scn and my H2 pressures climb fast to off scale high [21:42:01] I'm still getting master alarms in all mission scenarios [21:42:40] but not any pressure rises I think [21:43:21] I get them from the suit compressor or o2 flow stabilizing [21:43:22] I see the pressure rise in that scenario though [21:43:35] but in these ones my H2 press is going up and up lol [21:45:19] no idea why [21:45:53] and the burn is fairly bad [21:46:28] maybe changed SPS gimbal trim? [21:46:48] uh oh [21:47:03] n7275 this is in one of the premade ones [21:47:37] Load one of the Apollo 9 scns close to deorbit and see if you can get the same results [21:48:43] it boils a bit easier now I suppose. with the natural progression of the mission it would be much colder [21:50:49] I checked a bunch of those mission scenarios and I dont remember them being too absurdly bad. nothing that would prevent completing a mission at least. [21:50:59] oh the scenario doesn't have the padload for the SPS cutoff transient [21:51:09] I thought I added that everywhere... [21:51:45] Also i just recomputed the maneuver pad, the retrofire pad doesnt have a burn attitude? [21:52:02] uhh [21:52:08] the Entry PAD doesn't [21:52:21] ahh its at the very bottom maybe? [21:52:37] you are looking at the Maneuver PAD from the MCC, right? [21:53:10] yeah [21:53:21] I am just not used to the R P Y being at the bottom [21:53:42] yeah this is the Apollo 7 and 9 format for Maneuver PAD [21:54:01] Yeah its been a while [21:54:18] I added the padload to the T-60s scenario [21:54:23] but not to any other mission scenarios [21:55:38] yeah the others need a bunch of work again anyways [21:55:39] I should do that if we want to keep these scenarios around instead of creating new ones soon [22:00:45] night! [22:01:18] I am going to fly this entry then try some other scns and see if I get the same issues [22:03:07] o2 now above limit lol [22:06:38] :( [22:12:48] Again this is just a saved scn, I didnt see it when I started from a prelaunch [22:12:57] But certainly worth analyzing [22:13:03] I know we flew at least 3 full missions with that system so in not worried about it too much [22:13:15] could be ecs values not set in the scn file p[roperly [22:14:50] almost positive that it's from the cryo tanks being warmer than they should be. the new vapor pressures and hvap mean that the state of these old scenarios is effectively superheated liquids [22:16:01] so as soon as you launch them, it all boils [22:28:40] running through the mission from prelaunch means that the cryo tanks are supercritical (O2 at least) for the first half, and then saturated liquid/vapor for the rest, and requiring heat input to stay at that equilibrium point. [22:30:31] so how do we fix this in the premade scenarios [22:36:09] reduce the Q value until the temperature is stable. [22:43:44] Curious what they are in those scns [22:44:56] Oh well we can tackle that when we go through them and clean them up [22:57:03] I mean we'll definitely re-fly them all before release [23:00:36] my specific heat update will mitigate this to some degree as a side effect [23:01:00] also includes energy changes to every scenario [23:02:51] we're probably going to need a better solution once we're supporting more missions than just 7-11 [23:03:22] Yeah [23:11:35] So are we doing 12-14 in the next support iteration? [23:12:23] .tell indy91 well it looks like EMEM1735 changed somewhere between 117 and 120 hours. I must've done something dumb here. [23:12:39] yes I think that's the plan [23:13:56] Which erasable is that? [23:14:01] REFSMMAT? [23:25:59] yeah [23:26:25] was 17155 until right before the P52 before landmark tracking [23:30:35] Wonder if you goofed and did something other than an option 1 [23:30:40] *option 3 [23:51:14] Well flew a few Apollo 9 entries, they feel really good [23:51:35] I did get a corridor light at EI but I cannot remember if that was expected [23:52:41] I noticed the 0.05g reading fluctuated a lot more than I am used to before hitting 0.05g but I also saw the spacecraft cross and down range seemed to be more easily held by the PGNS [00:23:09] I can't wait to try it from lunar orbit [00:33:50] Looks like you and Alex both have a TEC coming up [00:34:46] Which reminds me, I know the mains now if you dont release them right away pull the CM on its side in the "ocean" but is there any way to mitigate this or have the float bags right the spacecraft? Or is this an orbiter thing [00:37:10] I have no idea. sounds like a cm touchdown point issue. [00:38:00] I can't imagine it being a difficult fix though [00:38:16] Yeah its been a thing for a while [00:38:26] If you main release like right at splash it stays upright [00:38:36] but if you leave it for a second long it tips and stays sideways lol [00:39:32] rcflyinghokie never seen that behavior myself [00:39:41] Its pretty normal now [00:39:50] Just had it again doing 9's entry [00:40:00] it stays upright for me even with the mains still attached [00:40:06] weird [00:40:14] It used to for me [00:40:16] but not in a while [00:40:40] Next time you splash wait a moment before main release and see [00:40:45] I can replicate it pretty easily [00:41:05] does it do it for you on a pad abort? [00:41:55] Hmm good question, let me try [00:44:16] sure does [00:44:26] which scenario? [00:44:43] I just did Apollo 8 t-60s in this case I will try others [00:44:51] I just tried Apollo 11 launch -30s and it stays perfectly still [00:45:07] I'll try that one [00:47:00] flipped on its side [00:47:27] https://www.dropbox.com/s/49wpknrimv8bbv1/Screenshot%202022-01-25%20174714.jpg?dl=0 [00:48:10] do the floatbags flip it the right way up? [00:48:37] maybe it was a "feature" from years past [00:50:18] No they do not [00:50:44] The flipping over is relatively new to me, last 6 months or so [00:50:53] Noticed it when I flew 15-17 [00:53:22] aha! [00:53:46] its caused by the "Atmospheric wind effects" [00:54:08] I always have that off, thats why I never saw the issue [00:55:06] Ohh! [00:55:11] Haha good find [00:57:18] ooooh [00:57:44] I feel like we could fix tho [01:01:15] yeah, seems like the chutes are being tugged by the wind, even after splashdown [01:06:27] Which is, well, kind of realistic [01:21:11] mother of god. it happened. the missing panel has blessed me with an apperance. [01:22:16] hahahaha [01:22:18] the best bug [01:23:35] okay so the mesh is definitely there. it just has its alpha chanel set to 0 [01:25:05] SM-Panel4 [01:31:45] mwhume.space/Files/MISSING_PANNEL2.png [01:32:18] Finally! [01:32:27] http://mwhume.space/Files/MISSING_PANNEL1.png [01:32:38] http://mwhume.space/Files/MISSING_PANNEL.png [01:32:56] So, is that intentionally a "404 not found" [01:33:20] haha no [01:33:47] https://www.orbiter-forum.com/threads/fdai-textures.40324/#post-590153 [01:33:58] Is he allowed to take the KSP ones and repackage for NASSP the way he did? [01:34:05] Seems a but sketchy [01:34:10] bit* [01:42:02] no I don't think so [01:43:09] We should send him a message asking him to remove them and explaining why. [01:47:08] AlexB_88 is it a problem that we have some MESHHANDLEs defined globally twice? [01:56:54] n7275 agreed, I think that should be removed and a message sent, but I want to defer to Thymo before pulling the trigger [01:57:50] he knows the regulatory aspect better than me [02:02:53] sure [02:29:24] n7275, good question Ill have to take a look [02:36:36] might also be related to the Apollo13State union [03:23:00] I'm a little confused about uplinking a new refsmmat [03:39:32] oh wow, those FDAI textures... [03:45:43] Yeah, but those were taken from a KSP mod I believe [03:45:53] n7275 whats up with it [03:52:34] so using the REFSMMAT page I see where I can calculate the landing site refsmmat, how does that interact with the uplink? and what does the G00 MED do? [03:58:40] you just press CLC I think [03:59:26] G00 is if you want to transfer REFSMMATs between different "slots" [03:59:34] but not needed here [03:59:46] when you press CLC the REFSMMAT is stored in CUR [04:00:06] and CUR is what is loaded in the uplink page with MPT incative [04:00:13] inactive* [04:04:58] n7275 did something happen with the HGA and tracking? [04:05:06] Cannot get any signal strength [04:05:48] 1629 [04:05:52] Using V64, HGA manual, antenna is facing earth but no signal strength [04:06:12] SBD is on HGA [04:06:34] its working quite well for me [04:08:32] if you're in manual mode the beamwidth switches do what they say, in auto or reacq they acquire in wide and then switch to narrow [04:08:49] manual wide [04:08:55] on V64 numbers [04:09:15] Maybe the CSM is slightly blocking? [04:11:56] Yep [04:13:43] mwhume.space/Files/HGA-V64.png [04:15:29] there is a shadow zone in which the antenna can't see earth [04:17:05] Must have just been in it [04:17:30] Normally I have no issues, but the gent I am walking through things we were having trouble with it [04:17:59] it may be slightly too big, but its within a degree or so in the roll direction. the SPS bell and fore-aft SM don't shadow, so from the HGA's perspective it's stuck to the side of a 12ft aluminum sphere [04:19:06] simulating microwave reflections is hard, so that's a future project [04:25:48] this is a good perspective on shadowing the antennas https://youtu.be/EeeeTVr4Lyg?t=770 [04:56:46] Awesome [04:56:51] It probably was just right there [04:56:59] rolled about 10 degrees and bam [04:57:48] Hmm something for Nik, the P30 Pad in Apollo 8 (at least MCC1) has N44 for Ha Hp dV where Apollo 8's computer had this as N42 [04:58:25] .tell indy91 looks like Apollo 8's MCC1 Maneuver Pad had N44 for Ha Hp dV where Apollo 8's CMC used a N42 for these values [05:14:31] When in P30 [05:24:14] its N42 in Apollo 11 P30 too [05:24:26] V82 has it as N44 [05:32:05] the Apollo 8 flight plan also has N44 as the PAD entry so I think its correct already, even for 8 [05:38:10] Really [05:38:15] Interesting [13:46:26] good morning [14:53:31] hey [15:03:02] thanks for replying to that forum post about fdai textures. [15:08:43] Yep [15:10:33] I debated if I should hide the post or not. While I do have the means to do so, I'm not sure to what end we are actually supposed to moderate stuff like that since we're not technically moderators? [15:11:25] We have the permissions for that section, but I don't know that implies we also should be moderating in that sense. I'll need to clear that up with Xyon. [15:12:30] that would be good to know. [15:14:00] I think that the best case would be that user removing his post voluntarily. [15:14:27] Agreed [15:15:01] Other than being posted in out subforum it's not really out problem anyway. Best we can do is not endorse it. [15:41:57] hey [15:42:34] always this pesky HA/HP topic on the Maneuver PAD :D [15:44:00] n7275, maybe the P52 at 199h [15:44:02] 119* [15:44:38] an uplink alone couldn't do this, I think you have a valid alignment in your scenario [15:44:44] so not just the REFSMMAT [15:44:51] although I didn't actually check the IMU [15:45:36] which reminds me [15:46:05] I want to add this small cheaty utility calculation to the RTCC MFD where it shows you how good your IMU alignment is relative to the REFSMMAT [15:46:25] and maybe even a cheaty button where it fixes you IMU alignment, just to get a perfect one for testing [15:47:47] I managed to fix it last night. [15:47:54] ah great, I'm getting the good old issue where a scenario doesn't load anymore when something about the Checklist MFD was changed [15:49:00] I accidentally realigned in pulse mode which took a while [15:49:14] yeah haha [15:49:26] I think your alignment was wrong by almost exactly 180° [15:50:09] in both pitch and yaw [15:51:46] I missed a whole orbit of landmark tracking. thankfully theres a few more of those haha [15:51:47] alignment is fine in the scenario, so it had to have been a P52 option 1 [15:53:26] I'm sure I just pushed the wrong button [15:56:11] I got a little turned around while during the rendezvous and that made me think the alignment was bad, but I'm positive that was just high workload. [15:56:27] the last P30 in the CMC is the sep maneuver [15:58:51] but it doesn't look like that is the alignment [15:59:58] so potentially LOI-2, but it's difficult to say [16:00:26] have you seen the glycol loop post in the forum? [16:00:55] I saw it. haven't had a chance to look into it yet. [16:08:32] hmm looks like we merged my systems update back in the beginning of November [16:09:08] of course there are some big error bars on "about a month" [16:09:15] hey Alex [16:10:22] hey [16:14:39] very odd [16:15:56] I distinctly recall it the glycol getting very warm on launch with the radiators bypassed. [16:16:47] maybe ryan knows [16:34:25] hey Alex [16:36:36] ah great, always the checklist merge conflict... [16:37:01] I really need to get on with finishing Apollo 7 or I'll never get that done before Ryan wants to fix more checklist things [16:38:56] and I never know which version I am committing [16:39:14] Orbiter2016 branch had an update. I made changes in my Apollo 7 branch [16:39:20] I want my own changes to be overwritten [16:39:38] the merge commit has the changes to my own branch [16:42:32] and then I am confused which version I'll get after the merge haha [16:44:22] btw I have a PR with checklist fixes [16:44:27] kidding :D [16:44:53] I did say that Apollo 7 was open for changes again after I blocked it for a while [16:45:13] but I need to block it again or I'll get mad from implementing the same things four times [16:45:47] ah and now I had the checklist file open, which somehow changes it even if I don't save it in any way [16:45:56] and now it doesn't appear in the commit list anymore... [16:46:02] Excel files and git don't get along [16:46:40] ok I merged and with that last thing I now kept my own version [16:47:06] I can live with that, now it's Ryan changes which are going to be lost :D [16:51:32] it would not bother me one bit if we moved away from something that relies on Excel. [16:52:35] yeah [17:05:36] Do we even use any spreadsheet function in those checklists? Couldn't they just be a csv instead? [17:11:12] morning! [17:20:06] hey Mike [17:20:53] Thymo, from a structural standpoint the tabs/worksheets play a functional roll [17:34:12] Oh that's right [17:34:50] Mayble something like flat ODS? That puts everything inside a single XML file. Atleast the diffs would work again. [17:40:05] that would probably work [17:40:34] as long as git can see what's happening I think it's a huge improvement. [18:36:09] alright so I have been doing some more experiments with the "creeping LM on the moon" issue [18:37:02] at 1st I tried doing the same hack to force the vehicle landed like with the Saturn IB/5 on the pad [18:37:33] but the problem is that it forces the vehicle into a perfect 0,0 pitch/roll attitude [18:38:31] which we don't really want on the moon since the terrain can be hilly and you want to see a bit of a canted attitude after landing sometimes [18:38:55] so that leaves with just the friction coefficients of the touchdown points [18:39:24] mu & mu_lng [18:40:34] they are set to 3 in the TD points right now, which helps a bit to arrest the creep, but they need to be higher to really make a difference...problem is anything higher then 3 and you get a noticeable jerk forward/sideways at scenario start on the moon [18:42:38] What I just tired and gives better results is waiting a few timesteps before setting them higher, and his seems to actually work on my initial tests [18:42:52] you can use SetSurfaceFrictionCoeff to set them higher [18:46:17] So for my test, in the timestep, they are set to 0 for 10 timesteps then set to 20 [18:46:53] so that means the LM stays solidly in place and no jerk at scenario start [18:57:35] sounds like a workable solution [18:58:25] any issues landing with the higher friction coëfficients? [18:59:00] I have to do more tests but landing seems fine [18:59:12] and APS ignition/staging [18:59:51] if you fire an RCS thruster during time accel though, that might be bad with the higher coefficients [19:22:39] rcs + time acceleration is almost universally a recipe for a bad time though [19:25:18] yeah... I was testing very high friction, and accidently has RCS fire at 100x [19:25:51] the sim froze and then my LM was in a part of the Orbiter universe I had never seen before [19:27:10] there was a bunch of weird white textures everywhere, maybe I was in the sun [19:30:36] you've discovered the secret level. [19:30:43] haha [19:31:13] that was with coefs at 50 I think [19:31:41] at 20, you'll just get a bunch of jitters if you fire RCS + time accel [19:35:01] afternoon [19:35:36] hey Ryan [19:36:12] Just catching up on the forum posts [19:36:26] Looks like VC viewpoint is still moving? [19:38:04] https://www.orbiter-forum.com/threads/a-few-apollo-9-bugs.40330/ [19:42:31] that is caused by the JostleViewpoint code in the timestep [19:43:15] AlexB_88: Sounds like you've gone to plaid! [19:43:17] I think the gravity from the earth/moon is slightly affecting the viewpoint [19:43:35] Hmm interesting [19:43:49] oh wow [19:44:05] gravity haha [19:44:30] Thymo, plaid? [19:44:42] Spaceballs joke :P [19:44:51] oh hahaha [19:44:52] rcflyinghokie: Bingo :D [19:45:03] https://www.youtube.com/watch?v=mk7VWcuVOf0 [19:45:09] I think its just been too long since I've seen that [19:45:19] Its always been too long even if I just watched it :) [19:47:22] rcflyinghokie, what changes have you made to the Apollo 7 checklist? [19:47:38] I renamed BAT BUS C to BAT C [19:47:43] ah [19:47:55] As there is no BAT BUS C on the DC indicator [19:48:00] right [19:48:10] just in the description of the checklist step I guess [19:48:15] not actually renaming the switch in code [19:48:22] Yep literally just the text [19:48:44] If I want to keep my own changes that will get merged (eventually!) then I have to do that in my own copy as well [19:48:52] I have been flying through a mission with someone learning NASSP and watching the stream and its amazing how many things I notice when not actually flying it haha [19:48:58] in the branch I have for Apollo 7 [19:49:16] Haha yeah I only changed the EPS System Check procedure since its basically copy paste [19:49:21] yeah I had the same experience when watching the Apollo 7 real-time mission [19:49:57] Certainly is interesting how that works [19:50:23] Oh, does the extraction attitude not compute for Apollo 8? [19:50:42] uhh [19:50:57] It was all balls [19:51:08] Or was that not in their TLI pad [19:51:44] I think it wasn't [19:51:47] Ah it wasnt [19:51:59] but I thought our MCC was just calculating the same old TLI PAD for all [19:52:06] Yeah the extraction being all zero on there threw me off [19:52:32] As opposed to RTCC? [19:53:05] ah I think I know why [19:53:19] TLI PAD calculation in the RTCC MFD uses an old method still [19:53:32] but a while back I changed it so the MCC uses the MPT for TLI [19:53:38] and takes data from the DMT [19:53:58] but I didn't copy over the procedure to get the extraction attitude [19:54:02] Ahh [19:54:04] as Apollo 8 didn't get that [19:54:08] Makes sense then [19:54:21] Sep attitude was close [19:55:03] 2-3 degrees off in roll 1 in pitch and 1 in yaw [19:57:27] it's always off in roll by that much [19:57:28] I wonder why [19:58:08] Hmm it always off could be a computation error [19:59:17] I'm sure it is [19:59:20] but a weird one [20:01:42] Eerily consistent [20:30:56] n7275 did you figure out the REFSMMAT issue? [20:32:12] indy91, I have these changes that should help a lot with LM creeping: https://github.com/jalexb88/NASSP/commit/96686a21b72fcb1ec27f2c242c0a321a8987e034 [20:35:55] rcflyinghokie I uplinked a new one. much better [20:36:43] Any idea what caused the error? [20:40:48] probably an accidental option 1 [20:41:44] ah [20:44:43] AlexB_88, I'm not a fan of a solution like that, but it might not be avoidable... [20:46:11] its definitely not pretty... [20:48:11] hopefully the Orbiter engine can be improved going forward to avoid these hacks [21:07:24] anyway I am happy with it so PR sent, I tested the crap out of it to ensure its stable in all cases, even with RCS firing with 10x time accel [21:08:13] I'll give myself until tomorrow to come up with a better concept [21:08:40] haha sounds good [21:10:01] the thing it helps the most is the LM needing to stay in the exact same attitude after say, a 400+4 lunar align or updates to 047/053 in the AGS [21:11:24] so if you get your ascent pad, update the AGS values (047,053) and do a 400+4, but then right before liftoff you save reload, the jerk that sometime happen really screws up the AGS orientation [21:11:25] true [21:11:49] did you guys do some CM reentries with my update? [21:12:27] not yet but I will definitely do one with 11 probably on Friday [21:12:40] rcflyinghokie? [21:12:52] I did [21:13:36] I flew a few from Apollo 9 [21:14:07] I didnt notice anything bad, it actually felt "better" if that makes sense [21:16:09] as I said, the only thing you do notice is the transonic behavior [21:16:12] at least if you look for it [21:17:31] that has definitely changed [21:18:57] I have a graph for that [21:20:44] https://i.imgur.com/IY8UtMq.png [21:23:18] I don't know why we ever had it like that, but with the old behavior the trim AOA was rapidly going in one direction and then the other near mach 1 [21:26:04] when I did that reentry with the apex cover forwards it did very extreme changes near mach 1 [21:26:07] I was in SCS [21:26:21] rate limit kicked in so RCS was firing against it [21:26:23] It felt more stable overall [21:26:36] I also noticed that the 0.05g counter on the DSKY fluctuated a lot more [21:26:38] it almost put itself in the correct attitude [21:26:57] that doesn't sound more stable haha [21:27:06] but I think it's fairly normal in Earth orbit [21:27:41] I would say it is, as the g buildup felt more gradual and it would go from .01 to 0.02 to 0.01 to 0.02 to 0.03 to 0.02 etc [21:27:50] instead of just 0 1 2 3 4 5 [21:28:13] right [21:28:14] more friction effects perhaps? [21:28:35] it's not super stable yet with that high Mach number I think [21:28:38] holding EI and pitching the horizon was easier to me [21:28:40] and I guess you were in SCS att hold [21:28:43] yes [21:29:17] Just did a few by the book [21:29:30] it's oscillating a bit more in attitude pre 0.05g I think [21:29:35] Also the PGNS seemed to do better on nulling the xrng and dnrng error [21:29:53] I didnt have to make too many R or Y corrections [21:29:57] before 0.05g [21:30:08] I was on 1 ring [21:30:45] I would say at high Mach numbers it shouldn't have changed much in terms of lift and drag, relevant for the PGNS [21:30:54] at a bit lower Mach numbers maybe a bit more different [21:31:20] I did have a lift vector down light at EI for a while [21:31:36] its been a bit since I flew a deorbit entry so I didnt remember if that was normal [21:31:53] always the case in Earth orbit [21:31:59] it's not useful [21:32:16] Ah ok I thought I remembered that but again its been a while [21:32:24] if it gives you lift vector down when coming from the Moon then you might want to listen to it :D [21:32:29] haha [21:34:07] do you want some more deorbits flown or lunar entries [21:34:09] yeah AOH says only use for lunar entry [21:34:39] whatever you want [21:34:43] ok [21:35:00] again I noticed nothing out of the ordinary in terms of breaking things [21:35:02] I think it's in a good state, there is one or two things I still want to look at but more for improving performance, not changing the behavior [21:35:21] Lets see what Apollo 10 looks like with a fast reentry [21:36:06] scratch that, its about the only mission I dont have scns for [21:36:50] and I never finished creating mission scenarios :D [21:39:41] indy91, maybe Kevin Bacon should try the new CM aerodynamics [21:42:16] what's this i hear about Apollo 10 scenarios? [21:42:17] what was that again? I remember I once created a scenario called "Kevin Bacon Challenge", but forgot what was special about it... [21:42:30] only good Apollo 10 scenarios :P [21:43:10] he says constantly disabling the "Auto show PAD" option in the MCC by accident [21:43:33] I think it was a manual re-entry challenge? [21:43:50] pretty sure it was referencing the sim scene in Apollo 13 [21:44:39] might wanna ignore the ones around 120hrs then haha [21:45:13] yeah I remember the Kevin Bacon challenge! [21:45:18] Manual entry haha [21:46:09] indy91 would a scribe do anything at all to help you with confirming the aerodynamics are ok [21:46:17] EMS scribe [21:47:45] hmm, I don't think it says that much [21:47:53] too many variables [21:49:31] I trust the numbers in the CSM Data Book, that is what is implemented. I think that it works as I expect it to because it has the predicted trim angle of attack. The various coefficients have to all be correct otherwise it wouldn't work out [21:49:41] in fact I got something wrong in the yaw axis at first [21:50:05] when it did the 180° roll maneuvers when coming from the Moon it spun out of control [21:51:08] and I am using a very standard CG location for the calculations [21:51:12] all hardcoded so far [21:53:50] 8 and 11 entries both went great [21:54:04] saw a little oscillation in the rate needles more than I am used to [21:54:16] But the crossrange and downrange errors seemed to null out better [21:57:08] that is good to hear [21:57:16] In the yaw axis we had no airfoil before, it was just kept stable by the center of pressure location [21:57:21] way too stable I am sure [21:57:31] in pitch it shouldn't have changed too much [21:57:36] so is that why i swing in yaw when rolling more noticeably? [21:58:10] nothing unstable just more prominent on FDAI 1 [21:58:19] yeah [21:58:23] and I think it's realistic [21:59:04] before it was just rock solid [22:01:46] right I noticed that in both lunar and deorbit entries [22:02:51] it should be about the same kind of oscillations in pitch and yaw now [22:03:01] and we should have had them before in pitch [22:03:42] yeah thats on par with what I saw [22:04:08] it's a nice and slow frequency [22:04:16] so even with terrible framerate they shouldn't get worse [22:22:10] night! [03:26:39] https://www.orbiter-forum.com/threads/fdai-textures.40324/#post-590203 [03:27:00] so does this mean we can use it as long as the original creator is credited? Thymo? [03:33:01] the thread it's from is here: https://forum.kerbalspaceprogram.com/index.php?/topic/164158-13-navballtexturechanger-v16-8717/ [03:34:57] looks like he's right about this being CC-BY, based on that first post [03:35:44] https://www.gnu.org/licenses/license-list.en.html#ccby [03:36:03] official GNU guidelines say it is compatible with all versions of the GPL [03:37:57] I think the legal justification for this being CC-BY might be a bit tenuous though [03:38:39] tooRelic didn't declare a license themself; the OP of the thread simply stated that he would assume all non-licensed things to be CC-BY [03:39:15] ah interesting [03:39:24] there also this: http://orbiter.dansteph.com/forum/index.php?topic=14697.0 [03:39:51] I don't know if its the same? texture the guy is making looks similar [03:51:24] not the same guy [03:55:17] chrival; has the same username on Orbiter Forum as well. [03:57:50] That KSP one is also off by one degree in the pitch direction [04:17:12] ah ok [04:18:01] so I guess there is some competition to update our FDAI :D [04:37:08] it's like the time we were all working on telemetry clients [14:56:29] hey Niklas [14:56:57] hey [14:59:52] got a question on docking [15:01:16] I tried to make a video but the results were embarrassingly bad lol [15:03:03] what were your issues? [15:03:05] attitude? [15:03:12] when exactly in the timeline of docking should I be in AGS/att hold/pulse per the checklist [15:03:27] yeah keeping the LM attitude stable [15:05:16] I don't know what our checklist says specifically [15:05:26] the flight plan isn't very detailed [15:05:30] and we don't have much else [15:05:34] for Apollo 10 [15:06:26] are you not supposed to use the PGNS? [15:08:52] our checklist says ags [15:09:14] so maybe pulse to get to docking attitude [15:09:28] and then att hold, mode control? [15:10:26] that would make more sense [15:11:30] is it CSM active docking? [15:12:45] I can tell you the attitude from the operational trajectory [15:13:09] 120, 345, 0 for CSM [15:13:18] 180, 165, 0 for LM [15:15:51] hmm looking at our checklist [15:16:00] maybe you got confused in the order of things [15:16:10] LM gets into attitude, under PGNS control [15:16:11] V77 [15:16:16] and then you switch to the CSM [15:16:22] and perform the docking [15:16:37] and you only go to AGS pulse mode after docking... I think [15:17:58] well that would definitely be easier [15:22:11] hard to tell from mission audio but I think they went into ags/pulse 15 ft out or so. i might be misremembering though. [15:22:30] right, maybe to prevent RCS firing upon docking [15:34:27] good morning [15:34:30] I'll give that another go. [15:34:34] hey alex [15:35:15] I had a question for you last night/github issue I thought we should add and now for the life of me I cant remember it [15:50:08] good morning [15:50:36] hey [16:00:10] having a discussion about the no auto abort light, would this just be lit up by switching EDS to off or should it also be lit by turning off lv rates and 2 eng out? [16:04:55] ah looks like just the EDS switch [16:05:50] morning! [16:08:20] hey :) [16:14:47] So refresh my memory, our RTCC has 4 P99 uplinks correct (0 1 2 3)? I see in the Apollo 15 timeline that it says P99 uplinks (3) does this mean only using 0 1 2 in the RTCC? [16:25:55] hey guys [16:26:10] there are several versions of that uplink [16:26:24] maybe we don't have the final one, or the one actually used on Apollo 15 [16:26:53] and it wouldn't be accurate for the no auto abort light to be on with those switches set to off [16:27:08] as there is still the automatic abort if 2 of the 3 wires from CM to IU are cut [16:27:24] regarding the light, I found the wiring in the schematics and figured that out haha [16:27:25] or the CBs for them are being pulled [16:27:50] regarding the EMP, what is in the RTCC then? [16:28:27] I have to check, I think we got ours from the GSOP section 7 [16:28:42] but there is a different version in a Luminary memo [16:29:22] ah but that GSOP is from April 1972 [16:29:24] I thought I remember using the RTCC when I did my deorbits [16:29:35] Just did a P30 uplink first then ran that [16:30:41] oh I didn't read part 2 of your question haha [16:30:48] definitely don't skip the last uplink [16:30:57] maybe the version they used on Apollo 15 came in 3 parts [16:31:03] but for us we definitely need all 4 parts [16:32:02] Even in the luminary memo 168 it only has 3 parts [16:32:41] are we missing something? [16:33:08] we use the version in the GSOP [16:33:30] I see another version Luminary memo #199 [16:33:44] 3 parts [16:33:50] that could be the one used on Apollo 15 [16:33:58] it's the same software, so I don't think either version is wrong [16:34:09] maybe the 4 part one has more protections of some kind [16:34:16] it's probably better as it's later [16:34:16] the 4 part was used for 14, correct? [16:34:35] I don't know [16:34:40] I doubt it [16:34:55] if Apollo 15 had 3 parts I doubt that Apollo 14 used the one we use [16:36:08] Luminary memo 168 might be what they used for Apollo 14 [16:36:14] and 199 for Apollo 15 [16:36:23] and the GSOP version for Apollo 16-17 maybe [16:36:36] but what the RTCC MFD has will work fine for Luminary 1E at least [16:36:43] Ok [16:37:30] Wonder what the differences are [16:38:54] ah, memo 199 says [16:38:56] "As it may or may not be known, the LM Deorbit burn for Apollo 14 was performed using P99 - Erasable Memory Program - written for Luminary ID (Rev 178) and enumerated in Luminary Memo #168. Herein lies the re-write of P99 for Luminary IE (Rev 209)." [16:39:57] Ah ok, so the 168 memo load was for 14 [16:40:03] 199 for 15 [16:40:15] Curious about the 4 uplink version now [16:40:34] it gets better [16:40:55] memo 211 (revision 1 haha) is meant for Apollo 15 [16:40:58] and it has 5 parts [16:41:44] I am so confused haha [16:41:56] I don't think any of these are wrong, just different [16:42:14] but you always need all the uplinks of course [16:42:53] interesting this memo has 5 uplinks [16:43:07] but even the 15 LM timeline book says P99 uplinks (3) [16:43:42] Ahh the timeline is dated 5 APR [16:43:48] The memo 28 APR [16:44:20] the two V71 uplinks are identical between the GSOP and memo 211 versions [16:44:54] oh I see [16:44:58] I think they are identical [16:45:15] one version does two short V71 [16:45:18] and then one V72 [16:45:26] the other does two longer V72 [16:45:43] do you know the difference between the verbs? [16:47:19] I do not [16:48:07] V71 is a block of erasable addresses, V72 is single addresses [16:48:09] the format is [16:48:25] V71, number of addresses, first address, data [16:48:45] V72, number of addresses, first address, single data, second address, single data etc. [16:49:05] so the actually uplinked stuff is identical, just uplink in a slightly different way [16:49:17] Ahh [16:49:25] so I think we have the last and definitive version [16:49:30] in the RTCC MFD [16:49:33] So our uplink while different has the same data [16:49:49] well different from the version with 5 uplinks [16:49:59] right [16:50:00] but 3 uplinks is an earlier versions [16:50:11] memo 199 [16:51:09] February 1971, 3 uplinks [16:51:23] by April they had the last version [16:51:28] identical to the GSOP version from a year later [16:51:45] Lots of swift evolution [16:52:04] but yeah seeing as the date on the 15 LM timeline is a few weeks prior I see why it says 3 uplinks [16:52:41] yeah either the updated version didn't get shipped to MSC in time, which doesn't seem very plausible [16:53:01] it does still say 3 uplinks in the flown version of the timeline book [16:53:15] could have forgotten to update that [16:53:52] The date in the flown version is 5 April, correct? [16:54:20] aha! [16:54:28] confirmed, 4 uplinks [16:54:36] I have the list of all uplinks done on Apollo 15 [16:54:41] "LGC EMU B" [16:54:45] and that 4 times [16:56:44] So 15 had the 4 afterall [16:56:49] yes [16:57:01] flight documentation didn't get updated then [16:57:06] I mean, it's a minor thing [16:57:08] And I guess 16/17 did as well [16:57:17] Oh I know, still nice to get it correct [16:57:40] well I meant, it's not too bad that they didn't get it right haha [16:57:53] not a major oversight, even if wrong [16:57:57] Yeah [16:58:01] Still works [16:58:12] and yeah, I find it likely that they used the exact same uplink on 16 and 17 [16:58:14] Any idea if 14 used the 3 uplink method? [16:58:53] yes, I quoted the memo earlier [16:58:58] "As it may or may not be known, the LM Deorbit burn for Apollo 14 was performed using P99 - Erasable Memory Program - written for Luminary ID (Rev 178) and enumerated in Luminary Memo #168. Herein lies the re-write of P99 for Luminary IE (Rev 209)." [16:59:11] and the uplink in memo 168 has 3 parts [16:59:31] Right, but do you have a confirmation similar to 15 [16:59:48] nah, sadly I don't have this document for any other mission [16:59:57] well I think I have something similar for 11 [17:00:16] "RTCC Coordinator's Report for the Apollo 15 mission" [17:00:25] UHCL has a bunch of these [17:00:53] it's pretty nice, has all the time updates, REFSMMATs etc. [17:01:04] system parameter changes [17:01:09] oh cool [17:01:56] I know there are a lot of other uplinks for things like short burn constants (CMC) and zeroing positive and negative cells (LGC), would those kind of things be in there? [17:01:58] for 11 I have the "Network Controller's Mission Report" [17:02:18] hmm [17:02:58] can you get me a rough GET when that would be done? [17:03:10] ah there is [17:03:16] "LGC EMU B V71" [17:03:49] transmitted on mission day 7, 10:18h GMT [17:04:31] but of course it doesn't really say what it was [17:05:23] the zeroing? [17:06:00] yes [17:06:20] yeah I never quite understood what it was [17:06:28] its usually done before lunar liftoff [17:10:32] that erasable update was done just before the LS REFSMMAT uplink [17:11:38] You mean RLS? [17:11:45] (going by the flight plan) [17:12:29] ah yes [17:12:37] misread it [17:12:43] but that was probably it then [17:12:48] whatever "it" is haha [17:12:55] Yeah that is the right time, now what is it :P [17:13:03] Wonder if thewonderidiot would know [17:13:12] hides [17:14:23] I could only imagine it being something like DOWNTORK [17:14:33] "ACCUMULATED JET TORQUE COMMANDED" [17:14:45] which is relevant for the CG tracking for ascent guidance [17:14:49] DAP* [17:15:01] but I didn't think that was even used before ignition [17:15:34] that and DLAND is set to 0 in the padload [17:15:42] DLAND is the landing site correct [17:15:43] N69 [17:15:48] correction* [17:17:05] sleepy brain trying to follow: so the question is that they zeroed some erasables but it's unclear which? [17:17:42] yeah [17:17:48] lunar surface checklist has an uplink [17:17:57] "zeros POS/NEG Cells" [17:18:15] and we don't know what that is [17:18:42] huh, interesting [17:19:07] it started with Apollo 14 I think [17:20:13] can you point me to a PDF where I can see that step in context? [17:22:13] https://www.hq.nasa.gov/alsj/a15/a15_LM_lunar_surface_checklist.pdf [17:22:22] top of page 12-2 [17:22:37] thanks! [17:22:38] it's about in the middle of LM activation for lunar ascent [17:23:15] they seem to want to set something to 0 that is positive or negative [17:24:15] well that really narrows it down :D [17:28:07] hmmmmm [17:28:11] yeah I'm not sure [17:39:05] I also never found anything in the program notes that could be related to this [17:39:25] but if it's some kind of workaround, why didn't they fix it between 14 and 15 [17:39:52] so it must be a fairly normal operation [17:40:46] 187:13:57 Fullerton: Okay. Your up-links are coming. We'll give you a vector and zero the pos/neg cells. Your RLS is okay. [17:40:49] not helping :D [17:41:20] haha [17:52:20] haha damnit [17:53:10] this feels like something that should be covered in the GSOP, or User's Guide, or something [17:53:25] yeah [17:58:49] indy91 does that doc have the erasable that were changed or does it just say an uplink was there [17:59:16] only that there was an uplink sadly [17:59:56] it says it was V71, but that doesn't tell you much [18:02:26] but it does give each individual uplink [18:02:41] so that's why I know there was at one point 4 of these erasable memory updates in a row [18:14:24] what "cells" would be relevant to zero before a P12 or P20 I wonder [18:18:06] or P57 [18:18:50] Hmm didnt think about that [18:20:10] Also has a P22 after that [18:56:11] indy91, did you have any more thoughts today on the surface friction PR? [18:58:13] only one thing [18:58:22] old value is 3 [18:58:27] new value is 20 [18:58:34] that's the initial number [18:58:41] and then it's set to 1 for 10 timesteps [18:58:46] and then to 20 [18:59:01] so it might have 20 for the very first timestep [18:59:13] before it calls clbkPreStep [18:59:23] don't think that is a problem though [18:59:49] yeah, the instability seems to be caused later then the very 1st timestep [19:00:02] but before the tenth [19:00:19] so the instability happens when it's loading in the terrain etc, right? [19:00:39] yeah [19:00:57] isn't there DX9 client settings for that? [19:01:00] its worse if you have higher definition terrain, like with ggalfi's stuff [19:01:26] advanced setup [19:01:34] surface texture load options [19:02:12] I feel like your PR might work well for you, but it won't work the same for everyone with different hardware and these settings [19:05:01] I mean it is a bit of a hack, but I think it should help instabilities regardless of terrain settings/system differences [19:06:17] with setting 1 it doesn't fully stabilize and with setting 20 it tends to flip out, is that accurate? [19:06:49] yeah, during loading [19:07:11] it will flip out during loading at 20* [19:07:33] well, jerk [19:07:53] I had it flip over when set higher like 30+ [19:08:10] but after 10 timesteps its stable [19:09:51] I will test with my slow laptop and see if 10 timesteps is also enough to prevent the instabilities at startup [19:17:59] right [19:18:30] do other vessels not have this issue? [19:22:20] non-NASSP I mean [19:29:02] the DeltaGlider doesnt not jerk at scenario start [19:29:09] does not* [19:29:40] however if it is on an incline of more then a few degrees, it creeps [19:30:26] I tested with gear up as it then uses coefficient set to 3 [19:30:39] which is what we used beffore [19:30:58] or are using now* (before the PR) [19:33:38] I mean in ideal world there is probably a magical set of numbers for the 3 values (stiffness/damping/friction) that will make the LM behave perfectly stable and not creep [19:34:08] I have been trying for 6 years to find these values :D [19:38:25] haha [19:38:36] now that we have Orbiter code we could maybe derive those magical numbers [19:39:09] true [19:41:00] ... it's a lot of code [20:02:14] so I won those LTA-8 Elementary Functional Diagrams and they should be here next week. as part of scanning those in the best possible resolution, I think I'm also going to sort and clean up the NTRS scans as much as I can, since they're kind of a jumbled mess [20:21:36] congrats on spending money :D [20:22:17] the good thing about the NTRS version is most pages were updated at some point so they appear twice, with one version being a bit better [20:44:31] AlexB_88, your PR is approved, I have no better idea [20:45:08] rcflyinghokie, for the erasable memory updates, I think I'll add the uplink pages for those and then have the EMPs in text files in the RTCC config filder [20:45:29] which should be quite similar how they actually did this [20:45:34] Oh that would be great [20:45:52] So would it no longer be in the UTI->EMP section [20:46:00] But the uplinks themselves [20:48:19] yeah [20:48:36] it was in the same category of MOCR displays [20:49:00] so would you choose the EMP in there or elsewhere (like the REFSMMAT) [20:51:06] in there [20:51:27] there won't be a section elsewhere in the MFD to calculate data for this [20:51:36] Ah ok that will be removed then [20:52:42] yeah [20:52:50] Another question regarding MCC pads, are ullage remarks in there hardcoded or dare they computed [20:53:00] I'll make it both more realistic and give it more options [20:53:01] *are [20:53:04] Awesome [20:53:16] I think the remarks are hardcoded [20:53:34] I don't have a function that calculates ullage time from vehicle weight or so [20:53:38] Ah ok [20:53:51] and I think I'm still missing ullage in a lot of places [20:54:39] Yeah I dont think 8 has ullage remarks as they werent in the flight plan [21:37:07] indy91, ok thanks. I tested it in many situations and it was stable...maybe you guys can just check to be sure the LM is still stable on the moon on your systems [21:37:22] ok, I'll do that [21:37:53] if you fire an RCS thruster with time accel, it will jitter and might fall over...but this was the case anyway even before [21:38:55] right [21:39:39] but with this PR, you can land on fairly steep slopes and the LM will not move [21:40:08] that's nice [21:40:15] the coefficients set to 20 really help for that [21:41:16] hopefully it will be stable for everyone...if we get reports of instability I can always bring the value down a bit [21:43:04] it looks the same for me. I used one of the Apollo 15 scenarios from Wedge313, but I think the main issue there is the different terrain installed [21:43:15] so the attitude at scenario loading isn't the same [21:43:37] it changes attitude when loading and RCS starts firing to compensate [21:43:55] ah right [21:44:04] and now once its settles, save and reload [21:44:14] it should stay steady at loading [21:46:30] hmm, no [21:46:39] but I feel like that isn't a problem with friction [21:47:13] https://www.orbiter-forum.com/threads/apollo-15-lunar-ascent-preparation-and-rtcc-procedures.40282/page-5#post-590031 [21:47:16] this scenario [21:50:58] yeah RCS is firing in that one [21:51:47] indy91, you dont have the Apollo 15 scenery, correct? [21:52:57] I have the scenery and when it loads there is a bit of RCS firing, I just recycled to ATT HOLD and back to AUTO to stop the RCS firing, then when I quit/reload its perfectly steady [21:53:04] no RCS firing [21:54:00] yeah, that's not happening for me [21:54:22] every time I reload the current scenario it starts firing again because of an attitude change [21:54:40] and I did cycle the PGNS [21:54:45] are you both testing that scn on different scenery? [21:55:22] I think so [21:55:32] but that should only matter on the initial scenario load [21:55:59] the behavior is the same without the PR though [21:56:27] so that isn't fixed, but it's also not making it worse [21:56:59] indy91, are you testing before or after the PR? [21:57:12] oh haha you just said [21:57:31] I'm testing both [21:58:19] maybe in the default terrain it's just a bad spot [21:58:58] weird im testing with the default scenery right now and no RCS firing on that scenerio [21:59:29] you sure you have no elevation maps in the moon texture folder? [22:00:14] oh [22:00:17] I have something there [22:00:26] did I install an old version of the terrain... [22:00:28] in July [22:00:46] I have some landed scns if they would help [22:00:49] different missions [22:02:37] rcflyinghokie, sure I guess it would be good to verify they are still stable with this PR [22:03:24] Any particular LM configuration? [22:03:35] just landed on the moon [22:03:42] I shall take a look [22:03:56] after I update [22:04:48] AlexB_88, ah, I do have the landing site installed [22:05:08] ah [22:05:16] but the RCS should still stop though [22:05:26] at least it does for me [22:06:06] maybe it depends on the settings [22:06:14] I didn't have mesh resolution set to 64 for example [22:06:35] yeah I forget about settings often..like my CM blown over thanks to atmo effects in orbiter :P [22:06:40] oh [22:06:52] that scenario's mode is set to "translation" [22:07:25] so the ACA out of detent in ATT hold for a sec won't work until you switch to rotation [22:07:54] Just loaded a 16 post touchdown scn no RCS firuing [22:07:56] firing [22:09:47] do you guys have Orbiter installed on an SSD? [22:09:59] yep [22:10:18] because for me it takes a few seconds for it all to load, so I think the terrain on the first timestep is quite different from when it has finished [22:10:35] and that's why it always has a terrain change [22:10:40] attitude change* [22:10:52] probably not in a super flat area like Apollo 11 landing site [22:11:02] oh it takes a few seconds for me too [22:11:07] but this spot in this Apollo 15 scenario is fairly rough [22:12:33] it takes about 5-6 seconds for me [22:12:41] same [22:12:56] but did you manage to stop the RCS firing? [22:13:34] cycle to off [22:13:37] and back to Auto [22:13:57] every time I load this scenario the LM even appears to be under the surface at first [22:14:42] hmm [22:14:45] something is weird [22:17:19] https://i.imgur.com/JlPdRCI.png [22:17:28] ignore the white part on the right, that was Paint :D [22:18:08] hmm almost looks like you mixed texture packages [22:18:37] I think the outer textures look like the ones from 4th_rock [22:19:16] and the inner ones are ggalfi's...he made them shadow-less on purpose [22:19:50] weird, I don't remember installing so many things haha [22:20:54] any idea where that would be? [22:21:09] I'm pretty sure I have only ggalfi's files in Textures/Moon [22:21:19] in the Surf folder [22:21:58] it would be quite hard to separate them now inside that folder [22:23:13] each folder number in there is a different texture level I think [22:24:24] I deleted the folder and reinstalled it [22:24:38] seems like I had two things installed there [22:27:07] but that doesn't change the behavior for me [22:27:48] https://www.dropbox.com/s/17pw3sp2ox37a1d/Screenshot%202022-01-27%2017.26.51.png?dl=0 [22:27:56] thats what mine looks like [22:28:26] same now [22:28:56] if I load the Apollo 11 pre lunar liftoff scenario with your update it also freaks out quite a bit and I get 8 red TCA flags [22:29:52] ... [22:30:00] in the old version the LM flips over [22:30:03] what is going on [22:30:10] it has to be my settings or something [22:30:21] that didn't happen before [22:32:06] so one thing I kind of got used to doing, when I load Orbiter I am usually tabbed out. No idea why I started doing that, but when I do that the LM doesn't flip over, but still 4 red flags [22:32:46] but right now I can't really load any lunar surface scenario properly, doesn't matter with or without PR [22:34:16] when you revert between pre-PR, post-PR states, are you also reverting the tdv[i].mu = 20; [22:34:17] tdv[i].mu_lng = 20; back to 3 when testing the pre-PR state? [22:34:20] so I don't think it's an issue with the PR, just something on my side [22:34:47] uhh [22:35:04] I'm mostly loading saved scenarios [22:35:13] not load/save/load [22:37:09] but it's getting too late, I'm not going to make smart debugging choices today anymore :D [22:38:24] very weird behavior [22:38:59] And I don't think I really changed much [22:39:16] I updated DX9 Client not too long ago [22:39:25] I loaded a few landed scns from 15-17 with the terrain installed and didnt get RCS firing [22:39:39] the only time on my system I saw it jump like that at loading was when I had set the coefficients to 20 in the touchdownpoints, but with OUT setting a counter in the timestep [22:40:03] thats why I added that bit in the timestep, so it stops making that jump [22:40:23] but very weird as you said it happens even before the PR [22:40:25] well I'll look more into it tomorrow, I'm sure I set up something wrong. Or my PC is dying or something [22:40:58] are you running a 486? :D [22:41:12] fights off bitcoin miner for graphics card. [22:41:27] lol [22:41:51] HDDs do like to die on me [22:42:37] I hope I can get it resolved. Good night! [22:42:48] cya! [22:43:56] Thymo did you see the reply wrt the FDAI texture use? [22:44:01] very weird what Nik is seeing...rcflyinghokie, was there any instability noticed on the moon before & after this PR? or anyone else? [22:44:20] Before yes, I was usually unstable after loading a save [22:44:28] the rate needles would jitter [22:44:39] right, that would happen to me too [22:44:40] and the LM sometimes would slide a little bit [22:45:00] but what Nik is describing is a bit more severe, like the LM flipping over [22:45:06] I think the jitter impacted RCS firing after landing, ACA out of detent wouldnt always work [22:45:12] Yeah I didnt see that in any that I loaded [22:45:38] the sliding should be a thing of the past now, with the PR [22:45:57] you will still see the jittering but only for a few seconds at most [22:47:42] I didnt see it at all for 15 16 and 17 post landing scns I loaded [22:48:25] I didnt try the one Wedge posted, he was landed on more of an incline than any of mine [22:48:42] I remember that from doing a P57 in his scn and seeing the FDAI after haha [23:42:06] Still not sure how I feel about this and it's use/distribution https://www.orbiter-forum.com/threads/fdai-textures.40324/ [23:45:38] I think n7275 also pointed out a slight inaccuracy in it [23:46:20] iirc pitch is off by one degree [23:46:25] not that its un-fixable [23:46:50] but yeah better be totally sure its legal before we do anything [23:47:06] I'm not comfortable using this without permission from the original author [23:47:19] Yeah thats my concern, it was made my another author, he "edited" it and is distributing it [23:47:41] Just the post makes me uncomfortable to be honest with the file in there [23:48:00] Saying we should put it in the next release just like that [23:50:03] btw I think I found out the cause of Nik's instabilities [23:50:55] he was right its not caused by the higher friction, but by the damping/stifness factor [23:53:46] on my slow laptop I was able to replicate the behavior and it was there even before the PR [23:54:04] Ahh [23:54:14] Thats one case I cannot test is slower computers [23:54:17] a slight jerk or jump when starting a scenario from the lunar surface [23:54:22] haha [23:54:24] me neither [23:54:38] I am running on a beefy system, even my laptop is beefy enough to handle it [23:54:39] but on Nik's 486 its a different story :D [23:54:42] Hahaha [23:55:41] setting the x-factor (damping/stiffness) from -0.25 to a more stable -0.5 makes the jump go away [23:56:01] x_target* [23:57:25] I just need to make sure that doesnt screw anything else up [01:11:26] .tell indy91, I was able to recreate the behavior on my laptop that you described, and it happens regardless of the previous PR...It is due to the x_target factor for the damping/stiffness, The default is -0.5 but I had it set at -0.25 for the landed stages but this is causing issues on some systems. I have made a PR to put it back to the default value -0.5 and this should fix your issue [02:29:36] interesting, someone found an interesting save/load bug with SMRCS [02:30:02] He saved when the SMRCS CW light went off for low pressure (typically signifying opening the SEC fuel valves) [02:30:12] But upon load, it loads a default pressure of 185 [02:52:43] once we merge the specific heat update we could look at doing that with the substances [03:30:12] oh absolutely [03:30:28] I still want to also add proper pressurization via bladders [03:30:40] And, mixing substances for the DPS He [03:47:51] n7275 any idea why that pressure loads as 185? [03:48:11] I also see the other quads are 185 even [03:49:45] welcome CaptainSwag101! [03:49:48] hello! [03:49:52] Yep you made it [03:49:57] woohoo [03:49:59] <--Folgers/Ryan [03:50:10] you can call me James if you like [03:50:27] or just Cap, Swag, whatever [03:50:31] Yeah we are on pretty casual first name basis here [03:52:33] sounds good! [03:52:42] lemme just figure out my nickname registration [03:53:12] ah yeah good idea [03:56:32] okay I think that's sorted, let's see [04:01:50] okay test [04:01:52] there we go [04:01:54] all sorted [04:02:05] woo! [04:02:14] nice [05:24:41] I have no idea [15:19:44] hey [15:20:06] morning [15:27:51] hey guys [15:29:03] when had you set it to -0.25? [15:29:18] long time ago [15:29:40] probably 2018 or so [15:29:58] I am running a two monitor setup now. I get good frame rates, but if anything has changed for me is that things seem to load a bit slower now. Or at least the first few seconds are worse if I have a second monitor [15:30:21] maybe that makes a difference [15:30:30] yeah, I think thats it [15:30:58] the -0.25 was borderline for stability, but with faster systems, you don't notice any issues [15:35:12] hmm, one monitor doesn't make a big difference for me [15:35:38] I hope it's not my hard drive dying, becoming slower to load or so [15:35:52] which DX9 Client version are you on? [15:36:19] 30.7 [15:38:17] there are 2 30.7's I believe [15:38:52] make sure its the r90 one [15:38:54] ok, I have the same [15:39:50] AlexB_88, Apollo 11 mission scenario no. 17 Before Lunar Liftoff [15:39:58] if you load that, do you get TCA flags? [15:41:01] not with my main PC, but I did get it with my laptop before setting the -0.5 [15:41:46] I was abble to re-create all the behavior you described on my laptop (jerk/jump with TCA flags) [15:42:27] but setting the x_target to -0.5 and its rock solid at loading, no TCA flags at ll [15:42:42] I just merged and updated, nothing has really changed for me sadly [15:43:11] hmm [15:43:32] it must be something on my system rather than these small tweaks [15:44:08] I don't know why. But I guess I have to load the simulation in the paused state from now on [15:44:17] that fixes 90% of the issue for me [15:44:52] Is there an option to load a scn paused? [15:45:07] I wonder if that would help a lot of issues [15:46:04] indy91, do you mind testing something? Set tdv[i].mu = 1; [15:46:05] tdv[i].mu_lng = 1; in ConfigTouchdownPoints in the LM [15:46:29] rcflyinghokie, in the Orbiter Launchpad, top right [15:46:33] to see if that very 1st timestep setting it to 20 is causing issues [15:46:37] "Start Paused" [15:46:45] ah I never saw that [15:48:04] AlexB_88, sure [15:49:01] on my local copy I have added a check on FirstTimeSTep [15:49:13] might not be a bad thing [15:49:30] feels slightly better, but still TCA flags because of an attitude excursion [15:49:45] and then if you save reload? [15:49:47] well, it's random [15:50:10] it tried to flip a bit this time [15:50:24] changed attitude by 15° before it settled again [15:51:01] thing is the -0.5 does slightly modify the settled height I think, so an old scenario will have a jerk but then if you save/reload it shouldn't move at all [15:51:19] reloaded the current scenario [15:51:22] this time it did fall over [15:51:49] surface elevation using linear interpolation? [15:52:02] or should I use cubic [15:52:09] pretty sure I changed this around some times [15:53:03] linear [15:55:06] your friction counter is still setting the number to 20 [15:55:12] after 10 timesteps [15:55:38] if I change that to 1, no attitude excursion and TCA flags. But could be a fluke [15:56:29] well, small attitude change [15:56:33] again no TCA flags [15:56:48] and what about current scenario... [15:57:17] about the same behavior [15:58:24] in the Apollo 15 scenario, small attitude excursion, large enough for RCS to fire [15:58:32] and it's sliding [15:59:28] yeah with 1 its basically a scating rink [15:59:39] skating* [15:59:46] the issue seems to be that the number is set to 20 too early, on my system that is [15:59:59] try increasing the counter [16:00:50] yeah [16:02:48] uhh [16:02:53] why is it still sliding [16:04:34] is there a difference between the mu of touchdown points and the one you use in SetSurfaceFrictionCoeff? [16:05:07] I think its the same [16:06:05] ohh [16:06:31] if you increase the counter, also set the == to the same value [16:06:52] ah right haha [16:07:00] I made that mistake lol [16:07:14] just looked it up, I can tell you the difference [16:07:31] Orbiter only uses the touchdown point mu and mu_lng [16:08:04] SetSurfaceFrictionCoeff does two things. It saves a "global" mu and mu_lng for the ship and sets the mu and mu_lng of all touchdown points to those values [16:08:44] there is a version of the SetTouchdownPoints function with 3 VECTOR3 as inputs [16:09:02] if you use that simplified version then it uses the vessel wide mu and mu_lng to generate touchdown points [16:09:08] other than that they are not used [16:09:30] so for our purposes, SetSurfaceFrictionCoeff justs resets all touchdown points to those new values [16:11:06] right [16:13:06] so if I set the counter to 100 it works better for me [16:13:25] no TCA flags, that Apollo 15 scenario does have RCS firing, but if I save/reload it doesn't anymore [16:13:36] but this number is probably very system specific for mr [16:13:38] me* [16:18:09] I mean 100 might be the best in general [16:18:48] hey guys [16:20:31] hey [16:22:33] n7275 I know I am doing the ECS changes, but would you mind helping me try to figure out why the CM is not venting at about 25k ft during boost, it doesnt seem to vent until well out of the atmosphere [16:34:23] indy91, when everything is loaded on the moon if you say change views in the VC and 2D panel rapidly WHILE firing RCS...Are things stable on your system? No jumps? [16:34:48] with the friction set at 20 [16:40:07] rcflyinghokie, sure [16:40:41] the pressure relief code is so convoluted I am just having trouble making it out right now [16:40:55] I cannot find what triggers it to open [16:41:12] seems like it might be mission scenarios that have the issue, but not the -4hr? would you agree? [16:41:14] Debugging a boost the atm pressure is like zero and cabin press still >15 [16:41:28] I will test a fresh one now [16:41:41] I would look at flow rate through the valve. [16:42:42] morning! [16:42:57] it may be with my latest systems update that cabin pressure increases for a little while, but with only 60 seconds until launch there isnt enough time for it to stabilize [16:43:00] hey mike [16:48:18] the solution--if that is the issue--is to "refly" the prelaunch sceneriaos. [16:48:23] unless I have my debug line wrong flow rate is zero for almost all of boost [16:48:31] hmmmmmmm [16:48:46] sounds like the valve is closed then [16:54:37] the logic for this looks like its in ecs.cpp lines 421-432 [16:55:26] Yeah which is where I am and where my debug is [16:55:33] It just doesnt make much sense to me lol [16:55:39] As I said, its convoluted [16:56:18] I know I shoudlnt worry about this and I should just keep pressing on with ECS rework but it bothers me and seems it would be a quick fix...If I can decypher it [16:57:57] Ahh [16:58:02] its the T-XX scn [16:58:07] it opened on a fresh launch [16:58:21] So some state isnt set [16:59:02] okay. well that makes sense [17:00:39] not really a bug, just things not liking the sudden change of physics [17:00:53] yep [17:01:04] I am not going to worry about it then [17:02:43] you can blaze through prelaunch with auto checklist in 24 minutes at 10x [17:07:40] I usually run it at 30x [17:07:53] then back to 10x about 2 minutes before [17:13:32] Are the Shift + WASD keybinds set by NASSP? [17:16:22] I dont think so [17:17:24] They control RCS [17:17:41] Hmm [17:17:56] Even if I turn off the RHC Normal and Direct switches [17:18:34] Wait only in CMC control [17:18:47] LEB min imp controller? [17:21:11] yes [17:24:00] AlexB_88, seems quite stable [17:24:07] oh whooops [17:24:23] I think for me it's just that initial terrain loading that's the problem [17:24:31] my framerate is good and stable [17:24:38] ok so the coefficients themselves are stable at 20 after loading [17:24:47] I think so yeah [17:24:57] after it has settled definitely [17:25:06] so the issue with the friction timer at 100 is that the LM has time to slide about a foot in that time [17:25:08] not good [17:26:20] and it seems that for you and on my laptop, the friction needs to be at 1 for 100 timesteps for it to be stable at loading [17:27:00] which is weird because the DeltaGlider has it at 3 all the time and not stability issues at loading [17:28:02] someting tells me there is something still wrong/unstable with the damping/stiffness even at -0.5 [17:28:55] indy91 does the DeltaGlider ever show instability on loading for you? [17:31:13] not really [17:31:17] but it can slide [17:31:26] right, with 3 it will slide [17:32:33] I have a test with a DG on a slope, landed gear up as that makes all the TD point friction at 3. Sorry I am giving you a lot to test, but if I give it to you do you mind just checking if it loads stable? [17:32:57] https://www.dropbox.com/s/djjpdzf7qmwlnsy/DG%20slope%20test.scn?dl=0 [17:33:28] it will slide a bit but I would like to see if it loads stable with no jumping on your system [17:33:31] oh it's no problem [17:33:53] I better make sure it's the same DG though [17:34:02] pretty sure I have experimented with it and build dlls [17:35:54] no sliding [17:36:03] of course I got the usual issue when the terrain is loading [17:36:06] attitude change a bit [17:38:09] right [17:38:27] but not the big jump like in the LM I guess? [17:39:04] because in the LM, with the same friction value (3) you get a jump at loading, and this was the case even before the PR [17:39:43] could this be a 3 touchdown point vs 4 touchdown point thing? [17:40:45] so I think the damping/stiffness needs to be re-thought...I am thinking of using the DG vales as basis, it uses 1e7 for stifness and 145 for damping [17:40:49] there is also damping and stiffness [17:40:51] ah yes haha [17:41:08] 1e5 for damping* [17:41:22] maybe I can just scale it for our weight [17:41:40] the LM is about 31% the DG weight [17:41:53] at landing time [17:43:39] n7275, I think its just a question of adjusting the damping/stiffness of each point [18:05:23] that makes sense [18:20:49] so it seems that the DG's values, scaled at 0.3 give about the same "feel" to the LM touchdown points as the DG...but its way less stable [18:21:29] I am thinking probably due to the longer loading needed for the LM, bigger meshes etc [18:50:54] so it looks like im getting stability by scaling the stiffness/damping to very low values [18:51:47] it might be a bit unrealistic ie. no bouncing or anything but it might be the price to pay [18:51:58] anyway Ill look at this more tomorrow, cya! [20:30:16] indy91 random question, are you familiar with the Gemini/Titan guidance at all? I am curious about the 90 degree turn it gave the crew [20:30:33] nah, no idea. I heard about that though [20:33:37] I have heard a few different theories from it being done for ejection (but I dont know when in flight it performed this roll) or that it was a throwback to the original missile guidance system [20:33:48] Was trying to find some docs that might explain it [20:59:20] Welcome! [20:59:27] I see you found our IRC haha [21:03:02] Hello, I'm Paolo, thank you for having me. For those of you who don't know me, I'm the creator of the 3D model of the Apollo Mission Control Center, used by space-themed YT channel Lunarmodule5 and Reentry an Orbital Simulator [21:05:34] hey, welcome :D [21:05:47] thanks, great to be here [21:06:00] indy91, Mike and I wanted to introduce you especially with all the MOCR displays and RTCC work you have done [21:06:02] I've made it somehow :') [21:06:19] yeah that would be great [21:08:34] the one time Nik is quiet ;) [21:10:16] But yeah very much welcome, we have most of our dev chat here for NASSP and its a great little group of nerds [21:11:15] great to have found it [21:13:33] hello! [21:13:37] hello [21:14:23] I'll probably need to ask for some help to register my nickname and secure my presence here, I'm not very familiar with libera chat [21:15:43] Thymo can certainly help with that as well [21:16:20] Its not too hard though: https://libera.chat/guides/registration [21:16:24] we also have a model of the MOCR, but it's very... basic haha [21:16:45] Alex created that one, just enough so that you can display a bunch of MFDs in it [21:17:17] good to know [21:17:44] hey Paolo! [21:17:52] I'm the one who gets happy when I find an exact display format for one of the screens and then get sad because MFDs in Orbiter have the aspect ratio of 1:1 and I have to somehow squeeze it in [21:17:59] mine took a few years of research, I was still in high school back in 2014 when I started my quest for informations to recreate the room [21:19:17] one ambitious long term project is to process telemetry and then have it be displayed in the MOCR. Of course it's not just the screens, but also a lot of lights on each console that are driven by telemetry data [21:19:28] I can understand that, mine was all about making it realistic-looking. I didn't think it would end up in a simulator like Reentry [21:19:29] Similar to what reentry has [21:19:33] because we do generate most of the CSM and LM telemetry [21:20:18] yeah reentry uses my model [21:21:11] since the model has all of the telemetry lights with labels it would be possible to link them to the proper telemetry command [21:22:26] yeah, for the lights we know what each was doing from the Apollo 15 MCC Operational Configuration document [21:23:17] I used it for the labels. That's PHO-TR155 [21:23:33] yep [21:23:43] probably the most valuable document about the room [21:24:07] for the screens, which is my specific interest, I wondered what they used in the actual, restored MOCR [21:24:47] so I contacted them. they did not find any more documentation than is available on the Internet sadly. But what they did have is hardcopies of some displays [21:25:10] as you probably know they could press a button on the console and then they got send a copy of what their scren was currently showing [21:25:18] yep [21:25:59] https://twitter.com/poppy_northcutt/status/1210053922137821186/photo/1 [21:26:00] like this [21:26:16] oh wow [21:26:21] I needed that display [21:26:25] many thanks [21:26:48] no problem. I implemented that in NASSP, too [21:27:22] I'll replicate it in the blink of eye [21:28:03] and my other main source was stock footage taken when they were doing simulation runs for Apollo 14. Stock footage for a documentary. [21:28:15] So in that video you can see stuff like this: https://i.imgur.com/THJBg90.png [21:28:34] That's of course even better than a hardcopy, that's the actual display with numbers [21:28:46] but you can't see many of these in the video, at least not with any clarity [21:28:51] yeah I've found those about a year ago on the us national archives [21:28:56] yep [21:30:18] I can't adequately describe my excitement when they came across my laptop screen [21:30:47] and then what I also found is an IBM document with details about the calculations for some displays. And in some cases it also showed how the display is supposed to look like. [21:30:58] I immediately proceeded to secure them on my hard drive :') [21:31:22] I don't think I have that IBM doc [21:31:38] There is two screens I managed to decode from that video in long work. By knowing roughly what it should show [21:31:58] it's a pretty large document [21:32:04] https://web.archive.org/web/20100525000249/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19730062603_1973062603.pdf [21:32:18] one example of what it contains is e.g. PDF page 958 [21:32:39] there is a bunch of these [21:33:36] and in another IBM document there is a list of all display formats, but just with their name and number, no additional details. It's a few hundred, most of them just telemetry being formatted in different ways. [21:33:44] not sure if that is any use to you [21:33:46] yeah it's pretty large. Can't wait to dig through the pages for infos. Btw the mocr videos are about six or seven and I was able to replicate some screens for the booster, surgeon, fdo, guidance consoles [21:34:21] ah great. I'm sure I have seen those all as well, but do you have a list or so of what you managed to replicate? [21:34:49] I'll be very happy to look at them anyway. About the list, give me a sec [21:35:07] I know there were some gorgeous shots of the Booster (BSE) screen [21:35:11] with some telemetry [21:36:15] yep [21:36:26] I have about 27 apollo-era displays [21:36:42] this is how it looks like in NASSP, that Lunar Orbit Insertion Planning display: https://i.imgur.com/gEmw7um.png [21:36:49] quite basic, and wrong aspect ratio [21:36:55] but we can't do much about that [21:37:23] but the calculations are done to spec and the display is very close, too [21:37:34] no problem about the ratio, still looks great [21:37:54] yeah, some displays contain a lot of information and the ratio becomes a problem haha [21:38:11] I can imagine [21:39:39] one of my deciphering projects was this: https://i.imgur.com/ZrjQ26B.png [21:39:51] not sure it's the best frame from the video, but nearly [21:39:58] Oh the VPS? [21:40:03] yeah [21:40:14] Haha I could tell what the blur was based on our VPS [21:40:19] I couldn't replicate that sadly [21:40:30] well I could by knowing what it should display [21:40:36] another I couldn't was the checkout monitor [21:40:48] I got you covered [21:40:58] that sounds great [21:41:06] and that IBM document I linked, it has the description of the computer function that calculates both the vector panel summary and the checkout monitor [21:41:15] functions* [21:41:36] beautiful [21:41:47] checkout monitor is on PDF page 792 [21:41:55] but that's slightly outdated. [21:42:10] because the pages before that describe each item and there are some additional ones [21:42:21] glad I downloaded the doc on my computer [21:42:22] and those additional ones I have seen in the Apollo 14 sim stock footage [21:42:29] fantastic [21:47:38] just look through that whole IBM RTCC document, there is a lot of displays. IBM was mostly interested in describing what has to be calculated for each number on a display and not to show a high res photo of the display [21:48:00] displays for telemetry only have nothing extra to calculate for, so they aren't in there at all [21:50:01] absolutely great document [21:51:02] I really wish we had more Philco documents, like that PHO TR155 [21:51:17] I am fairly certain there should be one with the display format descriptions [21:53:21] https://ntrs.nasa.gov/api/citations/19730010501/downloads/19730010501.pdf [21:53:41] this is about the display formats for design and production during the skylab program [21:54:08] yeah, I know that one. It gives the full data for one example display [21:55:11] yep the csm gnc rcs maneuver [22:10:48] I'm sure you have seen high res photos from the restored MOCR [22:10:50] https://cdn.arstechnica.net/wp-content/uploads/2019/06/console-row1-retro2.jpg [22:11:57] the right one, Lunar Launch Targeting Table, is funny to me. It is a display for the short rendezvous profile after lunar ascent. A sequence of maneuvers first flown on Apollo 14. And they changed the numbers from their hardcopy to Apollo 11 numbers [22:12:22] of course kind of impressive that they put in that effort to make it more Apollo 11 like. But then they shouldn't have used this Apollo 14+ display :D [22:14:00] well the room is supposed to depict the apollo 15 layout, to me they shouldn't have messed up with the hardcopy at all '=D [22:15:29] yeah weird, but they changed e.g. the latitude and longitude of the lunar landing site (LLS), top right of the display, to Apollo 11 numbers [22:15:48] although they mixed up latitude and longitude haha [22:17:23] and they hoped no one would notice [22:17:30] so do you research the displays mostly for Reentry? I have seen some pictures of their MOCR with some displays. [22:18:11] not only, the model is always to be upgraded [22:18:22] right [22:18:30] reentry uses a mix between original and custom made displays [22:18:57] Petri, the creator of Reentry, made some on his own to display orbital data and so on [22:19:29] I think he'll be very happy to look trough that IBM doc [22:20:22] that's a really great document, but the main thing interesting for you will be the list of all displays [22:20:28] starts on PDF page 472 [22:20:44] as you will see, there are hundreds [22:21:35] listed by MSK, which I think stands for multi select keyboard? [22:21:50] it's that thing on each console where you enter a 4 digit number and press a button [22:21:53] and then you get that display [22:22:03] manual selection keyboard [22:22:08] ah right, manual [22:22:10] yes [22:23:38] most of that list is acronyms [22:23:44] I know most, but not all of them haha [22:25:05] that room is just a universe of acronyms haha [22:35:07] that one has the massive table of MED formats too :) [22:36:37] yep, really impressive [22:40:43] anyway, I think I'll get some rest, it's almost midnight here, tomorrow will be a long day. Thank you to all for warm welcome and the documents. Talk to you all soon [22:41:22] same for me haha. Good night! [13:07:40] Hey [13:08:16] Someone posted this to the Discord. Had me laughing xD https://cdn.discordapp.com/attachments/809545464331370506/936891765871501322/youcanhaspad.png [14:11:06] it always gives me the feeling "yes, the RTCC calculation didn't break" [14:13:53] Thymo, what do you think about my draft PR. Here is my problem I still have with it. There is two airfoil functions, vertical and horizontal. But both have to do the same interpolation which feels unnecessary. And after the interpolation the aerodynamic coefficients in each axis are calculated. [14:14:19] The advantage is, the numbers being interpolated are straight from the CSM Data Book [14:15:19] the alternative would be, make an even larger array of data, of rather 5 of them. Which then isn't bilinear but trilinear interpolation [14:15:38] The advantage of that is, no calculation is done twice and the result of the interpolation is already what Orbiter wants as coefficients [14:16:11] But it will be a lot of data points which are then not from the Data Book but are already pre-processed so to say [14:16:21] not directly* [14:17:38] oh and I think you would need to generate a whole new array of data if you wanted a different CG location, not actual CG in Orbiter but just in terms of aerodynamics [14:17:55] right now it would be fairly flexible in that regard [15:33:15] flexibility in cg location seems advantageous [15:38:00] good morning, by the way [15:44:30] would you need a different array for different cg locations though. you have the moment coefficients. [15:46:45] hmm right. I am already using the center of pressure vector [15:47:39] if that was set to 0 then I would have to re-calculate all the moment parameters for each different CG location [15:48:29] although right now I am only using it in one axis, the other CG location axis is used in the airfoil function for the calculation [15:48:43] *cm = sin_phi_A*(C_M_A + C_NY * (1141.25 - 1040.9) / 154.0); [15:48:55] 1141.25 is the reference position [15:48:59] 1040.9 the CG location [15:49:44] what I haven't tried yet is make 1141.25 the location of the center of pressure [15:50:02] that would of course be quite wrong, but I could make use the moment coefficients from the CSM Data Book directly then [15:52:23] and then, if I would to use a 3D array to interpolate in for each axis, that array would be independent from the CG location [15:56:21] that would be interesting [16:03:37] seems to give the right numbers [16:04:26] it's interesting, I have two documents for the NAA simulator. One for CSM-101 and one for CSM-103 [16:04:43] one uses the same aerodynamic reference as the CSM Data Book [16:05:05] which is at the apex cover, not anywhere near the real center of pressure, but a useful reference [16:05:32] but in the 103 version they probably thought the same thing as me. That's not really the actual aerodynamic reference, so we shouldn't use that [16:05:50] but then you need to convert all the moment coefficients [16:09:58] hey [16:17:49] hey Alex [16:17:51] hey Alex [16:18:06] good synchronization [16:18:13] we'll get it down to half a second I am sure [16:32:58] haha [16:33:14] AlexB_88, what does your latest PR do? [16:33:25] when else is ConfigTouchdownPoints called [16:33:33] if not on the first timestep [16:33:35] staging? [16:37:30] the 1st calling of ConfigTouchdownPoints on loading [16:38:47] the thing we talked about where its set to 20 before the counter sets it to 1 for 10 timesteps then back to 20 [16:39:15] its to prevent it from going to 20 before the counter finishes [16:40:09] morning! [16:41:35] hey Mike [16:41:51] hey [16:42:02] but when is ConfigTouchdownPoints called otherwise? [16:43:57] staging [16:44:36] also the CG shift stuff calls it every CG change [16:44:51] oh right [16:45:30] and at gear deploy [16:45:57] merged [16:46:40] thanks, but this might not be the last PR in the touchdown point saga :D [16:47:04] I am working today to find some better damping/stiffness numbers [16:47:39] and fingers crossed it might actually be stable enough to remove the counter hack [16:47:56] I am fine with better numbers. I have more problems with code getting more complicated, special cases etc. [16:48:12] yeah, hopefully I can remove the complications [17:02:43] Taking a look at that PR now [17:04:05] it's a classical case of readable code vs. efficient code [17:05:29] but I think at least the part about being more flexible with a different CG is solvable if I choose the more efficient solution [17:06:31] Thymo, if you compare CMVertCoeffFunc and CMHorizCoeffFunc, everything before "if (Kn > 10.0)" definitely needs to be done in both, no way around that [17:07:01] but then the next part is the interpolation and that is done in each, exactly the same way. That is what annoys me a bit haha [17:13:26] so the same 3 interpolations for C_A, C_NY, C_M. Then more calculations to resolve it into the two axes, different in the two functions. [17:14:34] I mean, the details aren't super important. I just wonder if it would be a good idea instead to make a large 3D array with all these numbers for cl,cd and cm already pre-calculated [17:27:33] indy91, if I understand correctly you still get an attitude excursion at scenario load on the moon correct? [17:27:52] always [17:28:05] there are different levels of elevation data fidelity, right? [17:28:14] Those load one after each other [17:28:15] unless you increased the counter [17:28:24] yeah [17:28:37] that's what is always causing an attitude excursion [17:28:43] as long as it's small it's fine I guess [17:28:44] Im not too sure exactly how that all works though, the terrain loading [17:28:48] increasing the counter made it better [17:34:58] indy91: I assume this is done every timestep? Overall I think it looks readable, eventhough this goes way above what I'm educated for. The question you want to ask yourself is if folding those 3 interpolations into a single 3D array will improve the computational complexity at all. [17:35:42] good question. It's done at least once per timestep. Was trying to track that down. It could be multiple times per timestep in Orbiters numerical integration [17:35:51] and good point about the complexity [17:36:35] Overall I think it looks good, its pretty well commented so that even allows me to roughly get insight into what steps are going on. Things like those blocks of constants may look ugly, but you need to put them somewhere so that's totally fine. [17:36:52] yeah and that block would only get worse if it's 3D [17:37:04] SSU loads its aero parameters from csv files [17:37:31] if I would go to 3D then I might do the same [17:38:06] the good thing right now is, that block of constants is taken directly from the documentation I mention in the comments [17:38:32] nothing processed about those. So if there is any typo or something like that it could be corrected without having to recalculate all the numbers [17:39:03] and anyone but me would first have to figure out how those constants were even generated [17:47:16] Yep, the most important is that someone touching it in the future atleast has an idea how to constants were determined. Coming from the databook makes it obvious, I'm not sure precalculating it and documenting it is doable especially if you're doing it in a file. [17:47:40] Alternatively you could calculate it once in the first timestep and then store the result for the next timesteps? [17:48:02] Provided its not too heavy on the first timestep [17:49:04] you mean to solve the issue with calling CMContinuumFlowAero twice? [17:50:16] one solution I thought about was calculating the numbers in e.g. CMVertCoeffFunc [17:50:23] and store them [17:50:27] and then let CMHorizCoeffFunc use them [17:50:28] Yeah and the 2D/3D thing [17:50:36] Yeah like that [17:50:47] the two functions are called in the order they are registered with Orbiter [18:57:13] not to go off on too much of a tangent, but how broken is SSU these days? [19:11:17] when I worked on the Shuttle FIDO MFD I found it quite usable [19:11:40] coming from NASSP I thought it was lacking a lot of DAP and GNC functions [19:11:55] I actually implemented them partially myself, just so I could fly it haha [19:12:14] but didn't get them into a state where I could really contribute any update to SSU [19:13:12] indy91, I might have a testing branch soon with adjusted damping/stiffness/friction values...and with the counter stuff disabled, do you mind testing it when you have a chance and check the stability at loading [19:13:26] sure, no problem [19:13:40] I seem to have the more problematic system, so it's a good test haha [19:13:50] ok, won't be long ill have it up [19:54:35] indy91, https://github.com/jalexb88/NASSP/commit/924b5a9b73a8ca22702f6665b587097652875d11 [19:55:25] so im now using friction of 10 [19:55:43] it should be more stable then 20, but still arrest the creep [19:56:05] and the x-target of -1.0 makes the damping/stiffness more stable [19:56:31] hopefully it makes it load stable without the need of the counter [20:02:21] I'll give it a try [20:05:20] ah, it's your Orbiter2016 branch [20:05:28] and not a branch, branch haha [20:05:38] I know [20:05:43] that was a mistake [20:06:02] I wanted to make a separate branch, but I forgot before hitting the commit button lol [20:08:34] seems like I can have have the variable CG of the CM (just for the aerodynamics of course) all in the center of pressure vector [20:08:39] so all in one place [20:08:56] Orbiter airfoils aren't as useless for us as I thought haha [20:11:41] AlexB_88, first impression, very good [20:11:57] Apollo 11 didn't move at all as far as I could see [20:12:03] needles jittering, that's it [20:12:14] Apollo 15 scenario only moved a little bit [20:12:16] in attitude [20:12:19] no sliding [20:14:17] awesome [20:21:39] needles jitter a bit for the 1st few seconds and then stop [20:22:28] yeah [20:22:30] it's always done that [20:29:33] and you don't get any TCA flags? [20:30:56] I guess that would be the Apollo 11 lunar launch scenario that did that, with the RCS main SOVs closed [20:33:23] yep [20:33:26] no flags [20:35:04] great [20:35:09] but to be honest, I don't trust this to be consistent behavior [20:35:24] I got the issue worse than ever before in the last days [20:39:10] the damping/stiffness was -0.25 before, that was borderline stable even for a fast machine [20:39:51] the x_factor was -0.25* which is what is used by the damping/stiffness equation [20:40:16] so that was the real culprit, even the counter didn't help that [20:47:18] ah interesting [21:00:58] you never have any loading instabilities with the Saturns on the pad? [21:01:27] hmm well, now they are forced landed until liftoff anyway [21:07:16] can't remember any [21:07:36] not until we first figured out touchdown points for it [21:11:45] but I guess it's a nice, flat terrain [21:12:12] true [21:13:39] I'll do a bit more testing, but I think im quite happy with these numbers for the LM TD points, Ill PR tomorrow [21:14:07] with all that timestep stuff removed [21:14:29] nice [21:14:53] should be the last of the PR's for this for a while [21:16:24] until someone on the forums says they loaded their LM and it went to Plaid :D [21:54:52] Looks like the FDAI texture legal discussion has been solved [21:56:56] ah nice [21:57:21] and looks like he's also aware of the yaw discrepancy [21:59:45] night! [22:03:07] indy91_: How difficult is it to calculate an Entry MCC with the RTCC MFD. I'm a little over 15 hours from EI and want to make sure I'm still good. [22:03:22] P37 gave me -119.1 dvZ [22:03:33] high speed procedure? [22:04:06] it's a two step process to get to a DV vector for a Maneuver PAD, but if you only want to check what the total DV will be the first step is enough [22:04:15] Abort Scan Table [22:05:23] Maneuver Targeting, Entry, Abort Scan Table that is [22:05:50] Then for the transearth MCCs you usually would only do corridor control [22:05:54] not targeting a specific longitude [22:06:04] so that would be [22:06:05] High speed yes. I forgot to do the peturbed solution, -119 was conic. Running it now. [22:06:11] TYP: Unspecified area [22:06:18] SIT: FCUA [22:06:25] that mean fuel critica, unspecified area [22:06:32] critical* [22:06:45] then you need to choose a TIG [22:06:55] rest of the inputs can stay as default [22:07:12] AST button to go to the display and then CLC to calculate [22:07:29] in the middle column there will be a DV [22:09:00] DV 0,00 VEI 36226 GEI (angle I think?) -6.51 GETEI 148:48:25 LNG IP 165W [22:09:09] 0.00??? [22:09:10] So I'm good still :) [22:09:16] Yeah [22:09:24] that's almost suspicious [22:09:55] I don't need to get a DC vector from the vector panel right? [22:10:00] nah [22:10:06] only if you use the MPT [22:11:16] https://puu.sh/IFNQ0/9ac39a38fe.png [22:11:19] https://puu.sh/IFNPw/cbcf622087.png [22:11:58] did you just perform an RCS MCC? [22:12:30] 30 hours ago at MCC-5 [22:12:35] 6 was scrubbed [22:13:03] -1.0 dvx 0.0 dvy -0.7dvz [22:14:00] it probably has to do with the iteration [22:14:09] it uses current trajectory as initial guess or so [22:14:15] and then doesn't ever have to change it [22:14:27] so even if the actual DV could have been 0.03 or so it stayed at 0.00 [22:14:38] because of convergence limits [22:15:31] I think you can trust it [22:15:41] splashdown longitude also exactly 165° [22:16:28] the Abort Scan Table is: integrated trajectory, but impulsive maneuver [22:16:55] if you would want to do the maneuver you would then go to the Return to Earth Digitals and select a thruster, mainly [22:17:23] but that's obviously not necessary :D [22:18:49] Cool [22:19:38] P37 still wants -118 dvz after doing the peturbed solution [22:20:31] But apart from that it pretty much agreed with the RTCC on V400K and Gamma EI [22:20:46] hmm, weird [22:21:30] If you don't do the high speed procedure you get more like 50-60 ft/s iirc [22:21:43] if normally the DV was 0 I mean [22:21:59] time to do some vector comparison? [22:22:24] I can take a look at the scenario if you want [22:22:47] I would. but that would bring us into the discussion of what downlinked state vector is to be used [22:22:59] I did uplink a fresh one right before the P37 though [22:23:49] hmm [22:24:03] Would you look at that [22:24:07] MCC-7 has been scrubbed [22:24:25] yeah no surprise there [22:24:30] you can NOT has PAD [22:24:37] or an Entry PAD [22:24:39] haha [22:24:42] at least no Maneuver PAD [22:24:58] https://puu.sh/IFNZf/c0604f1310.scn [22:25:00] go wild [22:25:31] if I know one program it's P37 [22:28:35] hmm I think the -MA constraint gives you larger DVs closer to Earth [22:28:47] you can barely do the procedure before it finishes the conic solution [22:28:59] so maybe you just have to be quicker, I'll try if I can manage that [22:29:20] conic solution converges quicker when the time between TIG and entry interface is smaller [22:29:47] oh [22:29:55] precision solution was 0 [22:30:00] well nearly [22:30:10] +00001 +00000 +00000 [22:30:21] in the conic solution I had your -118 [22:30:25] I got dvx 1.3 and all zeroes on y and z for the conic solution [22:30:41] I probably did the procedure too slowly for the conic solution [22:30:53] but the precision solution worked with the -MA fix [22:32:18] Do you need to enter it again for the precision solution? [22:32:22] no [22:32:46] did you ever get near zero in the conic solution but -118 in the precision one? [22:33:00] that would be weird [22:33:23] but otherwise I think the procedure wasn't done quick enough. Conic and precision solutions should be very close to each other [22:33:29] oooh you know what it could also be [22:33:32] Ehh yeah at some point [22:33:40] the conic solution comes up with a reentry angle [22:33:47] the -6.51° or whatever [22:33:58] the precision solution doesn't iterate on that angle anymore [22:34:20] so it would be possible that the conic solution comes up with a "wrong" angle and then screws up the precision solution [22:35:07] Could you still manually change the angle in noun 60 after you did the conic solution? [22:35:56] Precision solution gave me +0,2 0 0 on the dVs [22:36:40] yeah you can change it [22:36:48] N60 can be confusing because of its double use [22:37:05] R2 can be both the DV you want P37 to do, for TLC aborts [22:37:09] and the entry interface velocity [22:37:48] ok when I do the -MA procedure with 0.1x time acceleration it gives me the 1.3,0,0 for the conic solution [22:38:37] and 0.1 0 0 for precision [22:39:40] I think it's just weird things with that procedure [22:39:53] after all you are changing a variable in erasable memory while P37 already uses it haha [22:40:35] the faster you do it after the PRO on the first N60 the better [22:51:02] Oh wow, just reading the P37 section in the users guide and the precision solution is stated to take anywhere from 2 to 35(!) minutes lol [22:51:51] Which makes me think. A worst case scenario would probably TLC or failed LOI where you are very far from earth [22:52:10] Would it just calculate a direct abort if in TLC or do a lunar flyby? [22:52:32] it can't do a lunar flyby [22:52:48] the worst case in terms of computing time is a late TLC [22:53:06] especially one with a small DV [22:53:29] because then after the abort it has a very small velocity and the Moon and Sun are pulling on the trajectory [22:53:45] which the conic solution of course doesn't consider [22:54:04] Oh that's where the outside Lunar SOI comes from? So you can either do a direct abort before you get there or calculate a return after you've already been around the moon. [22:54:06] that's the case where conic and precision solution will be most different from each other [22:54:55] and P37 iterates on integrated trajectory. So if the time between abort and entry interface is long it has to do a lot of integrating [22:55:21] I'm pretty sure it can't do a flyby. The conic solution will not consider Moon gravity at all [22:55:52] not sure if later CMC versions give a program alarm directly for trying a flyby, but it might simply not converge at all [22:56:42] Colossus 3 doesn't have an alarm for it, other than it not converging after X iterations [22:57:04] right [22:57:23] but it won't allow you to choose a TIG inside the lunar SOI [22:58:28] for Apollo 8 the TLI+44 abort should be the slowest to calculate in P37 [22:58:40] that's the last direct abort they got a Maneuver PAD for I think [22:59:33] I haven't done any P37 during TLC. Can't remember if I skipped them or just weren't in the flightplan [22:59:47] they got a full Maneuver PAD on Apollo 8 [22:59:58] later missions just got the P37 input data for TLC aborts [23:00:12] and then full flyby maneuver and PC+2 maneuver PADs [23:01:38] Apollo 8 really had to write down a lot of Maneuver PADs haha [23:02:03] I have pages of A4 paper filled to the brim haha [23:02:12] they got a full TEI PAD for each orbit around the Moon, too, which later missions didn't get [23:02:49] they just always had one PAD for some future maneuver if communications should fail [23:03:02] but those could be several orbits apart [23:06:47] good night! [23:06:51] night! [07:04:52] .tell rcflyinghokie this is from 2006, may be of historical interest https://nassp.space/index.php/Environmental_Control_System_(CSM) [13:54:08] looks like we merged some checklist updates recently? I'm thinking that's what's breaking my scenerios [14:35:56] Ryan did some minor changes in the last two weeks yeah [14:36:57] BTW I added you as an administrator on the wiki, now you can edit the wiki until I take some spam precautions for normal users. [15:12:30] cool, thanks! [15:14:20] I had a mediaWiki installation on a server around 2017ish. I thought I had all the security sorted out, and then one day I had ~1.5 million spam articles... [16:02:01] ugh, this checklist CTD thing is going to bother me [16:26:55] hi Alex [16:27:59] hey [16:30:49] quick question on the latest checklist update [16:31:46] it looks like that breaks some in-progress missions (at least my scenerios, not the mission scenerios). is there an easy fix? [16:38:16] hmm good question [16:39:56] I am begining to question the amount of checklist data that we actually need to save in our scenerios, too. [16:40:44] it seems some of my Apollo 10 scenarios are broken [16:40:59] dont know if that is checklist related [16:57:24] my easy fix is using the old checklist for now haha [17:05:43] there probably could be some changes made in the save/load code so at least it doesn't CTD [17:09:21] not something super pressing, but I would think some something like: save the name of the particular checklist, and/or subchecklist, and the line it's currently on, without needing to save the status of every item. [17:10:19] also: good confirmation that our optics transfer functions are right https://youtu.be/VAAOOsRhOiA?t=103 I had never seen this one before [17:22:02] ah interesting [17:24:05] morning! [17:24:27] afternoon [17:24:49] hey guys [17:26:24] indy91, PR is up with hopefully the final TD point revision [17:26:25] :D [17:26:30] awesome, thanks Mike [17:27:44] haha, -3.6 to -3.7, -5.31 to -5.41. That's what I call fine tuning [17:28:26] the new damping/stiffness slight changes the settled height of the footpads [17:28:35] slightly* [17:29:11] so a bit of an adjustment was needed to have them appear correctly [17:31:46] thewonderidiot, the part about the training activities makes me want to implement scenarios for each LM training sessions :D [17:32:14] hehehe [17:32:37] that would be awesome [17:34:41] n7275, about the checklist MFD CTDs, we need to look into that. If a scenario has trouble loading because of that it should just revert to the beginning of the checklist or something [17:35:29] I never looked much into our checklist MFD code [17:35:50] the most I ever did was implement the DEDA interface [17:36:02] and that was mostly copy and pasted from the code for the DSKY [17:39:05] my Apollo 10 scenarios are broken, I suspect due to the checklist MFD [17:39:23] It might be worth revising it at some point. We talked about the possibility of replacing the xlsx spreadsheets with a flat ODS XML file. That way you can actually see the diffs between the two. There's also some broken pages in the MFD and missing buttons on some pages [17:39:47] Are you guys getting CTDs with the Apollo 10 scenarios too? [17:39:50] what you can always do is to delete the checklist part of the scenario [17:39:57] I'm getting CTDs in some scenarios yeah [17:42:34] Thymo I am certainly up for a better option for checklists for sure [17:45:01] many of the mission saves have bad checklist states right now [17:45:40] yeah, I think it shouldn't be too complicate to at least make those scenarios load [17:45:48] even if the checklist state could be screwed up [17:48:15] Alright, so with the latest FDAI textures posted, are you guys all ok if I PR them? [17:49:30] did a bit of testing with them and they look very good [17:54:17] The ones from https://www.orbiter-forum.com/threads/fdai-textures.40324/ [17:55:02] yes [18:00:12] I like how they look and I think he re-created them from scratch, so no license issues [18:00:41] what's the best way to have him be the one who is credited? [18:01:07] in the commit itself? [18:01:43] thats what I did with Max-Q's textures [18:05:16] yeah, probably [18:05:30] rcflyinghokie, I think you were asking about attitude rates during reentry with the CM [18:06:12] I was just mentioning how I saw the oscillations [18:06:17] But overall the stability was good [18:06:19] from what I could gather in mission report supplements rates up to 1-1.5°/s were fairly normal [18:06:26] Thats on par with what I saw [18:06:31] CMC will do rate damping above 2°/s [18:06:48] and the mission reports say that happened rarely on early reentry [18:06:57] but it can happen once or twice [18:07:14] until you get to transonic, but then the trim AOA changes a lot [18:07:19] so that would be expected [18:07:41] and yeah I agree, that is what I saw as well [18:07:58] depending on roll maneuvers and RCS firing it could induce those 1°/s rates [18:08:05] sometimes it stays quite low [18:08:42] I liked the swing in yaw though, "felt" more accurate [18:08:43] and when looking at the graphs then I think the moments keeping the CM stable are slightly lower than before [18:08:44] even in pitch [18:08:54] so that makes sense [18:09:33] What I could take another look at is mass and inertia, but I think those are fairly accurate already [18:09:48] that should be the only things influencing the behavior [18:11:01] well the actual CG is probably centered [18:11:08] relevant for RCS jet positions relative to the CG [18:11:31] have to check how close that is to what our aerodynamics now assume where the CG is [18:13:33] I wouldn't be surprised if the RCS positions were off [18:13:39] they were for LM and SM [18:14:53] Hmm I didnt think about that [18:19:56] I just flew a very interesting reentry [18:21:30] apex cover first? :D [18:23:00] wanted to power through the rest of Apollo 10, so I just left my post-TEI scenerio running at 40x until 191h (so no MCCs), decided to do a manual reentry on the EMS roll and lift vector alone, and I didn't die... [18:23:39] any idea what your reentry angle was? [18:24:31] And did you get a copy of the EMS scroll? [18:27:02] mwhume.space/Files/ProjectApollo%20EMSScroll%2001-30-22_13-24-41.bmp [18:28:33] not sure on the angle, how to I calculate that [18:29:19] I made the Space Digitals display compatible with non-MPT mode [18:29:28] gives you EI data [18:29:32] column 3 [18:29:42] ah okay [18:30:02] I think you just need to enter a time, basically the "vector time", but as long as it is before EI it can be anything [18:30:32] so you just left the EMS at 37,000 ft/s [18:31:09] Oof that g loading [18:31:17] Probably a bit high, your final range on the EMS wasn't near 0 in the end I bet haha [18:36:56] was very much a last minute "might as well try it" attempt [18:38:32] which angle am i looking for, GEI? [18:39:31] alright guys PR sent for the FDAI textures, I have you all as reviewers [18:40:11] -6.03 by the looks of it [18:40:38] yeah, G for gamma [18:40:49] so shallow [18:40:52] but not too bad [18:41:04] that was my first impression from the EMS scroll, too [18:41:06] slightly shallow [18:42:05] VEI was 36317, so yeah EMS is shifted a bit [18:42:31] in the end you pulled a lot of Gs. Did you try to get to range = 0? [18:42:48] That's probably when your actual vs EMS inertial velocity became quite mismatched [18:43:03] due to lack of velocity initialization [18:44:58] and I can already tell that I want to update our CM RCS thruster position and directions [18:45:06] I didn't even look at range, but my splashdown coordinates were 165.73W, 16.07S. [18:46:36] AlexB_88 great, I am going to do some maneuvering in the CM and LM and see how it looks [18:50:47] I like the new textures. They're not perfect, but it's a massive improvement [18:51:26] yikes it looks awful in the LM [18:51:30] so pixelated [18:52:26] https://www.dropbox.com/s/r5na28chyfxj1w7/Screenshot%202022-01-30%20115215.jpg?dl=0 [18:54:01] rcflyinghokie, I think thats unfortunatley just a quirk or the 2D rendering using the higher texture [18:54:13] it looks way better in 3d https://imgur.com/a/c304sm1 [18:54:17] if you look at the 3D cockpit FDAI the resolution is much better [18:54:20] yeah [18:55:21] the 2D panel FDAI rendering is more to blame here imho [18:57:32] I seldom use 3d [18:57:42] So I am really disliking how it looks in 2d [19:00:34] reducing the resolution for the 2d ones would fix it. it looks like it's just using the fastest/lowest quality bitmap scaling possible. [19:01:42] we could have separate ones for 2D/3D Iguess [19:02:02] unless you know what you are looking for its a bit hard to read [19:05:02] ok so I guess we can hold off on merging the PR until we find a better solution for the 2D panel FDAI [19:14:52] I am open to other opinions of course, that was just my first reaction to the 2d panels [19:15:25] I have to go to work but tomorrow or the next day, I will test with a lower res version of the texture for the 2D panel [19:16:38] sounds good [19:16:45] cya! [19:18:17] Is that little jump the FDAI does when yawing through +/- 90 actual behavior? I have always wondered about that [19:18:23] In the LM [19:19:56] good question [19:19:59] probably not [19:20:11] it's basically limit on how fast each axis of the FDAI ball can rotate [19:20:21] but that limit could be wrong and likely is [19:21:19] because of different code I think that only happens in 2D [19:21:29] 3D doesn't have that behavior [19:21:46] limit is 50° [19:22:01] so it takes a couple of seconds to rotate 180° I guss [19:22:03] guess [19:22:09] 50°/s [19:33:02] I think I'm confident enough in my specific heat update to merge it now. [20:01:17] Awesome, I had no issues when I used it to fly 17 [20:01:36] Few save load hiccups on loading an old scn but nothing breaking [20:01:55] indy91 ok thanks for that [20:09:17] I wonder how the behavior was in the actual LM wrt the roll needle reacting [21:42:18] thewonderidiot: Does magc not work with yaYUL ropes? [21:44:47] When I try to use them it appears that the agc is in a restart loop. [02:58:09] hey [03:06:55] hey [07:51:05] Thymo, no, it works only with my hardware rope format [07:51:19] i.e. bank order 0, 1, 2, 3, parity required and in bit position 15 [07:51:31] yaYUL can generate this format with --hardware [15:43:22] good morning [15:55:50] Hi [15:55:54] thewonderidiot: I see, works now. [17:12:10] morning! [17:57:24] thewonderidiot, do you think you could get me a good image of some DSKY digits, with perhaps a scale measurement. or do you know of a document that specifies this? thanks. [17:58:07] https://photos.app.goo.gl/t8maF47BxQ9DD9EP6 [17:58:13] drawing number is 1006315, standby [17:58:50] https://archive.org/details/apertureCardBox439Part2NARASW_images/page/n222/mode/1up?view=theater [17:58:53] and two subsequent pages [18:04:12] oh wow. awesome. [18:06:40] :) [18:18:04] Man I am at a loss as to how to "accurately" present the EL colors now :P [18:18:21] Based on displays, getting it "close enough" seems to be the end goal here lol [18:18:35] yeah definitely [18:18:45] if we have the resolution, I think capturing the "graininess" might go a long way [18:21:53] but I was definitely not expecting the spectrum to be that damn wide [18:22:02] it emits all sorts of light lol [18:23:01] I wasn't surprised with it being EL [18:24:19] its also not directional light [18:29:21] so it has a spread spectrum when using a spectrometer [18:29:27] hence the plateau [18:42:16] yeah [18:42:29] I'm very glad to at least have numbers behind this now [18:42:38] and a way to convey how hard it is to describe the color lol [18:56:58] yeah empirical evidence for all the armchair DSKY experts on the forums ;) [19:05:47] Hey Mike, are there still things in magc that you know are broken? I'm running Borealis and when I run PRESTAND via VB60 I get a TCTRAP and CCSHOLE alarm. [19:06:35] standby is definitely broken :P [19:06:50] and I haven't fleshed out any I/O or counters except for timers and DSKY [20:37:26] oh looks like my message didnt send earlier [20:38:08] our dsky digits are 9px tall. I'm thinking we can afford to make those a bit higher [20:50:35] .ask indy91 Can you check the TRANSEARTH7 and TRANSEARTH8 MCC states for the C Prime mission? Either my MCC got desynced or those aren't quite right. [21:01:03] oh yeah that's not a lot of room to work with haha [21:01:58] n7275 approximately how much water are the fuel cells producing right now after your rework [21:02:15] And is that going into the waste tank because potable is full [21:08:38] I just got very confused [21:08:45] The EMS lights don't work in the VC [21:09:27] Sounds like an Alex ping [21:10:14] Argh [21:10:19] In test 3 it works [21:10:32] Someone forgot to enable the .05G light in Test 2 [21:16:23] rcflyinghokie, it should be the right amount, it's some number of mols of water per coulomb of charge that is transported across the cell. [21:17:01] unless I got the number of electrons wrong.... [21:17:30] but no, it's the same math that calculates reactant usage [21:17:58] I am trying to figure out how the waste dump code works right now [21:18:11] Maybe it just doesn't dump fast enough? [21:18:19] waste dump level is very odd [21:18:35] wasteWaterDumpLevel = 0.5 * (wasteWaterDumpLevel + (wasteInletVentPipe->flow / wasteInletVentPipe->flowMax)); [21:19:18] Thymo its that plus the fact that potable water isnt being used [21:19:48] That code seems to control whats displayed which doesnt make sense to me [21:20:42] Ryan you did some CM RCS stuff. Are the heaters working? [21:21:18] yep [21:21:40] should be able to use the system test meter [21:21:57] and if they are on the cool side you can fire up the heaters [21:22:32] What does the temp pkg indicate in CM RCS 1 and 2 then? [21:27:48] Those I think are still hardcoded [21:28:02] I did the RCS injector valves which are measured on the test meter [21:29:15] System test meter is pegged on 5 volt. I reckon they are hot enough now :P [21:29:44] On all jets? [21:30:10] 5c 5d 6a b c d [21:30:31] And did you use the heaters [21:30:50] Yes and yes [21:31:10] You probably didnt need to then :P [21:31:26] Also the cmrcs helium temp is the tank temp it seems [21:31:36] return KelvinToFahrenheit(heliumTank->GetTemp()); [21:31:49] The checklist mfd didn't mention to check any temps [21:32:42] Hmm probably because it dodnt work yet, checking now [21:33:09] I will amend that [21:33:33] Also the A8 Entry checklist calls for VHF A - Simplex at 142h. The MFD doesn't have that [21:36:24] ah the handwritten note there [21:37:57] adding [21:39:18] And added this note [21:39:19] If sys test mtr 5c,d 6a,b,c,d all read 3.9V (28F) or more, omit preheat [21:41:47] Same for all missions so its now in them all [21:42:26] good evening [21:42:40] Thymo found a VC bug :P [21:43:08] We ought to replace that system test meter guide texture too. It doesn't match with what the meter is actually showing [21:43:22] Yes yes yes [21:43:30] Yes, I made an issue too. The EMS 0.05G light doesn't illuminate in test 2 [21:43:36] Also, hi [21:43:54] Granted the missions differed slightly, maybe just add what we model currently [21:44:41] hmm [21:44:55] it should have the same functionality as the 2D panel [21:45:11] is the behavior different in the 3D cockpit? [21:45:44] 0.05g light doesnt light in VC [21:45:49] For EMS Test 2 [21:45:57] But does in 2D [21:45:59] which is odd [21:46:37] n7275 can you help me track down what controls the waste water tank display and also the dump rate, that code doesnt really make sense to me [21:46:46] Seems to control the display not the dump [21:47:05] If I change the tank valves the display is all funky [21:48:20] weird [21:48:41] which scenario are you guys testing on? [21:49:23] sure, I can look into it. [21:49:26] I am trying one of my Apollo 11 scenarios and it works [21:50:12] Apollo 8 [21:50:15] EMS to normal and test selector 2 [21:50:29] and .05 G light comes on after a few seconds [21:50:32] I didnt try it I was watching Thymos [21:50:35] Maybe his scn? [21:50:43] Ill try Apollo 8 [21:52:36] Yeah, I tried it like 30 minutes ago as part of entry prep [21:54:00] also, Thymo, I was just thinking about making a new system test meter panel before you mentioned it haha [21:55:19] Thymo, do you have a scn where the issue happens? [21:59:17] I thought I did, I have relaunched Orbiter in the interim and now I do get the light. Could there be something that prevents it from lighting in the VC that's not properly saved? [22:06:17] ah [22:06:53] the redraw function in the VC for the EMS lights calls the 2D panel EMS light surface [22:07:33] SRF_EMS_LIGHTS [22:07:42] should be SRF_VC_EMS_LIGHTS [22:08:30] so I guess it works but maybe its buggy since it tries to draw a BMP surface in the 3D cockpit? [22:08:38] Could be [22:08:59] anyway Ill fix that and hopefully fixes that issues [22:09:51] Thymo, how do I remove a push from my branch? I grabbed the FDAI textures but want to remove them before PRing the checklist changes [22:10:15] I mean I cam manually delete the files of course, but can I prune the commit? [22:10:38] rcflyinghokie, did you try the modified textures he posted? [22:11:11] Not yet I saw the pictures [22:11:29] I would say a little less blur and they look good [22:11:41] they start becoming dim [22:11:49] Do a git log to find the commit -before- the one you want to remove. then do a git rebase -i ^. The ^ is important. Then remove the commits you don't want. [22:12:14] It uses the vi editor. Use the arrows to navigate. Hit d twice to remove a line and type :wq to save [22:12:22] will I lose my current changes [22:12:37] right, but its going to be a tradeoff between blur and having them being a bit grainy [22:12:40] As in uncommitted? [22:12:59] so I guess we'll have to find a middle ground [22:13:01] Shouldn't as far as I'm aware, you can do a git stash to save them to be sure [22:13:10] I think I can just delete the files [22:13:23] AlexB_88 yeah thats what I mean a little less blur so they are a bit darker [22:13:44] I think that would be a good medium [22:13:45] he actually added two version in the zip file [22:14:05] "Little blur" and "More blur" [22:15:56] Thymo I just reverted them and updated the PR [22:20:43] to me it seems the "more blur" has the best look for the 2D panel [22:21:04] its a bit blurry looking for the VC though [22:21:19] trying them now [22:21:35] so considering in the VC we might get even higher textures down the line, I think we should have 2 versions of the textures [22:21:45] higher resolution [22:22:03] the 2D panel one is limited anyway to 1024x514 [22:25:26] less blur isnt bad haha [22:25:48] ah yes [22:28:18] rcflyinghokie, in satsystems.cpp line 538, the "WaterControler" is initialized. look at ecs.cpp line 1117, this refers to the valve in saturnsystems.cfg line 479 [22:28:58] I think the valves there probably just need to be a bit bigger [22:31:09] yeah, WASTEH2O:OUT and OUT2 are hooked to H2OVENT [22:32:57] valve sizes are liters/Pa/sec and the vapor pressure on our water is much [realistically] lower. it was boiling it's way out the vent before [22:33:52] keep in mind that this is one of those things that gets saved in the scenarios... [22:33:59] when I increased the valve size from 0.001 to 0.01 the waste tank would not fill even with the dump off [22:34:09] I think it has to do with whatever that flow/flowmax code is [22:42:31] in the interim it might not hurt to increase the dump rate and somehow decrease the fill rate (perhaps creating a slow drain on the potable?) [22:46:41] Thymo, Yeah I knew someone else was working on some FDAI textures...to me its no problem if we integrate these ones and than later update them with a higher resolution one, no hassle at all really. The textures posted on the forums are in my opinion way better then what we have now so yes to me, it would be a major improvement....but I am easy if we think we should wait for the other ones to be finished so be it [22:49:34] the other thing is as far as the 2D panel is concerned, I think 1024x512 is the highest supported, so any higher resolution would be for the VC only [22:50:28] which is why I thought of the idea to have 2 separate versions of the textures for the 2D panel and VC [23:08:24] thats probably wise [23:23:19] rcflyinghokie, so "Little Blur" seems best for you? [23:23:27] in the 2D panel [23:23:31] In 2d yeah [23:23:37] ok [23:23:46] 1920x1080 overall [23:23:51] for reference [23:24:08] seems to be a tradeoff between contrast and clarity [23:24:14] I would like other opinions of course [23:24:56] I have a UHD monitor so its a bit hard to test the 2D panel [23:25:35] well "UHD" 2560x1600 [23:25:40] poor man's UHD [23:37:17] so testing on my 16:9 monitor, it looks good [23:44:07] haha [23:44:26] simple 1920x1080 ASUS here [00:17:34] AlexB_88 is there any simple way to prevent tipping of the CM with wind effects on? Or make the float bags upright it? [00:19:35] not sure right now, but Ill look into it [00:20:48] I do like how the CM drifts laterally when on the chutes instead of straight down with it on [00:21:23] But if there is no good workaround might have to concede and turn it off :P [00:21:28] the chutes effect probably just has to be disabled right at splashdown [00:27:24] would that impact them falling tot he water [00:32:49] im not sure how that all works [00:35:13] me either haha [01:08:11] FDAI textures PR amended [01:11:49] "little blur"? [01:18:48] .tell indy91 had Thymo fly your CM Aerodynamics on 8, more good results [01:37:07] I gotta say, orbiter looks fantastic at 21:9 [01:38:44] well, 64:27 technically... [01:47:39] How do the 2d panels look [02:09:18] rcflyinghokie, yeah the textures from "Little Blur" folder is what I used [02:34:04] awesome [02:34:13] hopefully the feedback is positive [04:55:00] Thymo, Wiki question: appears to be failing, do you know if randomimagebycategory is installed? [08:36:04] n7275: Probably not. This install is pretty vanilla. [13:45:52] okay, I'm not super worried about it. we can just replace that with a static image or something. [13:50:24] I'm not sure if that extension is still available and being maintaned. If it is, I'm sure it can be added back. [13:55:23] sure [13:56:10] I think I might want to gather some more up to date screenshots [15:36:06] good morning [15:36:15] hey [15:37:56] morning [15:38:48] Hey Nik [15:39:42] About MCC. It was most likely my MCC that was desynced, someone else did get the proper uplinks. Everything appeared good after I incremented my state once. [15:40:16] couldn't replicate that EMS thing, can't be the code itself, but if it's just the VC it could be a strange VC thing. It does take 10 seconds for the light to come on, but I'm sure you know that [15:40:43] I think Alex found that issue [15:40:52] I waited a good minute and did it multiple times. After I reloaded the scenario I was unable to reproduce it again though. Really weird. [15:40:56] I couldnt replicate it either [15:41:09] ask NAA for a night lightbulb [15:41:12] a new* [15:41:43] Oh god please don't tell me the C&W light failure code also applies to the EMS [15:41:57] I don't think so, maybe it does [15:42:33] hmm [15:42:37] there is a pt05GFailed variable [15:43:06] Let me guess. It recalculates on each load and is not saved... [15:43:18] but nothing sets it [15:43:34] and it's initialized to false [15:43:38] so I don't think it can be that [15:45:23] Need to have an SPS ON light failure like 15 ;) [15:45:28] Ah another variable for the dead code pile [15:46:40] oh that was worse than a light failure [15:46:49] it was a short in the SPS ignition electronics [15:47:05] it would have fired the engine if the other conditions for that would have been set [15:47:36] mission report has good details, I'm sure it's something that could be simulated in the relay logic [15:48:23] Thymo, and what was the issue with the MCC. It didn't show the final Entry PAD? [15:48:32] together with the last SV uplink? [15:49:10] it does that when time to entry interface is 45 minutes. Maybe that time was calculated incorrectly or something then it wouldn't switch to the next MCC state [15:49:17] indy91 oh I know haha, SPS was armed ;) [15:53:24] n7275, about your PR. So the sensor in the comm system already should return 0-5V? [15:53:43] ah right, must be. Otherwise it would need to go through the SCE [15:53:54] which very few systems actually have to do [15:54:15] not like in the LM where the SCEA does almost all conditioning to 0-5V for all systems [15:54:55] the Systems Handbook says -130 to -50 DBM and not 0 to 5 V [15:55:10] but that's probably what they scale it in the RTCC [15:58:09] rcflyinghokie, why has your PR a change to the Apollo 9 LM checklist when it concerns the CM RCS preheat? [16:00:27] There was also a change removing a copy paste error, but because the PR was still open when I pushed it it added to the PR [16:01:13] Edited the title [16:02:02] ah, yeah no problem, just asking haha [16:05:48] indy91: It was probably my fault, I had to rewind MCC earlier in the mission because I missed a PAD or something. That together with me being confused by not getting a REFSMMAT uplink I was wrongfully expecting caused me to be suspicious [16:06:09] indy91, im fairly certain its 0-5V. I want to make the amplifiers to this. right now the antennas just output a 0-100 (no units) range. this was just a quick fix to get it on the telemetry output [16:06:57] Yeah, we usually let the scale_data function take care of it, but that's of course mostly wrong as the PCM should be supplied with 0-5V inputs [16:10:48] we can work on that [16:48:44] Look who just commented on a PR since forever [16:48:46] hey [16:48:49] Hi Alex [16:54:25] in the process of writing a reply now. I agree with both of you. [16:58:59] wow I havent seen him around, nice to see! [17:02:54] I know my ECS changes will break things for sure but they are a little ways from being testable [17:10:48] it's really too bad that there isnt an Orbiter version to target a release at. [17:22:38] or maybe we need a dev branch that we all merge into rather than Orbiter2016. and then merge the dev branch into Orbiter2016 once a month or something like that. [17:33:49] morning! [17:35:55] hey Mike [17:52:34] what do you know about USB phase error? [17:54:32] mmm what do you mean? [18:14:32] theres a telemetry word for it. I presume its related to phase locking. [18:15:33] oh, probably the static phase error [18:15:48] it's essentially a measure of how far off the received frequency is from the expected frequency [18:15:57] SPE too big, the transponder can't lock onto it [18:19:17] gotcha [18:19:29] https://photos.app.goo.gl/uvzXpV7bEh7KJpxv5 [18:42:10] n7275, do you have one of your Apollo 10 scenarios ready that you know is having a CTD because of checklist changes? [18:42:46] I want to look at that. Just to see how difficult it is to at least prevent the CTD from happening [18:42:58] even if the whole checklist state gets lost [18:56:46] A few of the presaves do it [18:57:26] After docking I know for sure [19:06:43] https://drive.google.com/file/d/13wdVrYdTmcDtboWpwhY45PvfM84CesHe/view?usp=drivesdk [19:12:56] thanks! [19:13:18] oh lol [19:13:21] I already had that one [19:13:23] A10 [19:13:31] I was only looking for "Apollo 10" in my folder haha [19:29:04] Did you try the pre saved missions for 10? [19:59:10] you mean the mission scenarios? We broke mission scenarios? [20:01:04] yes [20:01:15] Thats what I thought we were talking about [20:01:23] I have no idea how they broke though [20:03:56] Checklist changes [20:04:05] I think how it works is [20:04:26] it has saved the state of checklist item X in checkout group Y [20:04:42] but due to a change, maybe order of checklist groups, there now is no ite X in group Y [20:04:43] item* [20:06:04] somehow I missed that it broke those Apollo 10 mission scenarios. That makes fixing the CTD a top priority I guess. You could probably fix it by removing the right lines from the scenario, but I wouldn't know which [20:06:34] and removing the entire checklist part of the scenario isn't good either. That will at least make it 100% load [20:06:35] I can jump into those, remove the checklist, and resave with the proper location [20:06:54] But I dont know which checklist change did that haha [20:07:17] I can just remove the whole thing and replace it with the proper location [20:08:12] sure [20:08:48] I know that if I find a solution for the CTD it will probably not still be at the right point in the checklist [20:08:55] so the scenarios might need a fix anyway [20:09:03] but I have a bunch of code reading to do I guess [20:09:13] I'm not very familiar with this checklist MFD stuff [20:45:40] the strange thing is [20:45:52] if I debug it doesn't even get to loading checklist items [20:46:11] a vector is out of range during the loading of the Excel file [20:47:13] not sure, but I think that issue only happens in debug mode [20:47:20] doesn't affect all missions though [20:47:35] very odd [20:48:22] maybe it's something with the Apollo 10 checklist file specifically [20:53:14] it loads a vector of chars [20:53:24] I think that's the whole checklist file [20:53:41] 1,198,918 chars [20:53:55] I was casually looking at the first few of them [20:54:04] kind of spooky, it had my first and last name there :D [20:54:15] must be the initial of last author of the Excel file [20:54:18] or* [21:13:46] I don't understand it very well yet, but it does something weird with the Apollo 10 checklist only [21:14:40] I think it stores each unique text field like "RNDZ XPNDR PWR - HTR" in a vector [21:14:50] so those usually have 10-30 chars [21:15:10] but in the case of Apollo 10, where it has a CTD, it suddenly has one with 45000 chars [21:16:28] that is one hell of a checklist step [21:17:13] uh oh [21:56:51] difficult to debug, this code to load the Excel files are quite complex [21:56:54] thewonderidiot: The DSKY has its own power supply that is disabled when the AGC is shutdown right? So would the DSKY power back on if you removed power from the AGC but let the DSKY remain powered? [21:57:51] what do you mean specifically by shutdown and remove power? [21:59:54] Sorry, I meant standby. And by remove power I mean pulling the breakers removing power to the AGC. [22:00:25] it has an EL power supply to derive the 250V needed for the segments, that is derived partly by 14VSW, which goes off with standby [22:00:51] the DSKY's 28V power comes from the AGC itself, so if you cut the breaker that goes away [22:01:11] The way I have it now is when the CMC is in standby the DSKY is off with STBY lit. When I pull the breakers the ELs come on with whatever state the relays have [22:01:13] the power for the lamps comes externally though from the vehicle [22:01:35] night! [22:01:38] the EL should definitely not be on if the AGC breaker is out [22:02:10] Does it generate EL power from 28VDC? It's hooked up to the CSM AC bus right now [22:02:26] it comes from 28COM, from the AGC [22:02:34] not from the AC bus [22:02:42] or rather not directly [22:03:22] the 28V to the DSKY goes away if you pull the AGC breaker [22:04:13] and even if it didn't, it would need the 14V and the EL clock pulse from the AGC to actually generate the 250V for the EL [22:16:26] Send you a screenshot on Discord. [22:17:00] I got that from the system handbook last time under the assumption the ELs were hooked up to those breakers. [01:35:38] Looks like we have another FDAI texture now... [01:35:39] https://www.orbiter-forum.com/threads/new-fdai-tex-1800x900.40338/ [01:54:31] .tell indy91 also I tried removing the checklist from 10, but as soon as I go to NAV on the checklist MFD I get this... [01:54:49] .tell indy91 https://www.dropbox.com/s/yut0tqpw449pqqk/Screenshot%202022-02-01%20185359.jpg?dl=0 [04:09:33] Thymo, I looked at your scn_check branch. That's exactly what I was thinking. [09:09:35] n7275: I'll take a deeper approach tonight. Perhaps we should indeed expand that variable to have more fidelity like a date or commit id. [14:43:45] good morning. [14:50:13] we do have a mesh for the subsat mwhume.space/Files/subsat.png [15:05:55] hey [15:06:44] ah, I think that's the issue I remember with a mismatched scenario state for the checklist [15:07:09] what I am trying to debug it's currently not even loading the Excel file successfully with that Apollo 10 checklist [15:07:12] and it's so weird [15:07:39] yesterday I said it's finding a checklist item with 45,000 characters [15:07:44] and that's where it fails [15:08:14] the last good item is "DAP Deadband Change 10°" [15:08:21] except it ends with the 1 [15:09:04] so I thought maybe the problem is the ° character [15:09:20] but it's working fine if I change it to 100° or 11° [15:09:29] or leave the degrees out completely [15:09:35] so strange [15:13:07] uhh [15:13:19] I don't have the latest state of that checklist merged yet haha [15:19:26] but the issue stays the same [15:25:38] if this has any relation to enviornment variables it may look like a different issue for different people debugging it [15:26:05] even if it isnt directly related [15:26:11] actually [15:27:28] I think it's purely the Excel file [15:43:48] each cell seems to store some format information [15:43:53] something there throws it off [15:44:38] that would explain why editing with libre office breaks it [15:46:42] good morning [15:49:17] hey Alex [15:51:02] does the basicExcel api that we use have any options that we should be using but aren't? "ignore formatting, et c." I've honestly never looked at it. [15:51:44] hey [15:51:59] I'm not sure, really only getting familiar with it myself [15:52:33] ok, so in the raw data it usually has this [15:52:38] LM TUNL VENT vlv - VENT [15:52:56] and then three characters for formatting and string ending [15:52:59] in this case it has [15:53:10] " \x1c \0 \0" [15:53:15] and then the next thing begins [15:53:20] Install Tunnel Hatch (Decal) [15:53:37] but then what follows is 5 characters with some formatting or null [15:53:50] and that's where the processing of the data gets confused somehow [15:54:09] it accurately finds that the next string has 23 characters [15:54:27] but starts 2 characters too early because of the additional 2 (5 instead of 3) [15:54:56] and so the next "format characters" are actually the last two characters of the next cell [15:55:13] DAP Deadband Change 10° [15:55:18] it only stores up to the 1 [15:55:26] 0 and ° it checks for some kind of formatting [15:55:39] and then gets confused, somehow thinks the next string has 45,000 characters [15:55:40] and CTD [16:01:27] probably goes looking for a \0 at a specific index, doesn't find it, and then keeps on going until it hits some memory that's off limits [16:04:00] it has \x17 \0 \b \x1 \0 [16:04:14] whatever that means :D [16:05:28] I wonder if it's something with modern Excel [16:06:31] they're pretty good with not breaking frontend compatability...wouldn't bet on the same for their file formats [16:12:43] ah wait, I should check why I could fix it quite easily by changing something simple [16:13:27] ah wait I already know [16:13:31] haha [16:13:52] it uses the last two characters of "DAP Deadband Change 10°" to determine the next formatting or so [16:14:01] so of course it has an effect when I change that [16:14:04] in any way [16:19:50] hmm [16:19:59] I wonder if the Checklist MFD is doing memory unsafe stuff [16:20:08] maybe making SM panels transparent? :D [16:20:16] although it's mostly vectors and such [16:20:25] which does a hard CTD [16:22:47] oh that would be weird but vaguely plausable [16:23:47] mwhume.space/Files/MISSING_PANNEL2.png [16:24:41] yep [16:24:51] 4th number set to 0.0 [16:24:56] I think that's what does it [16:26:22] just catching up on all of this [16:29:40] maybe the issue causing the CTD is very common, but only rairly does it cause a CTD [16:30:15] we have to be careful that we don't blame all our bugs on this haha [16:30:30] so am I reading correctly that the degree symbol is at fault? [16:31:24] we're just shooting in the dark here. [16:31:27] ah [16:31:40] I don't think it's the degree symbol [16:31:42] well [16:31:44] not sure yet [16:31:57] but yeah, this could be a common case [16:33:19] maybe the ° symbol is causing the addition characters in the raw data [16:36:38] Just removed them and all load properly [16:36:49] the thing is [16:36:55] I can change 10° to 11° and it loads properly [16:37:05] very odd [16:37:15] I changed to (10 deg) to be safe [16:37:31] so 0° is the culprit? [16:37:37] no [16:37:40] 100° works fine, too [16:37:47] it's really just using the 0 and the ° to determine some formatting [16:37:55] the issue happens before it gets to that point [16:38:11] DAP Deadband Change 10° [16:38:20] when the issue happens it already has an offset [16:38:30] it knows there is 23 characters there [16:38:59] but it starts 2 characters too early because for some reason there were 5 instead of the usual 3 characters (for formatting I think and null) [16:39:22] and then it wants to process the next cell [16:39:28] but it starts with the 0 from the 10° [16:39:46] so if anything having the "0°" at exactly that place is the cause [16:39:47] huh [16:39:57] but I'm sure it's not the only combination causing issues [16:41:58] For now should I PR the amended checklist [16:42:08] That will "unbreak" those Apollo 10 scns [16:42:15] all of them load now [16:42:33] what does the first INDEX statement mean in the scenario? [16:43:07] before any of the tags [16:46:52] rcflyinghokie, any minimal change is really fixing the issue. By guessing and I'm sure there is other bugs going on [16:47:33] Probably [16:47:43] n7275, index of the checklist group [16:48:24] and the other indizes are probably the line in the checklist group [16:49:53] there are indices, sequences, items, and groups [16:50:58] other than the excel file, the checklist MFD is an enigma to me :P [16:52:19] yeah, same [16:52:28] and I've already been looking at this since yesterday [16:55:41] If I were writing this from the scratch, I think it would save like 5 lines total. [16:57:41] morning! [16:57:56] hey Mike! [16:58:37] I think the checklists overheard us talking about CSVs the other day [16:59:43] well they're not doing them selves any favors to improve their longevity [17:07:01] might be a good thread to look at https://web.archive.org/web/20181231164156/http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=1459.0 [17:07:26] Oh hey I am in contact with lassombra by the way [17:11:11] haha, I noticed him the other day on the Reentry discord, Swatch is there occasionally I think too [17:14:28] yep he and I have discussed quite a bit since I ran into him [17:17:48] Rob has the database from the old forum. At some point I would like to preserve it in some kind of archived format. [17:27:34] ah it's annoying [17:27:53] you basically have to understand the complete structure of an Excel file before you can get an idea of what could go wrong [17:41:44] that sounds like a problem [17:43:16] on a byte-by-byte level [18:55:34] indy91, for the return to earth midcourse targeting, is it always just a corridor control, or are there cases where it re-targets the longitude (say if the dispersion is high enough)? [18:56:11] MCC-5 only [18:56:22] would retarget if you don't land safely on water [18:56:37] ah [18:56:42] at least that's what the mission rules say [18:56:57] might depend on the mission [18:57:27] because I have both DVX and DVZ components, so I think it re-targeted [18:58:22] mission? MCC or RTCC MFD? [18:58:24] but maybe even just with a corridor control, its normal to have velocities in both X and Z [18:58:30] Apollo 11 MCC [18:58:44] TRANSEARTH MCC PHILOSOPHY. TEC MCC WILL NOT USE LANDING POINT CONTROL UNLESS THE LANDING POINT IS UNACCEPTABLE. [18:58:58] right [18:59:03] and only prior to EI minus 24 hours [18:59:08] Apollo 17 mission rules [18:59:29] and that is MCC-5? [18:59:34] on your Apollo 11 [18:59:36] yeah [18:59:50] DVX -2.3 DVZ -4.9 [19:00:14] hmm [19:00:43] seems like the way I implemented it is that it's always longitude control for MCC-5 [19:01:26] might be something that had changed at some point [19:01:32] will probably change that again eventually [19:01:53] a good catch-all solution I guess :D [19:03:55] quite a bit of DVZ, that's all longitude control [19:04:04] but I think it can be expensive [19:04:05] I think some of the J missions had more specific requirements for that [19:04:13] that's why you don't do it normally [19:04:18] Thymo, rcflyinghokie, if we add the real flight plans, it would be nice to have the re-formatted one for Apollo 11 [19:04:20] and never after EI-24 [19:04:34] a re-formatted one without typos haha [19:04:39] AlexB_88 I agree with one caveat...there are many errors in it [19:04:44] yep lol [19:04:48] ah lol [19:05:19] Probably transcription errors (typos, missing words/sentences etc) [19:05:30] so are you saying I shouldn't have closed my O2 surge tank on the post-TEI pre-sleep check? :D [19:05:43] If there were a better way to clean those up I am all for it [19:06:00] Haha well as long as your SM supply is good I wouldnt worry ;) [19:06:11] I thought that was a typo... [19:06:24] It could be [19:06:42] But surge tank could of course be safely closed with SM supply active [19:06:54] right [19:07:21] Nope thats not a typo :P [19:07:36] a ok [19:08:41] Confirmed https://www.dropbox.com/s/5u9vrpa13rndci0/Screenshot%202022-02-02%20120828.jpg?dl=0 [19:10:26] indy91, one thing about my TEI is that my RCS switches were not properly set for the ullage, so the attitude drifted a bit and led to a transient at ignition [19:10:57] TEI with the SCS? [19:11:02] so that might of messed the trajectory a bit, but I doubt it would have been much [19:11:09] CMC [19:11:33] yeah probably not a lot from that, the residuals are more relevant [19:12:12] when I eventually listen to how the RETRO really did the TEC MCC planning I will revisit the decision logic of the MCC [19:13:57] and 2.3 ft/s DVX is normal to low for the Apollo missions [19:21:16] ok, open PRs [19:21:56] my own one for the CM, now that I could move the CG related calculations out of the airfoil functions I decided to change the coefficient interpolation from axial/normal to lift/drag [19:22:06] a bit more efficient and I did the same with the CSM [19:22:31] so hopefully that is now ready. Just a bit more testing and checking on the trim angle of attack [19:22:51] rcflyinghokie, your PR just changes the ° symbol to DEG? [19:23:43] if we fix the actual bug there we can probably add the symbol again, but for now that at least makes our Apollo 10 scenarios work again [19:26:05] indy91, should be flying a re-entry later this evening [19:26:37] Thymo, we could add the Apollo 7 final flight plan, too, now that we actually got that. 19MB, these PDF files will make the NASSP install somewhat larger, but it's quite small so far [19:28:16] indy91 yes, just allowed those scns to open for now [19:28:30] makes sense [19:28:56] tested all the mission scns they all open now [19:29:21] yeah, it really wasn't the scenarios [19:29:27] it was the checklist file itself [19:29:36] right [19:29:37] I think not even the T-4h scenario would have worked [19:45:42] I'll add all of them that we're going to support [19:47:18] Other than increasing the size, is there harm in adding the others? [19:48:03] The flight plans? Not that I can think of. Any concerns? [19:48:25] None here, we do have a few different versions so we want to make sure we have the best of the available options [19:48:31] make sure it's the final revision [19:48:37] ^ [19:49:26] but with what's available on the Internet it's difficult to not get the latest revision haha [19:49:47] Honeysuckle Creek website version of the Apollo 11 flight plan is missing some Revision A change for example [19:51:15] What should we do with the doc files in the Apollo 7 directory? [19:54:25] hmm the word flight plan still contains some useful things that the actual flight plan doesn't have [19:55:56] We do have the building blocks of the flown checklist [19:56:11] that crew abbreviated checklist that Mike has scanned is the non-flown version of it [19:56:37] it's basically the flown checklists combined [19:56:57] on 7 they would still have their personalized checklists like on Apollo 8 [19:57:35] and the other doc files need to be updated, but are still useful [20:00:42] So keep them where they are or move them to that obsolete docs directory? [20:01:30] hmm [20:03:05] let's keep them [20:03:11] only that flight plan will be obsolete [20:03:32] but for that to be the case we would need to include more than the actual flight plan [20:04:01] So keep them but move the flightplan to the obsolete docs folder [20:04:25] no [20:04:26] haha [20:04:35] they are outdated [20:04:48] but they will be, in updated form, in the NASSP 8 release [20:04:55] so they are just outdated, not obsolete [20:05:13] oh [20:05:15] sorry [20:05:18] I misread that [20:05:25] I thought you meant move the whole thing [20:05:57] let's not make this change for Apollo 7 yet [20:06:19] I'll leave them all as they are now then [20:06:21] I don't think there is a good realistic choice really [20:06:35] the problem is, there would be a CDR, a LMP and a CMP checklist [20:06:38] with lots of duplications [20:06:54] I don't think that would be helpful [20:07:33] I'm thinking about the case where people don't like the Checklist MFD [20:07:48] because it's unrealistic to have that in-sim [20:07:54] those people will use the word flight plan [20:08:06] and the flight plan has references to generic checklists [20:08:19] but also some special procedures, not found in the actual flight plan [20:08:25] No, it wouldn't. For things like checklists people can go to the MFD or fetch the checklist themselves. The flightplan however is a good addition to the MFD as it gives you an overview and also has some extra info the MFD doesn't provide. [20:10:16] including the crew abbreviated checklist would be bad [20:10:27] the whole section for the CMC has so many different verbs and nouns [20:10:30] from Colossus [20:11:24] the actual final flight plan is quite good, definitely want to included that. But keeping the word flight plan around would then just be confusing [20:14:12] I don't think they even had a Launch Checklist on Apollo 7 [20:14:24] on Apollo 8 it was called TLI Checklist [20:14:37] but on 7 that would just be in the CDR, CMP, LMP checklists [20:17:54] I'm a bit confused. What do you want me to do besides adding the final flightplan for Apollo 7? [20:19:59] I too am confused [20:20:13] I am just coming to the conclusion that there isn't really a good solution that doesn't take away something helpful that we have right now [20:20:55] maybe if we add something that combines the CDR, LMP, CMP Checklists [20:21:17] which is then basically the crew abbreviated checklist. But that again would need to be modified to apply to NASSP [20:24:05] one thing I was thinking of doing is creating a custom LM timeline book for Apollo 11, and add the missing pages [20:24:22] using bits from the Apollo 12 LM timeline book [20:24:33] but in the Order that they happened in Apollo 11 [20:24:59] whats missing is post docking activities [20:25:45] That would be pretty good, thats basically what I did when doing the Apollo 11 checklist MFD [20:26:17] Also what might be needed is an activation checklist for Apollo 11 [20:26:27] Okay, so for now just adding the flightplans without moving anything else is good? Then we can always add more/custom docs. [20:26:45] its similar to Apollo 12 but a different order [20:27:18] Yeah you can get the order from the flight plan but the procedures should be almost identical [20:27:32] right [20:27:36] Thymo, just leave the Apollo 7 flight plan out for now. The others are good to add [20:31:14] I've amended the PR indy91 rcflyinghokie AlexB_88 [20:33:58] looks good [20:34:57] hmm [20:35:05] yep all 3 are final versions, I didnt check through every page hopefully they arent missing pages [20:35:51] I think Apollo 11 doesn't have revision A [20:35:54] July 8 [20:36:20] to be fair, I'm not sure which version of mine actually has those updates haha [20:36:21] let's see [20:37:05] I got them from the vAGC library [20:37:08] scribd.com/doc/46181272/Apollo-11-Final-Flight-Plan-Revision-A [20:37:14] this is just the revision document [20:38:34] I'm not sure they even made a printed version that has those Revision A pen and ink changes [20:39:17] ah wait I got it backwards [20:39:29] Honeysuckle Creek version seems to have the revision [20:39:58] reformatted has the revisions, too [20:40:48] hmm [20:40:59] it has the page where it says revision [20:41:06] but pen and ink changes weren't made [20:41:32] so maybe none of the available copies is really perfect [20:44:27] Honeysuckle Creek version at least has the replacement pages [20:44:47] what is this new puzzle, it's worse than Sundance :D [20:46:39] hahahaha [20:48:01] one solution would be to ask the person who made the reformatted version to fix the typos and use that [20:48:32] well [20:48:36] it doesn't seem consistent [20:48:44] doesn't use all replacement pages [20:49:15] I guess it's time to get that quote from the Apollo 11 FIDO audio again [20:49:34] 106:48:20: "We owe the crew a desired orientation, at 107:25 in the flight plan" "The old flight plan?" "Well, yeah. I thought it was THE flight plan" "They issued a new one" "Yeah, I see it here. I cannot comprehend all this" [20:51:13] ah who cares about the revision [20:51:32] Thymo, what's that change to the gitignore? [20:51:53] oh I see, it's ignoring the wrong folder? [20:51:58] it was* [20:52:21] or excluding from ignoring [20:56:10] It missed the spaces [20:56:16] So NASSP was ignored [20:57:36] right [21:14:31] Guenter! [21:14:46] interesting [21:14:47] Well then [21:15:12] "net split" [21:15:13] can you eat that? [21:16:18] https://en.wikipedia.org/wiki/Netsplit [21:17:01] One banananetsplit please [21:18:19] With extra chocolate [21:20:59] "unexpected networking fun" [21:21:22] #libera is going crazy [21:21:33] NickServ is down too so you can't authenticate at the moment [21:21:40] hah oh boy [21:21:59] well at least comms are up [21:22:04] have they tried IRC to Aux [21:22:06] No LOS currently ;) [21:22:30] IRP to aux what the hell is that [21:22:48] IRC, not IRP [21:22:49] IRC [21:24:32] IRC to AUX [21:26:10] ...you guys haha [21:26:22] one day I need to make a video about how high bitrate fixes the DAP on Apollo 5 [21:27:51] ok, it wasn't so clever to launch the LM unmanned in low bitrate [21:28:06] but how could I know that it would actually break something :D [21:30:44] looks like I missed some fun network problems, haha [21:32:26] uptime [21:32:30] oops [21:34:41] 2:34:31 up 2 days, 5:45, 6 users, load average: 0.76, 0.41, 0.32 [21:39:45] 16:39:23 up 148 days, 22:26, 3 users, load average: 2.12, 1.78, 1.69 [21:39:56] might be time for a restart lol [21:40:14] I hope that's your pi and not your laptop [21:40:44] yes lol. [21:41:11] I'd indeed apply updates and reboot lol [21:41:44] https://blog.qualys.com/vulnerabilities-threat-research/2022/01/25/pwnkit-local-privilege-escalation-vulnerability-discovered-in-polkits-pkexec-cve-2021-4034 [21:42:36] oh oh [21:42:50] *uh oh [21:43:26] It's not terrible since you'd need to be logged in in the first place. But still you'd want to patch against that [21:44:06] Btw, I'm starting on 9. Do you want me to and how do I test that specific heat model [21:46:24] Sure! The biggest thing to watch out for would be weird temperatures (absurdly high or low). Cryo system is probably the most sensitive. [21:46:50] You mentioned something about testing against branches [21:46:58] CMECS and FuelCellSystemsUpdate2 [21:47:24] Is all I need to do checkout specific_heat? [21:51:05] yeah, just checkout specific_heat. My comment was that Ryan and I should be developing our respective branches with this update applied. [21:52:01] otherwise we would have to go back and retune every temperature/valve size, post hoc [21:52:17] night! [22:15:27] n7275 yeah when I have the ECS in a point where it can be tested I will be testing it with your branch for sure [22:20:40] CMECS is in no way runnable yet [00:04:05] So what do you all think about the other FDAI? [00:16:05] I like what I've seen so far [00:16:35] question is can we get it clear in 2d [00:17:45] I would imagine so, probably by a similar method [00:36:31] yeah with having 2 textures, 1 for 3D and 1 for 2D, it should be fine [00:40:04] but I think the textures are awesome, both chrival's and Lupus's [00:40:35] but I guess we all agree to give the go ahead to chrival as we asked him first? [00:41:17] yes that makes sense [00:42:17] and as soon as Lupus_Vulpes made his post, I warned him that it was in the works. They seem to be on good terms in the girhub comments. [00:44:30] The idea of making the texture dimensions a multiple of the factors of 360 is something I never would have thought of, but it makes so much sense. [00:46:50] git is confused about a bunch of documents now [01:15:33] oooh [01:16:01] guess who reacted to one of my forum posts [01:16:13] Tschachim [01:28:11] oh wow [01:41:17] hmm, so when I turn on the CM RCS HTRS, I get a main bus B undervolt [01:43:39] let me give it a try here [01:47:36] where's the cb for those? [01:48:38] panel 8 [01:48:51] oh... [01:48:55] haha [01:49:11] I killed the high gain so now it doesnt give an undervolt [01:53:31] I'm seeing virtually no voltage drop [01:58:53] hmm weird [01:59:21] I see about a 1-2 volt drop and a sharp amperage increase [01:59:36] when I cycle the CM RCS HTRS switch [02:01:01] mind if I give you a scn? [02:09:36] go for it [02:16:19] https://www.dropbox.com/s/38be9dc9mgwa5qu/Apollo%2011%20MCC%20-%20CM%20RCS%20HTR%20test.scn?dl=0 [02:20:19] I actually had the same thing happen but I think I had other stuff powered also that shouldnt have been on [02:20:27] What were your RCS temps before? [02:26:55] oh wow. MNB is really working for it [02:30:26] strange. I don't even see the needle move on mine [02:32:45] which testmeter positions show the valve temps again? [03:08:59] rcflyinghokie, I think all but 5c and 6a on the test meter were good [03:09:17] 5c and 6a were almost 0, so I did the preheat [03:11:47] n7275, Apollo 13 entry check says to look at 5c,d 6a,b,c,d [03:18:46] I'm pretty sure mine aren't heating then [03:22:45] nevermind [03:24:13] RCS logic has to be on [03:24:39] looks like an extra 10A on MNB [03:25:37] And about the same on MNA, but it has 2 fuel cells [03:34:53] looks like we have another Apollo 10 typo... Line 760 in flightplan [03:37:23] mwhume.space/Files/orbiter.exe%20Screenshot%202022.02.02%20-%2022.35.21.37.png [03:59:07] for Nik's sanity I'm not going go touch that one yet [04:28:07] .tell indy91, everything looked fine on my Apollo 11 re-entry, using the latest "Better CM aerodynamics" PR state [14:22:31] n7275 where's the typo? [14:23:09] I see a decimal symbol in the heading which isnt causing problems, but no typo [14:23:38] I didnt remove all the decimal symbols only that one in the text field [14:24:27] .tell AlexB_88 hmm interesting I never had any close to zero in my tests, some slightly colder but not that cold, I will investigate [14:25:51] the time [14:26:39] rest peroid ends at 146:00 [14:27:03] next item is start 30° PTC at 138:40 [14:27:43] and then battery charge at 146:35 [14:29:29] ah will fix [14:29:43] pulling up the checklist I have just the seconds not the h:m [14:29:58] maybe I should have looked at the picture :P [14:31:49] Easy fix [14:32:39] Any others while I am in here lol [14:32:52] not that I've found [14:33:41] but it has likely been a while since anyone has flown the post LM jettison half of Apollo 10 [14:40:10] Its been a little for me for sure [14:40:55] Not since I wrote the checklist for it and reflew to fine tune it for MCC [14:57:15] There is some timeline deviation from the final flightplan in lunar orbit. It is possible that I caused that on the way to the moon though [14:58:16] hmm what kind? [14:58:40] and yeah MCC things at different times can cause it as well but it should sync back up [15:05:09] about 10 minutes late wrt the timeline at TEI [15:06:58] Yeah that is based on the orbit and TLI etc...10 minute difference was common [15:08:12] TEI was about 15 minutes late on the actual mission WRT the flight plan [15:08:30] 137:36:28 actual [15:08:43] 137:20 planned [15:10:50] hey [15:11:06] good morning [15:12:33] yeah I think that latest update is getting reversed haha [15:12:58] it changes the trim attitude somewhat [15:13:15] I don't like it [15:13:30] before: interpolate between axial/normal coefficients and calculate lift/drag coefficients from that [15:13:47] now: pre-calculate lift/drag coefficients and interpolate between those [15:14:02] that results in differences in-between the data points in the interpolation [15:14:21] was that change done after I flew it a few times? [15:14:45] and more than I like. And in the graph with the actual moments generated in each axis the axial/normal version has a nice straight line between data points [15:15:03] lift/drag is curved [15:15:18] yeah I just pushed it yesterday [15:15:37] ah [15:15:50] the difference isn't terribly large, but noticable in the debug line [15:16:03] in the older version it agreed 100% with the SCOT data [15:16:23] now it's 0.2° off in trim angle of attack [15:16:38] and 0.005 in lift-to-drag ration. 0.286 instead of 0.291 [15:17:31] I'd rather use the version that is consistent with the various simulators they used during Apollo [15:17:47] even if it takes a few calculations more [15:19:20] there is a data point at 160° and one at 165°. There the two methods of course give identical results, as it's not really an interpolation exactly at a data point [15:19:38] but it's not even 1° away from an actual data point and the result already differs by 0.2° [15:19:57] 160.7° vs. 160.9° [15:25:10] Yeah i think getting it to match SCOT data is the way to go then [15:25:37] could fix this with a more smooth interpolation? [15:27:04] bicubic? [15:30:12] might work [15:30:42] but if I use normal/axial then the resulting moments are linear between data points [15:31:12] while the curve in the lift/drag version could in some cases be more realistic and in others exactly the opposite [15:31:51] it doesn't say in the NAA document what method for interpolation they use [15:31:59] any downside to doing it that way? [15:33:12] you mean using the normal/axial coefficients? [15:33:20] Orbiter wants lift and drag coefficient [15:33:32] so you still need to convert it to that, after interpolating [15:34:15] that's why I had changed it to lift/drag coefficients being interpolated, a bit more efficient [15:34:52] MIT hybrid simulator uses linear bivariate interpolation of CN, CA and CM, so same as I was [15:35:05] their digital sim only has 3 data points near the trim angle of attack [15:35:14] and they calculate a quadratic function with those [15:35:54] ahh okay [15:36:02] and then linear interpolation with the Mach number [15:36:31] if the goal was to make it more efficient, then adding bicubic interpolation would negate all the performance gains [15:38:52] yeah [15:39:16] at most I would use parabolic interpolation between the angle of attack data [15:41:54] yeah, those are mostly a 2nd order thing, until you get into the really obscure stability derivative [15:41:57] s [15:54:44] yeah for the most part linear interpolation seems fine [15:54:57] at least when interpolating between the right type of coefficients [16:07:31] I have about 40 hours left until reentry. [16:14:54] you could add your scenarios as the missing Apollo 10 scenarios [16:18:50] sure [16:20:04] I have 122 of them saved not including the quicksave haha. I can fill in the end of the mission. [16:20:35] last one is after docking [16:20:40] maybe one before landmark tracking day [16:20:42] one before TEI [16:20:50] one before MCC-X (whichever it is) [16:20:57] and then Entry prep [16:20:59] and EI [16:21:02] something like that [16:22:01] two minutes before EI is best [16:28:16] can do [16:47:51] ok, CM aerodynamics are getting merged today [16:48:10] it's really the decision making that was the biggest hurdle, not the calculations or code [16:48:59] no need to test this latest update much, it's basically the same as the first version of the PR [16:56:43] nice! [16:59:56] tiny PR up for the Apollo 10 checklist [17:03:46] do scenarios still load with that? :D [17:05:56] oh, I should probably test some launch aborts [17:06:11] once the LET is gone the new aerodynamics are used there, too, of course [17:07:12] Haha yes, yes they do...it was just a copy past time error [17:07:26] Do the pitch motors/canards work? [17:07:38] yep [17:07:44] canard still needs an animation [17:08:07] but after lots of searching I had found a document with aerodynamics for the launch escape vehicle [17:08:12] 2 years ago or so [17:08:19] and it works pretty good [17:11:18] once the apex cover is gone the CM airfoils aren't used anymore [17:11:34] so for Mode 1A there is only a few seconds where they are even used [17:16:32] oh nice [17:18:24] morning! [17:23:35] hey Mike [17:29:36] the good thing about the new CM aerodynamics is that it will behave at all Mach and angle of attacks like the actual Apollo simulators. The bad thing is those simulators behaved a bit too nicely in the transonic region [17:30:08] our old CM airfoil was fairly crazy in transonic [17:30:12] maybe a bit too much [17:40:39] I guess you can't have it all at once haha [17:50:08] Not sure if anything would come of it, but it might be interesting to set up some CFD simulations with simple geometries. Need a good high-Mach, low Knudsen number solver. [17:51:51] could be useful for LM moments and drag too [17:53:07] or the S-IVB alone with SLA panels attached [17:53:27] That would make Apollo 7 more interesting :) [17:56:49] and more predictable I would say [17:57:12] right now, no moments, either the APS propellant runs out or the LVDC shuts off [17:57:22] leaving the S-IVB to slowly drift out of the last desired attitude [17:57:28] how quickly it does that, random [17:57:47] but if it's properly tumbling then on average it will have some, fairly predictable drag coefficient [17:58:07] so adding more randomness of the moments would actually make drag more predictable, I think [17:58:29] I would tend to agree [17:59:33] just a side thought, is there any way to force an attitude hold/killrot for the SIVB for say translunar coast? I love being able to target the SIVB but of course when you time accelerate the APS keeps firing and you run our of propellant...I know its trivial but something I thought of haha [18:01:47] I can look if the button in the PAMFD can be used [18:01:58] other than that, scenario editor also has that option [18:04:28] yeah thats what I usually do [18:09:33] we should probably revisit the topic of variable timestep length and rcs thrust at some point. [18:12:38] one idea is to reduce thrust with time acceleration [18:12:45] that's good for att hold [18:12:54] but bad for maneuvers that the S-IVB does on its own [18:17:28] we could keep track of total on time in the step, calculate the impulse, then apply the moment in poststep [18:19:06] another case where it's applicable is the post jettison LM [18:19:19] Most were told to hold jettison attitude [18:19:46] Start pushing time up and you get a lot of RCS firing, usually to depletion depending on the RCS quantity remaining [18:24:20] you would probably need some kind of RCS servicer thread to keep track of the on/off times [18:58:44] hey [18:59:10] morning (almost afternoon) [19:01:14] yeah I guess being near 0 is why the load was so high [19:06:12] I think the heaters are all on or off so the load would be the same [19:06:44] the heaters effectively are the secondary coils [19:18:11] when I finially figured out which switches I needed to turn those on, It looked like they pulled a total of ~19A [19:19:35] They should be divided between MNA and B [19:21:19] Ring 1 on MNA and Ring 2 on B IIRC [19:24:34] yes, a little less than 10A per bus [19:26:30] so question is why would that overload other things on MNB unless some things were on erroneously or drawing too much [19:30:58] correctly me if I'm wrong Alex, but you had other things on MNB right? [19:31:12] total draw was ~50A on FC3 [19:31:48] when I tried the same thing during my PTC scenerio I had about 36A on FC3 [19:35:54] Mode 1C test worked fine [19:36:06] I'll do one Mode II and the PR is ready for review [19:42:49] Ill test my re-entry again with the latest state [19:44:43] n7275, I think I just had the normal items that would be activated at that time per the checklist [19:45:09] but I could be wrong, maybe I had something on that shouldnt be [19:51:33] Mode II went well. Pretty high pitch rate oscillation [19:51:46] but I think that is normal [19:51:59] if it goes beyond 2°/s the SCS will damp the rate [19:53:38] and it didn't even quite get there [19:57:18] what kind of g loading did a Mode II presenty [19:57:21] present [19:57:46] I did near worst case [19:57:49] a bit over 10 [19:58:13] worst case is an early Mode II as your trajectory gets quite steep [20:02:10] and even with the oscillation SCS didnt have to kick in? [20:02:29] yeah, I think it got to maybe 1.5°/s [20:03:02] so I would say it behaves as expected [20:03:21] you sometimes get close to that limit, but rarely. And even if you do, all that happens is the RCS firing once [20:03:34] in pitch or yaw, which normally doesn't happen during reentry [20:04:38] Yeah that sounds good [20:04:54] Hmm in other news it seems the Apollo 15 docs page now 404's [20:05:00] It was working this morning [20:05:27] maybe they are just changing some things [20:05:48] the other collections they have don't work either [20:06:20] or maybe they are transferring to a different page [20:06:54] https://readux.io/collection/apollo-15/#:~:text=NASA%20referred%20to%20these%20documents,used%20by%20Commander%20David%20R.&text=Worden%2C%20and%20Lunar%20Module%20Pilot%20James%20P. [20:08:11] Yeah thats what i was hoping since it just dropped all of a sudden on me this morning [20:13:50] I got it all downloaded anyway [20:13:54] even if it's large PDF files [20:14:10] they seem to have added Gemini 8 Rendezvous charts and Flight Plan, too [20:22:03] PR is ready. Feel free to fly another reentry with it before approving [20:23:38] Oh interesting, I have a few of those [20:24:05] next I'll make the same type of changes to the CSM aerodynamics. That should be a quick change [20:25:18] just flew one, nothing to report [20:40:26] oh and I will also change three Entry DAP guidance related padloads to their actual values [20:41:10] should work fine, even if we don't use a mission specific CG location yet [20:41:20] in most cases it should work better [20:47:37] 7 entry looked good [20:47:53] Nothing unusual I could see [20:49:40] 9 also [20:49:53] (figured I would do the deorbits since Alex flew the lunar returns :)) [20:52:03] very nice [20:53:44] I'll make a lengthy forum post [20:54:16] I think this is a nice technique for creating airfoils for spacecraft, valid at any attitude [20:56:39] It was interesting to watch the spacecraft pitch against the oncoming airflow instead of just rotating straight in it [20:57:13] or yaw against it I guess haha [20:58:25] what was your attitude there? [20:59:13] indy91, is the rolling re-entries you spoke of now possible? [21:00:15] I didn't change anything for that [21:02:28] actually having worked on RTCC entry simulation, I'm not sure that technique is really useful for lunar entries or cases where the CM RCS is completely dead [21:02:54] but it's for fuel critical cases for sure [21:02:59] one Earth orbit technique is [21:03:17] lift vector up until 0.2g [21:03:25] then 20°/s roll [21:03:31] with RCS rate damping disabled [21:03:38] wait until after maximum G [21:03:53] enable rate damping [21:04:02] stop roll at 90° angle [21:04:38] yaw about 20 degrees [21:04:52] 15-20 [21:04:56] ah [21:05:10] yeah the behavior in yaw is now quite different [21:05:15] before it probably was super stable [21:05:17] i mean nothing looks wrong, just interesting to see it wrt the ground track [21:05:42] watching the yaw swing L to R etc to correct [21:05:44] feels more real [21:06:13] yep, there is now actually an airfoil for that lol [21:07:44] ah yeah, if I start at 15° yaw it will go back and forth and RCS need to do rate damping [21:10:01] depending on how faithful I want to be to all these P23s, I may or may not make it to reentry tonight [21:10:36] I can wait with the merge. I'll have my forum post to work on until tomorrow or so [21:13:15] Not that its much faster, a fresh Apollo 10 entry would be a good final test with the velocity being higher [21:21:10] might be useful to create a seperate P23 (Landmark) checklist group at some point [21:26:24] I mean it would be easy to do [21:26:34] Apollo 10 liked landmark tracking so much that they even did it with P23? Impressive [21:27:17] yes, and thankfully I knew where most of these were [21:28:46] I can't imagine actually superimposing the star against the moon like that [21:28:58] the moon is fairly bright... [21:31:12] user's guide has a note to that effect [21:58:58] night! [22:12:05] https://github.com/orbiternassp/NASSP/pull/699/files [22:12:16] Don't they have to be changed in more than just the scenario files? [22:12:20] Like RTCC and such [22:24:54] Anyone seen Max's PR? [22:25:23] What the hell is going on with those files? Looks like a tab vs space or line ending change [22:26:25] Yeah thats what I just posted [22:26:39] Why are all the lines cut and pasted again...I dont like that [22:26:57] "Add files via upload" [22:27:13] That feature always causes trouble one way or another... [22:27:15] Also wouldnt naming also impact things like RTCC and how it pulls mission data, there are presets for each mission that this could impact [22:27:22] And Charlie Brown doesn't have a hyphen [22:27:54] Does Orbiter support spaces in vessel names? [22:31:19] Yep line endings... [22:31:21] I don't know [22:31:48] If not then I understand but it looks odd to me with one [22:31:56] oh there is something bad with no hyphen [22:32:00] it will cause a CTD [22:32:19] We use Unix line endings in most files. So only a \n (ASCII linefeed) is used to indicate the end of the line [22:32:40] Most Windows editors use \r\n (carriage return, linefeed) by default [22:32:55] Comment removed [22:33:51] But other than the files, need to ask Nik how the naming and RTCC works with pulling the data like EOM or prelaunch SFP etc [22:34:48] if I recall, there used to be a CTD with Apollo 12 that took months to figure out...ended up being because of Yankee Clipper name...setting it to Yankee-Clipper fixed it [22:35:38] yeah definetly has the potential to mess with RTCC/MCC stuff [22:41:11] rcflyinghokie: I edited your first comment [22:41:23] If you do it like that it automatically closes that issue when the PR is merged. [22:41:42] Well that was the intended behavior [22:42:17] The issue I opened technically would be closed with this PR being merged (changing names) [22:44:32] oh wow, that's a few changes haha [22:48:09] in reality its like 3 lines ber scn [22:48:12] per* [22:48:21] But...he did it odd [22:58:23] oh I know. git did not understand... [23:00:25] It's just his editor [23:00:43] You can configure git to only accept one or the other, but he did it through the web interface [23:03:20] I would encourage he use VS or similar :P [23:09:03] VS is way overkill just to edit some scenarios [23:10:00] I always encourage people to learn how to work with the git cli. It's very easy to work with once you know the basics and it gives you a lot of flexibility if you need to do something the GUIs don't offer. [23:11:26] Fair enough, I just use it already for NASSP so it just naturally is what I open scn files with [00:01:27] the Old Forums used to have a post setting up your dev environment/git so that you didn't break line endings. [00:03:44] maybe we should have some kind of onboarding guideline. "read the contributing guidelines, talk to us first. etc" [00:06:51] Yeah those might need to be cleared up again, we havent had any outside contributors in a while though in all fairness [14:14:40] "ThymoNL assigned indy91 15 hours ago". I've never understood what assigning on Github even means haha [14:15:09] I've already the one doing the pull request. You can ask people to review the PR. But what is assigning for? [14:15:14] I'm* [14:27:38] In this case I meant that you can merge it. :P [14:27:56] It's nothing more than an indication who is responsible for something [14:28:03] ah ok [14:28:10] well I did finally merge it haha [14:28:48] For example at work, as long as I'm working on something I assign it to me. When I want it to be reviewed its assigned to the person reviewing it. [14:29:02] Just so others know what to do/who to contact [14:30:46] right [15:00:42] ok up to Apollo 13 we have basically been using the same Entry guidance padloads as the actual missions [15:01:06] just the trim angle of attack is different for each mission [15:02:32] yeah mostly a function of the CG location in the z-axis [15:02:48] in spite of my best efforts I did not make it to reentry last night :( [15:03:04] ah no problem [15:03:14] I had no issues left that prevented it from being merged [15:03:34] there was one thing I looked at. Orbiter has API functions to return total lift and lift vector [15:03:50] but those do not take the lift calculated in the horizontal airfoil into account [15:04:05] so that green lift vector that you can let Orbiter display [15:04:08] it's not the total lift [15:04:12] only in one axis [15:04:21] that confused me for a bit :D [15:05:17] ahh those visual helpers can cause confusion [15:05:25] especially the moment [15:07:30] I wonder if they updated the entry padloads for Apollo 13 [15:07:57] I know they compensated for the moon rocks, but it's still not the same CG location as in the SCOT [15:09:31] ah [15:09:34] found something [15:10:26] our Apollo 10 checklist ends just before MCC-7, so I guess I should probably fill that in. [15:10:52] hmm [15:11:02] I think it will automatically jump to the entry checklist [15:11:05] "Because of the abort condition, the end of mission LD dropped to 0.2905. This was outside the premission update limits for certain erasable memory parameters (LADPAD, LODPAD, and ALPHAPAD). However, since the timeline was critical near reentry, it was desirable to not have to update these parameters unless absolutely necessary. A study was conducted in the RTCC and with our mission planning decks to see if the loaded values of LADPAD, LODPAD, and [15:11:06] ALPHAPAD were acceptable. It was found that as long as the entry range was 1250 n. mi., the loaded erasable memory parameters would be acceptable for an LD of 0.2905 +/- 0.03. Therefore, LADPAD, LODPAD, and ALPHAPAD were not updated." [15:13:25] n7275, the entry checklist starts at a fixed mission time, if no other checklist is still open [15:14:04] 186:50h [15:14:23] and then there is a "deadline", but I'm not sure how that works [15:14:36] but I think you really just need to wait when the last flight plan item is over [15:14:57] uhh [15:15:02] that time doesn't seem right [15:15:25] ah [15:15:32] MCC-7 is part of that checklist [15:21:05] that's something we need to improve, it's always confusing when the Checklist MFD says that the checklist is over [15:21:15] but it's actually waiting for a time to start the next one [15:22:25] oh I was just looking in the spreadsheet. did i just miss it haha [15:23:08] okay I need to look at that again... [15:25:43] indy91 wonder if it would be prudent to just have all of the groups on the "flightplan" page [15:25:57] instead of the timetagged ones in the groups section [15:26:07] That would prevent the "no active checklist" [15:32:04] hmm yeah, could work [15:34:46] will likely break all scenarios though if we change the structure like that... [15:38:46] maybe we wait to break everything until we switch away from Excel sheets. [15:46:55] is there a plan to switch? [15:47:51] not really a plan, but it's not a good system, especially if we get random CTDs that we don't understand [15:48:06] do you happen to have an Apollo 14-17 scenario before entry interface? [15:48:20] want to fly a reentry with the modified padloads [15:48:25] it needs to be before CM/SM sep [15:48:34] before entering P61 [15:48:46] I think so let me look [15:50:04] I likely have one for each 14-17 [15:50:21] pick the one that is the easiest to find haha [15:50:40] before entering P61, but it would be nice if it wasn't many hours before [15:50:58] I would like to know why they changed the two gains that are part of the padload. If that is increase mass, different CG... [15:51:09] but it's unlikely that I will find a source on that [15:51:32] could also have happened due to the reviews and off-time after Apollo 13 [15:58:23] uhh [15:58:25] Wont take long, I found 14 and 15 getting the proper 16 and 17 now [15:58:33] I only need one [15:58:37] not one for each mission [15:58:41] Oh haha [15:58:43] just wanted to test Artemis [15:59:20] https://www.dropbox.com/sh/1wdjo2gnrf5ex6r/AABJIvHHoQmpEPYv0mH219h2a?dl=0 [15:59:24] 14 and 15 [15:59:25] awesome, thanks [15:59:37] I just saw in the Apollo 13 SCOT that it already had the updated gains [15:59:48] but the published padloads for Apollo 13 doesn't have that yet... [16:00:56] Let me know if you need any others (16 and 17 etc) [16:00:58] so I don't know what to believe haha [16:03:27] Also added a 13 for you just before LM jettison [16:03:32] same folder [16:03:39] If you needed a comparison [16:06:43] Hmm maybe not haha guess changes have made those start without power :P [16:07:04] I think I'll be satisfied after one reentry where I don't even see a difference [16:07:12] haha ok [16:09:04] what are you setting your event timer to? EI or 0.05g time? [16:11:31] Honestly I do not remember off the top of my head [16:11:57] I know I made a switch at some point [16:12:36] I think I saw in the Apollo 9 scenario that it was 0.05g [16:12:40] I think it's supposed to be EI [16:12:55] that's the time on the Entry PAD [16:12:56] RRT [16:14:02] in the not tooo distant future I'll be adding some more items to the Entry PADs [16:14:17] which are numbers based on the reentry simulation [16:14:23] and some of them are time of events [16:14:46] relative to EI or deorbit TIG [16:17:02] Oh nice [16:17:27] most of them are related to backup procedures [16:17:44] if you compare the actual to our PADs you will notice that it's not complete [16:20:31] what is it missing? [16:20:37] I am looking at 15's entry pad now [16:20:53] Ah all the RET [16:21:02] yeah, like to from EI to X [16:21:39] can't get those without simulating the reentry [16:22:41] like the* [16:22:57] Makes sense [16:23:07] RETBBO and EBO [16:23:09] DL and VL min/max is for P65/P66 only I believe [16:23:14] I assume RETDRO is drougues [16:23:23] drogues* [16:23:24] yeah [16:23:28] what about the others [16:23:53] there is a description of each item in the flight plan [16:24:07] e.g. Apollo 11 reformatted one [16:24:18] ah [16:24:38] perfect [16:26:56] your event timer is relative to 0.05g [16:27:14] I think that's not the correct technique [16:27:27] even if the difference is just the 28 seconds from EI to 0.05g haha [16:28:11] yeah I dont think I really knew which was the appropriate way [16:29:29] yeah just adjust it to the time on the PAD [16:29:34] RRT [16:31:12] hello Hawaii [16:36:07] ha [16:36:12] EMS ended on 0.1 NM [16:36:19] oh nice [16:36:25] DSKY couldn't decide [16:36:31] it started at -00019 [16:36:34] so I flew lift vector up [16:36:39] and in the end it was +00011 [16:37:10] that -00019 is a bit more than I usually saw When it switches to N67 [16:38:25] but maybe I am imagining that [16:38:36] otherwise I didn't see much of a difference [16:39:39] That seems about right when it goes to N67 on a lunar return [16:39:48] and its usually easy to null [16:40:16] yeah [16:40:26] CM is still quite fast when it switches [16:40:36] so what did I even change... [16:40:45] LADPAD, nominal vehicle L/D [16:41:05] changed from 0.3 to 0.27 [16:41:19] LODPAD, final phase L/D. Changed from 0.18 to 0.207 [16:41:33] any noticible differences? [16:42:00] And would this be identical across all of our CMs right now? Do we even use different masses? [16:42:32] not for the later missions [16:42:41] I think for APollo 7-11 we have custom CM empty masses [16:42:58] Didn't notice much of a difference. At most it let the downrange error get higher than I was usually seeing [16:43:00] but not much [16:43:04] and it quickly fixed it [16:43:11] hey [16:43:18] hey Alex [16:43:33] I think I'm fine with changing Apollo 14-17 padloads to their actual numbers there [16:43:52] the third padload, the trim angle of attack, is closer to actual anyway than our current fixed 20° for all missions [16:45:01] I think that's only used in the attitude hold calculation before P64 [16:47:48] I think the change from 0.3 to 0.27 makes it more likely that you get 0° roll at 0.05g [16:47:54] instead of 15.2° to either side [17:22:20] morning! [17:37:07] hey Mike [17:59:37] thewonderidiot, I lost a bit of trust in the padload documents :D [17:59:46] oh boy [17:59:53] how so? [18:00:19] they changed two numbers for entry guidance. According to the padload documents it's been mostly the same numbers up until Apollo 13 [18:00:40] and from Apollo 14 on they were different [18:01:05] but the Apollo 13 operational trajectory mentions those numbers, the values given are what was used from Apollo 14 on... [18:01:32] so no idea what they really had on Apollo 13 haha [18:03:09] LADPAD = 0.3, LODPAD = 0.18 [18:03:18] Apollo 14-17 all have 0.27 and 0.207 for those [18:03:29] and so does the Apollo 13 operational trajectory [18:03:34] but padload document has 0.3 and 0.18 [18:03:58] I tried to find a reason for the change [18:04:05] now I don't even know the time of the change [18:07:12] hmmmmm [18:07:32] I know they checked the number. Missing moon rocks, different CG of the CM [18:07:40] but they decided not to change them before reentry [18:07:54] but it doesn't give values [18:09:13] ah wait [18:09:16] don't we have... [18:09:24] G&C Checklist [18:10:08] which has 0.3 and 0.18 [18:10:32] maybe the people creating operational trajectories got ahead of themselves and made a change to their sims that the real CM didn't even have yet haha [18:10:48] but there could still have been a handwritten change [18:10:53] to the checklist [18:14:05] not during the mission at least [18:14:29] I think I am slightly leaning towards trusting the padload documents for what was actually in the computer [18:16:25] hmmm [18:16:56] ooh [18:17:28] operational trajectory Volume 2: trajectory parameters, revision 1 [18:17:43] which is later than what I was looking at, Volume 1, Mission Profile [18:17:57] "Two earth entry guidance constants, LADPAD and LODPAD, have been [18:17:58] changed to .30 and .18, respectively. The effect of these changes on the [18:17:59] shape of the entry trajectory are slight." [18:18:14] so they were already thinking about changing them to 0.27 and 0.207. [18:18:26] between 13 and 14? [18:18:30] or pre 13 [18:18:33] pre 13 [18:18:47] But then in the final revision of the operational trajectory for 13 they changed it to the actual values used on that mission [18:19:46] and then for Apollo 14 they actually changed it to 0.27 and 0.207 in the padload [18:20:49] I guess they came close to using the newer values, but didn't get in enough testing or something [18:20:54] or too late to change the padload [18:22:55] so all Apollo 13 padload documents have 0.3/0.18. And the missions before that used that, too. [18:23:16] they thought about changing them to 0.27/0.207. Those values were used in the initial SCOT for Apollo 13 [18:23:28] but then they didn't end up actually changing the values for 13 [18:23:39] so the final SCOT document has the same as in the CMC, 0.3/0.18 [18:23:46] interesting [18:25:08] just a little bit confusing :D [18:25:43] so, trust in padload documents is at least partly restored? haha [18:26:00] yes [18:27:22] the MSC people just couldn't decide what they want [20:43:18] thewonderidiot, it gets more confusing [20:43:25] oh no [20:43:48] I was wrong, Apollo 11 and 12 padloads had 0.27 and 0.207 [20:44:01] the GSOP suggested values are 0.3/0.18 [20:44:17] and with the lack of padloads that's what we were originally always using [20:45:08] yeah, the GSOP says nominal values 0.3/0.18 [20:45:14] in all revisions of the GSOP section 5 [20:45:54] we don't know for Apollo 10 and before, but maybe only Apollo 13 flew the GSOP suggested values then... [20:46:34] a bunch of MSC documents suggest 0.25 and 0.225 for simulation runs... so a third set of numbers. But unlikely to be actually flown on a mission [20:47:45] do I want to look at Skylark padloads... [20:48:26] hahahaha [20:48:33] 0.25 and 0.225 on Skylab 2 [20:49:15] same for ASTP [20:49:44] the thing is, these sets of numbers aren't chronological. You basically have all 3 of them in various documents at any time [20:49:49] and all three versions were flown [20:51:18] I feel like 0.3 and 0.18 came from MIT [20:52:20] earliest version of the RTCC reentry simulation (mid 1967) also used 0.3/0.18, but that's probably before they had time to try and find better numbers [20:58:30] I can only assume there were 3 groups of people each lobbying for a different set of entry gains. And each group won the argument at different times. [21:03:18] oh jeez [21:03:25] that's crazy [21:04:19] I'd love to find some memos about that, I'm sure they had some good arguments [21:05:34] oh right [21:05:38] Tindallgrams [21:07:45] hmm, or not [15:04:55] good morning [15:05:27] Apollo 10 reentry went well [15:11:46] this one's unlisted because I wasnt sure if you were going to make one. [15:11:50] https://youtu.be/9ouV55wJucg [15:17:22] hey [15:17:37] nah, it hasn't really changed that much, wasn't going to make a video [15:17:45] nice FDAI [15:39:50] cool. [15:40:31] I might want to revisit the FDAI thing, need to check which one I have. was testing both. [15:44:08] I haven't really paid much attention [15:44:22] I'll be fine with it when you all like it haha [15:49:08] oh the reason why I didn't really know Alex' answer about ballistic entry from the Moon is that we don't have a single Apollo Mission Techniques document for TEI through reentry [15:49:16] UHCL has at least one version, for Apollo 8 [15:49:18] already scanned [15:49:27] so not having that yet is easily corrected [15:51:00] I guess I'll just request all the mission techniques documents they have already scanned at once [16:27:19] good morning [16:29:34] hey Ryan [16:29:48] are you seeing any issue with that PR for renaming the CSMs? [16:30:18] there must have been some very old scenarios where there were Gumdrop and Charlie-Brown [16:30:44] because in the places where vessels are detected by name there already were checks in place for both e.g. AS-504 and Gumdrop [16:30:51] PAMFD and RTCC MFD [16:32:05] just in one place it was missing [16:32:21] it should be fine. If something we didn't think of breaks it will be easy to fix I think [16:33:57] and I think the line endings issue is also fixed? [16:37:51] must be, in the initial PR it was like every line was changed [16:51:17] Got sidetracked, Yeah the first PR the line endings made it like 500k changes lol [16:51:27] As far as the current state I have not tested it [16:52:09] ah testing [16:52:10] good idea [16:52:16] Haha [16:52:28] I'll quickly look at his branch [16:52:44] I think it was your one ARCore change and then just scn files changes [16:53:23] I know we have talked about markers many times, is there a simple way to put lunar landmarks in Orbiter 2016 Beta/NASSP? [16:56:05] the landmark format changed in Orbiter Beta. I think it's just a matter of converting them over. [16:56:29] changed in Orbiter Beta or for Orbiter 2016? [16:56:42] I think it is sort of compiled files [16:57:00] so we have to edit files that come with Orbiter? [16:57:05] maybe I am remembering wrong [16:57:41] it's been a while since I looked at it [16:57:41] Yeah i think there is some editing [16:57:55] But I have had people ask about it and I think it would be good to somehow include [16:57:59] I just dont know how [16:58:05] maybe they never worked in 2016 [16:58:24] iirc the format changed to include altitude [16:58:32] if it is the same sort of scheme like the star file then I could come up with something [17:03:34] I am trying to find it...some people had a work around for using old landmarks [17:03:41] I just cannot remember what it was [17:04:56] LabelFormat = 2 [17:05:20] will allow using old style landmarks [17:05:46] where is that changed [17:05:55] but then you have no altitude, right? [17:05:57] and is there a way to make new ones and push them with NASSP [17:08:25] ah, LabelFormat goes in the planet config file [17:08:47] Post in thread 'New Orbiter SVN commit (r.71, Oct 14 2017)' https://www.orbiter-forum.com/threads/new-orbiter-svn-commit-r-71-oct-14-2017.33387/post-509707 [17:12:21] it's weird that out Apollo Earth Landmark mkr file is in Config/Earth/Marker [17:12:25] our* [17:12:43] yes [17:14:24] I added LabelFormat = 2 a few years ago when we switched to using the Orbiter Beta [17:15:12] there is a marker file in both earth and moon [17:15:32] ah "If you want to use the old-style mkr files, take out the LabelFormat = 2 line from the config." [17:15:46] take out, I thought add haha [17:15:59] Would that work? What about the altitudes? [17:18:07] they would be off, but at least you'd see relatively where the landmark was [17:18:50] Could we feasibly add the altitudes? [17:19:34] I'm sure [17:19:54] we would need to understand the format of the tree file [17:20:50] So not as smile as just putting in what the CMC uses [17:20:52] simple* [17:29:53] indy91, does the DSKY name section know to use the non AS-XXX name? [17:30:03] AGC_BEGIN [17:30:04] ONAME AS-504 [17:30:04] ONAME Gumdrop [17:30:05] For example [17:30:31] AGC ONAME [17:30:33] well you shouldn't have both haha [17:30:44] right that was copy paste not having the +/- [17:30:56] AGC_BEGIN [17:30:57] -ONAME AS-504 [17:30:58] +ONAME Gumdrop [17:31:02] that's used just in a few places now [17:31:12] for example to let the RR know which vessel is the CSM [17:31:20] and yeah it can deal with it [17:31:23] Ok [17:31:31] Other than that I don't see any issues [17:31:32] what I looked at for a moment was the naming of the S-IVB [17:31:47] but it gets its numbers from the VehicleNo [17:31:52] which is separate from the vessel name [17:32:14] so the S-IVB will still be called AS-504-S4BSTG if AS-504 gets renamed to Gumdrop [17:32:18] because VehicleNo is 504 [17:32:24] Right, which makes sense [17:37:20] Those seem localized to the scn file so old and new scns wouldnt break RR tracking [17:38:00] yep [17:38:45] just confirmed in Orbiter code, the old style labels always have the same radius as the planet [17:39:10] So thats why alt wasnt required? [17:39:17] it got never added [17:39:24] from before Orbiter 2016 [17:39:49] So what would we have to do to enable these [17:40:03] remove [17:40:03] LabelFormat = 2 [17:40:13] from the Earth and Moon config files [17:41:10] but especially on the Moon the markers could then be off by up to 2 NM from the actual surface [17:41:38] I found the PDF where the new format is described [17:41:45] fairly easy to generate the raw data for that [17:42:59] I'm pretty sure that the RR uses the class name, not the vessel name [17:44:06] oh, maybe we can get rid of it then [17:45:42] nah [17:45:46] LM_VHF still uses it [17:45:50] csm = lem->agc.GetCSM(); [17:53:45] So as long as the scn file loaded is consistant it should be fine [17:54:57] yes [17:55:29] hmm [17:55:35] maybe there is a way [17:55:38] for the labels [17:57:44] I mean we have the coordinates, we would just have to add altitudes? [17:59:29] I mean separately from the label.tree file that is part of the Orbiter HD textures [17:59:47] Label.tree is 100MB [18:00:00] wouldn't be a great solution if we had to edit and distribute that [18:00:24] but for the non HD textures there is a different file format [18:00:45] and in the default setting it will kind of try to load both HD and non HD textures [18:00:49] don't know how that works [18:00:58] hmmm [18:01:18] Some people have the regular and some have the high res also [18:01:34] So a solution would have to take into account both types I would think [18:04:31] so why cant we use the marker file? [18:05:05] because of terrain [18:05:26] I mean maybe as a temporary solution [18:05:37] we could enable the old style markers [18:05:43] even if it's at the wrong altitude [18:07:37] it would still give a ballpark [18:08:09] oooh [18:08:59] https://i.imgur.com/AYJ7OXl.png [18:09:21] Test321 successful :D [18:10:54] Oh nice! [18:11:03] and this is added in a separate file [18:11:07] Now will that still work with HD texture files [18:11:12] yes [18:11:26] it loads this marker, but also all the other markers from the Labels.tree file [18:11:41] that's what I was afraid might not have worked [18:11:44] but it does! [18:11:51] woooo! [18:11:53] as long as you have the right setting in the DX9 client [18:11:58] but I think it's the default [18:12:12] top left [18:12:15] Tile Archive [18:12:21] option needs to be Cache & Archive [18:12:43] that way it tries to load both the default textures (Cache) and the big .tree files (Archive) [18:13:12] but that is on by default I believe, I hope I didn't change that [18:14:02] so now I need to understand what I even did :D [18:15:11] I kind of followed the PlanetTextures.pdf suggestions [18:15:27] I added a file in Textures\Earth\Label\05\000000\000001.lab [18:15:34] but what does that even mean... [18:16:51] I believe the 5 is the resolution level [18:16:57] but why does that even apply to labels [18:19:45] ah I guess it's loaded together with a specific resolution level [18:20:16] so it wouldn't appear if you are far away if the label is only in resolution 10 or so [18:20:45] that's why the Label.tree file is so large, it has to have each landmark many times... [18:21:12] I should just RTFM [18:21:38] "he resolution level at which a label appears in the quadtree determines the camera [18:21:39] distance at which is appears in the render window. By moving a label to a lower resolution level, it will be visible at a greater distance. For example, large cities should be [18:21:40] entered at a lower resolution level than small villages." [18:24:15] oh wow [18:24:37] So does this mean the moon behaves the same way? [18:25:22] yeah [18:26:16] I have merged the CSM Name PR [18:26:30] Does the texture resolution in the d3d9 settings mess with these at all? [18:27:04] And excellent [18:27:32] I will launch a few of them and verify names then close the issue [18:29:43] ok [18:29:58] Eh [18:30:16] I wanted to squash Max's commits so they don't say "Add files via upload"... [18:31:19] uh oh :P [18:31:28] I guess you arrived about 2 minutes too late for that haha [18:32:10] and that's just part of the commit name [18:32:28] if it was just "Fixed the Apollo 9 and 10 scenarios so the CSM uses the correct name instead of AS-5XX numbers" it would be better of course [18:33:07] indy91 should I be able to generate a DC vector for the CM on the launchpad in RTCC? [18:33:23] Typing "Gumdrop" doesnt work [18:33:39] maybe it blocks you out because you are landed [18:33:40] let me check [18:34:05] I was able to initialize the masses and such with Gumdrop at least [18:34:21] //CSM state vector can't be landed of course... [18:34:22] if (csm && landed) return 1; [18:34:28] doesn't allow it [18:34:46] prevents a DC vector for the CSM ephemeris that is landed [18:35:10] and you have to manually enter Gumdrop anyway, it just takes the vector from the vessel you enter [18:35:41] so that would always work as long as the vessel is in the simulation, whatever its name. As long as it isn't landed and a CSM DC vector hehe [18:36:21] I think I specifically added that for you and your crashed S-IVBs [18:36:49] Ah ok just checking [18:37:11] Trying one in orbit [18:37:39] the thing about the tiles, at higher resolutions there are multiple files for textures, elevations, labels [18:37:56] 1 file in level 3, 2 files in level 4, 4 files and so on [18:38:17] if it only loads level 3 tiles of an area then you are still far away [18:39:04] which means, if I add the lavels to a higher level than level 3 then I need to split them up over multiples files [18:39:24] so I will try level 3. I hope you can't still see Earth labels from the Moon [18:39:34] at that level [18:40:25] Haha or moon labels from earth [18:40:38] yeah [18:40:47] I mean, it wouldn't be terrible, you can turn them off [18:42:00] and you would want to see the labels as soon as you come over the horizon [18:44:34] true [18:44:55] Also I didnt dig too deep but the RTCC seems to be playing nice with the names [18:45:05] Going to try some RR tracking just to be sure [18:46:02] ok, so, I flew straight up from that test label [18:46:31] and it disappeared at 11,000 km [18:46:35] not tooo bad [18:47:15] not at all [18:49:21] So this would make the labels work out of the box if turned on? [18:51:29] yep [18:51:46] it would be added to the list of default Earth labels [18:52:47] and the markers just turned on and off the normal way like stars? [18:53:31] yeah, like landmarks before [18:53:56] in Orbiter 2010 [18:57:09] very nice [18:59:29] although that does overwrite the small Labels.cfg file from Orbiter [18:59:38] adds a line to it [18:59:54] Label.cfg* [19:03:04] Okay. Fixed the squash issue. Please see who is assigned to a PR next time. This took 10x more time than it should've... [19:03:23] that shouldnt be a big deal though if one is using the current beta, but updating orbiter could overwrite that correct? [19:05:27] Thymo, thank you for finally giving an example what that "assigning" means. I think I've understood it now haha. [19:05:36] indy91: Will your padload changes be accompanied by a worksheet update or did you source them from somewhere else? [19:05:38] I'll look at that from now on [19:05:56] one step ahead [19:05:57] https://github.com/orbiternassp/padloads/pull/6 [19:06:36] Thanks. I probably should've communicated my intent better. I'll be sure to add a note if I want to do something next time. [19:07:07] yeah, initially I wanted to wait to ask you, but I thought all remaining issues were resolved after the line endings were fixed [19:08:09] the source for the padload update is the padload documents. We have just been using the same set of default numbers for all mission [19:08:18] until now [19:08:24] the MIT suggested values [19:08:28] only flown on Apollo 13... [19:09:51] I flew an Apollo 15 reentry for testing. Ideally this goes together with a mission specific CG of the CM, but it works just fine [19:10:12] and the more padloaded parameters are identical to the actual missions the better [19:10:52] Looks like LAD LOD and ALFA pad were changed? [19:11:00] yep [19:11:25] LAD and LOD are gains [19:11:38] ALFA is used to determine the attitude to hold before reentry [19:12:10] And we can now use this because you improved the aerodynamics I take [19:12:48] I guess it's slightly closer. But I am sure it would have worked fine before with those values, too [19:14:14] I guess until now when we created new padloads we just stayed on the safe side and used the same set of numbers for all missions that we knew would work [19:24:40] So whats the verdict on the markers? [19:29:30] I'll try to convert the old markers to the new format [19:32:07] Did the SM get changed recently? [19:32:31] I'm sitting on the pad and it's almost like it's glowing blue [19:33:36] not that I know of. The CM got changed and is now a lot more shiny [19:33:56] have a picture of it? [19:34:47] https://puu.sh/IHfgr/8238b6b424.jpg [19:35:06] Like a water reflection [19:35:34] that looks like when you use the DX9 debugging tool let it display a specific mesh [19:35:35] weird [19:36:26] I'm sure Alex would have an idea [19:36:53] .ask AlexB_88 Is this a reflection side effect? Looks weird to me. https://puu.sh/IHfgr/8238b6b424.jpg [19:38:07] oh [19:38:10] I get it, too [19:39:10] it's partially transparent [19:39:17] the color depends on what you have in the background of it [19:40:11] Hmm yeah [19:40:28] there was a SM change [19:40:33] https://github.com/orbiternassp/NASSP/pull/672 [19:41:17] and [19:41:18] https://github.com/orbiternassp/NASSP/pull/667 [19:41:44] Interesting lol [19:42:40] it seems better once the tower is gone [19:50:41] What's Orbiter's atmosphere temperature again? [19:50:43] Cold? [19:53:20] basically standard atmosphere I think [19:53:37] you can look at the info tab [19:54:06] Well either my temperature gauge is broken or its freezing in Floraida [19:54:30] 13° C [19:54:43] Hmm. My CSM is pegged low at 20F [19:54:46] So -6 C [19:55:43] I think it can be seasonal [19:55:52] if the default atmosphere model is used [19:56:25] or not [19:56:30] I get fixed 288.13 K [19:57:17] Mine is 287.62K [19:57:24] is this cabin/suit temp? [19:57:45] Yes [19:58:19] I was just looking at a DG at KSC, it probably depends on the location [19:59:18] I shut the hatch. Too cold for me. [19:59:31] Cabin is instantly 70°F [19:59:36] Suit is still freezing [20:00:35] I've got 70°F and 70°F on a fresh Apollo 12 scenerio [20:00:57] what branch are you in? [20:01:44] Orbiter 2016 [20:02:36] hang on, let me switch [20:02:48] I'm past cabin closeout [20:12:21] I have never tested anything I did for GSE in the stable branch only the beta [20:13:04] Temperatures are coming up again [20:19:31] strange, I'm seeing normal temps on Orbiter2016 too [20:21:31] old scenario maybe? [20:22:49] which mission? [20:23:02] 9 started last week [20:24:58] did you by chance switch to my specific_heat branch at all? [20:26:50] I have at some point [20:27:08] This is were I continued tonight https://puu.sh/IHfK5/bc878a759f.scn [20:27:23] CabinTempMeter 68.475847 68.475847 SuitTempMeter 52.772413 52.772413 [20:27:26] Still looks normal though [20:57:55] hmmm [23:50:38] .ask indy91 would this issue be closable now? https://github.com/orbiternassp/NASSP/issues/5