[15:38:28] NASSP Logging has been started by n7275 [15:38:30] hey [15:40:51] Good morning [15:41:13] I didnt realize how much had to be undone with the CSM ECS in the code lol [15:41:26] There is so much done in there unnecessarily [15:49:55] hey [16:01:10] good morning [16:05:11] helli [16:05:17] *hello [16:09:50] I'll generate some graphs now to compare old and new aerodynamics [16:10:37] nice. I like graphs [16:11:46] I built your branch last night but didnt get to much testing. should be able to this weekend though [16:13:51] rcflyinghokie, no hurry on teating the specific heat update. but I wanted to make sure you had it before you tuned everything to the old system [16:14:19] hmmmm [16:15:10] You mean for the CSM ECS? Or the current state? [16:15:59] for the csm ecs [16:18:11] I think 5% of realistic drag isn't actually a good tradeoff [16:21:51] https://i.imgur.com/WC6Ma4q.png [16:23:44] in terms of coefficients at 0° the legacy model gives almost no drag [16:25:40] if I make it 40% you can see the difference between realistic (40%) and legacy very well [16:25:42] https://i.imgur.com/9Bk1HMu.png [16:26:04] n7275 yeah I am a ways from being able to actually test the ECS (lots of code fixing to do) [16:26:20] it's of a bit misleading as you will likely spend more time at 0° angle of attack than in other attitudes [16:26:29] but not that much more [16:37:22] as you can see from the blue line, it makes a huge difference between 0° and 90° [16:38:04] and that is a randomness factor that I want to get rid of [16:43:25] So Reentry is starting LM tests...I am helping debug...man they are going to hate me [16:47:03] oh you got hired away from us? :D [16:47:20] nah [16:47:26] I saw the call for LM testing [16:47:46] So i decided to try it...its pretty frustrating so much is wrong :P [16:47:50] I don't even own Reentry yet [16:48:01] Its pretty, but very much on rails [16:48:09] be careful with what you call wrong, you never know [16:48:13] like abort "buttons" [16:48:19] and FDAI rate needles... [16:49:05] I've started to not take any NASSP code from before my time as given by god haha [16:51:42] Oh haha [16:51:51] With the LM its pretty easy though [16:52:02] Like their Panel 16 is literally inverted [16:52:18] They flip the LM PWR CSM switch up to CSM to switch to LM power [16:52:33] Pull all cross tie and bus breakers during powerup and leave them open [16:52:34] etc [16:54:04] But I digress, I can only do that for a little at a time [16:54:06] yeah, I'm sure there are a lot of things that we would call easy mistakes [16:54:17] Very much so [16:54:22] speaking of not so easy mistakes [16:54:29] I feel lied to by the Orbiter API guide [16:56:08] oh? [16:57:06] legacy aerodynamics [16:57:08] SetCW [16:57:12] you give it 4 values [16:57:19] cw_z_pos coefficient in positive z direction (forward) [16:57:20] cw_z_neg coefficient in negative z direction (back) [16:57:22] cw_x coefficient in lateral direction (left/right) [16:57:22] cw_y coefficient in vertical direction (up/down) [16:57:35] The first value (cw_z_pos) is the coefficient used if the vessel's airspeed z-component is positive (vessel moving forward). The second value is used if the z-component is negative (vessel moving backward). [16:57:50] that's what it says [16:57:53] I'm reading the code [16:57:59] it doesn't use cw_z_neg at all [16:58:04] and I just tested and confirmed that [16:58:05] oh no [16:58:25] I don't know if that was used at some point or what [16:58:57] so does that give you zero drag moving backwards? [16:59:01] nah [16:59:08] it always uses the forwards value [16:59:20] double cw_cs = vd_side*fabs(vnorm.x) + vd_vert*fabs(vnorm.y) + vd_forw*fabs(vnorm.z); [16:59:33] vnorm being the airspeed vector [17:00:23] oh okay [17:00:35] https://github.com/orbitersim/orbiter/blob/main/Src/Orbiter/Vessel.cpp#L6950 [17:00:46] it calculates a "vd_back" value in SetCW [17:00:49] but it's not used [17:02:40] even more reason to switch to airfoils I guess [17:02:48] but in any case, I think 5% is too little [17:03:07] 30% might be closer than what we get on average [17:03:11] but if 30% is ok [17:03:16] why not 100% immediately haha [17:05:51] Here is another interesting graph btw [17:05:55] https://i.imgur.com/Y4luFYf.png [17:06:02] it has legacy aerodynamics as before [17:06:16] but then the two flow regimes the new airfoils simulate [17:06:26] free flow is what you basically get in orbit [17:06:30] and that was used in the previous graphs [17:06:45] continuum flow is what you in at lower Mach numbers, in atmosphere [17:06:56] it's more intuitive [17:07:06] if you think about the shape of the CSM [17:07:17] 180° being SPS nozzle poiting forward [17:07:38] a lot more drag than CM forward with the continuum flow [17:07:41] not so with free flow [17:30:14] for some reason imgur made me confirm I was over 18 for that one haha [17:30:46] haha oh my [17:50:23] the curves weren't that sexy [18:03:45] morning! [18:08:33] hey Mike [18:15:29] hey Mike [18:17:13] indy91, coördinate system question. what rotation matrix do I need to go from a global relative position vector (vessel to celestial body) to a local vector in the planets rotational frame? [18:26:50] oapiGetRotationMatrix [18:27:04] that converts from local to global [18:27:15] left handed [18:33:05] although if this is modified Orbiter code you might even be able to directly access the matrix [18:33:10] and not call the API function [18:41:54] ok I think I'll keep the drag at 5% for now [18:42:20] get that merged, work on Apollo 7/9 MCC better taking the drag into account [18:42:25] and then put it up to 100% [18:44:46] Let me know when you do, I will go through the checklists for 7/9 when you do so everything lines up [18:48:03] I think I'll keep Apollo 7 close to the actual mission, but I was also planning to do a few checklist updates from the final flight plan [18:48:14] but you can do some more of course [18:54:47] sounds good [18:54:54] I could use a flythrough of 7 [18:58:01] get a good book for the second half of the mission [18:58:32] but I can probably add some activities from the final flight plan [18:58:37] slightly less boring mission then [19:01:35] haha I can let it coast as I work :P [19:34:23] if I want to avoid flying Apollo 7 twice then I need to make the changes to Apollo 7 and 9 MCC in one go [19:34:44] both with full drag [19:38:48] haha [19:40:35] Apollo 9 shouldn't need too many changes [19:41:35] maybe none, but I am not sure [19:45:41] I think SPS 7 was the only one with issues? [19:48:41] yeah, although that wasn't really drag related and is already fixed [19:49:14] after SPS-7, because of the random drag and the RTCC not taking it into account, you got inconsistent deorbit targeting results [19:49:59] I guess if the MCC is directly doing some long term trajectory predictions it needs to use new functions that take the drag into account [19:54:02] Yeah propagation and such [19:54:11] I think a smart way of doing it would be to have the MCC manipulate the areas and masses for the vehicles [19:54:23] as stored in the MPT header [19:54:35] and then the trajectory propagation stuff just works as normal [19:57:18] maybe that's how it should work in the RTCC MFD, too [19:57:44] just need to not confuse myself with MPT vs non-MPT modes there [20:01:39] Ah yeah lol [20:16:04] I need to circle back around to that Apollo 9 s band antenna tracking test at some point [20:22:59] Ah yes I remember that one [20:23:31] n7275 was looking at that as well with the tracking stations I believe? [20:25:45] yes [20:28:21] it's more a question of when should stations become active/inactive relative to aos/los of themselves and other stations [20:32:44] hmm would one of those earth orbit charts with the range circles help? [20:47:16] somewhat. our MCC already knows what's in aos though [21:02:36] maybe something like x seconds after aos a station becomes active, and stays active until aos by the next station [21:03:42] the RTCC calculates these times for 0° elevation, although I have seen reference to 5°. 5° might be a reasonable number for when a tracking station can be used [21:10:55] the tracking stations get acquisition data and also directions where to point the antenna [21:11:10] but when the actual AOS happens, not sure [21:14:46] indy91, I am trying to remember, when we did the LM ECS was there any code written to account for a valve slowly opening or cracking open? [21:14:53] Or were they all open or closed [21:15:51] I am writing the emergency cabin pressure regulator class for the CM and want to be able to go from no flow at >4.6, a minimum of 0.67 lbm at 4.2 psi and it increase to max flow as the pressure drops to 3.5 [21:16:05] not sure what the max flow is though haha [21:16:57] so not slowly opening/closing over time, but in a pressure range [21:17:41] yes [21:17:43] I don't think we wrote a class for this, but we used that kind of logic a few times [21:17:48] just as a linear equation [21:17:58] ah ok thats what I thought [21:18:01] /0 flow at 5.25 psi, full flow at 5.8 psi [21:18:02] cabinOVHDHatchValve->flowMax = max(0.0001, (660.0 / LBH) * (1.81818*(cabinpress*PSI) - 9.54545)); [21:18:04] like that [21:18:09] Thats the one I was thinking of [21:18:49] I just wish I knew the max flow it was capable of [21:19:22] I could probably reverse engineer it, it can provide a mass flow rate to maintain 3.5psi for 15 minutes with a .25in hold [21:19:28] hole* [21:20:04] whoever put this // 0.67 lb/min max, see AOH in the code didnt read the AOH very well :P [21:22:27] haha [21:23:33] clearly says "minimum" in the AOH and system handbook [21:56:22] night! [22:03:47] this is annoying I cannot find max flows for the cabin pressure regulator or emergency regulator [22:09:29] Not sure where else to look [22:11:57] Hopefully I find something haha [22:19:05] odd that the minimum is specified but not the max [22:23:00] probably because there is no flow restriction for a max, its dependant on the pressures [22:23:17] Basically max is just "wide open" haha [22:28:14] do you know for sure that it's a 0.25" opening? [23:40:19] Well thats the scenario [23:40:36] For the emergency regulator [23:41:00] for a 0.25" hole in the CM, the regulator can provide a minimum of 3.5 psi in the cabin for 15 minutes [00:08:09] oooooh okay [00:25:56] hmm my naïve Bernoulii-equation attempt at solving that gave me an answer that is an order of magnitude lower than your minimum... [01:07:41] my gravity model seems to work well, except that it returns -inf NaNs if the order and degree are 1458 or higher... [15:37:40] hey Alex [15:41:03] hey whats up [15:50:31] not too much, taking a break from part two of my fuel cell update to upgrade Orbiter's gravity model. [15:55:02] what's up with you? it's been a while. good to see you here :) [15:59:16] ah, nice. I guess that will help simulate the "mascons" experience on the real missions [15:59:52] not much on my end, been busy with work, but I might fly Apollo 11 over the next few days which I have off [16:31:21] nice [17:23:13] .tell indy91 before I forget, is there any reason the PTC REFSMMAT time is editable in the RTCC mfd? Just had another user change it, ending up with an incorrect REFSMMAT [14:59:35] .tell indy91 we did it again, answering the question together lol [15:16:46] rcflyinghokie, too slow [15:17:37] yeah got distracted mid message [15:18:09] not for any flown mission no, but for missions that are theoretically possible to fly, like a different launch day [15:18:31] Makes sense [15:18:33] might need a different PTC REFSMMAT [15:19:12] Need to make a note to not touch that time lol [15:19:33] yeah, that time might appear like something random [15:19:38] Right [15:19:48] I have had 3 people now change it to the current time [15:20:12] I guess I'll add a note on the display saying what that time really is [15:20:18] average time of TEI in the launch window [15:20:36] Or maybe a way to default it back [15:22:28] maybe. I think a short explanation on screen is helpful in any case [15:23:27] hey guys [15:23:31] hey Matt [15:23:37] Shifting gears slightly, how do you compute the LOI-5 and PC+2 in the current RTCC state? [15:24:01] discrete time aborts [15:24:08] basically like any TLI+X I think [15:24:41] AST page? [15:24:46] yes [15:24:50] got it [15:25:34] Before I am doing too much thinking on it, I'll merge the drag update and get to work on making the 100% drag possible [15:25:42] Awesome [15:25:46] on average that leads to less drag than before, but just temporarily [15:25:59] And for the TZ? What times were used on those? [15:27:03] whatever the CSM had enough fuel for [15:27:35] haha [15:27:36] and doesn't lead to a violation of the reentry speed constraint [15:28:16] I'm not sure they had a 100% consistent system [15:28:22] in doubt read the AFJ [15:28:30] and find the TZ in the flown PADs [15:29:19] I've definitely seen cases where they didn't choose the theoretically fastest return home [15:29:42] where they had enough fuel to return home 24 hours quicker [15:31:43] for PC+2 there are two types though [15:31:52] minimum DV and minimum return time [15:32:08] for minimum return time you would increase the maximum reentry speed [15:32:10] Used the flown pad for this one [15:32:17] Numbers worked well [15:32:25] RTE page isnt populating though [15:32:26] from the 36323 or whatever it is to 37500 ft/s [15:32:33] Error: 8 [15:32:43] AST worked but RTE not? [15:32:45] yes [15:34:22] good morning [15:34:48] hey Alex [15:34:51] Hey [15:35:01] rcflyinghokie, error 8 is numerical integrator failed to find the desired condition [15:35:14] I'm flying Apollo 11 with MCC, just about to do TD&E [15:35:38] I see 2 cases of it in the code. One time the AST solution fails to intercept entry interface [15:36:09] https://www.dropbox.com/s/qe8ecj18tt9oxg8/Screenshot%202021-12-13%20083557.jpg?dl=0 [15:37:27] I'll need a scenario, it sounds like a bug [15:38:00] here is the one I am troubleshooting: [15:38:35] https://www.dropbox.com/s/ir3x7tv9mj1e2f8/0004_Sun_Dec_12_12.35.33_2021_0004_0005.scn?dl=0 [15:38:50] He had MPT active but I deactivated it before computing [15:40:46] ok, which inputs did you use [15:41:15] I guess I can mostly see if from the screenshot [15:42:21] haha yeah [15:43:23] 72:24:53 and 166:54:02 [15:43:28] MPL [15:43:30] etc [15:43:31] can reproduce it [15:48:12] that is LOI-5, right? [15:48:16] Correct [15:48:21] I think it searches for the reentry flight path angle [15:48:33] but finds it in lunar SOI [15:53:04] it's a bit confusing why that can happen [15:57:32] So a bug? [15:57:41] yeah definitely [16:05:21] curious if it impacts the MCC at all [16:05:52] it doesn't. This procedure with AST first and RTE later is not used by the MCC yet [16:06:31] there is a bunch of code in the RTCC that exists twice. An old function that is still used by the MCC because it's reliably [16:06:48] and new, more realistic function used by the RTCC MFD [16:09:40] over time the old functions get removed [16:10:03] but as we see here, there can still be bugs in the new functions :D [16:11:08] haha yes [16:11:18] So would PC+2 likely result in the same bug? [16:12:43] nope [16:13:00] the error happens because it's searching for the reentry flight path angle of about -6.5° [16:13:20] with LOI-5 it finds that angle in lunar orbit [16:13:24] lunar SOI* [16:13:29] just before pericynthion I guess [16:13:57] instead of at entry interface [16:15:12] that angle doesn't occur after PC+2, not until EI [16:15:26] Ah [16:16:27] there is a flag that can be switched on that always propagates the state vector to pericynthion first [16:16:46] maybe that just needs to be done [16:19:38] would that be accurate [16:21:09] it's one of those annoying cases where I have both functions involved in this from the IBM RTCC documents. It's very clear what happens if the flag is switched on [16:22:01] but in the other function the flowchart only has this [16:22:15] "set up triggers, weights, limits, step sizes for independent variables" [16:22:35] so probably a lot of stuff that has to be taken care of not given in full, but just this short text [16:24:18] so in one case I am happy "oh great, it's so detailed, I'll implement it exactly as in the real RTCC" [16:24:33] and then when the other flowchart isn't as detailed I have to deal with the consequences... [16:35:45] haha [16:48:40] so, the silly question, is this an easy fix long term or a bandaid [16:58:18] it's fairly easy. Just have to check if I can find a good solution that works in all cases and still agrees with the IBM RTCC documents [16:58:31] if not it will deviate just a bit from it [17:02:18] sounds good [17:08:31] For the VHF ranging, does the VHF A RCV need to be off in the actual vehicle? [17:08:50] I am just trying to find out where that is shown [17:19:12] rcflyinghokie, I see you have taken over my job of RTCC MFD bug hunter since the past few months :D [17:19:49] Apparently! [17:53:31] morning! [17:58:57] hey mike [18:03:32] hey Mike [18:16:15] I cant seem to find an answer to this LM VHF question haha [18:16:55] what's the question? [18:49:23] rcflyinghokie, any specific guideline on when to connect the "CSM O2 Hose"? [18:58:20] thewonderidiot basically if for CSM/LM VHF ranging, the VHF A RCVR has to be off, and also the guidance on if both can be on [18:58:56] AlexB_88 its whenever you IVT to the LM, you will see on the IVT checklists to bring the CSM O2 Hose, that is essentially what this is doing right now [18:59:17] Once the LM ECS is powered up then the hose is usually brought back up the tunnel [18:59:53] But in any shirt sleeve LM operation when the LM ECS is not on, the hose is used to circulate air and keep CO2 levels down in the LM [19:04:37] got it thanks [19:05:07] up to the evasive burn now on 11 [19:05:54] I feel like the LM pressurization goes much quicker then before, and closer to the timeline in the checklist [19:07:45] like before I would need a few refills of the repress package, but now it seems that I can go through the whole procedure without having to refill it at all during, other then when you do it at the very end [19:12:25] You are welcome :P [19:13:03] I tweaked the eq valve to get more realistic timing, its still not perfect, but seems to work much better [19:13:24] Hopefully will be even better with the CSM ECS updates (a little ways off of course) [19:24:56] nice [19:26:05] any other observations in particular for the CSM and LM ECS's? I know they've been worked on extensively since my last mission I think [19:41:14] Waste stowage valve is functional [19:41:30] n7275 did a rework of substances properties [19:42:12] LM seems to be better climate controlled, though still needs more heat added to the glycol with a few remaining systems [19:53:29] https://www.orbiter-forum.com/threads/v8-release-work-thread.36128/page-8#post-587754 [19:56:26] ok [19:56:38] I also noticed the Direct O2 valve pressuizes the cabin quicker [19:59:53] I haven't adjusted that in a while, could be simply the substance changes with that one [20:02:26] Trying to think if I made any other changes that would impact the Direct O2 valve [20:04:48] Regardless good to hear things working better than broken! [20:18:01] quite good so far [20:23:37] Please point out any anomalies of course [20:27:16] sure [16:23:40] good morning [16:37:09] hey Ryan [16:38:46] hey [16:39:11] hey Alex [16:39:25] trying to fix that RTE bug, then on to Apollo 7 [16:40:44] nice [16:41:00] just about to do MCC-2 on Apollo 11 [16:43:02] Ah sweet [16:43:24] indy91, were you able to ponder the VHF receiver question at all by chance? [16:43:48] ah no, I was thinking the question was more for n7275 who worked on it more recently [16:43:59] I can look [16:44:39] I just mean the fact that our implementation I guess must have VHF A RCV OFF [16:45:05] right [16:45:07] I just couldnt find why that has to be the case, especially since its not in procedures that way (no mention of turning it off before turning B on) [16:45:24] in the AOH they do "VHF A sw - OFF" [16:45:36] so that you don't send voice over VHF A [16:46:38] but as far as I can tell having the VHF A receiver on might be harmless in reality [16:46:53] recently = 18 months [16:47:39] "more recently" [16:47:40] haha [16:47:58] LM Systems Handbook has a switch configuration for VHF Ranging [16:48:07] VHF A XMTR - VOICE/RNG [16:48:10] VHF A RCV - ON [16:48:14] out implimentation has a function that checks if the vhf system is "configured" properly [16:48:16] VHF B XMTR - OFF [16:48:21] VHF B RCVR - ON [16:49:27] so VHF A receiver on should be fine [17:00:57] but I am not sure where in our code that would prohibit it wrong working right now [17:01:02] it from* [17:02:16] indy91, I just made a small modification in the mission constants used by the MCC for my mission, the landing site [17:02:41] the age old question of the Apollo 11 landing site radius? :D [17:02:42] so that it targets the actual landing site since I am using custom scenery [17:02:59] the coordinates [17:03:23] IsVHFRangingConfig() [17:03:35] oh ok [17:04:00] n7275, I think the issue is only on the LM side [17:04:44] correct switch position there [17:04:51] that function is only in the CSM as far as I am seeing [17:05:43] I guess just changing the landing site shouldn't mess it up to bad, I changed them in the files 1969-07-16 Init, 1969-07-16 SFP and the erasable memory RLS for CSM & LM [17:06:14] so far the MCC seems to be fine with it, MCC-2 calculation seems good [17:07:42] then again does MCC even use the SFP stuff? [17:08:43] it does [17:09:02] even automatically stores table 2 for MCC-3 and 4 [17:09:12] wow [17:09:21] even with a MED input haha [17:09:42] GMGMED("F30,1;"); [17:10:01] the MCC is outdated in some ways when it comes to RTCC functions [17:10:05] but not with the TLMCC [17:10:25] right [17:13:23] and the MCC for Apollo 11 especially should be fairly flesible [17:13:27] flexible* [17:13:42] as I intended it to also work with the July 18 and 21 launches [17:13:50] not that I ever fully tested that :D [17:21:53] I guess for the full launch window too for a given launch (late launch, 2nd opp TLI) [17:24:29] damn it I keep opening the CM forward hatch when clicking the DSKY from the CDR seat [17:24:58] since it is directly in line with it behind [17:25:18] I will have to prevent click actions in that area when in the CDR seat [17:25:20] Haha [17:25:31] I already did that in the LM actually [17:27:33] you can only click the forward hatch handle or relief valve when in the proper view (hatch) in the LM [17:36:20] I am curious why placing that VHF A RCV to OFF resolved the ranging issue if there is nothing in the code requiring it [17:37:49] morning! [17:39:56] hey Mike [17:47:00] hey [17:47:10] rcflyinghokie, nothing I immediately saw at least [17:47:31] interesting [17:47:43] but there could still be something [17:48:27] thewonderidiot, Ron still hasn't put everything on the website from your scanning trip, did he? I was looking for the AS-205 and 504 crew abbreviated checklists. Found them on your Google Drive though. [17:48:49] he hasn't because I haven't processed everything and sent it to him yet :( [17:49:02] definitely going to try to finish that off over this christmas break [17:49:03] ah, that would be the reason haha [17:50:05] I got a bit, uh, distracted by this rope stuff [17:51:04] understandable [17:51:48] rcflyinghokie, in that scenario with the RTE bug, that's an interesting PTC going no [17:51:49] on* [17:51:54] about 10x too fast :D [17:52:01] Haha I know I pointed it out [17:52:10] Rate scale was set to 5|5 [17:52:58] yeah, that's what I thought [17:54:31] at first I thought it was a SCS issue [17:54:55] in old scenarios, preceding a BMAG change I did, the attitude error could be suddenly high [17:55:06] causing some RCS firing if you were in SCS att hold [17:58:05] and the MPT doesn't like that scenario either [17:58:18] when I open/close it and then open the current scenario [17:58:23] it fails to load :( [17:59:01] there is a maneuver without code which is already very weird [17:59:50]