[23:34:06] NASSP Logging has been started by thewonderidiot [23:34:11] Guenter! [00:12:08] oh good, someone woke him up [13:06:10] Hey Nik [13:06:16] hey [13:17:13] the SCS update will be fun to review [13:17:20] it's exciting changes like [13:17:25] pitchrate = pitchBmag->GetRates().x*cos(Attitude.x) + yawBmag->GetRates().y*sin(Attitude.x); [13:17:26] to [13:17:30] pitchrate = pitchBmag->GetRates().y*cos(Attitude.x) - yawBmag->GetRates().z*sin(Attitude.x); [13:17:50] "Looks good to me" [13:24:23] still working on SCS Auto TVC though. Not 100% sure I got it right yet [13:26:26] it was all kicked off by Alex asking innocently if the DV CG switch is now doing something :D [13:36:16] on average I get about 10 ft/s error in the DVY and DVZ axes for both LOI-1 and TEI [13:36:30] I'm not really sure if that's good [13:37:03] I guess it isn't bad at least, it's like a 0.25° average pointing error of the thrust vector [13:57:29] I'm flying 10 right now. did my first TD&E last night with the new cg [14:00:31] ah fun [14:00:45] with the updated RCS directions it will feel slightly different, but not too much [14:01:13] I think in general the rotations caused by translations will be less [14:02:02] it wasn't as bad as I thought it would be. going slow is definitely the trick [14:03:13] yeah it's just the opposite effect of what we had before and a bit stronger because the moments of inertia are smaller [14:07:25] i wonder how bad a CSM-active rendezvous and docking in lunar orbit, with tank slosh modes would be. [14:17:20] GSOP section 6 has calculations for slosh [14:36:34] ooooo cool. I might throw this into a matlab simulation this weekend [14:36:49] I see there's bending mode dynamics too. [14:37:07] yep [14:41:47] I'm not sure that there is a Orbiter API function apply a custom moment [14:41:52] there is AddForce though [15:22:00] Good morning [15:23:48] hey Mike, Ryan. [15:28:15] morning! [15:30:31] indy91 any luck looking at that TLI? [15:30:54] hey [15:31:08] well all I saw was the normal small transient when it switches to terminal guidance [15:31:16] maybe slightly larger than usual [15:31:25] but nothing unusual [15:31:32] ok which is what I saw as well [15:31:49] and using the correct timing for it (30 seconds vs. 15 seconds) doesn't change much [15:32:05] trajectory differences negligible? [15:32:07] time from cutoff [15:32:13] hmm good question [15:32:24] if anything doing it earlier will be slightly less accurate [15:32:34] but it's what they used [15:33:03] terminal guidance at 30 seconds from cutoff, the 15 seconds came from the 1967 Boeing document [15:33:20] its interesting that the jump isnt on the TLI tables under the psi (which I assume is ordeal?) [15:33:40] it's visible in the graph in the launch checklist [15:34:42] very much so haha [15:35:11] interesting its not on the table as well [15:35:57] it's a 4 degree jump in the table [15:36:11] 260° at 5:00, 256° at 5:30 [15:36:26] hmm [15:36:47] the graph and table are 1° off from each other at 5:00 [15:37:11] but not on the psi [15:37:39] did you get a jump in yaw? [15:37:52] Apollo 17 yaw angle is basically 0° throughout the burn [15:37:53] oh psi is yaw [15:38:16] and you of course have to look at the nominal table [15:38:18] not manual [15:38:20] I dont know why I was thinking that was the ordeal pitch *facepalm* [15:38:29] manual is fixed yaw, and constant pitch profile [15:39:03] oh you thought ORDEAL pitch, I see [15:39:13] Apollo 17 is doing extremely little yaw haha [15:39:14] yes thats the root of my confusion [15:54:07] I have the draft PR of my RCS/SCS update up [15:54:32] not 100% convinced yet about the SCS Auto TVC, but I don't have a good reference for what is good [15:57:13] Manual TVC in Rate CMD works as well as before even with the shifting CG [16:05:20] being able to set the right trim angle before the burn is very important, so I don't think the "hidden" right click option to change the angle by 0.1° is good enough. That should be more obvious. [16:08:01] yeah probably true [16:08:09] also, did you look at the ASCP by chance? [16:08:27] it takes 11 right clicks to move 1 degree which seems wrong [16:09:00] I think that might just be a visual glitch [16:09:06] I can check [16:09:21] there is also this [16:09:22] https://github.com/orbiternassp/NASSP/issues/47 [16:10:56] I'm seeing 10 clicks for 1° [16:11:04] maybe it depends on the initial angle? [16:11:17] and where did you see it, roll, pitch, yaw? [16:16:08] let me test [16:16:36] just tested in yaw at 0deg [16:17:19] going up 0 to 1 takes 11 [16:17:24] going from 0 to 359 takes 9 [16:17:40] ah [16:17:53] so I think the actual 0° position is visually off [16:20:12] VC or 2D? [16:21:22] and I don't think its consistent haha [16:30:43] all 2d [16:30:47] havent tried vc with this [16:39:54] ASCP needs an overhaul anyway, the code for it is bad a complicated [16:39:58] and* [16:40:22] at least the code related to displaying and controlling it [16:59:52] I wrote a really incorrect BCD to hexadecimal converter in a PLC once. our ascp behavior reminds me of it. [17:09:18] haha [17:19:46] n7275 LM press went normally [17:19:56] No surprises or unusual readings [17:22:01] that was my experience with 10 as well. good to know. [17:37:37] insy91 just making sure I still remember, its the evasive maneuver enable that starts the sequence for the SIVB yaw maneuver etc correct? [17:37:41] indy91 [17:38:06] yeah [17:38:20] and then TB8 enable [17:38:49] evasive maneuver is the yaw maneuver and tb8 is the evasive burn? [17:39:35] TB8 starts the evasive burn [17:39:49] got it [17:39:58] and the yaw maneuver is basically the first step for in the evasive maneuver [17:40:06] but the naming can be confusing [17:40:15] right thats why I had to confirm [17:40:43] Apollo 17 flight evaluation report calls it "evasive yaw maneuver" and "TB8 Initiate" [17:40:53] maybe I'll add the yaw in the PAMFD description [17:41:25] makes it a bit more clear [17:42:32] gotcha [17:42:40] the flight plan has yaw maneuver and evasive burn [17:46:55] bye bye SIVB [17:51:31] do we have a complete pdf systems checklist for 17? I see the one on the AFJ but its individual pages [17:53:21] thewonderidiot scanned one [17:54:31] or was that Systems Data only... [17:55:20] I see systems data [17:55:32] right [17:55:37] I haven't made the Systems Checklist into a PDF yet [17:56:16] Are you just using these pages? [17:56:17] https://history.nasa.gov/afj/ap17fj/a17-csmscindex.html [17:56:51] that's what I have looked at in the past [17:57:03] we do have the very similar Apollo 15 one though [17:58:43] right I have that [18:00:00] you fly the mission with the CSM CG update, right? [18:02:36] Yes [18:04:16] let me know if you see anything unusualy. I hadn't tested SIM bay door jettison yet, but the change for it was exactly the same as for the optics cover. [18:04:28] and that I did test that it gets created in the right place [18:04:31] so should all be fine [18:04:40] TD&E actually felt good [18:04:51] it felt more "expected" if that makes sense [18:08:39] will still change a little bit with the update RCS thruster directions [18:09:33] it mainly makes the rotations causing by translations weaker [18:09:38] but they are still there [18:09:45] oh I saw them [18:10:16] but nothing out of the ordinary if anything it felt more stable [18:10:34] when I tested SCS Auto TVC with TEI and did the ullage burn the rotations were quite strong [18:10:42] that's why I checked and then changed the thruster directions [18:10:50] they are in the draft PR I have up [18:10:59] should get merged soon, a bit more testing [18:11:45] sounds good [18:17:02] https://www.dropbox.com/s/d7ycxt0x2o3gpiz/Apollo%2017%20CSM%20Systems%20Checklist.pdf?dl=0 [18:17:12] combined from the AFJ files if you want it [18:19:05] ah great, thanks! [18:20:27] Mike scanned the EXP/EVA Checklist [18:20:37] that used to be in the Systems Checklist [18:21:07] I saw that, I haven't opened it yet though but I am certainly looking forward to putting flight plan references to it and procedures into context this time [18:21:36] 16 already had that, right? [18:21:44] for 15 it was in the Systems Checklist, I think [18:22:43] 16 has it yeah [18:23:18] systems checklist we have for 15 had TBD on thoser sections [18:24:10] not the flown 15 one [18:24:34] https://readux.ecds.emory.edu/books/readux:vg61k/ [18:25:25] the copy on the AFJ has the TBD yeah, that's what was available first [18:28:05] I keep forgetting about that collection [18:29:22] oh can I see when my tb8 time is via the lvlog? [18:30:15] ah found it [19:27:32] So with this late launch do i need to do anything different when calculating MCC2 [19:28:52] looks like the actual MCC2 was burned on the FP time of 35h30m [19:29:41] just that you want the planned LOI GMT instead of GET [19:30:10] so basically a bias on the flight plan GET [19:30:13] with your launch delay [19:30:58] 2:40h earlier than the flight plan GET, or whatever the delay was [19:31:52] ah ok [19:32:09] I hope that works [19:32:20] well the initial guess is already close to that [19:32:26] maybe try an unconstrained LOI GET first [19:32:29] if it even works [19:32:43] yeah thats what I meant [19:32:46] oh [19:32:48] great [19:33:05] what's the DV like [19:33:08] 13 minutes different unconstrained (taking the 2h40m difference into account) [19:33:12] 8.1 [19:33:15] love it [19:33:24] going to constrain a bit and see what happens [19:35:11] I constrained to the FP LOI time and have a dv if 17.1 [19:35:29] I'm totally fine with that considering we don't have the full presettings for 17 [19:35:33] is there a proper way to run the constraints? I usually just tweak TLMAX [19:35:48] and leaver TLMIN the rounded hour before the burn or so [19:35:56] ah if that works, great [19:36:09] on Apollo 13 they kept it in a 10 minute window from TLMIN to TLMAX [19:36:17] oh ok cool [19:36:20] and then shift that window around until I get the desired result [19:36:41] how large the time window is does make a little bit of a difference in the generalized iterator [19:37:09] but in general it should work fine with any values [19:38:22] I usually keep it within about 30 minutes, I reduced to 10 in this case and now have it within 1 second of LOI planned time [19:38:29] 17.7 the final dv [19:39:02] https://www.dropbox.com/s/b6cwiwb4qjzvqiv/Screenshot%202021-09-24%20133850.jpg?dl=0 [19:39:33] I'll recompute after PTC but I am happy with that initial computation I think [19:39:34] I'd say that is the better IU navigation at work [19:39:49] Yeah it looks good [19:39:58] the display there estimates the LOI TIG in a fairly simple way [19:40:18] so that will already be a few seconds off from when you would calculate LOI for real [19:40:41] maybe some bored night shift FIDO tweaked the numbers even more to get the actual LOI TIG right on the second [19:41:20] that's my impression from listening to the FIDO audio :D [19:42:08] actual LOI ignition was about a minute earlier than flight plan [19:42:43] 88:54:21.74 versus FP 88:55:37.5 [19:56:25] yeah, I think the actual desired condition is rev 2 meridian crossing time or so [21:16:24] just for grins I am burning APS-1 and APS-2 [21:21:23] what are all the "minor loop" in the lvlog? [21:22:16] maybe ran out of propellant during time accel? [21:22:35] hmm yep [21:27:32] oh haha [21:27:48] I guess it displays a bunch of stuff that it normally doesn't [21:27:54] or logs I mean [21:29:06] the lvlog needs to write less stuff in general [21:39:13] night! [21:44:28] .tell indy91 forgot to ask before you left, can we uplink a SIVB PTC command yet? [22:03:16] hmm I think waste water dumps slower now (it was already slow before I believe) [22:04:41] 3 hours to dump 80% [22:04:47] that seems wrong [22:59:29] yeah, that doesn't seem right at all. [23:03:15] I question is: why. [23:04:10] I bet the pressure is lower. [23:32:10] I mean it dumped slow to begin with I think, but yeah [23:39:59] I will have to look up the spec'd flowrate but increasing the size of the valve should be a nice tidy solution to that. [23:45:36] yeah easy fix we just need to figure out how much [23:52:59] the units of "size" are alegedly in liters/(Pa*sec) [23:53:29] so hopefully not too much trial and error [14:54:44] good morning [14:56:18] morning [14:57:53] hey [15:12:39] hey [15:20:05] I dont think the water dump is entirely dependent on the valve size... [15:20:07] wasteWaterDumpLevel = 0.5 * (wasteWaterDumpLevel + (wasteInletVentPipe->flow / wasteInletVentPipe->flowMax)); [15:20:45] the code is a little confusing to me its not a simple open/close [15:20:53] ecs.cpp line 1115 [15:29:32] yeah, I don't like how that's written either [15:33:26] oh I see updates to your vap branch, anything I should be merging? [15:36:00] I just pulled the changes that Nik pushed yesterday [15:39:11] Are you sure that line controls the water dump rate? [15:39:21] ah ok [15:39:26] And no I am not [15:39:57] But I increased the valve to 0.01 from 0.001 and saw no noticeable change in dump rate [15:40:30] I'm 95% sure it is used to control the particlestream [15:40:53] increased from 0.01 to 0.001? [15:41:41] no increased from 0.001 to 0.01 [15:44:40] okay, I need more coffee [15:49:22] ditto [15:51:48] let's point some debug strings at it [16:45:57] I am out of the house for a few hours. I can poke at that when I get home later. [16:55:55] I will be as well most of the day [18:28:04] hey [18:28:12] not really [18:28:19] Afternoon :) [18:40:23] I've added a bunch of people to review my PR, haven't found any new issue with it [18:40:51] I still want to go through the SCS coordinate changes to make a final check on the code itself, but testing has been all good [18:41:55] so still a draft for 1-2 more days [18:43:01] the SCS Auto TVC does now work differently for CSM vs. CSM/LM with the DV CG switch. But what is still not implemented is the filters [18:43:19] not that we really need them, we don't have noisy signals or body bending [18:43:23] right [18:43:43] in the NAA simulator there are the transfer functions for the filters [18:43:45] Any particular situation you want tested with that? [18:43:52] hey Niklas [18:43:56] hey [18:44:10] any SCS operation you can think of [18:44:34] ok [18:46:02] there is a LM-on and a LM-off shaping filter for noise in the SCS Auto TVC. The transfer function is basically a damped harmonic oscillator, so that wouldn't be too difficult to implement [18:46:34] for the CSM/LM docked case there is an additional filter for body bending I think. That looks a bit more complex [18:47:41] but in any case, they won't be part of this PR [18:47:50] just a nice enhancement for the future [18:50:30] Indeed [18:50:43] I guess the SCS Auto TVC could use some specific testing [18:51:05] Some long and short burns under SCS? [18:51:08] sure [18:51:31] that's the enhancement part of this update. The other SCS changes are to make the code readable haha [18:52:06] was really confusing dealing with attitude rates in Orbiter coordinates while everything else is in the correct, CSM coordinates [18:52:38] the issue isn't even completely fixed. It goes as far as displaying the the attitude rate in the FDAI class [18:52:47] that is still not using the right signs and coordinate I think [18:53:05] but I didn't want to have to do changes in the LM when I wanted to fix stuff in the CSM SCS... [18:53:50] I dont blame you [18:54:08] MTVC with Rate Cmd hasn't really changed, just that the CG shifting means that you have to do more inputs [18:54:14] especially during TEI I guess [18:55:04] but I think that still works very well, you could easily fly a maneuver using CMC guidance, but SCS control looking at the error needles [18:55:17] like manually flying a reentry to the CMC guidance [18:59:01] I meant it's a bit like that. I was of course talking about SPS thrusting maneuvers with manual TVC. [18:59:27] although SCS entry is something I also haven't tested yet with the update [19:04:22] I wouldnt mind playing around with that [19:04:32] Though not using a joystick makes it challenging [19:07:41] it's not too bad actually, the MTVC integrator means it remembers the last input you did [19:08:12] so you don't really have to constantlly do a small input [19:08:29] so it works ok with keyboard [19:10:21] Accel Cmd however would be difficult without joystick [19:14:34] just tried a TEI, using the CMC error needles, but manual TVC in Rate Cmd. 2.0 ft/s residuals [19:14:49] with keyboard [19:14:55] it's definitely better with joystick [19:15:01] but it works fine without [19:23:28] Ok good to know [16:07:00] good morning [16:10:51] hey Matt [16:13:17] I feel a bit stupid asking, but what exactly is this ECS project you and Ryan are working on exactly changing. Just behavior of the substances? [16:21:58] hey, nothing wrong with asking. Yes, I am working on am inprovement to our substances. [16:22:29] right now I'm focusing on vapor pressure, and enthalpy of vaporization [16:22:55] so really just a physics change [16:23:01] trying to find my graphs to show you... [16:23:06] and not a format change to scenarios or so [16:23:35] or chemistry I should probably say [16:25:37] amazingly, no, I don't think we'll need to change anything. [16:25:40] https://i.imgur.com/IZXEZGU.png [16:26:35] that's good and we should keep it that way, I think changing how the substances behave is a big enough update [16:26:57] the red shows the the systems as they are now, and the blue shows the new version [16:27:05] definitely a difference [16:27:12] Ryan is flying 17, and I'm flying 10 with these changes [16:27:30] it's probably not even that bad for old scenarios I would imagine [16:27:54] and I used a scenario from Ryan in my branch without the update, got an O2 flow alarm but it settled down after a bit [16:28:09] I think the systems that are currently implimented, and the values that were chosen for the implimented systems work really well together [16:29:35] the heats of vaporization are constant, but they were chosen at temperatures that most of the implimented systems are at, [16:30:14] right [16:30:41] like the CG of the CSM was well optimized, but sadly just for Apollo 7 only haha [16:30:45] and the slopes and values of vapor pressure are close approximations of the new and improved versions at the temperature-pressure values that most things are at [16:30:55] haha, yeah. [16:31:20] are a lot of additional calculations required? [16:31:24] what this update should do, is allow us to impliment things that were previously impossible [16:31:37] not that I really think the systems simulation is really the CPU killer [16:31:45] it's the 2D panel and the emulators [16:33:16] very little extra overhead https://github.com/orbiternassp/NASSP/compare/Orbiter2016...n7275:VapPressAndHvap?expand=1 [16:33:57] yeah that's not much [16:34:31] calling exp() instead of simple arithmetic is probably the biggest, but CPUs are good at that [16:36:29] yeah [16:37:07] I was already thinking about the SCS Auto TVC filter and how I would implement that in the most optimized way [16:37:22] but it would also just be two exp() and a sine and a cosine or so [16:37:58] but I can make it so that the same calculation isn't done multiple times at least [16:41:52] direct solution of the transfer function which is a damped harmonic oscillator [16:42:01] can't have a numerical, timestep by timestep solution [16:42:15] that differential equation is extremely stiff [16:42:50] yeah, that wouldn't work [16:44:09] thankfully, damped harmonic oscilators have nice analytical solutions [16:44:21] yeah [16:44:52] even though I had trouble figuring out the right equation to use. Had a confusion about degrees and radians, rookie mistake [16:47:14] ouch, yeah. "why is this off by a factor of 57..." [16:49:34] I havn't made it very far on the tank-slosh project, didn't have the time yesterday. [16:49:43] https://i.imgur.com/beEdP1z.png [16:50:15] simple noise filter [16:51:31] what is your noise function? [16:52:50] x = 0.9 + 2*rand()/10.0; [16:53:02] random from 0.9 to 1.1 [16:53:07] on average 1 [16:54:07] that looks nice and easy to compute [16:55:04] yeah, easier than I initially thought [16:55:12] it's a forced damped harmonic oscillator [16:55:18] but the force function is the constant input [16:55:33] at least constant over one timestep [16:55:47] you still need to calculate and keep track of the initial conditions [16:57:37] I wonder if the magnitude of the noise should decrease with increasing timestep? [16:57:43] length [16:58:59] you mean remaining noise of the output? [17:00:22] yeah. unless I'm thinking about this wrong [17:00:29] you are thinking right [17:00:40] if I make it 10 fps then there is no difference to see between input and output at all [17:00:51] the graph was with 60 fps [17:01:20] for 600 fps the output looks basically the same as with 60 [17:01:32] but the noise graph is of course a lot more visible [17:01:39] as it's a random number on each step [17:10:15] this is for the CSM alone case [17:10:29] I think the CSM/LM docked version is a bit less stiff [17:11:38] CSM: damping ratio 0.805, angular frequency 40.7 rad/s [17:11:52] CSM/LM: 0.489, 29.0 rad/s [17:17:50] ok SCS works correctly during entry [18:05:45] nice [18:07:33] I still need to review/test your changes. [18:07:34] out of the house now, hopefully can do it tonight [18:08:16] sure, no rush [20:21:40] night! [05:14:49] .ask rcflyinghokie when you edited the waste water valve size did you do the one in the CFG file, or in the scenerio? [14:10:08] hey [14:11:33] morning [14:11:58] I did the config file [14:12:09] but then reverted when I found that code [14:17:40] I changed the valve size in the scenario, and was able to change the flowrate [14:18:18] I think the scenario overrides the cfg if the system exists already. [14:21:46] it does, yes [14:43:59] 0.05 was nice. no idea if it's right or not. [14:50:09] yeah I dont know where to find flow rates for the dump [14:50:35] maybe in some of the 16 and 17 experiment docs since they used urine and water dumps to test some of the equipment [14:54:51] hey [14:55:18] morning [14:55:45] what are you looking for? Waste water flow rates? [14:55:49] dump* [14:57:09] yeah [15:02:49] AOH had nothing [15:05:16] Is the dump valve the same as the pressure relief valve? [15:05:29] or are they different components [15:06:00] the water overboard dump nozzle is the one connected to the pressure relief valve [15:06:08] urine is separate [15:06:36] the waste water you manually dump is the pressure relief valve [15:09:13] 12 lbh at 70F and 6.5psi dP [15:10:28] and for the relief valve in all positions its a .3 gal/min minimum flow with 48psi dP [15:11:05] n7275 CSM data book pdf 307/308 [15:11:16] data book part 1 [15:15:19] thank you [15:22:06] Hmm I cannot seem to get this MCC4 on the MPT [15:22:20] I computed one and then deleted it and now am doing another and it wont go on the table [15:23:23] any error on the online monitor? [15:24:17] nope [15:24:56] are there old maneuvers on the MPT? [15:24:57] ephemris updates completed and rmmascnd convergence limit [15:25:04] MPT is blank [15:25:21] "rmmascnd convergence limit" is it trying to find the ascending node, which only works in low Earth or lunar orbit [15:25:34] so that error is always there in TLC or TEC [15:25:35] I did compute one, it appeared there, then I did a replace and it didnt replace [15:25:45] so I deleted it and tried again with no luck [15:25:47]