[22:30:43] NASSP Logging has been started by thewonderidiot [13:38:47] Good morning [13:41:16] hey Ryan [13:41:32] Secondary loop works [13:41:38] at 298 lb/hr [13:42:11] very good [13:42:19] I'm teaching the MCC how to do IU uplinks [13:42:30] I was worried last night in testing because the press came up to the middle of the green band, but looking back I realized that was just from heating [13:42:42] and the 21 psi is based on 40F glycol [13:43:08] middle of the green band seems not so bad, haha [13:43:12] Exactly [13:43:35] The nominal discharge pressure is 21 for the sec loop and 23 for the prim loop, giving a lot of room for increase [13:43:45] Because 20 is the bottom of it [13:44:26] Now do you mean IU for TLI or also post sep things? [13:46:02] for Apollo 9, so removing the two inhibits. [13:46:13] first the on that keeps the S-IVB in TD&E attitude [13:46:24] and then the one that inhibits the 2nd burn [13:47:50] for both the astronauts technically have to give their go, so I might add something for that to the CAPCOM menu [13:50:58] Yeah seems prudent [13:52:18] Oh you probably saw this but if you want to fly an extended J mission, I do have tanks in the config that match the mass and volume of 3 tanks so they can be used in the 2 tank configuration for long mission tests [13:52:45] ok [13:52:46] Until we have a J mission config of course later down the road [13:52:51] yeah [13:53:06] shouldn't be too complicated to implement the separate J mission config [13:53:12] Nah, same with the LM [13:53:23] Just add a tank here, battery here etc [13:53:57] oh, that's the easy part. Making the vessel load the right config is a little bit more tricky [13:54:10] Ah yeah [13:54:13] because there are also different panels and switch logic involved for the additional tanks [13:54:33] we have some old logic for the Skylab CMs in the code right now [13:55:09] not creating certain switches etc. [13:55:12] Right [13:55:16] Deleting O2 fans [13:55:35] changing which tanks are displayed on the gauges [13:55:54] Etc [13:56:06] yeah [14:38:21] morning [14:38:45] hey [14:40:13] so I see the FC rad's are normal again [14:40:46] guess it needed a min load [14:41:19] yeah [14:41:23] Yeah [14:42:28] I am trying to figure out the best approach to this suit heat exchanger [14:43:07] Right now, because of the plumbing, when it is closed all the mass flows out and it is really low pressure, seems like a source of instability [14:43:57] is this CSM or LM? [14:45:52] LM [14:46:16] I got the secondary loop up to 298 lb/hr last night so I have moved to the primary loop [14:48:45] I noticed that LM pressurization is faster now with yesterday's PR, am I imagining? [14:51:58] btw guys, I was pondering something yesterday... Should we change the name of "Apollo - Historical Missions" folder to that of something more appropriate like "Training Scenarios"? [14:52:01] You may have the technique down [14:52:14] My last big PR didnt change LM Press [14:52:26] haha im getting better [14:52:40] maybe its more stable though [14:54:20] You had my surge tank and other updates already right? [14:55:01] hmm I guess, I'm up to date with the main repo [14:55:42] so I must of had those updates as they cam, yes [14:55:47] came* [14:56:03] So probably just getting better ;) [14:56:21] Usually takes me 50 minutes to get to about 4.8 psi in the LM [14:56:36] right [14:57:03] also on older scenarios I notice that 02 tank 1 PSI full scale high [14:57:10] but on launch scenarios it looks ok [14:57:26] maybe a bit higher than the PSI on tank 2, but not a lot [14:58:14] that's not the O2 tank 1 [14:58:32] that's the surge tank [14:58:51] O2 tank 1 is normal [14:59:45] the scenarios throughout the mission are not only for training [15:00:06] if you screwed up your flight and just want to continue, then they are also useful [15:01:21] yeah I agree, maybe "Apollo - Mission Scenarios"? [15:01:38] just ideas of course, its not bad as it is now [15:01:45] AlexB_88 the surge tank is not gaseous O2 so an old scn that had liquid O2 is now "boiled" and thus the pressure is way high [15:01:50] yeah, Mission Scenarios could make sense [15:01:52] now not "not" [15:02:14] You will see the same thing in the repress package gauge [15:02:42] I mean if its way complicated to change that folder name, maybe too much work for nothing [15:04:45] there are some simple ways to renaming a folder and all scenarios in it [15:04:54] in git I mean [15:05:02] rcflyinghokie, yep I see that now. One thing though, the higher pressure on O2 tank 1 display when my switch is in "tank 1" and not surge tank [15:05:29] in the launch scenario that is [15:05:55] Yeah for some reason the fans in tank 1 are turning on [15:06:03] Same with the H2 [15:06:09] I cannot figgure it out [15:06:19] They shouldnt be hitting the pressure switch [15:06:32] If you start a launch scn and turn the fans to off you dont get the rise [15:06:33] ah ok [15:06:56] And turn them back on in about a minute to auto no rise happens, it looks like a loading transient in pressure maybe [15:06:59] weird [15:07:13] But it rises and then when it hits the fan press limit it comes back down to normal [15:07:25] No c/w [15:08:25] I havent debugged any further than that to be honest [15:08:46] indy91, I'll give the folder renaming a try, so "Apollo - Mission Scenarios" [15:09:22] ok [15:12:56] are tanks 1 actually dropping below the lower pressure limit for the auto cycle to start? [15:13:40] ah, to be 28 again [15:14:19] and to exist 3 times [15:15:12] 1st time i've had that I think [15:16:02] I did some searching online, it appears renaming can be done with git mv oldfolder newfolder [15:19:50] wow that was easy [15:22:35] indy91 I dont know, the gauges come up slow but come up to a normal pressure [15:22:51] I havent checked the pressure immediately on startup [15:23:16] how did you calculate the initial energy in the tank? [15:23:28] to achieve a certain temperature or pressure or... [15:27:16] the descriptions of Apollo 7 and 8 still have the "Enabled features: Virtual AGC, LVDC++ and MCC" I'm thinking of removing that from the descriptions as now all those things are by default, except MCC of course [15:27:51] unless the plan is to add those to the remaining scenarios [15:28:00] I calculated to a specific temperature then adjusted for pressure [15:30:21] Pressure and temp are good on startup [15:30:29] Yet the fans turn on [15:34:01] fans or heaters? [15:34:27] or both [15:34:56] hmm, they are all boilers in the code, so it doesn't make much difference [15:35:36] I think it was just the fans but I am going to check it now [15:40:57] I think I'll add just Enabled features: MCC to the scenarios with MCC [15:43:43] Yep fan and heater are on at start for tank 1 [15:44:01] If I turn them off and back to auto they stay off [15:44:16] Nothing should be activating those [15:44:17] that is normal [15:44:26] Not it on at scn start [15:44:32] no, not that [15:44:44] if they drop below the lower limit they will stay on until the pressure is at the upper limit [15:44:52] Yeah [15:44:57] so maybe something happens on the first timestep that makes the pressure drop [15:45:07] Nope unless I cant see it [15:45:22] Pressure is just above 900 right at start [15:45:35] but maybe not during the first timestep [15:45:40] could be some weird new init issue [15:45:48] So what would cause that in tank 1 and not 2 [15:46:06] the order [15:46:10] Ah [15:46:17] I am checking the H2 tanks as well [15:46:22] the flows will be calculated in that order [15:46:53] Also, the switches should be in OFF at startup I believe not AUTO [15:47:40] According to the AOH before backup ingress and at launch they are off [15:47:57] yeah [15:48:25] could it be the manifolds? [15:48:42] tank 1 flows to manifolds, pressure there is normal, but tank 1 has lost a bit of pressure [15:48:49] I initialized them [15:49:03] Tank 1 should barely use any pressure [15:50:02] The switch shouldnt come on until 865 psi I believe [15:54:11] hm, in the code, in auto mode, the boilers are on by default [15:56:07] They arent pumping though, just in controlled controlled mode [15:56:20] I am going to see what happens if I start those switches in OFF [15:57:10] Nope they start on as well [15:57:44] config and switch position at init have to be in sync [15:58:10] They are now and they start off [15:58:16] And properly turn on [15:58:17] PR sent with the folder changes [15:58:28] That should fix the problem [15:58:36] And is IAW the AOW [15:58:38] AOH [15:59:28] that doesn't explain the problem though [16:00:22] No it doesn't [16:00:31] oh, I think I know [16:00:33] It has to be a transient or something [16:00:55] the tank 1 heaters are on MNA [16:01:01] tank 2 heaters on MNB [16:02:13] Both busses have power [16:02:56] maybe not on the first timestep? [16:03:04] I'll check what really turns those on or off [16:03:34] After we figure it out, those switches should be initialized to OFF [16:03:43] yes [16:03:47] I have that done in my local [16:04:50] there it is [16:05:09] O2TANK2HEATER gets turned off during the first timestep due to lack of power [16:08:10] Wonder why they even turn on [16:08:36] they are on by default [16:08:43] pumping = h_pump = i_pump; [16:11:56] the question is rather, why were they not on previously? [16:12:56] Or did we not notice [16:13:40] yeah, but it's either: both were on or neither [16:16:52] uhh [16:17:00] I just tried this in the Orbiter2010 branch [16:17:08] which hasn't been updated in a long while [16:17:12] exact same behavior, haha [16:17:21] So we never noticed? [16:17:31] I guess [16:17:39] not sure how it is in the 7.0 release though [16:17:44] Haha I usually load and go right into time accel [16:17:53] So I dont pay attention [16:18:02] But of course making new tank sizes I focused hard on those [16:18:23] 925 PSI was the pressure at start previously [16:18:39] now it is just above 900 PSI [16:18:45] that is why we didn't notice this before [16:18:54] because now the pressure in the tanks is lower [16:19:39] Ah [16:19:51] Yeah my target was 900 [16:20:16] upper limit and 925PSI isn't much of a difference on the gauge [16:20:23] Right [16:20:42] More noticeable now [16:21:47] At least it wasnt a "problem" per se [16:23:11] so MNA is powered by FC and GSE, MNB only by GSE [16:23:27] so somehow the power needs a timestep to propagate to MNB from GSE [16:25:35] some order changes in config or code might fix that [16:33:54] ah, I know [16:34:20] SetGSEState is done on the first timestep, in the GSE code [16:34:37] so the GSE battery is not wired to the main bus controllers until that [16:35:06] So MNB is totally unpowered at init [16:35:12] yep [16:35:15] for just one timestep [16:35:25] and the Load function of the main bus controllers also call SetGSEState [16:35:37] so after saving and loading once the issue doesn't occur again [16:35:39] Wonder if that affects anything else [16:35:47] so it's really just the very first timestep ever [16:36:29] And also makes me think is a timestep issue causing the LMs inability to be powered internally without saving and loading? [16:37:15] maybe [16:37:36] could be some similar issue in the ECA code [16:39:35] Also makes me wonder if the LM is being powered [16:43:11] what do you mean? [16:46:07] Well We connect power to the CSM, but is there a way to verify it is actually powering the LM? [16:47:08] during TLC? [16:47:27] the batteries of the LM are not getting drained [16:58:04] I havent checked to make sure [16:58:16] At least not when that problem is around [17:04:33] ah, you mean without reloading [17:04:34] now I get it [17:05:20] Yes [17:45:53] morning! [17:47:33] hey Mike [17:48:20] I finally finished putting together a PDF for LDW 370-54001 [17:48:21] https://drive.google.com/open?id=12o-aAlwTwMzU75GUMiqiceL8ZKmLriPd [17:48:37] I *think* I caught all of the stitching errors [17:48:49] cool stuff [18:02:06] awesome [18:03:42] and now the same for the ECS? :D [18:05:00] haha I can do that one next [18:05:20] it has the fewest pages so it is the easiest [18:11:53] might be able to get it done tonight? it depends on how finickity ICE wants to be [18:14:40] cya later [18:24:15] rcflyinghokie, in the J-class tank configs (commented ones), is the extra mass/volume of the O2/H2, based on 1 extra H2 and 1extra O2 tank that were both identical the their counterparts? IE is it based on adding a third tank that has the same mass/volume? [19:32:11] rcflyinghokie, I re-ran my ECS, but this time simulating the 3 amps rom the CMC elsewhere (POT H20 HTR and SEC COOL PUMP) and after 244 hours I get 17% H2, exact same as mission report [19:45:18] AlexB89, excellent! [19:45:31] AlexB_89, excellent! [19:45:54] So the tank quantities are good and the CM electrical load is good [19:46:14] looks like it [19:46:20] And for the tanks [19:46:34] I took the total mass and volume of 3 tanks and divided it by 2 [19:47:00] ah ok [19:47:02] But the quantity gauge only starts at the old mass so you will be on 100% for a while [19:47:03] are you testing the J-mission config? [19:47:12] yeah [19:47:52] I was curious of looking into the code to re-scale the quantity indicator for the extended stay config [19:48:20] but its not that big of a deal, better wait until we model the actual 3 tanks [19:48:32] if it even needs to be rescaled [19:48:43] the DPS propellant for example didn't change their sensors [19:49:04] so they started with 105%, with the sensors only measuring 95% or lower anyway [19:50:10] in my j-mission tank config test, (2 tanks with combined quantity of 3) the indicator reads 100% of 2 tanks only right now [19:50:26] ah, right [19:50:35] Its based on mass [19:50:37] so it will start moving down like at 160 hours or so [19:50:39] There is a nasspdef [19:50:46] for the full tank quantity it compares to that [19:50:56] right [19:51:17] how did they display the 3rd tank quantity? [19:53:00] looks like a bunch of switch changes, on panel 2 even [19:53:01] http://www.space1.com/Spacecraft_Data/Handbook_Illustrations/Apollo/Apollo_Control_Panel/CSM114-panel-4000.gif [19:53:20] https://www.hq.nasa.gov/alsj/a14/a14mr-a.htm [19:54:05] looks like 2/3 are combined on the same scale [19:54:11] That explains the changes from 2 to 3 tanks a little [19:54:11] yeah [19:55:33] A little bit of plumbing changes as well, and no o2 fans [19:55:49] oh and unrelated to that, I get a momentary O2 flow high warning light during S1C flight [19:56:00] lasts maybe 5 seconds [19:56:17] I did too [19:56:49] Might be something with how the code handles the launch as far as cabin pressure [19:57:16] But I dont think it touches the surge tank or repress package [19:57:25] Those are the only changes other than tank sizes [19:57:26] yeah, I had noticed that as well [19:57:46] I think you guys said that warming is wired to the wrong circuit or something [19:57:51] warning* [19:58:08] The flow is measured from the wrong places [19:58:14] right [19:58:17] It simply adds up all the O2 flows [19:58:36] Where in reality most were in a manifold and were not independent flows [19:58:42] ah and I found the relevant tank capacities in nasspdefs.h [19:58:57] Yeah, easy change [19:59:04] so I can basically * 1.3 them? [19:59:06] though i dont know why LM H2O tanks are there [19:59:08] 1.333 [19:59:16] Ill give you the exact masses one sec [19:59:37] 217724.3386 [19:59:40] O2 [19:59:47] 19050.87954 [19:59:48] H2 [20:00:20] I might have added some LM tank capacities there [20:00:31] yes [20:00:41] thanks Ryan [20:01:45] used in the e.g. DescentWaterTankQuantity function [20:02:39] rcflyinghokie, is that value for 1 tank right? [20:05:10] ah, yes it is [20:06:22] indy91, about the LR issue (latitude error) one thing I notice is it tends to be worse with rough terrain like Apollo 17. Maybe it is range after all? [20:07:48] it's possible [20:07:58] after all the LR beam is not directly forward [20:08:09] but 6° to the right (or left?) [20:08:28] one interesting experiment would be setting that to 0° and also setting the padload for it to 0° [20:08:49] LR sits to the left of center [20:08:51] just to see if the effect is caused by that angle [20:08:54] right [20:09:00] No, left :P [20:09:11] correct [20:09:16] There we go ;) [20:09:20] or better [20:09:22] richtig [20:10:00] Looks like right and means correct? [20:10:10] yeah [20:10:14] Well done [20:10:30] but it doesn't mean right as the opposite of left [20:10:33] that is: rechts [20:10:38] we have two words for it [20:10:44] much more precise, haha [20:10:49] I see that [20:11:02] I'll just say port and starboard ;) [20:11:47] that works [20:11:57] Ill do the test [20:13:03] LRALPHA1 and LRALPHA2 are the padload for the two LR position [20:13:16] thanks [20:13:23] /Radar Beams Orientation Subroutine [20:13:23] alpha = 6.0*RAD; [20:13:26] yep [20:13:32] great [20:14:37] the LR code is basically doing the LGC calculations backwards [20:15:02] but I might have overlooked something with the velocity returned by the Orbiter API [20:16:15] also, Doppler compensation. If that was even a thing for all missions [20:16:28] I read that both the LR and software theoretically could do that [20:18:13] hmmm [20:18:42] I knew you would say that [20:18:49] Luminary 99 and 116 both mention doppler, but 210 does not [20:18:51] lol [20:19:06] damn, the LM is giving me CTDs now [20:19:28] Zerlina doesn't contain the word "doppler" either [20:19:37] 131 does [20:19:54] rcflyinghokie, something about pipe max flow [20:20:34] I believe there is a padload related to this, which probably disables it on the software side [20:20:48] RADSKAL [20:20:55] probably [20:21:17] "LR Alt Doppler Bias" [20:21:18] yes [20:23:06] set to 0 [20:23:55] there's also this line: [20:24:02] or lines [20:24:04] +3 TC INTPRET [20:24:05] DAD SL # CORRECT HMEAS FOR DOPPLER EFFECT [20:24:05] HMEAS [20:24:06] 7D [20:24:30] which is correcting horizontal measurement and doesn't seem to be referencing RADSKAL [20:24:52] only for high scale [20:25:01] er [20:25:08] nevermind [20:25:13] both high and low scale [20:31:06] can you guys check an old LM scenarios, i'm getting a CTD on every one of them [20:31:46] not right now, sorry [20:32:12] p->flowMax = flow; [20:32:19] p was nullptr [20:32:50] https://github.com/dseagrav/NASSP/pull/270/files#diff-04fdea3f2baac4a6dbc9c559c8a01c91L678 [20:33:03] probably one of those [20:34:20] ASCBATINLET [20:34:21] ? [20:34:56] and DESBATINLET [20:35:03] those don't exist, rcflyinghokie [20:35:29] haha [20:37:15] https://www.dropbox.com/s/b9qyl777fel1wm9/CTD_Feb20.png?dl=0 [20:37:46] yep says ASCBATINLET in there too [20:41:29] They do in my local [20:41:47] Sorry about that [20:42:33] I think I didnt have it saved when I made the PR so it didnt get pushed [20:43:00] haha no worries [20:43:15] ive commented them out and doing the LR test now [20:43:25] Just made a small PR with them [20:43:56] Breaking down the glycol into individual pipes to have a better view of flows [20:44:19] The PR should resolve those CTD [20:44:48] merged [20:51:13] hmm [20:51:39] in my Apollo 11 scenario I used to have 0.04 latitude error, now its 0.02 [20:51:44] let me try Apollo 12 [21:07:56] same with Apollo 12, 0.02 [21:08:57] interesting [21:09:41] I am much closer to surveyor with angle 0, then I was with 6 [21:10:03] since that cut the error in half... what about -6? [21:10:29] but before I was 0.04 to the right of surveyor [21:11:22] but now I am maybe 1500 feet left of it [21:12:46] so I think the change cancelled out the original 0.04 error, and went further by 0.02, so combined 0.06 change [21:13:04] oh interesting [21:13:27] so maybe it would be dead on with 2 instead of 0? [21:13:43] maybe [21:13:47] I doubt that [21:14:02] Alex changed both the LR code itself and the padloads to 0° [21:14:03] haha [21:14:42] one thing I have tried at some point is leaving the padload unchanged and just set the angle in LR code to -6° [21:14:51] interesting results, just not very survivable [21:15:53] but in any case, the main issue we have is LR making the state vector worse in the crossrange direction [21:15:59] hmm [21:16:15] what could also play a role is timing [21:16:48] yeah, because this scenario I am using has perfect SV's, if I dont take LR updates, I land right dead center with Surveyor [21:17:06] and no N69's of course [21:17:14] timing on what level, are you thinking? [21:18:06] any kind of delay between LR measuring and LGC requesting, but also the way the LGC compensates for that [21:18:44] so maybe it would be good to try to understand exactly how the gating pulses generated to the LR work [21:19:02] my understanding is that the LR is integrating or whatever for the duration of the gating pulses [21:19:20] and then the overall timing is similar to what we discussed while trying to trigger the Apollo 11 alarms [21:19:38] if you just simulate the timing that way does the error change at all? [21:20:21] that would be interesting to know [21:21:22] so let's see, what was the timing of that again [21:21:59] it can take up to 10ms after setting the channel bit for a radar cycle to actually begin [21:22:26] once it does begin, gating pulses are transmitted to the radar for the next 80ms [21:22:42] so presumably it can take up to 90ms for the radar data to actually be fully formed [21:22:46] I'd approach this from the other direction [21:23:02] what do you mean? [21:23:10] the LR code is getting the data as it they are right "now" [21:23:33] so what does the LGC do in software to compensate for getting the data later than now? [21:23:47] sure, I'm just trying to figure out when it actually is instead of "now" [21:25:39] if we simulate our LR for any delay the software expects, then our worst problem is that the LR is "too good" [21:26:03] better than the actual LR and interface etc. [21:26:19] that is not 100% realistic, but probably much easier [21:26:32] if the software was compensating, it would think you were further along in the landing than you actually were, right? [21:26:37] by 95ms or so [21:27:22] yeah [21:28:09] and with the LR beam being 6° out-of-plane, and also with some roll angle, there will be a relevant crossrange velocity measured [21:28:14] right [21:28:50] and if that crossrange velocity is off in timing, during deceleration, then we might get the latitude error [21:29:14] so the radar data is fully-formed 80-90ms after it is requested, and the LGC receives that data a bit over 5ms later [21:29:52] that 10ms of variance is hardware-induced, but they could probably make it consistent with clever use of interrupts [21:30:59] the GSOP talks a bunch about timing [21:32:56] just as a first past to test the theory, what we did for the 11 stuff is probably sufficient -- just do what you're doing now, but delayed by 5 or 6 frames [21:33:29] and see if that has any effect -- that should be much closer in timing to both the actual sampling and when the LGC expects to receive it [21:33:43] what did we do for 11 again? [21:34:10] I don't know how you implemented it, but I am pretty sure you just delayed the measurements by 5 frames after they were requested [21:34:18] ah right, that [21:34:45] ideally you wouldn't actually calculate the numbers until after the 5 frames had elapsed [21:35:48] so the LR data at the time the data is read back to the LGC [21:35:55] yep [21:35:55] not when it was requested [21:35:58] right [21:36:37] it's not quite right, but it should be close [21:36:41] so, software wise, the LGC accounts for 80ms lag of the velocity tracking loops [21:37:08] also [21:37:26] "each sample represents an 80.001 millisecond duration count in the LR of certain doppler frequencies" [21:37:50] yeah, so that's how long the gating pulses are generated [21:40:37] honestly it's not entirely clear to me how exactly that sort of thing compares against an instantaneous velocity [21:41:47] probably not much of a difference [21:42:09] but if it is a constant difference throughout a 10+ minutes descent then it might add up [21:43:16] man I work for a company that does radar [21:43:21] I really need to learn more about how radar works, heh [21:48:44] I'll do some more experiments tomorrow [21:48:46] good night [21:51:09] It is quite amazing how versatile that radar is though [21:51:48] it is pretty neat [21:53:28] I flew PDI yesterday with Apollo 17, took manual control at 45000 feet and completely ignored the guidance profile, veering off on my own trajectory and just going by eye until I was about at 1000 feet above the surface, but in a completely different area [21:54:07] I then flipped back to P66 and the LGC took came back like it hadnt skipped a beat! [21:54:28] hahaha, that's awesome [21:54:40] I've said this before, and I still feel kinda dumb saying it [21:55:03] but it is incredible how well this stuff works, once we provide a good simulated environment for it to run in [21:55:11] yeah [21:55:36] and I bet the guys who programmed this, would have KILED to have the simulation environment we have today [21:55:53] hahaha yeah absolutely [21:56:20] to be fair I would kill to have something like the LM simulator at the Cape [21:56:33] oh for sure haha [21:56:37] but there was only the one of those and it was a hell of a lot more expensive than NASSP :P [21:56:52] yeah [21:57:24] maybe LM sim, but with some screens hooked up to Orbiter 20176 :D [21:57:27] 2016* [21:57:29] yes! [21:57:35] do want [05:47:25] .tell rcflyinghokie here's a preliminary stitched LDW 330-55000: https://drive.google.com/open?id=146-nbsik0phptDBMwWEuX8tQ3X9t1SBa [13:48:00] hey [13:49:08] hey Alex [13:50:08] I tested the Apollo 13 & 15 TLI's last night [13:50:21] went extremely well [13:50:39] Apollo 13 MCC-1 was 9 fps [13:50:51] Apollo 15 4 fps [13:51:18] awesome [13:51:54] with operational trajectory numbers in the FER I was quite confident that TLI will work accurately [13:53:09] also, plane error was very small, like 0.5 fps [13:56:08] one thing though, Apollo 15 has a pericynthion altitude of 68 nm. opt. 4 of RTCC MFD does no calculate with that altitude, I had to bring it down to 60 for it to give me a solution [14:00:57] ok [14:03:27] so what I did was take the resulting solution from option 4, went to see its nodal target in option 1, and then re entered 68 NM on that page [14:06:50] alright going to test Apollo 16 now [14:12:54] the easiest mistake I could have done with these presettings is the time at which the LVDC starts testing for TB6 start [14:13:21] I did that with Apollo 10 [14:13:40] I noticed it on the TLI PAD though [14:14:08] you might have seen the "Time until first TB6 check" in the lvlog [14:14:32] if it starts testing when it should have started TB6 already then bad things happen [14:15:06] otherwise I don't think there would be many error source that could be a problem for the Apollo 16 TLI [14:17:00] I haven't done Apollo 17 yet [14:17:52] worked on the Apollo 9 MCC instead [14:18:05] up to LM activation now, so I have to figure a few things out for the LM now [14:26:42] yeah I guess the whole MCC coordination between the 2 vehicles [14:30:00] I'll probably use a single timeline [14:30:07] not separate for CSM and LM [14:31:05] yeah [14:31:20] but I'll need to add a bunch of PADs and that stuff [15:12:17] OK on Apollo 16 it took my pericynthion of 71.4 NM in option 4 [15:12:50] 2 fps?? Niklas you made this thing way too accurate... :p [15:35:00] all I did was take the operational trajectory numbers [15:35:44] also, without the free return constraint, the trajectory is probably easier to optimize [15:36:05] but even then, the pericynthion altitude constraint remains [15:36:16] and if that is only 2fps to correct, pretty impressive [15:37:01] yeah, that was right after SIVB cutoff [15:37:26] what I have done with the presettings is keep the performance related numbers the same for each mission, using the Apollo 11 LVOT number. [15:37:30] now with ejection and all, MCC-1 at 30:40 is about 6fps, but thats still just half of the real mission DV [15:38:01] So the actual TLI burn of those missions would be slightly more optimize in terms of DV [15:38:39] those numbers are hard to guess and will be the main difference to the actually flown presettings [15:39:26] the real Apollo 16 MCC-2 was 12.5 fps, my test 6 fps [15:42:30] just sad that I can't use this method for Apollo 17 [15:43:29] an incentive for us to find the Apollo 17 LVOT [15:47:15] oh, and I realized that the flight evaluation reports actually have a detailed change log for the LVDC flight program in the back [15:47:23] there were changes for every mission [15:50:42] oh, I just found the preflight numbers for Apollo 4 [15:51:07] the format is a bit different, but maybe I can generate the presettings for that mission as well [15:58:51] ah damn, ignition in TB6 was still different on Apollo 4 [15:59:12] might be the same time as in the 1967 Boeing document though [16:33:05] im just making a PR with a small change to the one I did last night (extended stay tanks) [16:35:39] and rcflyinghokie, my tests with the larger cryo tanks is very good so far [16:36:04] As far as consumption? [16:36:10] I think its a good interim solution until we introduce the true CSM modifications [16:36:29] Agreed [16:36:35] after 300 hours on Apollo 17 H2: 32 % [16:36:43] real mission I think was 27% [16:36:51] O2 should still be above half I think? [16:37:21] The goal of 3 tanks other than redundancy was so no tank dropped below half thus removing the need for the fan [16:38:05] And that would be more accurate to look at if you had crew of 1 in the CM for the duration of LM activity of course [16:38:15] yeah [16:38:51] the only thing is that I get a momentary cryo C&W light on prelaunch scenarios, with the larger tanks [16:39:06] lasts a minute or 2, then goes out and stays off [16:45:03] Any idea what triggers it? [16:46:09] Also does anyone else notice when the quantity gauges are full the arrows arent at the very top? [16:54:09] And I might initialize the O2 starting pressure a bit higher, it falls down to almost the heater limit before liftoff [16:54:57] But I dont know if that is necessary since fill pressure could vary [16:55:22] its the heater that cause the cryo light [16:55:25] or lack of [16:55:50] once I through the 4 heater switches to off to auto, the light goes out [16:55:55] throw* [16:56:07] Slightly higher pressure at fill should remedy that I think [16:56:08] from off to auto* [16:56:30] Arent the heaters on AUTO during launch? [16:56:38] yes [16:56:57] Oh this happens prelaunch when they are off? [16:57:26] and I was saying the light came on and went out on its own, but that was actually when the automatic checklists turn the heaters to auto [16:57:43] yes this only happens on prelaunch [16:57:56] the heaters there are still off [16:59:21] High or low pressure [16:59:30] I think low [16:59:43] Yeah I think filling a little higher would help [17:00:06] I am taking a glycol break and finding out exactly when that o2flowhigh happens during ascent and possibly why [17:01:10] can't figure out the Apollo 4 presettings, too many new variables that were different on that mission [17:01:22] bummer [17:01:54] were you going to give the Apollo 17 actual launch pre-settings a try, or is waiting for on-time numbers the better plan? [17:02:48] not sure yet [17:02:56] I'll leave it as it is right now [17:03:19] yeah, in any event we still have RTCC MFD to make the solution [17:03:38] if you do that the next time, then I want the numbers from the 7-parameter update [17:03:45] maybe I can figure something out with those [17:03:54] sure [17:04:02] at least eccentricity and C3 for the on-time launch [17:04:33] I can get that pretty easily, just an on-time launch and once in orbit, calculate a TLI solution [17:05:13] yeah [17:05:36] I guess I just have to make sure the constants in RTCC FMD are good too, we didn't have a full SCOT for that one [17:05:38] what I want to try is those numbers with the target vector from the actual launch [17:06:29] hmm [17:06:31] actually [17:06:42] I also would like the TB6 and TLI state vectors [17:06:54] so the mission has to be flown to at least that point [17:06:58] and then I just need the lvlog [17:07:06] sure [17:17:41] Ok so the O2 flow jumps at 54 seconds [17:17:50] Anything specific happening there in code? [17:18:55] maybe a special altitude relevant the cabin dump [17:18:57] for* [17:19:54] Maybe the readytolaunch case is triggered there [17:21:40] what is that? [17:28:10] case SATSYSTEMS_READYTOLAUNCH: [17:28:11] if (GetAtmPressure() <= 8.5 / PSI) { [17:28:11] // Cabin pressure regulator and relief pressure to boost configuration, disable max. flow [17:28:12] CabinPressureReliefValve1.SetReliefPressurePSI(4.82); // 5 psi - 5 inH2O [17:28:12] CabinPressureRegulator.SetPressurePSI(4.7); [17:28:13] CabinPressureRegulator.ResetMaxFlow(); [17:28:13] // Reset (i.e. open) O2 demand regulator [17:28:15] O2DemandRegulator.Reset(); [17:28:17] // Cabin leak [17:28:19] CabinPressureReliefValve1.SetLeakSize(0.001); [17:29:13] yes, could be that [17:43:49] morning! [17:46:12] O2DemandRegulator.Reset(); [17:46:14] Thats what does it [17:47:25] hey Mike [17:47:33] two LVDC related things for you [17:48:00] one, I previously read that the LVDC flight program was loaded into the IU/LVDC "in the lab" [17:48:17] that is still true, but that lab is not at Marshall or something like that. The lab is in the VAB [17:49:17] so for a case like Apollo 8 where the mission was switched quite late it was still possible to load the flight program into the IU at that time [17:49:27] at least as long as the Saturn was still in the VAB [17:50:18] oh interesting [17:50:50] that makes sense [17:51:11] and second, in the last pages of the flight evaluation reports of all missions, there basically is an extensive "Saturn changelog" [17:51:16] and that includes the flight program [17:51:21] ooooo [17:51:23] there are changes for every mission [17:51:24] awesome! [17:51:32] hahaha not surprising [17:51:44] although, that includes 15-17? [17:51:44] only small ones from 15 to 16 to 17 [17:51:50] but yes, changes [17:51:54] interesting [17:52:00] hmm, let me check though [17:52:13] they sometimes also listed changes that would only affect presettings [17:53:14] yeah, actual changes [17:53:47] Apollo 16 introduces additional logic to distinguish between S-IC engine failures of the "upper, lower or center engine" [17:53:49] im revising the EMP latitude before doing the Apollo 17 TLI [17:54:04] huh [17:54:38] thanks to your Skylab document I know that the Skylab LVDC got separate input discretes for all 5 S-IC engines [17:54:53] :D [17:54:55] so that was introduced on Apollo 16 [17:55:11] I think I'll write Ron about this, might be interesting for the LVDC page [17:55:16] yes definitely [17:55:25] so he can have a full changelog there [17:55:49] it's always fun to realize we've had stuff like that all along [17:56:40] unrelated, but did you see the stitched ECS schematics? [17:56:51] yep [17:56:54] very nice [17:57:34] there's a crazy amount of part numbers on there, so it's very possible we can drill down and get arbitrarily detailed info [17:59:09] also unrelated, but I have been talking with Francois again [17:59:21] he's going to try to get me access to that AGC he made a few videos about :D [17:59:43] AS-202 CMC? [17:59:55] no, he just has the rope modules for that [18:00:05] I don't know what the serial number for this AGC is, but it was not for flight [18:00:12] ah [18:00:16] most of the modules and the backplanes are unpotted [18:00:18] but that software version? [18:00:38] this AGC actually has core rope simulator adapters plugged into it [18:01:22] Virtual AGC page says it is the AS-202 software [18:01:27] no the rope modules were the flown ones [18:01:32] but that was Block I [18:01:41] Block I modules are incompatible with this Block II AGC [18:01:51] these are just two different things in this person's collection I think [18:01:57] oh, now I get it [18:03:28] but Francois has also been wanting to map out the pins on this AGC [18:03:42] he sent a tester to him but the guy is afraid to do it on his own [18:03:42] and you know all about pins [18:03:50] and Francois is on South Africa so that is difficult [18:03:58] I know enough to efficiently map out what we don't know [18:05:08] indy91, if I move that line of code to the next event I get no o2 high and still get a normal cabin pressure decrease [18:07:49] so at 3 PSI instead of 8.5 PSI [18:08:04] But is cabin venting for launch or landing [18:08:19] Has to be launch I think [18:08:27] https://drive.google.com/open?id=13qR4UqLyJ6vP3HuE6szs_2Q0yjS1l-vR [18:08:29] But yes [18:08:41] That line just opens the demand regulators [18:09:12] right [18:09:16] But moving the line I have a normal launch [18:09:40] I am making sure nothing is messed up in the insertion steps but it looks completely normal [18:10:06] Bot suit and cabin pressure settle to about 5 [18:10:13] No o2 flow high [18:14:45] And totally normal post insertion checks/configuration [18:26:06] I am also going to increase the fill pressure a little bit and see if that stops the cryo light on the larger tanks [18:28:29] indy91, I will have that TLI data for you shortly [18:35:02] great [18:57:29] Ok PR is up with the higher fill pressures and the regulator moved to the next launch event [18:57:59] That should solve the cryo lights Alex got with larger tanks, prevents heaters from kicking on the pad, and that o2 flow high during boost [18:58:09] why did we even get that issue with o2 flow high [18:58:29] that didn't happen before, did it? [18:58:59] No [18:59:17] And frankly I am at a loss as to why it happens unless it was the valve changes in the CSM [19:01:12] The main regulator feeds the demand regulator [19:01:20] and the sm supply feeds the main regulator [19:01:32] Nothing changed in those that I can see [19:03:03] making the SM supply a gas maybe? [19:04:15] That was already a gas [19:04:40] We only changed the repress package and surge tank to gas [19:04:50] ah right, surge tank [19:04:55] The boilallandsettemp was already in place on the sm supply [19:07:41] Oh interesting though.. [19:07:46] O2SURGETANKOUTLET [19:07:47] O2SURGETANK:OUT O2SMSUPPLY:OUT2 PREG 1378952 0.0 ONEWAY # 200 psi [19:07:47] [19:07:49] Weird connection [19:08:19] So the surge tank is connecting back to the sm supply for some reason [19:08:43] Maybe that is how it feeds the CM after sep [19:08:51] yeah, we saw some weird connections when we were working on the surge tank [19:09:01] lots of code handling this [19:09:04] Yeah [19:09:19] Well moving that regulator code just a little bit later seems to do no harm [19:09:54] I concur [19:09:54] I cant find evidence why it was put there to begin with other than just needing to be reopened during boost [19:11:01] And the new pressures are towards the high end of the limits to facilitate dropping on the pad and to prevent the need for heaters to kick on until after insertion, they should also resolve the larger tanks cryo press lights Alex was having [19:13:37] Ok, back to the LM [19:28:42] indy91, 7-parameter update: T_RP: 10791.243447, C_3: -1731050.733163, Inc: 32.767130°, e: 0.971571, alpha_D: 21.451429°, f: 13.722839°, theta_N: 121.746879° [19:29:04] ill get you the full LVlog right after TLI is done [19:30:05] thanks a lot! [19:30:33] my pleasure [19:31:11] is it only the lvlog you want for the pre-TLI state vectors, or a .scn too? [19:33:02] lvlog should have all I need [19:34:44] ok [19:36:06] eccentricity of the flown mission: 0.97212628 [19:36:16] which, as expected, is higher than the nominal one [19:36:26] to reach the Moon 2:40h earlier [19:36:32] so on time [19:39:18] one thing about the TLI target I used, it is o nodal target TLI which has the SCOT LOI ignition pericynthion parameters, so not the LAH, but a bit before [19:39:40] should that be an issue? [19:39:49] close enough probably [19:41:06] if it is maybe I could fly the TLI, then do an option 4 after, that recomputes the correct pericynthion, then take those coordinates and use that to go back and recalculate a TLI and 7-parameter update [19:42:52] I'll let you know if that will be necessary [19:42:56] ok [19:47:45] https://www.dropbox.com/s/5mpc0xcxn5wir6w/lvlog_A17_TLI.txt?dl=0 [19:48:07] thats up until TLI SECO [19:48:32] comparing the target vectors will be interesting [19:56:01] indy91 is there any good way to look at flow through a pump pipe when it is not on? [19:56:27] Ah never mind it has a FLOW [19:56:39] yeah, we added that [19:58:38] Thats right it came back to me when i saw it [20:01:52] AlexB_88, I also need the exact azimuth of your launch [20:01:58] LVDC_Azimuth in the scenario I guess [20:02:45] LVDC_Azimuth 1.259104946355 [20:03:44] 72.1413993901874° [20:04:32] I was hoping it was radians, or else I'd be over the north pole [20:04:56] yep [20:05:54] so, when looking at the presettings, one good indication of accuracy is the argument of periapsis from the TLI state vector vs. what the presettings calculate as the target [20:06:37] for the actual launch I am down to a 0.0012° difference [20:06:59] which is actually larger than most of the other launches I calculated these for [20:07:19] I bet it's due to 100NM vs. 90NM and also because of the lost mass through the longer coasting in EPO [20:07:27] Apollo 17 having an Atlantic launch window [20:07:41] still, tiny difference [20:08:08] with the state vectors from your flight I have a 0.2° difference [20:08:27] hmm [20:08:29] not terrible at least [20:08:56] it will also be due to the 7 parameter TIG [20:09:13] and the resulting fairly constant attitude during the burn [20:09:55] I'll try propagating the TB6 state vector back and forth a bit [20:09:58] the lvlog I had given you was after a quicksave so maybe if I give you the original lvlog, maybe the SV was better? [20:09:59] maybe that makes a difference [20:10:39] no, it's just that this is really the worst method to generate presettings [20:10:45] from a 7 parameter update and all [20:10:59] right [20:11:14] I took the state vectors in the lvlog at TB6+0 and TB7+10, those won't be any different in the original lvlog [20:11:20] or won't be in it [20:12:43] right, I was thinking because in that lvlog, it had been running from liftoff to TB7 without reloading so maybe it would mean the SV is better, but maybe not [20:13:21] state vector errors shouldn't be much of a factor in these calculations [20:20:19] what was your TIG? [20:20:44] that's one number for the actual launch we have [20:20:52] planned launch I mean [20:21:38] I used the SCOT 3:20:58 [20:22:12] yeah, but what was the result on the TLI PAD? [20:22:49] I think I want your post-TLI scenario after all :D [20:23:51] TB6 3:11:32 [20:23:55] sure, one sec [20:24:23] https://www.dropbox.com/s/i86874exafbh116/Apollo%2017%20-%20after%20tli%202.scn?dl=0 [20:25:53] only 9 seconds early [20:26:23] so the TB6 state vector should be quite good for these geometry calculationd [20:26:28] calculations* [20:36:07] well, those 0.2° don't want to go away, but I am not too worried [20:36:34] Target vector with launch on time: [20:36:38] Declination = 13.80066 deg [20:36:39] Ascension = 99.312098 deg [20:36:44] Actual launch: [20:37:04] Declination = 14.027005 deg [20:37:05] Ascension = 98.764023 deg [20:37:22] I'd say that is a reasonable change for the 2:40h delay [20:39:51] I'll create presettings with those data points for 0 and 2:40h delay [20:40:19] TLI should become more accurate when you get closer to the actual launch time [20:40:35] I guess that will just add a few fps for the MCC's [20:40:49] yeah, shouldn't be much [20:57:08] so with the 2 data points we essentially have full launch window coverage? [20:58:12] or 0 to 2:40 [20:58:42] yeah, I'll just use linear approximations of the full window [20:58:58] so the data points 0 and 2:40 extrapolated to the end of the launch window [20:59:34] launch window was 21:53 to 01:31 EST [21:00:13] so 3:38 in duration [21:01:13] 100° launch azimuth at the end [21:01:37] so not the full 108° covered [21:44:11] AlexB_88, I think you can launch Apollo 17 again very soon [21:51:08] great! [21:55:00] update pushed [21:55:03] good night! [14:26:14] hey [14:26:53] hey Alex [14:30:01] going to give the Apollo 17 TLI a test now [14:31:26] Good morning [14:31:37] hey [14:32:35] hey [14:32:44] Hows it going? [14:33:05] doing some more MCC work [14:37:27] Fun [14:41:35] also I'm trying to get us the Apollo 11 LM Timeline Book [14:41:57] Where is that? [14:42:24] the flown one was sold as a whole for lots of money [14:42:38] but Paul Fjeld, a contributor to the ALSJ, apparently has found one in the Grumman Archives [14:42:52] and Ron Burkey has been in contact with Paul for a few Virtual AGC things [14:42:58] so I wrote to Ron about this [14:43:24] Oh nice [14:44:01] Maybe Paul, just like David Woods from the AFJ, has some scanned checklists sitting on his PC but nowhere online, haha [14:44:17] Worth a look! [14:45:10] asking never hurts [14:50:23] Nope [14:52:44] Hmm I am trying to add debugs to watch flows through the pumps and I keep getting a nullptr [14:53:02] double *Pump2Flow = (double*)Panelsdk.GetPointerByString("HYDRAULIC:PRIMGLYCOLPUMP2:FLOW"); [14:53:09] where did you add that line? [14:53:13] satsystems maybe? :D [14:53:16] LM [14:53:21] lmsystems [14:53:23] lemsystems [14:53:32] With my collection of debugs [14:53:39] one nice thing to have is that missing page from the A12 LM timeline book [14:53:40] it's a pump [14:53:42] ELECTRIC [14:53:46] Ah [14:53:51] duh [14:53:54] thank you [14:54:29] I was thinking pipe, flow, hydraulic [14:54:38] And I am on coffee 1 so there is that [15:38:26] On the bright side I have primary glycol flow up to 283 [15:38:40] out fo 290 [15:38:41] of [15:39:03] Now I have to get the pump pressure and the accumulator pressures correct [15:40:36] sounds like you know what you are doing [15:40:52] it took a long time to get there for us, haha [15:42:15] Yeah i finally know what changes to make to tweak it [15:42:19] And they are small [15:42:54] However I am still going to have to figure out a better approach to the suit heating exchanger [15:43:36] Because the primary loop is large I dont think I can get 290 flow all throughout without having much larger flows elsewhere if that makes sense [15:50:46] ok Apollo 17 on-time TLI done, MCC-2 is 19 fps [15:51:07] that's better than I expected [15:51:48] and thats at 30 hours, at 20 hours its 16 fps [15:52:09] that number will be lower at the actual launch time [15:52:28] How are your consumables doing? [15:52:48] assuming I did everything right with the calculation of the time segments for the presettings [15:53:09] And any random alarms? [15:54:11] no random alarms, and everything is good [15:54:14] Great [15:54:24] and the cryo light did not happen with the latest update [15:54:32] and thats with the larger tanks [15:55:19] Great [15:55:48] That was simply not enough fill pressure [15:56:09] While it was in the middle of nominal, the pressures decrease on the pad [15:56:28] So by increasing it a bit the pressures dont hit the lower limit until insertion when the heaters are on AUTO [16:06:22] so I guess we have TLI presettings for every mission now! [16:07:52] seems like it [16:07:59] good work [16:09:52] and its nice because we have the full data for both missions that were delayed [16:14:55] well, "full data" [16:15:23] Apollo 14 we have everything of course, because we have the LVOT [16:15:41] For Apollo 17 we don't have anything on the 2nd TLI opprtunity [16:15:48] right [16:15:54] I just added some numbers that could be good or not at all [16:17:21] we also have full presettings for some unflown launch days [16:17:51] Apollo 11 July launch month, Apollo 12 September launch month [16:18:03] yeah I saw those [16:18:17] I'll try to make the MCC compatible with those other launch days for Apollo 11 [16:19:59] I'm looking at some mission constants that are the same like TLCCPeriGET and TLCCNodeGET, in Apollo 15-17. Right now they both have an entry, but that could be made as "TLCCPeriGET = TLCCNodeGET ="? [16:20:35] for the initial guess? sure [16:20:41] yeah [16:21:18] at some point maybe introduce a TLCCLAHPeriGET maybe? [16:22:24] for the initial guess entry in TLMCC option 4 [17:34:55] I found a better EMP latitude for Apollo 13, the mission where we don't have the post-TLI free-return perilune parameters. I used LTMFD to analyze the TLI flown with the new presettings and made a new EMP lat out of that [17:35:47] that new EMP latitude then used to calculate MCC-1 after a TLI with the new presettings is only 2 fps, not bad [17:39:18] I really have to look at all these latitudes and GETs again, I barely know what you are talking about, haha [17:40:12] haha I barely know what i'm talking about to, but I've flown these TLI's so many times i'm starting to wrap my head around it [17:44:48] morning! [17:47:26] hey Mike [17:48:10] what's up? [17:53:02] just finished testing the new TLI presettings [17:53:34] now experimenting with new EMP latitudes, and other constants in RTCC MFD [17:56:46] :D [17:57:04] Damn the only way I can get stable pump on and off flows with the right pressures is having a pump off pressure of 16.5psi which is still in the green band [17:57:38] I wonder if that was normal, I dont think the actual pressure set off C/W, I think it was just dP at the pump [18:04:03] indy91, about the periGET I was talking about earlier, I was saying that maybe we could use a new variable for initial guess entry of non-free return Peri GET. Now I am discovering that may not be necessary. Setting say "TLCCPeriGET = TLCCNodeGET = X;" in the constants sets the same initial guess for both free return and non-free return and taht seems to work quite well. [18:25:05] I'll look into it [18:26:46] it may be fine as it is, I just need to load the right pericynthion GET in the constants [18:41:42] Ok primary loop is at 290 and the heat exchanger now has the right flows, now to test the thermo [18:49:22] semi bad news from Ron, I also asked him about the full Apollo 8 LVOT and while the people at the archive are commited to digitize it, it's going to be a while until anything happens on that front [18:50:36] all we are missing from that document are the other December launch dates and lots of graphs though [18:50:58] but I'd still really like to have the full document [18:51:04] eventually [18:51:45] have they given him any reason other than that they are very busy? [18:52:04] that was the status when I last asked two months ago :P [18:52:18] "I had followed up with the archive, because they didn't get back to me after I submitted my requests, and I was told that they would certainly digitize it ... but that they were very busy. This situation is that there's only one or two paid people in the archive, and they involved in other activities such as preserving space suits. It typically takes a week or more even to get responses to emails. I fear we'll just have to be patient." [18:53:02] yeeaah [18:54:34] same thing from Debbie about the LM data book [18:55:15] damn [19:14:23] I'll be making a PR later today with some updates to the RTCC MFD constants. I have not touched those that we already had exact values from the SCOT, but rather the ones where we didn't like Apollo 13 free-return parameters and re-calculated the nodal target for non-free pericynthion of most missions [19:14:55] sure [19:15:02] I have done a lot of testing on these new values and they look quite good [19:16:50] after this a user can literally fly any maneuver in TLC, just by choosing a TLMCC option, and inputting a TIG [19:19:43] that would be the goal [19:24:47] obviously depending on the mission, like a option 2 (FR BAP) would not iterate on Apollo 15 [19:28:21] so in the Apollo 17 flight plan I found some interesting alternative missions [19:28:27] one being a CSM only lunar orbit mission [19:28:41] in the case the LM can't be ejected or something like that [19:29:06] nice [19:29:25] and in that case they would be lacking the backup engine, while being on a very non-free return trajectory [19:29:42] so with MCC-1 the first thing they would be doing was a return to free return [19:29:50] 650 ft/s or so [19:29:59] how would we calculate that right now? [19:30:03] wow [19:30:14] we would need an EMP latitude for it I guess [19:30:48] or maybe that would not work since we'd already be on a different trajectory [19:31:06] option 8? [19:31:54] nah, that option doesn't have a lunar orbit constraint at all [19:32:16] I guess it would depend on the planned lunar orbit [19:33:49] flight plan mentions an inclination of 20° [19:33:57] so about the same as the nominal mission [19:34:25] has to be option 2 or 3 [19:35:05] CSM only mission, LOI TIG is 77:09:07 [19:35:59] actual is 88:55:37 [19:36:15] surely option 2 will iterate with the 77h as a guess? [19:36:42] 11 hour difference is a loooot [19:36:53] would option 2 work on 17? [19:36:55] very non-free return that Apollo 17 trajectory [19:37:22] if not I have to improve it [19:38:41] it works when I change the latitude [19:38:49] using your post TLI scenario [19:38:58] new LOI as the guess [19:39:02] and -5° instead of -13° [19:39:10] 730 ft/s [19:39:32] 12h GET is TIG [19:40:03] interesting, so Paul Fjeld just has a few scans from the flown Apollo 11 Timeline book [19:40:14] "a few" = 13 [19:40:53] how do you know that and I don't, when I was the one who wrote to Ron about that [19:40:59] hahaha [19:41:00] I'll have to add proper EMP latitudes for Free-Return in the contants for 15-17 [19:41:01] check your email [19:41:21] Ron added me to the thread for whatever reason :P [19:41:22] yeah [19:41:25] wrong alarm [19:41:37] I told him that you told me that Ron knows Paul [19:41:38] obviously since non of those missions were ever free-return I had no data to calculate them [19:43:18] 13 pages is great [19:43:25] might be all we need [19:43:32] hopefully! [19:44:17] at least Ryan should be able to refine the procedures from undocking to PDI [19:44:24] there is the LR test [19:45:06] rcflyinghokie: http://pfinspace.com/Ron/AS11LMTimeline/ [19:45:22] no manual reset of the LR position flag at least [19:45:28] Oh very good [19:45:37] but the order of the procedure might still be different than we usually do [19:46:02] which alarm code was it again? 521? [19:46:28] 522 I think I need to look [19:46:47] I think 522 is right [19:47:03] Yeah it was 522 [19:47:21] Mike that is awesome! [19:47:41] Niklas and Ron did all the work here, I just ended up CC'd for some reason [19:47:44] lol [19:48:19] thank Niklas :P [19:48:20] I started the sentence with "Mike told me", that is why :D [19:48:24] thank Paul [19:48:25] haha yeah [19:48:40] LDG ANT - DES [19:48:47] that is different than the Apollo 12 procedure [19:49:15] oh wait [19:49:19] V63 is called twice [19:49:23] that is way different [19:49:27] :D [19:49:46] wow I can't believe that actually worked out [19:49:49] hooray for good luck! [19:50:04] we haven't tested it yet in the sim :P [19:50:30] yes but I mean, the fact that the pages Paul has scans of include what you wanted to see [19:52:36] yeah [19:52:56] although, page 6 and 7 in that document, which is what I wanted, would actually be the first pages [19:52:57] hmm [19:53:12] page 1-5 or so might just be flight plan excerpts [19:54:12] so the document basically starts with page 1 of what I thought would be page 1 [20:32:07] ok, got sidetracked and now I'm done writing the reply to Ron [20:32:24] the second V63 is the interesting one [20:33:02] all you really do there is start the self test, change the LR position switch, get the 522 alarm at that point, switch to auto, exit V63 [20:33:19] so I bet the only reason for that second V63 is to fix the flag situation [20:33:45] more elegant than manually resetting a flag [20:34:55] rcflyinghokie, I guess you have some Checklist MFD file to update :D [20:36:23] PR sent [20:37:23] It appears that way [20:37:35] Just in time this glycol loop isnt bad [20:37:54] I am very close to having a good version using small valves [20:38:47] next thing will be separate free-return latitudes for 15-17 [20:40:48] The only thing I dont like is how the pressures change when I swap screens [20:40:52] swap panels rather [20:42:06] yeah, that will cause one rather long timestep [20:44:20] They come back to normal but its still annoying [20:45:30] one minor issue with some missions is that MCC-1 TIG does not iterate (calculation stuck, or sometimes weird,very high DV like 16000 fps) But the same with MCC-2 TIG works perfect [20:45:47] thats with all options of TLMCC [20:46:09] for which missions? [20:46:26] later missions, 15-17 [20:46:30] right [20:46:46] say any time before 20 hours [20:46:50] yeah, I'll have to do some improvements there [20:47:35] oh and the high pericynthion altitude of 68 doesnt work well with it on Apollo 15 [20:47:41] a while back I did a fairly large update, which cut down the iteration times a bit, but at the same time it caused some issues like it not being able to iterate [20:47:59] I set it to 60 and its ok [20:48:01] wasn't the best update of all time [20:48:15] so, always more work to do on that [21:01:15] I've been using LTMFD to analyze the post TLI trajectories of the new presettings. Unfortunately LTMFD crashes in Orbiter 2016 [21:01:57] so I've been opening the scenario in Orbiter 2010 [21:15:44] Any ideas how to allow the heating heat exchanger maintain pressure while not allowing flow into it? [21:16:05] I have been experimenting with a two way pipe it works but I worry too much back flow will happen [21:17:22] And subsequently temperature changes [21:49:27] no idea [21:50:10] night! [22:21:39] rcflyinghokie, I did have the 3 FC C&W lights come on on my last run, shortly after insertion [22:21:55] I don't know if its procedure error though [22:22:50] because I did not technically go though the insertion check, I just made a big post insertion "flow" [22:29:44] Hmm [22:30:05] Any idea the trigger? [22:30:32] I think its the day/night thing [22:31:05] Apollo 17 night launch of course [22:32:27] Might be Niklas' fuel cell cooling changes [22:33:53] Do you know which limit was hit to trigger the lights though [22:35:31] hmm I think it was the FC rad TB again [22:35:42] Then yeah thats something with the cooling changes he made [22:35:49] it was barberpole [22:36:14] That also needs to be changed as I dont think it sets off a FC light [22:36:19] Just the CREW ALERT light [16:55:07] Good morning [16:56:33] hey [17:01:45] Where is Alex, I want to talk about him about ice hockey :D [17:09:45] Haha I love hockey if its any consolation :) [17:09:59] Going to a caps game tomorrow night as well [17:10:04] *washington capitals [17:11:14] shame the best players aren't at the Olympics [17:11:15] well [17:11:17] good for us [17:12:08] Yeah I was not happy about that this year [17:12:46] I mean I understand it can "stock the pond" [17:13:41] Oh random tangent, found a pic posted online of Eagle on the surface, that weird little deflector plate or whatever is clearly visible between the DPS and the LR [17:13:44] https://www.lpi.usra.edu/resources/apollo/images/print/AS11/40/5950.jpg [17:14:05] ah, so not some random addition to LM-2 [17:16:29] Nope [17:16:43] Wonder if it was later removed [17:17:01] I never found a reference to it in a handbook [17:18:12] At least not for LM 8 and later [17:18:19] But there it is on the surface no question [17:19:55] And just googling now Apollo 12 had it [17:20:38] Wow its more obvious in these pictures than I thought, 14 had it as well [17:23:07] Yep 15 and 16 too [17:23:17] Fair guess it was on all LM's [17:23:25] so standard LM equipment [17:24:04] https://www.google.com/search?rlz=1C1CHBF_enUS735US735&biw=1920&bih=949&tbm=isch&sa=1&ei=v02QWvNdxNrmAuHAk4AN&q=landing+radar+shield&oq=landing+radar+shield&gs_l=psy-ab.3...79107.82961.0.83280.24.20.2.2.2.0.165.1520.17j3.20.0....0...1c.1.64.psy-ab..0.17.968...0j0i67k1j0i10i67k1j0i24k1j0i10i24k1j0i5i30k1.0.8UkdnOUUxd8#imgrc=OcaJ5H_O1G0agM: [17:24:09] How about that [17:25:15] Looks like the mesh needs an addition :P [17:25:20] thermal shield [17:26:52] "A nonabsorptive [17:26:52] finish , thermal blanket , and external thermal shield partially protect the antenna assembly against the [17:26:53] effects of the descent engine plume and the thermal conditions of space." [17:29:14] Interesting what we never really came across that [17:29:35] Such a small detail [17:41:44] morning! [17:49:04] hey Mike [17:54:09] what's up? [17:57:25] Discovered that all LM's had a thermal shield for the LR (the weird thing I saw on LM2) [17:57:40] oh nice! [17:59:00] afternoon [18:00:43] hey Alex [18:37:00] AlexB_88 did you only get that cryo light once? Or did it come back a few times during TLC [18:37:37] hmm only once I think in EPO [18:38:07] Apollo 17 EPO starts at night, then halfway into daytime, in the following orbit, they went out [18:40:29] And it was the rad temp low for sure [18:43:55] yeah, pretty sure [19:01:27] someone on the Orbiter Forum was in a very wrong orbit after SPS-7 on Apollo 7. So naturally I am now adding the proper calculation for SPS-7 to the RTCC. [19:01:46] Naturally [19:02:03] Indy91, you might need to look at Alex's case of low rad temps on 17 [19:02:16] FC rads [19:02:28] I need to run some errands I shall return [19:02:33] not enough heat? [19:02:37] we are 160W lower than before [19:03:01] He can probably explain it better I just know he got the temp low on all 3 FC's after insertion on 17 [19:03:16] Possibly due to night [19:03:21] night launch I mean [19:03:27] I'll be back [19:04:53] im testing the actual launch time TLI now on 17, I'll report if the issue happens [19:06:29] I guess the temperature drops througout the prelaunch phase and in orbit you are still in the shadow [19:06:39] so no opportunity to warm up [19:07:01] well, late during prelaunch it will be cool [19:07:06] hmm [19:07:21] so what we are still doing is have at least 160W on the FC [19:07:39] but previously we just added the 160W to all the other loads [19:08:27] I think that 1. the radiators need to be adjusted now that we have a different load and 2. it was never much tested with a night launch before [19:15:05] yeah [19:16:17] btw SECO is very close to flightplan now, with the default weights set to that of Apollo 11 [19:17:05] oh, that's good to hear [19:17:14] I hadn't really tested those numbers with a flight [19:20:02] yeah, i've basically tested launch+TLI on Apollo 12-17 and all work very well [19:21:06] not bad for a NASSP version meant for Apollo 7-11 [19:21:15] lol [19:21:57] the lowest fuel remaining after TLI I saw was about 3000 KG [19:31:09] so, SPS-7 was meant to place the perigee at 45°W one revolution after the nominal deorbit burn [19:31:20] for the case the SPS fails and a SM RCS deorbit is done one orbit later [19:31:55] seems that before SPS-7 the CSM is in a good orbit in our scenarios [19:32:16] because the DV to put the perigee at 45°W at that time is only 5.8 ft/s [19:33:23] and moving the perigee there 20 hours later for deorbit should give a very nominal DV [19:40:07] getting a weird CTD after insertion at 17:31, hmm [19:40:41] "Symbol file not loaded" thanks, VS [19:41:35] thought it was the checklist MFD, so removed all the entries in the scenario for, it and usually fixes the problem, but not this time [19:41:36] very helpful [19:48:00] funny thing is it only happens if I time accel [19:52:15] another funny thing, did not get the FC C&W this time around [19:57:44] actually now it came on, but went out a few seconds later, so definitely intermittent [14:59:29] Good morning [15:03:04] hey [15:03:51] How's it going? [15:09:14] oh, just have improved the new Apollo 7 SPS-7 targeting a bit more [15:09:18] not much else [15:10:55] Excellent [15:11:14] I just pulled up the glycol loop again for some more tweaks and temp tests. I am close haha [15:11:53] nice [15:12:21] almost all of the Apollo 7 calculations that the real RTCC was doing were done with old Gemini computers and routines [15:12:34] similar kinds of maneuvers, nothing new and fancy like for a lunar mission [15:12:50] and I haven't really searched much for Gemini maneuver calculation documents yet [15:12:53] maybe I should [15:13:07] could help with Apollo 7 and 9 in general [15:13:46] True they used the same mechanics with the Agena [15:16:45] yeah, and similar kind of maneuvers [15:17:12] shaping the orbit for a RCS reentry was done on Gemini as well [15:17:25] or place the perigee at the right longitude for a reentry opportunity [16:28:36] Now that I have tanks stable and flows at the right level, I need to make sure not having a one way valve on the heat exchanger isnt a problem, and that it cools properly when the valve on the other end is closed [16:44:38] Where is the code for staging that eliminates tanks? [16:49:48] lemsystems [16:49:50] function CheckDescentStageSystems [16:50:46] Thanks [16:51:09] I have some flows that allow 60% of coolant into des bats and 40% into ascent bats [16:51:19] I need to elimitate the max flow upon staging [16:52:42] ah, right [16:53:03] I am just going to change the max flow of that ascent pipe in that function [16:53:17] I think that is all I would need [16:55:01] SetPipeMaxFlow("HYDRAULIC:ASCBATINLET", 290.0 / LBH); [16:55:24] And since the other max flows are in the init and not timestep that should work I think [16:56:10] yes [16:56:15] and then saved in the scenario [16:56:16] hmmm [16:56:54] In the init that pipe is set to 117 LBH [16:57:05] 117 [16:57:08] 116 not 117 [16:57:32] ok, LoadState is called after Init [16:57:51] so any number saved in the scenario will not be lost the next time you load [16:57:54] Ok [16:58:08] So at staging, the pipe max flow is changed and a save would hold onto that [16:58:13] yes [16:58:21] Great [16:58:33] I finally have the right flows going through the heat exchanger [16:59:09] And if this last test works with pressures then I can see if the temperature reacts properly to proportioned flows [16:59:15] how much have you tested under the operational heat load? [16:59:34] Not much yet, at least not for any length of time [16:59:43] I'm sure it will be fine [16:59:47] I just need to get the tanks stable (ie not fluctuating a lot) [16:59:53] yeah [17:00:04] that is the secret to avoiding the NaNs :D [17:00:24] Well I am happy to report I know how to do it, it just takes time [17:00:29] A lot of small adjustments [17:00:49] But my largest valves are pretty small and still giving me the right flow [17:06:40] And then after some thermal testing I need to decided if I want to update those checklists or work on that fuel cell issue [17:06:46] decide* [17:06:52] It's nice to have the day off haha [17:22:31] yeah, having that Apollo 11 LR self test procedure is so great [17:23:13] Have you tried it in the sim yet? [17:24:20] no [17:24:50] I will try it [17:25:01] just have do the old procedure and look at the flag state [17:25:09] then the new procedure and the flag should be ok [17:29:59] Let me know [17:32:02] if it works? [17:34:41] Yes [17:39:27] ok, flagword is 4502 before the test [17:39:31] relevant flag is 0 [17:39:37] which means position 1 [17:39:49] after the test the flagword is 4546 [17:40:36] which is basically identical, but the flag is indeed wrong [17:40:46] now the new procedure [17:40:57] fingers crossed [17:44:00] actually, you enter V63 in the Apollo 12 procedure as well [17:45:40] uhh [17:45:52] I'm not sure anymore the procedures are actually different [17:46:48] I am pulling them up side by side [17:49:39] They do look identical [17:49:39] hmm, I think I was right, just not in the way I thought [17:49:48] V63 is used with the RR again, after the LR self test [17:49:53] and that seems to reset the flag [17:50:24] so the LR self test procedure has V63 twice, but then it's used again shortly after [17:51:42] the Apollo 12 doesnt appear to have V63 twice [17:52:24] in the G&N Dictionary [17:52:41] step 4 and step9 [17:52:51] Oh I am looking at the 12 timeline [17:54:03] ah [17:54:11] yeah, the G&N Dictionary also has that variant [17:54:24] "If Antenna not commanded to hover, go to 13)" [17:55:38] yeah, simply starting V63 already fixes the flag [17:56:04] I guess starting V63 checks the input bits and sets the LR position flag accordingly [17:56:16] this might be something Mike had mentioned once [17:57:36] https://github.com/virtualagc/virtualagc/blob/master/Luminary099/EXTENDED_VERBS.agc#L630 [17:57:40] It sounds famillar [17:58:06] yeah, so starting V63 again is indeed the "fix" used during Apollo 11 [17:58:12] just not in the way I thought :D [17:58:21] Now was this fixed in the LGC for 12? [17:58:48] yes, 100% [17:59:05] Ah that explains the procedure differences [18:00:29] on multiple levels this was fixed actually [18:00:46] Luminary107: "PCR 817 - eliminate turning on LR position alarm 522 in Landing [18:00:46] Programs (R12)." [18:01:00] so you wouldn't even get that alarm [18:01:05] Haha yeah [18:01:07] even if the flag was wrong [18:01:12] at least not in the landing programs [18:02:08] also PCR 839 in revision 108 might be relevant [18:02:15] 3) PCR 839 was implemented. (R12 and LR Re-position Routine [18:02:16] Improvements) As a result of this PCR two former flagbits were [18:02:16] deleted and replaced with two new ones: N0511FLG replaced [18:02:17] SCALBAD (bit 3 of flag 11), and LPOS2FLG replaced READLR (bit [18:02:17] 6 of flag 11). [18:07:43] My keyboard keeps randomly freezing up, either no key will work, or it will get stuck on the last key I pressed [18:07:57] that seems bad [18:08:04] I think I am in need of a wipe/reinstall I have been getting all sorts of little issues like that [18:08:05] I'll blame Microsoft [18:08:34] Just waiting for my new laptop to arrive so I have my new office keys [18:08:40] My ones from school finally expired [18:09:13] So I took advantage of getting a 30 dollar discount on office and bought my own license [18:09:36] I am also hoping a wipe will resolve those debug issues with VS [18:09:42] Clearly its been fixed [18:09:55] But something on my install still doesnt let the debug button work right [18:10:01] yeah, works fine for me now [18:11:00] Its been a while since I have done a wipe because I didnt want to lose my office install [18:11:13] But it will be nice to have a laptop I can run orbiter on as well [18:14:36] yeah, I should do that as well soon [18:15:27] I probably spent more than i should but I likely won't have my desktop in Alaska this year [18:15:36] So I needed something that can game a little :P [18:15:55] Also havent bought a laptop in 10 years so theres that [18:16:56] not that I have to keep the Orbiter2010 branch update just for you :D [18:17:01] updated* [18:17:21] which is much more performance friendly of course [18:18:58] You know, I dont think I ever tried Orbiter 2010 on that laptop since we switched [18:20:22] haha, you just have to say a word and I'll spent some time trying to update that branch [18:21:03] Well new laptop is on its way so might be a waste of time trying at this point [18:21:57] I have this glycol loop so close! [18:55:39] Ok now to test the thermal side [19:10:25] I think its working properly.... [19:10:56] If anything it can take more heat :) [19:11:16] awesome [19:11:47] Which might be needed because I cannot get the suit heating glycol above 50 [19:12:06] But that might not be bad because other systems will be adding heat [19:12:16] ASA and IMU are still good as well [19:12:52] Now to add a crew [19:15:03] Suit temp 55 cabin temp 65 [19:16:05] I think this is good enough to merge [19:20:37] PR is up, now to get those checklist changes in [19:25:44] Hmm what would TM SW H/H be? [19:25:54] PCM high and what else [19:28:04] tape meter [19:28:25] Oh I was thinking telemetry [19:28:27] so the RNG/ALT MON switch [19:28:32] yeah, me too at first [19:28:37] Thanks [19:29:33] So H/H is altitude and alt rate [19:29:48] yep [19:30:17] as ooposed to H/Hdot [19:30:22] Right [13:59:12] hey [13:59:34] hey Alex [14:04:20] I used option 8 of RTCC MFD to calculate the Apollo 13 free return maneuver. I was surprised how well it worked, lots of control over the splashdown point... [14:04:49] with 40 degree ascending [14:06:51] that's what that option is for, I guess [14:07:04] yeah [14:08:31] I calculated the LOI-5 maneuvers from Apollo 12 and 14 with it. The DV's are basically (almost) identical to the real pad [14:09:12] much closer then if I used the fly-by option in the Entry page [14:09:23] very awesome [14:09:46] yeah, using the nominal peri latitude as a constraint helps a lot with that [14:10:54] or at least as an initial guess, I forget what option 8 does with that [14:11:21] option 9 is the fully optimized flyby, I'll add that at some point as well [14:12:06] optimized for splashdown point? [14:12:07] I have the flow chart from the same document as option 8, but it's more extensive [14:12:14] optimized DV [14:12:17] ah [14:12:50] there are actually 9A and 9B [14:13:07] 9A is fully optimized, 9B is with an inclination input [14:13:16] with option 8, what I found works well is playing with peri altitude until you get the desired splashdown longitude [14:13:59] yeah, for option 9B you actually do that manually with the input inclination [14:14:12] the altitude will be varied by the iteration for optimized DV [14:14:55] option 8 is called SPS lunar flyby and option 9 optimized RCS flyby, that is the main difference in their purpose [14:15:31] yeah, I was curious, its called "SPS" but LM DPS can be used? [14:15:56] I noticed the TIG is different in the LM so it seems to recalculate the correct non-impulsive TIG [14:16:20] yeah, it should calculate the burn with the DPS parameters [14:16:44] I guess the SPS/RCS terminology really means: situation is really bad, we need to use RCS [14:16:54] right [14:16:55] versus: we still can use the SPS [14:17:03] or any other major engine [14:17:05] so the DPS [14:17:29] and these options are also not really mentioning docked burns at all [14:17:41] doesn't make much of a difference for the RTCC [14:17:53] the actual burn data are computed with a separate computer [14:17:58] powered flight processor or so [14:18:17] so the result of the TLMCC Processor is impulsive anyway [14:18:29] I see [14:19:24] I'll have to actually fly Apollo 13 and test this all out [14:21:24] but I also want to re-fly Apollo 11 with the timeline book we now have...lol [14:22:46] haha [14:22:56] did Ryan tell you that I tested the new procedure? [14:23:54] oh really? [14:24:07] or were you even online yesterday, haha [14:24:15] nope working haha [14:25:10] so, the actual Apollo 11 LR self test procedure is basically the long version as it is done in the Apollo 12 G&N Dictionary [14:25:26] the Apollo 12 LM Timeline Book skips actually changing the LR position [14:25:50] so after the Apollo 11 LR self test the flag is in a bad state [14:26:00] but immediately afterwards a short RR test is done [14:26:10] which starts V63 again [14:26:17] just the first display of it though [14:26:27] and the process of starting V63 is what fixes the flag [14:26:45] interesting [14:27:07] it basically resets all the LR flags and evaluates their state again with e.g. the LR position input bits [14:27:27] so instead of changing the flag manually we could also have done: V63E 34E [14:27:36] V63E V34E [14:28:30] I guess they weren't too worried that the astronauts might forget to do that after the LR test [14:29:04] it seems to be fixed in Luminary116 [14:29:31] yeah, starting with Luminary107 you wouldn't even get the persistent 522 alarms in P63 [14:30:17] and they might have known about this issue beforehand and were monitoring the flagwords [14:30:36] most likely [15:17:29] alright, going to try a manual TLI [15:19:30] which mission? [15:19:37] Apollo 17 [15:20:08] I guess you'll to generate a LV GUID failure [15:20:27] yep, already done [15:20:43] I flew a manual insertion [15:21:22] fun [15:21:27] TLI PAD seems to still calculate, even with the LV GUID failure [15:22:11] I wonder if we have manual TLI charts for 17 [15:25:17] http://media.liveauctiongroup.net/i/32614/28064774_2.jpg?v=8D5011A3CE9DC90 [15:30:34] thanks! [15:58:57] just working out the last kinks of this apse line rotation calculation method [16:01:16] this calculation would have been done in the RTACF, by the Apollo real-time rendezvous support program [16:01:19] short ARRS [16:01:28] or alternatively called "The Monster" [16:06:32] awesome [16:09:29] gives good results for the Apollo 7 SPS-7. And it has some uses for Apollo 9 as well. [16:09:49] With the apogee placed at the right point, very low DV reentry solutions should be possible [16:10:19] What kind of dV did 7 and 9 have on the SPS deorbits? [16:11:23] Apollo 7 planned: 278.9 ft/s [16:11:35] but the nominal procedure is not DV optimal [16:11:43] because the attitude is constraint [16:11:51] placing the 31.7° line on the window on the horizon [16:12:13] so it's more than 45° pitched down from local horizontal [16:13:02] Apollo 9 Contigency Deorbit document has some details about other procedures [16:13:38] with a 90x220 orbit and a burn at apogee placing the perigee at 40NM you will get the results with the smallest DV that still gives you a reentry [16:14:17] I didnt realize 7 was so high [16:14:37] with that procedure you might get it down to 75 ft/s [16:15:07] for a hybrid deorbit that is quite nice [16:15:58] Apollo 9 will be similar for the nominal deorbit [16:16:07] and we got even higher numbers [16:16:15] because apogee wasn't placed at the right point [16:19:50] Good to know [16:20:32] These LM timeline procedures are much more streamlined than my previous ones which is nice [16:20:40] well here's to my great piloting skills, MCC-2 is 1950 fps [16:20:48] But of course I was tying together a bunch of different ones [16:20:59] 1950, impressive ;) [16:21:14] not quite in the nominal DV budget for TLC [16:21:47] Well he could probably enter LPO and then use the LM to get out ;) [16:21:51] the burn attitude just might be different with our calculated presettings [16:22:05] I'm sure the mission rules will tell us what to do [16:22:17] And I am sure it wont be my suggestion haha [16:23:26] it may of been a procedural error too, I'm following the Apollo 15 TLI checklist [16:23:34] maybe, yeah [16:23:40] ORDEAL attitude maybe [16:23:48] The TLI pad is actually identical to the real PAD btw [16:23:59] oh and I was flying the actual launch time [16:24:55] wait, actual launch time TLI PAD calculated with the RTCC MFD is identical to the 2:40h delayed launch TLI PAD from the actual mission? [16:25:00] uhh [16:25:04] on time launch* [16:25:17] I should try reading [16:25:31] all with the actual launch [16:25:54] they got a comment about the ORDEAL in the transcript [16:26:08] I flew launch with the 2:40 delay yeah [16:26:38] so what ORDEAL angle did you start with? [16:26:52] so obviously did not fly the attitude on the link to the chart you posted as that was for nominal [16:26:54] 312 [16:27:02] 002:30:16 Overmyer: And, Ron, in - on the Launch Checklist, on 2-25, on the manual and nominal S-IVB TLI-1, add 34 degrees on the nominal PAD for all the pitch angles; and on the manual PAD, add 34.5 degrees to all the pitch angles, and you'll have it right. [16:28:15] yep that adds up to 312 [16:28:38] maybe it was the .5 difference [16:29:05] oh wait [16:30:03] I was looking at the nominal side, 271.7+34.5 = 306.2 [16:30:27] that isn't ORDEAL pitch though [16:30:59] You set ORDEAL 0 for that attitude [16:40:07] I really need to set a dead-zone on my joystick [16:40:49] I have the same problem [16:40:57] But never found a way to do it that works for orbiter [16:41:47] In the 11 procedures, I find it interesting it makes no note of the 503 alarm that comes up if you try to proceed in P40 with throttle control at manual [16:45:00] 545 fps [16:45:51] maybe I could get away with free LPO [16:48:05] the mission rules have a few suggestions [16:48:09] total DV required to get to lunar orbit from my post-TLI (with non-free BAP, free LPO) 3132 fps. Hmm [16:49:05] for TLI underburns that is [16:49:43] 1. drop nominal constraint on TEC return inclination [16:49:50] 2.execute MCC-1 at TLI+3 hours [16:50:03] provide additional DV for MCC-1 by: [16:50:21] well, it lists 4 things there [16:50:32] "reoptimize the descent approach azimuth" is the interesting one [16:51:14] and more extreme [16:51:20] 4. Execute MCC-1 at TLI+1hour [16:51:54] 5B: Schedule TEI shortly after RNDZ or 5C: Add 24h to TEC [16:53:23] MCC-1 at 15 hours is down to 398 fps [16:54:08] anything before that time doesn't work unfortunately, gives weird high DVs above 10000 fps [16:54:34] so they had a few options [16:54:57] yeah, Earth gravity has too much of an effect before that time [16:55:00] I have to improve that [16:58:52] so with an early MCC-1 maybe 200 fps or so, if I could get it to work at TLI+ a few hours and LOI would result in pretty much nominal DV usage by the time I get to LPO. This mission looks like it would be salvageable [16:59:13] maybe just need a new lunar terrain model [17:18:47] Do we have a DPS config card? [17:21:10] what would be on that card? [17:22:03] I actually am not 100% sure, there is a step that says check DPS config card 4 minutes before DOI [17:22:38] we have manual TLI charts for most missions it seems [17:23:24] I have one for apollo 12 [17:23:28] in the data card book [17:23:52] ah [17:24:11] Oh never mind thats not the right one [17:24:28] I was about to ask which page [17:24:37] Unless it means the ones on pdf page 2 [17:25:19] But those are aborts from DOI I think [17:25:41] yeah [17:25:52] I think this might be a general cue card for a DPS burn [17:26:39] yeah [17:26:47] we have that for Apollo 14 at least [17:27:01] Maybe that will be close enough [17:27:40] the step in the Apollo 11 LM Timeline Book will be to check that the card card has been attached somewhere for DOI [17:28:28] Oh not to check it for proper positions? [17:28:50] position of what? [17:28:55] switches [17:28:58] oh [17:29:00] hmm [17:29:01] possible [17:29:25] I would think yes since the switches on the DPS data card for 14 are not all mentioned in the timeline here but need to be switched for a burn [17:29:33] Its not long [17:29:37] indeed [17:29:47] so it's the nominal switch config for a DPS burn [17:37:51] Easy enough [18:00:39] Another thing that might help the batteries later is that this configuration does not use the ascent batteries during DOI [18:00:50] So thats a little more juice [18:23:32] yeah I remember the ascent batts being a bit low after ascent on my last Apollo 11 run [18:26:06] btw just realized on my post-manual TLI, I had forgotten to adjust my pericynthion time for the launch delay (subtract 2:40). When I did that my MCC was much lower, still above 100 fps though [18:39:15] kmorning! [18:42:44] hey Mike [18:47:56] what's up? [18:53:24] hey Mike [18:53:35] having fun with manual TLI's [18:54:06] haha, awesome [19:04:16] I'm still implementing a few calculations for Earth orbital maneuvers [19:27:22] Hello [19:28:05] hey [19:29:16] Have been trying to get onto the irclog site and am being told that it is configured wrong, the certificate has ran out and is insecure ? [19:29:35] hmm [19:30:28] Error code: SEC_ERROR_EXPIRED_CERTIFICATE [19:30:37] I get the same [19:30:58] i was on it earlier and had no problems [19:31:05] at least there seem to be some more recent logs now [19:31:40] it's a private server, I am sure it's fine to open [19:31:44] The certificate expired on 25 February 2018, 16:01. [19:32:16] Both firefox and Chrome wont allow me to access it [19:33:00] I can click on a button on that page and allow it manually [19:33:10] Chrome [19:33:25] But I guess Thymo has some fixing to do [19:34:12] yes [19:34:50] Sorry to bother you [19:35:21] no problem [19:35:28] I'll bother Thymo some more about it :D [19:36:44] Thank you [19:46:42] just checking :) [20:36:41] why am I not surprised that it could be annoying to work on the calculations done by the RTCC program called "The Monster" [20:39:00] or RTACF rather [20:40:17] hehehehe [20:41:36] you know it's bad when that name is used in official MSC memos [20:42:17] hahaha it was? yeah that is pretty bad [20:42:58] that was kind of its official name, next to ARRS. Apollo real-time rendezvous support program [20:44:52] and when you have later paper analysing its capabilities, then you get something like this [20:44:53] https://ntrs.nasa.gov/search.jsp?R=19760020211 [20:48:44] haha, nice [21:16:56] What are the mode II RR angles again? [21:17:08] +180 -270? [21:20:07] Or +180 +270 [21:20:24] Which I think is also +180 -90 [21:21:46] I think +180 +270 is straight up [21:25:28] Ok [21:25:36] I remember one of those two not working [21:26:26] I think it was something to do with the software but I dont remember, but it doesn't apply here since it should automatically drive to a mode II position based on my orientation at this phase [21:26:45] yes, that was the whole thing with an outdated document using a different definition of the angles [21:26:55] well, outdated Luminary version really [21:27:00] before Apollo 10 [21:27:01] Oh by the way, did you notice the V25N07 110E 40E E in this timeline? [21:27:28] Its actually in the procedure [21:27:43] DOI +10m [21:28:02] So regardless, that fixes the flag before PDI [21:28:02] wooooow [21:28:11] it's actually in there [21:28:13] Yep [21:28:15] didn't even look at that page [21:28:16] hah! [21:28:21] So it wasn't a cheat afterall [21:28:34] that's incredible lol [21:29:17] After I am done with this, I am going to fly 11 again giving the LM (and these procedures) a full checkout [21:29:41] I have not really launched since all of the LVCD work [21:29:46] LVDC [21:30:43] haha, you can command a few fun things to the LVDC [21:30:54] and watch it do some other fun things [21:31:08] Very nice [21:31:12] so, immediately after the flag reset is "Track Light - Off" [21:31:24] that can't really be connected [21:31:30] it must be just a check [21:32:10] and the reason to put that procedure at that point is probably that all the radar tests are done at that point [21:32:15] Yeah probably to confirm the RR power off [21:32:20] yes [21:32:21] immediately before you do the V63 [21:32:34] which alone should already reset the flag [21:33:00] guess they actually knew about this issue and worried a lot, so they put that in again as a safeguard [21:33:15] yeah, just to be double-extra-sure [21:33:23] Yeah, ironic that they still had RR issues later [21:33:30] But different ones all together of course [21:34:20] The having to have the ASC ECA breaker in to turn on the ASC bats is wrong isnt it? [21:35:06] I mean the procedures never say that but ours wont work without that closed [21:35:57] I think you can't connect or disconnect the bats without that breaker [21:36:19] But is that the correct behavior [21:36:43] Because no procedure I have seen calls for that breaker closed before switching on the asc bats [21:36:49] hmm [21:36:59] not really sure [21:37:06] I have artificially added it to my checklists [21:37:35] But again, I cannot recall ever seeing that breaker closed in a procedure before powering the asc batteries [21:37:52] This one included [21:38:03] description of the ASC ECA breaker on panel 16: [21:38:38] "Power from LMP bus to power supplies of both asc ECA's for current & reverse current ind & O/C protection" [21:39:24] ASC ECA CONT is the one needed to switch OFF the ascent batteries [21:39:47] But not on [21:39:53] yeah, seems like it [21:40:08] Hm I will double check and see if it is mentioned when those are switched offline [21:40:29] aren't the ASC ECA breakers closed most of the time? [21:40:36] but not ASC ECA CONT [21:40:57] No I think they are open [21:41:05] No, closed [21:41:10] I had them backwards in my head [21:41:16] So yes you are correct [21:41:27] ASC ECA CONT is open most of the time [21:41:33] Correct [21:42:06] still can't believe the flag reset is actually like that in the procedure [21:42:21] that's almost on a level with the Apollo 8 P37 procedure for fast reentries [21:43:34] "they can't have seriously done this in the actual procedures... oh yes, they did" [21:43:45] I saw that and was like, that V25 N07 looks familiar [21:44:07] I was typing it into the excel sheet and was like...no way [21:44:14] Right there all along [21:44:21] Well, at least in this revision :P [21:44:46] yeah. I mean, they also reset that one RR bit on every mission. But that's not to avoid a software bug [21:45:03] Oh and the batteries looking at the 11-sur, the asc batteries are switched on before liftoff, bat 1 and 3 are switched off, and THEN the asc eca cont are closed [21:45:33] which one though [21:45:38] I am going to see if I can find when they are turned off after PDI [21:45:38] there are two of those CBs [21:45:40] Both [21:45:51] cb 11 & 16 [21:46:44] wait [21:46:49] And there it is, those are closed at PDI+20 before the batteries are switched off [21:46:56] And then opened back up [21:47:05] bats 1 and 3 are descent batteries [21:47:14] Yeah just reading the steps [21:47:17] Thats unrelated [21:47:25] that would be DES ECA CONT then [21:47:37] Which was already closed at that point [21:47:41] yeah [21:47:47] But for the asc batteries you are correct [21:47:57] looks like whenever they are turned off those eca cont are closed [21:48:08] Wonder if thats an easy fix in the ECA code [21:48:14] probably [21:48:28] I think Thymo wanted to look into LM EPS stuff [21:48:53] but I'm sure he won't be mad if someone beats him to it [21:49:53] At least not for something minor [21:50:10] I did want to dive into the ECAs at the very least for heat generation [21:50:29] The battery loops are cold and need some heat :P [21:50:57] haha [21:51:01] But the ECA fix would allow me to eliminate another deviation from the actual procedures in the checklists [21:51:10] all I ever did with the ECA was fix the initialization order [21:51:15] Where are they? [21:52:00] that was the reason why we had to do 4 LM system timesteps before all the other system could get power through the ECAs [21:52:07] lemsystems with everything else? haha [21:52:45] that was the one obstacle to moving a bunch of systems to PreStep [21:53:02] and also unhealthy in general [21:53:30] when you save and reload a bunch of times and skip 4 timesteps each time for all the systems then that can't be healthy [21:54:03] Not at all [21:55:19] LEMBatterySwitch [21:55:24] Is that where that logic is? [21:56:36] looks like it [22:00:18] Looks like that prohibits all changes if those breakers have no power [22:00:26] yep [22:00:44] Do the DES ECAs have the same behavior? [22:00:52] I think so [22:01:03] So they can be switched LV or HV without the ECA CONT? [22:01:19] I would think that controller is needed for the switching logic for the taps [22:01:32] But I honestly haven't looked [22:02:50] Not quite sure exactly what the code is doing [22:03:40] Looks like the deadface switch also has the same conditions with those asc eca cont [22:03:43] I'll look into in more detail, I'm sure the Systems Handbook also can help [22:03:53] Awesome [22:04:03] I look forward to at least removing that from the checklists :) [22:04:27] as usual, if you want something done, adding an issue on Github is always good, haha [22:04:31] I am almost to PDI on these changes [22:04:32] Right [22:05:20] ECA's in general need some love I am sure [22:06:54] probably. the power supply logic should be pretty good already [22:07:11] which is the most complex coding issue for the ECAs [22:07:27] theres still that issue where you need to close the ASC ECA to turn off the ascent batts [22:08:25] Thats what we were discussing actually [22:08:39] Looks like you only need it to turn the feeds off [22:08:44] At least in the real LM [22:15:07] night! [22:17:25] one thing we should get rid of is orbiter control saturn's main engine. (pressing keyboard + or operation of an orbiter configured joystick throttle, still activates the S1C,SII,SIVB engine) [22:18:20] Oh not good [22:18:31] of course joystick should be disabled in the Orbiter options, but I'm sure some new users will forget that [22:18:43] Can we disable that in NASSP? [22:18:59] Well, we did already for the LM and CSM [22:19:16] I honestly never noticed [22:19:37] Oh before I forget, remember that V25N07 that cleared the LR flag for PDI? [22:19:53] 110E 40E E [22:19:58] yep [22:20:03] Its actually in this LM timeline [22:20:20] DOI+10m [22:20:22] hmm V63? [22:20:27] oh [22:20:31] Nope after all of the V63's [22:20:46] literally has those steps that we used to clear the flag [22:21:23] Guess they knew about it [22:21:29] And had the same "fix" we used [22:22:26] hmm I cant see it, the Apollo 11 timeline book? [22:23:30] ah ok found it [22:23:36] interesting [22:27:34] Yeah [22:27:36] Imagine that [22:29:30] who needs a timeline book when you have a Niklas to come up with these things :D [22:30:07] I know, right? [22:30:23] I got deja vu when I was typing it into the excel checklist [22:30:33] hahaha [22:30:48] I was like want a minute, looked over at my LM cheatsheat postits slapped all over my tower, and there it is [22:31:22] So not only did they have the V63, they had that as one more measure to prevent the error [22:37:32] I am trying to figure how how this LEMBatterySwitch class works [22:37:42] Its where the eca breaker conditions are applied [23:06:58] Hmm, phrasing question, could opening thruster pair isolation valves mean switching them to enable or disable? [23:07:22] Probably enable? [23:07:54] probably enable, yeah [23:08:18] Ok [23:18:40] night! [23:18:59] hmm [23:19:23] do you think there's any chance there was ever a third rendezvous radar / VHF measurement? [23:19:30] other than range and range rate? [23:26:54] Such as? [23:27:07] I mean there is a theta [23:29:06] not sure, haha [23:29:15] I'm just working on yaAGC interface simulation again [23:29:24] I mean angle, range, and rate seem like all you need [23:29:33] You can derive everything from those [23:29:38] and it's generally careful about not transmitting garbage out [23:30:03] so radar selections 000 and 011 are not valid, with 001 and 010 being range and range rate [23:30:18] if you select 000, it will not attempt to talk to the RR [23:30:35] but it doesn't filter out the 011 case, and still transmits sync pulses to the RR [23:30:54] and accepts back whatever the RR has to say about the 011 measurement [23:31:24] just kinda curious why they didn't filter that out like they did with 000 [23:32:20] Unless it has to do with the AGS [23:32:33] Or is this the CSM computer [23:32:59] this is the AGC behavior in general, so it could apply either to RR or VHF I guess [23:33:04] Ah ok [23:36:22] The AOH might help [23:37:59] hmm, maybe early AOHs might say something? [23:40:41] There is a bunch of info about the RR in the later LM ones for sure [23:41:12] ah, if anything I think this is probably a really early design possibility that was abandoned early on [23:42:35] sort of like the EMSD/LEMONM output counter [23:43:40] Ah I did not think of that [23:43:50] A good reference might be gemini computers [23:44:06] I would assume they had radar for Agena docking [23:46:32] hmm, good idea [23:50:25] no, looks like just range and range-rate, if I'm reading this correctly [23:52:38] haha, more questions [23:52:42] was VHF a later addition to the CM? [23:54:18] the ICD for the CMC has specifications for the interface to the BMAGs, which was never used, but not for the VHF [00:24:45] I think VHF was later yes [00:25:04] At least the CSM ability to do anything with it [00:25:11] AGC not CSM [00:28:52] gotcha [00:36:01] I guess I need to ask Nik if the Apollo 11 LVDC stuff is timed right so I can change the auto checklist timing [00:36:29] I am flying 11 from the beginning its been a while since I have really left the LM :P [00:42:02] hehehe [00:43:31] But this is a good chance to give it a full checkout as well as testing out the new timeline book changes to the checklist [00:43:42] And it gets my head back into the cockpit ;) [00:44:37] Beautiful launch seems much smoother [00:46:37] I'll let my "crew" do the post insertion stuff as I eat :P [14:15:57] morning [14:26:11] hey [14:30:10] whats up? [14:31:34] still having some issues with this apse line rotation calculation [14:31:45] mostly issues of conceptual nature [14:32:10] do I want TIG to be at perigee or not, do I want to allow it to alter the orbit or only rotate it etc. [14:33:38] sounss a lot like the DOI calculation [14:33:42] sounds* [14:34:11] yes, a bit [14:34:45] I've also not done much with this kind of calculation before, so I need to study the orbital mechanics a bit more [14:35:31] another issue is that the calculation has to be fully automatic for the MCC [14:35:39] right [14:36:05] I'm sure there were some manual steps involved in the RTACF for this [14:36:14] for sure [14:36:42] I've tracked down where this would be calculated, General Purpose Maneuver Processor. But most I know about it are the output displays of it [14:37:05] the document with the displays actually has the Apollo 7 NCC-1 burn as an example [14:37:49] a TIG of 26:25:00 looked really familiar when I found that [14:38:39] haha yeah used that one often? [14:38:51] it's been a while, but yes [14:39:37] btw, Is it still in the planning to disable orbiter control of the Saturn engines? (keyboard +) also , if a user forgets to disable orbiter joystick, the slider still controls thrust [14:40:59] yes [14:41:13] that is accomplished by not setting a default main engine [14:41:33] right [14:41:36] the issue with that is that non-default engines don't use sound on their own [14:42:01] so for the RCS we always had a bunch of code on our own to play the thruster firing audio [14:42:49] when I deleted the default Orbiter RCS definitions in the LM I had to copy some code over from the CSM [14:42:57] I imagine assigning a sound for the main engines shouldnt be too hard [14:43:13] yeah, should be possible [14:51:03] Good morning [14:52:35] hey Ryan [14:53:48] I just started a fresh Apollo 11 mission from scratch last night, the launch/insertion was great [14:54:41] I do think I need to adjust the timing in the checklist MFD now though, as the old times were based on the old sequence of events [14:54:55] Are those pretty much at the right places? [14:55:40] which events? during launch? [14:56:11] Yeah [14:56:39] I think they are close, yes [14:57:02] Great [15:05:52] I was looking at that ECA code last night, I couldn't really see the best way to alter/fix it to work properly [15:09:16] that code is both in the switch code and the actual ECA code I guess [15:10:18] Hmm [15:12:46] I generally don't like that solution too much. I like my switch code staying dumb and instead use an ECA timestep for the logic. [15:12:53] Yeah [15:13:19] Creates potential logic conflict as well when we start changing things in one place and not the other [15:36:57] When does level sense happen with respect to the PU shift? [15:40:23] Looking at the transcript they were almost the same time [15:40:55] However looking at 12's launch checklist, they were about 36 seconds apart [15:59:31] level sense is a switch selector event, so a fixed time in the timebase [16:00:26] On 11 did they occur at the same time? [16:03:02] Apollo 8, TB3+335 is LOX and LH2 depletion sensors cutoff arm [16:03:20] that might be the same time for most missions [16:03:30] that is the planned time [16:03:46] Apollo 11, guidance sensed time to begin EMR Shift, TB3+333.2 [16:03:49] that is actual [16:03:57] so very close to each other [16:06:20] Ok [16:06:29] not sure yet about 12 [16:06:35] Thats what I thought based on the SV evaluation and transcript [16:08:33] So PU shift in the sim is 8:18 [16:09:04] The level sense in the transcript says 8:17 [16:09:14] for 11 [16:09:23] And PU is reported by the crew at 8:22 [16:09:24] yes [16:09:54] PU shift is not instant [16:09:59] so it can take a few seconds [16:10:10] so no inconsistency between 8:17 and 8:22 [16:11:09] So when should Apollo 11 level sense be? 8:17? Before the PU shift? [16:11:31] by my calculation 8:17 is the right time for that [16:11:38] which we also use right now [16:11:53] why is that event even relevant for the astronauts? [16:13:02] it arms the cutoff circuits in the S-II that automatically shut off all the engines based on low propellant [16:14:02] Apollo 12 had the first LVDC that had a S-II two engine out detection capability [16:14:13] maybe that's related to the later level sense arm [16:14:17] indy91, so I've been testing this a bit, starting with S1C, I changed THGROUP_MAIN to THGROUP_USER in the S1C section of sat5mesh.cpp and that works very well. [16:14:37] next I can add something like RCSSoundTimestep() in satsystems.cpp I guess? [16:14:59] yeah [16:15:08] should be much simpler of course than for the RCS [16:15:26] although it still has to take into account 1-8 engines burning [16:15:27] not sure [16:15:37] I can give a crack at it as it looks not too complicated [16:15:52] If I can get the S1C without any issues, i'll do SII and SIVB [16:16:02] indy91 I don't know its in the 12 launch checklist and reported to the crew by Houston [16:17:25] after the time of level sense arm a S-II cutoff could be nominal [16:17:31] instead of some malfunction [16:19:49] oh, I think I know [16:20:10] if the engines of the S-II fail before level sense arm it might not start TB4 on its own [16:20:26] so before that time you would have to use the S-II/S-IVB Direct Staging switch [16:20:32] Ah makes sense [16:20:40] so relevant for a crew procedure [16:21:52] yeah, that's it. TB4 can't start without the propellant depletion sensor being armed from the LVDC. [16:22:01] sensors* [16:26:28] now to find out why that time is different on Apollo 12 [16:26:32] Haha [16:27:15] well great, the Skylab document has those times as TBD [16:30:45] I doubt the S-IC flew 20 seconds longer on 12 than on 11 [16:41:30] anyone know the main engine equivalent of the RCSFireSound ? [16:41:35] mainext? [16:49:54] I have no clue [16:49:57] hmm actually, then engine sound is still playing after all [16:50:54] oh [16:51:14] I wonder why [16:58:11] it is not the same sounds though, it is a little bit softer, like the deltaglider main engine sound [16:58:19] not much different though [17:02:20] morning [17:04:32] hey [17:14:28] indy91, yeah the sounds all work. One issue is that all callings of THGROUP_MAIN in RTCC and MCC are now invalid it seems, I guess they would need to be set to THGROUP_USER, too? [17:15:15] ah right, that was another issue of changing this [17:15:20] hey Mike [17:18:14] and I don't think it's as simple as changing it to THGROUP_USER [17:20:29] yeah [17:26:13] the SPS and DPS are both using THGROUP_MAIN, yet you cant use the orbiter controls to start/stop the engine, so there must be a different way then [17:28:03] ah yes [17:28:21] if you add engine control to PostStep then you override any manual command done [17:28:55] because the Orbiter timestep is done between pre and post [17:29:04] Ok coming up on TLI stuff, any changes I should be aware of? [17:29:30] so the alternative solution is to move the Saturn stage timesteps to poststep [17:29:43] rcflyinghokie, don't think so [17:29:58] What about the TLI pad? [17:30:12] that should calculate correctly [17:30:30] Great [17:30:36] and has extraction angles now [17:30:37] And 11 does not need an uplink, correct? [17:30:45] CSM state vector [17:30:51] but nothing for the IU [17:30:51] IU uplink* [17:30:58] Ok [17:31:00] at least not before TLI [17:31:53] after TLI you have to enable TB8 through PAMFD if you want the S-IVB to do LOX dump and APS burn [17:33:02] I will ask about that when I get there :) [17:33:19] I see that we still cannot do the SM RCS hot fire while attached to the SIVB? [17:33:38] yep [17:33:58] Ok making sure its not a procedural error [17:34:19] I'm not sure if that will ever be implemented before the CSM is a separate vessel from the S-IVB [17:35:42] Yeah i expected as much [17:36:00] Separate vessels will help a lot assuming it can be done without breaking everything [17:37:08] I had some promising experiments with it [17:38:47] indy91, "is to move the Saturn stage timesteps to poststep" do you mean set in post step the function that calls up sat5mesh.cpp which in turn defines the thrusters? [17:40:50] no [17:41:18] during "mid step" Orbiter will set the thruster level of thrusters according to your inputs [17:41:25] like the + and - key on the numpad [17:42:08] but if you are also setting the thruster level in poststep in some vessel code, which is done for e.g. the SPS, then you overwrite whatever you did manually [17:42:17] right [17:42:20] that's how the Orbiter control is disabled for the SPS [17:42:31] so the solution would be to do the same for the Saturn engines [17:42:43] *a* solution [18:14:00] Sep attitude is close but the roll and pitch are a little off [18:14:43] 3 degrees off in roll, 1.5 in pitch and .5 in yaw, way better than before though [18:31:19] indy91, how do I get this TB8 going [18:32:09] Currently docked with the LM [18:32:14] Still in the SIVB [18:33:18] in the IU menu of PAMFD [18:34:14] Thats where I am [18:34:44] I went to time base 8 enable [18:34:53] stauts is vessel has no IU [18:34:56] status [18:37:48] did you set the source to your SIVB stage? [18:38:43] No? [18:38:48] I have never used this before haha [18:39:35] Ah got it [18:39:56] Is that all I need to do? [18:41:03] should be yeah [18:41:55] next is get the hell away from it before it burns... haha [18:42:58] Well I am still docked [18:43:34] Will be for another 30 minutes or more [18:45:35] ah right [18:46:08] and it won't do an evasive maneuver of course, thats on Apollo 12 [18:48:57] on 11 TB8 will not start until TB7 + 2 hours [18:49:12] so you can enable it anytime in TB7 [18:49:21] but it won't start doing stuff until 2 hours after TLI [18:49:39] Oh ok [18:50:01] Alex scared me with "next is get the hell away from it before it burns..." [18:50:02] for later flights that was handled a bit differently [18:51:42] haha sorry about that =p [18:55:46] nothing happens without the go from the astronauts :D [18:58:31] yeah [18:59:01] so calling s1c.timestep in post step of Saturn5.cpp? [19:06:29] yes. although I have to check if the thrust level is set every timestep [19:06:34] and how that is handled for the SPS [19:08:06] Does the system test meter work for LM power? [19:11:01] yes [19:11:06] 4 D? [19:11:46] yes [19:11:52] CSM TO LM CURRENT [19:12:02] Mine is reading zero [19:13:05] LM Power CBs in? [19:13:13] Thats what got me thinking that being unable to turn on the LM batteries without a save and reload might affect the LM power transfer as well [19:13:16] Yes [19:13:57] check the CBs again [19:14:19] I've had it happen that I got a random current and the CBs plopped open due to overcurrent [19:14:31] before saving/reloading that is [19:15:25] Yes [19:15:30] I have had that too but they are in [19:15:57] I cycled them to be sure [19:16:27] hmm, I've never seen that meter work either [19:21:35] I havent tried it after the battery switches work again [19:23:21] I've only recently added the LM current reading to the meter [19:23:59] Yeah no change in it [19:24:04] if it shows 0 then nothing is flowing to the LM [19:24:10] guess only reloading will fix that [19:24:21] Reloading fixed the batteries but still no flow [19:24:44] Maybe its because the batteries are full at LM spawn [19:24:59] Instead of drained a little [19:25:09] But even then, it should be powering the heaters [19:25:21] Giving at least a half amp draw [19:26:26] I've seen it working, so, not sure what the issue is [19:28:01] After this evasive I will look and see what the LM bats look like [19:28:33] If they are still full full, then that could explain it, but it would also mean the heaters arent using enough juice I think [19:30:09] last time I checked the current was on the low side, but still plausible [19:30:20] but that was before some of the heaters were added [19:31:09] It should be 0.5-3.2V [19:31:33] I dont know the correlation off hand to current [19:45:07] factor 2 [19:45:15] 0-10A [19:46:08] and I remember it showing about 1V [19:46:17] No such luck right now [19:48:33] I have tried saving and loading, cycling the switch cycling the breakers, making sure I am indeed on 4D [19:48:38] I doubt that it has anything to do with luck [19:49:07] hmm [19:49:11] now that I think about it [19:49:42] there might have been some switch setting I did in the LM to get it to accept power from the CSM [19:50:34] That isnt good [19:51:06] The closeout configuration switch settings should be correct to take CSM power [19:51:17] Assuming our LM has the correct configuration, of course [19:51:21] indy91, why not just disconnect the S1C,SII,SIVB propellant resource from the thruster, anytime the engine is flagged to stop in the systems' class [19:52:19] then you could still stop the engine manually by pressing minus [19:52:37] right [19:52:57] but maybe its an easier solution with less complications, or maybe not [19:56:59] well, something is super buggy. The CBs didn't want to stay in and now I get offscale high current on the test meter [19:57:21] Uh oh [19:57:29] On the plus side, the SIVB started venting [19:57:57] but it's been always like this [19:58:05] buggy [19:58:08] that's not new at all [19:58:21] Yeah I have had the breakers pop on me before and such [19:58:47] But no current flowing with the heaters drawing power is bad news for the LM bats [20:01:10] AlexB_88, both thruster level and resource are set to 0 on every timestep for the SPS [20:01:41] but you can still stop the SPS when its burning [20:01:45] with - [20:02:09] ah, right [20:02:27] not in the LM, for some reason [20:04:22] uhh, what? I've mapped the same button the engine stop button in the LM [20:05:05] so pressing the numpad minus should always stop the DPS and APS [20:05:43] ah right [20:08:04] the better long term solution is that I rework the RTCC to not directly ask for the main engine thruster parameters [20:08:31] and when that is done we can stop using the main and hover engine groups [20:08:38] yeah, I agree [20:12:08] I know I am a bit be annoying with this but as we now have a very detailed simulation of the relays and circuits that control each engine, I find it silly that we can still control the engine with the old orbiter controls [20:18:58] yeah, it's just not trivial to disable that, haha [20:20:28] Speaking of annoying, for 11 what do I use for MCC 1 calculation since I didnt calculate a TLI using RTCC [20:21:11] Option 1? [20:21:21] 2 [20:21:33] 2 I meant [20:21:52] yes [20:24:00] Do I use that for MCC1-4? [20:24:28] well for 1 and 2, then if you have to do 3 or 4, you use option 1 for those [20:24:51] option 2 will recalculate new targets for option 1 [20:25:31] so if you must do MCC-3 and 4, you use the same target that was calculated with the option 2 on MCC-1 or 2 [20:25:41] Thats what I always forget [20:26:06] MCC 1 16 fps [20:26:11] MCC 2 24 [20:26:22] I'll wait till MCC2 [20:27:19] not bad [20:27:34] real MCC-2 was 20.9 fps [20:28:31] So looking at my LM bats 3 of them have drained a little bit [20:28:39] 1 is still full [20:29:34] But this is after a few hours so either they arent discharging much or they are being charged afterall [20:29:36] DSC_BATTERY_A 43196651.4011 [20:29:36] DSC_BATTERY_B 43200000.0000 [20:29:37] DSC_BATTERY_C 43199834.5241 [20:29:37] DSC_BATTERY_D 43197306.0638 [20:29:54] Thats about 2.5 hours after ejection [20:34:55] I don't really understand half of what is going on with the CSM to LEM power, so this is one of those topics where I'd have to look at our code and documentation for a week before doing anything. [20:37:35] but I suspect that it has to do with the ECAs [20:37:43] at least the random power draw [20:37:57] that makes the CBs trip [20:59:25] ugh, too many things to work on at once [20:59:32] I'd really like to focus on the MCC for a while [21:06:36] yeah I hear ya [21:06:47] ho's Apollo 9 coming along? [21:09:07] too many things to work on; the perpetual problem [21:10:35] I will do periodic checks and see what the LM bats look like [21:19:30] Do we have a panel 16 closeout cb diagram? [21:21:33] I can deduce it from the entry checks of course but it looks like it is missing from the AOH [21:40:10] Hmm should the cabin repress and sband heater breakers be closed for launch since there is no power on the LMP bus during TLC? [21:43:12] hmm good question [21:47:14] They are closed on entry status checks though [21:47:26] But I dont have a panel 16 closeout list/diagram [21:53:36] is there actually no power on the LMP bus or only for us? [21:54:41] I've been adding a few Apollo 9 MCC related things, then I got stuck on this "rotate apse line for deorbit" things, which is relevant for both Apollo 7 and 9 [21:54:45] anyway, good night" [21:56:05] From what I can see the CSM power connection only powers the CDR bus directly [21:56:11] I am diving into the AOH to check [21:57:58] The EPS [21:57:59] distributes internally generated dc power from launch until LM-CSM docking, at which time LM Power is shut down and the CSM supplies 28 volts dc to the Commander's bus . (The dc power can be [21:57:59] routed through circuit breakers to the LM Pilot's bus.) [22:22:50] On the bright side no NaN's with my latest glycol loops [22:33:33] yeah [22:33:47] haven't seen NaN's in ages [22:33:50] Hmm during a purge is the bus and fuel cell voltage supposed to go up that high? [22:34:38] I know I have noticed it but never thought about it [22:34:49] I can see no reason that the voltage skyrockets [22:44:01] Also the H2 flow on the purging fuel cell during an o2 purge shoots up [22:44:08] And the temps increase [22:47:03] So looks like the reaction is increasing [22:47:14] yeah. i've always noticed that indications in general go up on the FC meters during purging [22:47:21] But I cannot find if that is the right behavior, I would think it is not [22:47:35] don't know how much is realistic though [22:49:08] Most of the reaction math seems right [22:49:31] I think what is happening is the increase in flow is somehow making the fuel cell run harder if that makes sense [22:49:38] Which I would think is incorrect [22:49:45] Especially with off scale voltages [22:54:56] back in a few [23:26:00] Yep batteries 1 and 4 arent charging [23:26:05] DSC_BATTERY_A 43143072.2415 [23:26:06] DSC_BATTERY_B 43200000.0000 [23:26:06] DSC_BATTERY_C 43199834.5241 [23:26:07] DSC_BATTERY_D 43143265.2090 [23:26:09] After 50 hours [23:26:19] But they are powering the heaters [23:26:34] Unless the charge is lower than the draw [23:39:41] .tell indy91, my LM has not drawn any power from the CSM during TLC, so the test meter is probably correct. However, des bats 1 and 4 have drained during TLC with csm power "applied". [23:52:07] nack [23:52:09] back [23:52:43] yeah, I thought I saw my batteries lower then normal during LM activation [23:55:24] Yeah as expected 1 and 4 are draining [23:55:43] Which are the two bats the LM runs on after ground power disconnect and before CSM/LM pwr [23:55:48] They run the heaters [23:56:00] On the bright side my heaters are working properly it seems [23:56:13] But it seems the csm is not powering the LM properly in some aspect [23:57:11] so how is our EPS modeling in the LM so far? Does it need a make-over? [23:57:19] Probably [23:57:24] I honestly have barely looked at it [23:57:45] But I have found a few problems mostly related directly to the ECA logic in the code [23:58:52] about the battery discharge, maybe you can make an issue for it on GIT? [23:59:17] Yeah I will, I have one up for the ECA logic [23:59:33] I am waiting until LM powerup to get a full TLC comparison of the batteries [23:59:45] So I have a better reference of draw [23:59:50] I am at 56 hours [23:59:57] Will just need MCC4 and LOI [00:00:02] Dinner time [00:00:07] ah right, did not notice the ECA logic one [02:14:31] Yeah looks like that probably needs a bunch of work [02:14:42] Though it already is quite complex, making it even harder to rework [13:06:05] hey [13:08:53] hey Niklas [13:42:09] I think I have to launch Apollo 9 again [13:42:31] the old PanelSDK state in my scenarios and the new code for it are not very compatible [13:42:43] pressure doesn't equalize at all [14:04:06] yeah [14:04:12] how old the scenario? [14:33:47] not super old, but just before Ryan did all the tweaks for the LM pressurization [14:39:07] bummer [14:40:48] at least I can check that the IU uplinks are working right and on time, I added them when I was already beyond the nominal time for them [14:41:39] can the switch selector in s1csystems be accessed by IU uplink in PAMFD? [14:42:51] I guess that would be the SI option in PAMFD [14:46:33] yes, but those uplinks wouldn't be accepted during launch [14:48:07] which might be different on some later flights, but for all I know switch selector commands through the DCS are only enabled after orbit insertion [14:48:27] not sure how it is on the launchpad [14:53:38] what do you want to uplink to the S-IC? [14:55:00] well, case 15 //S-IC/S-II Separation... Can't say that isn't tempting to try :D [15:00:52] hmm, I think range safety was able to tell the engines to cut off [15:00:55] but that's about it [15:01:22] so no way to directly command the S-IC/S-II separation [15:01:35] but I'm looking at the Skylab Saturn Flight Manual, maybe it has something about this [15:02:40] yeah, I've already implement a RSSCutoff variable for the S-IC [15:02:46] just nothing to set it yet [15:04:26] so TB2 is what nominally initiates S1C sep, correct? [15:05:38] TB3 [15:05:52] TB2 when at inboard cutoff [15:05:55] starts* [15:06:46] ah, I should learn to read [15:07:40] and it is a certain downrange velocity that starts TB2, or was that in the S1B? [15:07:59] DotS.z > 500.0 [15:08:27] both [15:08:34] but that is just a second criterium [15:09:16] S-IC inboard engine interrupt AND downrange velocity greater than 500 m/s [15:09:43] that makes it fail safe for the case TB1 was started on the launchpad without an actual liftoff [15:10:01] right [15:10:05] the J-Mission Saturn Vs were heavy enough to run into this 500 m/s constraint [15:10:31] so the inboard engine was cut off on schedule in TB1, but TB2 wouldn't start immediately, but only a few seconds later [15:10:58] when 500 m/s downrange velocity was achieved [15:12:40] and TB3 starts at S1C cutoff? [15:14:21] propellant low level [15:14:29] or thrust decaying due to propellant low level [15:14:45] but there also is a "level sense arm" for the S-IC [15:14:51] also commanded from the LVDC [15:15:00] TB2+19.5 and 19.7 [15:15:19] what about a manual cutoff by the T-handle? (with no abort) [15:17:00] that manually cuts off the engines through the EDS [15:17:22] I am not 100% sure about that case [15:17:55] in our LVDC the stack will coast until the engine cutoff is enabled at the times I said above [15:18:02] then it would be allowed to detect cutoff and start TB3 [15:18:22] but there is a backup signal, a discrete input (as opposed to an interrupt) [15:18:30] not sure if that is always enabled [15:18:38] maybe it would detect if all of the engines are off or so [15:19:12] it would have to be all of them, or else you might have TB3 starting during an engine failure [15:19:13] yep I tried it and it seems to work like that, coasted a bit then S1C sep, then SII ignition [15:20:01] a lot of off-nominal cases seem to be supported [15:20:06] yes [15:20:13] just by simulating it as it really worked [15:20:29] so the backup signal is from the backup depletion circuitry [15:20:48] that is the one enabled at TB2+19.7, nominal ones are at 19.5 [15:21:04] so I don't think TB3 can start before the LVDC enables the cutoff circuits [15:21:52] 10.5 and 10.7 for Skylab Saturn V [15:22:14] and the separation circuits also have to be enabled first before separation can be done [15:22:18] also done on schedule in TB2 [15:23:16] also, I noticed Apollo 15-17 don't have a flight sequence program in the .scn. I guess they load the default one? [15:23:52] right now, yes [15:23:58] there are a few differences I know about [15:25:33] for those missions the S-II ullage rockets were deleted [15:25:49] so the whole S-II ignition sequence was moved back by 1 second [15:26:46] no [15:26:49] does the default file have a TB8 timelune? [15:26:55] timeline* [15:27:01] the separation sequence was moved back 1 second [15:27:08] to let the S-IC thrust decay even more [15:27:12] which was an issue on 15 [15:27:16] almost had a collision [15:27:57] yes [15:28:03] the default one is derived from Apollo 11 [15:28:12] I'll add a J-Mission flight sequence program soon [15:28:21] should be identical for those missions [15:35:57] just noticed something interesting [15:37:24] When your in program 47, with V48 configured to SIVB (3), the CMC does not stop the IMU when in gimbal lock zone [15:39:15] which mission? [15:39:35] this is with Artemis072, Apollo 17 [15:40:43] P47 with S-IVB attached? Ever heard of P15? :D [15:40:53] maybe the CMC thinks your burning TLI, and does that for safety [15:41:14] P15? whats that? :p [15:41:50] would be in the program notes for Artemis then [15:42:03] funny thing is I configure for CSM only in V48, then it gimbal locks [15:42:20] hmm maybe this happens in other CMC versions [15:43:10] it's running a different DAP when in S-IVB mode [15:43:40] did you mean gimbal lock light 75° or actual lock at 85°? [15:44:11] actual 85, even 90. Try as you might, it stays happy [15:44:15] program notes mention that the RCS DAP "either CSM alone or docked" will stop an auto maneuver at 75° [15:44:43] but for the 85° limit it should be a separate logic [15:47:09] and this is only the case in P47? [15:47:11] not in P00? [15:48:49] found something [15:49:44] https://www.ibiblio.org/apollo/Documents/R577-section3-rev14.pdf [15:49:54] pdf page 206 [15:50:05] "Coarse align avoidance during SATURN Steering" [15:51:41] aha! [15:52:10] its to preserve manual "satstick" mode [15:52:19] thanks for the link [15:52:56] I guess basically just so the CMC needle deflection continues sending commands to the FCC [15:53:40] because if you coarse align, then the needle deflection obviously stops working [15:55:27] yep [15:56:01] so, I guess you can also use the manual Saturn takeover mode with a bad alignment [15:56:06] as long as the IMU is just working [15:56:14] yeah [15:56:31] Apollo 12 would be an interesting case for this [15:56:42] I was just thinking that too [15:56:48] I'm sure they had to quickly plan for the case that the P51 didn't work out [15:56:55] or at least not quickly enough [15:57:09] I'm sure they would have postponed TLI to the second opprtunity [15:57:11] but then what [15:58:47] of course the LV platform was still perfect and no saturn takeover was required, but I guess if they still wanted to have a good IMU, just in case [16:01:28] "perfect" [16:01:41] worst IU state vector of all missions [16:01:47] but not failed at least [16:02:06] let's see what the mission rules say [16:02:53] yeah, properly operating IMU is mandatory for TLI [16:14:35] Good morning [16:23:05] hey [16:25:47] I am close to LOI so i will have those battery numbers to check [16:26:13] But again, 50x coasting no nans [16:28:43] But it does look like batteries 1 and 4 are not charged up [16:35:36] hey Ryan [16:39:29] We might have to dive into the CSM/LM connection and charging if they are indeed not charging [16:40:37] yes [16:42:44] I am about to burn an LOI, I will get another look at the batteries after that to see how much discharge I have has during TLC [16:43:29] it's also possible that the move to PreStep of the LM systems could have broken something [16:43:43] because at least you were able to power the LM from the CSM [16:43:47] even with some buggines [16:43:50] bugginess* [16:48:05] Question is, did current actually flow between the two [16:49:13] indy91, so using the T-handle to cutoff S-1C and S-IVB works well, but the SII seems to not cut entirely if you do it too fast, (T-handle CCW, then back really quick) the SII seems to be left in a state with partial engine thrust [16:49:42] rcflyinghokie, the power has to come from somewhere [16:49:47] of course all is needed is to re-do the T-handle CCW but for a longer period [16:49:53] AlexB_88, interesting, sounds like a bug [16:50:04] maybe 2-3 secs and it cuts completely [16:50:26] the S1C and SIVB do not seem to have that issue, it cuts completely [16:53:43] rcflyinghokie, I remember it working for sure, because last year when I was flying Apollo 12-13 for the 1st time, I had depleted batteries when I got to PDI. I had forgotten to go to LM PWR - CSM [16:54:56] then when I did a mission with it I compared the batteries with and without LM PWR - CSM and they were for sure keeping it charged. So it must be a recent change [16:55:13] I guess the question is how much is supposed to be depleted, because I was under the impression that the batteries were not feeding the bus when the LM PWR CSM is engaged [16:59:17] the LM runs on its own power from the launchpad until CSM power is engaged [16:59:29] in our case from the time the LM is created [16:59:45] so yes, there should be a bit of juice gone from the LM batteries