[22:09:27] NASSP Logging has been started by thymo [22:10:20] Alright logging is back up. Did some power cable reorganizing today. :) [22:10:30] LM EPS needs help Thymo :P [22:10:42] What's up? :) [22:11:08] Well I have a running list actually, but right now the more pressing matter is CSM power transfer to the LM for TLC [22:11:15] Not functioning properly [22:11:36] I left 2 issues on git about the EPS [22:12:05] Ehh, I'll try to help. Power transfer is the one thing about the CM EPS I haven't really looked at thoroughly. [22:13:16] So if I read this correctly power transfer is completely broken? [22:13:27] I'm pretty sure it used to work a while back. [22:14:29] Yeah it did [22:15:08] Hmm. I'm in the process of updating my local repo anyway I'll take a peek. [22:15:21] I cannot get it to work at all, I sometimes get an overcurrent transient that pops the CSM LM PWR breakers, and with a debug script watching my heaters in the LM, they dont turn on unless that switch is flipped to reset [22:16:06] My first clue was the systems test meter not showing anything, and I thought that was working so I started looking to see if I had power at all and I dont, my LM batteries are slightly drained and none of my heaters are running on CSM PWR [22:24:00] Just looking through the commit history. CSM-LM current measurement wasn't added until Jan 12th. [22:26:31] Niklas said it was working, said it could possibly be a bug from moving stuff to pre step [22:27:11] My repo is still back in early January. I'll test if it works there. [22:27:27] Also check and see if you can do the following: [22:28:08] Eject the LM, start CSM pwr to the lm, reset/off csm lm pwer, and go into the LM and try to turn on the batteries after the disp and des eca cont breakers are closed [22:28:19] Right now we have an issue where that only works after a save and reload [22:29:01] Err, Orbiter Beta. I forgot to install DX9 when I set it up. Sec [22:37:11] rcflyinghokie: What version of DX9 is current? Codeplex has shutdown and the new site has multiple options. [22:37:26] Let me look and see what I have in [22:38:15] https://www.dropbox.com/s/c475j3rgj651f9v/D3D9ClientBeta25.3-forBETA%20r70%28r908%29.zip?dl=0 [22:38:27] Pretty sure that is it [22:39:40] Okay, looks like there is a later release then at that site (r914) I'll take that one. [22:41:26] Oh interesting [22:43:22] Where did you find it? [22:43:50] https://www.orbiter-forum.com/showthread.php?t=18431 [22:43:59] Has a link to https://www.tuttovola.org/index.php?PHPSESSID=hl0clhtrm2tli3dscnh25b8ts3&action=downloads;cat=64 [22:44:40] Having some issues though. Earth is now a giant sea. There is no land. [22:46:27] Oh that happens to me [22:46:31] It takes some time [22:46:43] It is weird [22:46:54] It eventually "recedes" and reveals the cape [22:53:55] Oh hey now. Hit an assertion. [22:56:50] What? [22:57:09] Orbiter crashed due to some assertion, [22:57:25] Maybe it doesnt like that DX client? [22:57:51] In isatty. Some Microsoft function called deeply nested in LEM::Init [22:58:10] Retrying fixed it. *shrug* [22:59:08] Interesting [22:59:17] You also probably have old scn's [22:59:38] A lot has been changed in the CSM and LM systems that save in the scn [23:01:25] Hmm the assertion hits fails again when I load a PDI scn. [23:01:49] Want to try one of my scns? [23:02:02] It might be an issue of stuff saved in old scns not in play anymore [23:02:10] My source is still old so that might break even more. [23:02:16] Oh thats right [23:02:21] You are trying an old source [23:27:47] Looks like I don't have my scenario's with a docked stack anymore. [23:29:53] I have some older ones [23:30:00] I think they should work [23:31:08] I'll update and debug from there. [23:31:22] This is from october, so before the major ecs changes [23:31:23] https://www.dropbox.com/s/n5cq1dbzhve4noo/Apollo%2011%20AGS%20Testing.scn?dl=0 [23:31:31] I think thats a stack in lunar orbit [23:32:13] I do have Apollo 9 in orbit. I just need to do TP&D. [23:32:45] That might be better [23:32:48] Fresh LM [23:36:26] I'll do that tomorrow though. Otherwise I'll be sitting here running checklists until 2AM. :P [23:37:07] .in 12h You should really update your HTTPS certificate. [23:39:54] Alright. I'll be back tomorrow. [23:40:39] Take care [11:37:47] I agree [13:22:36] Thanks Guenter. [13:24:34] hey [13:24:54] hey Alex [13:25:00] Hey [13:25:06] and Thymo [13:25:21] I'm changing the RTCC to not ask for the thrust parameters from the Orbiter API [13:25:53] was just working on the Apollo 10 MCC and it used the S-IVB thrust for the TLI+90 abort calculation [13:26:00] so I have to change that anyway [13:26:46] yeah, a good solution in the long run I think [13:27:37] if we use mission specific thrust and ISP values then the MCC/RTCC should have them separately saved in the launch scenario [13:27:42] as would the real RTCC [13:28:03] there might have been an update with the actual performance during the flight [13:28:26] but for the most part they just have the thrust parameters stored preflight [13:34:15] I guess that will work to with say trying to calculate the evasive maneuver before LM ejection from the SIVB on Apollo 11 [13:35:13] or before CSM separation rather [13:35:55] yes, although both thrust parameters and mass have to be right for that [13:36:17] mass is also from the Orbiter API usually [13:36:22] as well as the mass of a docked vessel [13:36:52] ah, right [13:37:32] and with this change now of course, all the saturn main engines can be changed to user defined [13:37:59] I wonder if anything else tries to access default engines [13:39:00] probably a few more things [13:42:26] I've been testing with all my engines set to user-defined on my local copy and so far so good. I've temporarily made a "dummy" engine on the SIVB, which is set to default, but has no fuel, just to keep RTCC MFD happy [13:43:19] i will search through all our code, if anything is accessing the Orbiter defined engines (main and hover) [13:44:47] still will be a lot [13:45:07] this is not a thing that can be solved in the next few days [13:45:25] you might be getting good results, but I am certain in some mission phase it still leads to bad issues [13:47:36] yeah, fair enough :) No rush need for this [13:59:12] I'm already deleting most of the THGROUP_MAIN and THGROUP_HOVER with this RTCC change for the TLI+90 PAD [13:59:37] but not all of them [13:59:47] S-IVB burn simulation will have to be handled separately [14:02:32] I only noticed the issue for the TLI+90 because I had the impulsive TIG fixed at 4 hours and the non-impulsive TIG was 3:59ish [14:02:45] the Maneuver PAD did the calculation right, burn time was close to 8 minutes [14:03:33] now I get nearly the same TIG as during the actual mission [14:19:20] awesome [14:31:07] can the RTCC MFD do that calculation, before TLI? [14:31:29] I guess it would need to get the TLI data from the LVDC, 1st [14:32:16] which calculation? [14:32:26] TLI+90 [14:32:41] no, the MFD can't do that right now [14:33:06] difficult to implement [14:33:40] and even the RTCC for the MCC doesn't do it very well. The post TLI state vector from the TLI simulation that the RTCC does is not perfect [14:33:41] yeah, not too important as we can always make the calculation after TLI [14:33:57] one of the few MCC only features of the RTCC right now [14:34:15] PADs have all calculated right now, so on to TLI [14:34:30] nice [14:34:52] of course I still need to do the right TLI simulation with the PU shift [14:34:59] burn time is still off [14:35:10] I think those are the only presettings I did not test yet [14:35:43] those are the only presettings that I tested [14:36:06] haha [14:36:20] we got it covered then [14:36:24] yep [14:36:27] it worked ok [14:39:43] I did a test yesterday with only on-time launch, 1st opportunity presettings (Apollo 13). I wanted to see if I can fly a second opportunity with a 7-parameter update with RTCC MFD, worked very well [14:41:51] After TLI, I added 1:30 to the pericynthion time, landing time (for the extra orbit). So that all worked good too with no other changes to mission constants [14:42:55] good to know [14:43:18] That mission had a fixed TLC time I think so I guess I would of needed a clock update [14:43:35] I'm not sure [14:44:00] I think I remember reading some things about Apollo 14 requiring flexible flight planning [14:44:08] yeah [14:44:21] more flexible than previous missions [14:44:42] mostly because the launch day wasn't really clear due to the CSM and other changes [14:45:00] So on those missions, you subtract the extra orbit (or whatever delay) to maintain the same TOA [14:45:06] during that time they came up with the concept of just sticking to the flight plan and changing the mission time [14:45:56] so I'm not sure if there would have been a clock update on 13 [14:46:32] right [14:47:22] would have required a lot of flight plan changes [14:49:11] and I guess a 2nd opportunity TLI is not the same as a pre-launch delay as it doesn't affect the MET start time [14:50:23] yep [14:51:25] so launch on time, 2nd TLI opportunity, Apollo 14 and later. That wouldn't require a clock update either, because both in MET and GMT the arrival time at the Moon is the same, right? [14:51:34] yes [14:52:15] and that would all work right in NASSP to I think [14:54:28] Apollo 8, 10-13, the peri arrival time is automatically adjusted forward 1:30 or the extra earth orbit [14:55:39] oh, did you ever figure out the CTD you had after insertion? [14:56:03] hmm I think I did [14:56:41] I got in the bad habit of waiting until 5 min before launch before pushing in the CMC breakers [14:56:50] that way I could time accel 100x until then [14:57:13] That may or may not be it, but it seem to only happen when I did that [14:58:08] hmm, interesting [14:58:20] i'll have to test more on that [14:58:54] it seemed to be something at 18-19 mins into the flight. it would not happen if I stayed at 1x through that time [14:59:51] but if I time acceled through about 18 minutes, I got the CTD. If I waited until say 20 mins, then time accel, no problem. [15:00:19] Also I sometimes get weird fps dropping [15:08:44] always fun watching the S-IVB maneuver to the sep attitude, outside view, global frame camera track [15:16:44] nice [15:32:53] ok, now I have to fix the evasive maneuver [15:36:47] Good morning [15:36:53] hey [15:37:56] hey Ryan [15:38:16] Did you get my message, Niklas? [15:38:18] I'm testing what I did with the Apollo 10 MCC so far and when I have finished that I'll dive deep into all our LM EPS issues [15:38:38] it's a few things by now [15:38:39] Great [15:38:43] CSM to LM, ECA etc. [15:38:51] "double volume,isol=0;" [15:38:53] Yes [15:38:57] I didn't understand your issue with this [15:39:12] that's the same as writing [15:39:14] double volume; [15:39:18] double isol = 0; [15:39:27] Ohh [15:39:37] I thought iso was supposed to be its own line [15:39:43] I see [15:39:54] nah, you have a few option with that in C++ [15:40:06] I was looking into tank isolation more last nigh and that caught my eye [15:40:09] But that makes sense [15:42:25] Well time to get Eagle on the moon and keep testing this ECS [15:42:57] time to get Snoopy at least TO the moon [15:43:26] remember the LR issue on Apollo 10? [15:43:35] that it basically returned nonsense to the LGC [15:43:41] or the LGC couldn't deal with it [15:43:58] I wonder if the flag causing the 522 alarms could be responsible for it [15:44:26] I'm sure we use a similar procedure on 10 as we did on 11 [15:45:06] so if the LR is in a different position than the LGC thinks [15:45:16] and there maybe is no check for that in Luminary069 [15:45:32] well, we can try to figure it out again when I get there with the MCC [15:47:13] Interesting [15:47:33] I never thought about that connection [15:47:52] just a theory [15:48:01] could be the padload, could be a procedure [15:49:30] Hmm I keep getting tracker lights when trying this first undocked RR test [15:49:59] And 1210 alarms [15:51:56] where is that in the procedures? [15:52:07] The test? [15:52:29] yes [15:52:44] Its actually a manual lock on with V63 not a test, bad phrasing on my part [15:52:56] But V63 is generating the alarms [15:53:31] And I cannot seem to be able to drive the RR using V41 N72 [15:53:53] LM Timeline Book? [15:54:00] just before the flag reset? [15:54:42] no [15:56:51] After sep [15:58:12] so all you did there was V63? [15:58:15] no P20 [15:58:18] Yeah [15:58:24] But a V56 just fixed it [15:58:38] I am pretty sure I didnt go into P20 in the LM, only the CM [15:58:59] V56 fixed it, that's really weird [15:59:43] must be more flag salad [15:59:50] now we need the activation checklist :D [16:00:04] Yeah seriously [16:00:42] If P20 was running then that explains the 1210 [16:01:09] V56 indeed does a bunch of stuff with flags [16:01:23] indy91, are you going to try and land Snoopy? :D [16:01:31] I have already done that [16:01:40] well [16:01:45] iirc P63 worked great [16:01:51] and P64 not so much [16:02:08] P71 also worked fine [16:04:09] rcflyinghokie, P20 or P25 don't have to be running, but maybe it's just another flag being wrong, one that gets reset by V56 [16:04:29] Could be the landing radar stuff done right before [16:05:34] maybe you forgot a V34 or so [16:06:37] ok, issue with the evasive Maneuver PAD solved [16:06:52] the function asking the mass from a docked vessel now checks if the docked vessel is a S-IVB [16:07:06] if yes, it call a payload mass function I added [16:07:41] and that's something the S-IVB always need to keep track off, for its own mass [16:23:54] Hmm I still have 2 names in here [16:24:26] not even 3, weak [16:26:46] Haha [16:27:10] There [16:27:26] Ok lets see how the flag salad came to be [16:32:25] Hmm so the V63 in the timeline just says V63 [16:32:31] It never says to PRO or anything [16:32:36] yes [16:32:52] Is that implicit that you do or omitted by design [16:33:03] you shouldn't do that there I think [16:33:18] a change for the Apollo 10 checklist, there was no uplink for the evasive maneuver [16:33:19] So leave it on the F 4 12 [16:33:31] Ok [16:33:32] I guess [16:33:48] I will see if that solves the flag problem [16:33:49] you first have to input the option code in V63, right? [16:33:53] No [16:33:56] It just says V63 [16:34:00] Thats my question [16:34:23] and my question is about V63 as well [16:34:32] is that the first thing that appears in V63? [16:34:52] I was too lazy looking it up, haha [16:35:07] Yes [16:35:12] Sorry misread [16:35:19] With 4 and 1 in R1 and 2 [16:35:41] well, which option did you use? [16:35:45] LR or RR? [16:35:54] but I think both are wrong [16:36:26] if the procedure doesn't say which one, then you should stay in F 04 12 [16:37:39] Yeah thats what I was thinking [16:37:50] but it causes a prog alarm when I switch to slew for a manual lock on [16:38:57] which one? [16:39:20] 1210 [16:40:17] Hm it didnt this time [16:40:30] which option code did you use last time? [16:40:38] option 1 [16:40:47] This time I am staying in F 04 12 [16:40:54] No alarm [16:41:12] I guess it wants me to lock on first [16:41:18] from the code: [16:41:20] "VB63 SAMPLE RADAR ONCE PER SECOND" [16:41:29] so that's why you start V63 [16:41:34] Ah [16:41:41] because then the LGC talks to the radar(s) [16:42:29] and the very first line of code in V63 (R04) is also fun [16:42:34] TC RDRUSECK # TRY TO AVOID THE 1210. [16:42:41] Haha [16:42:48] Well there ya go [16:43:16] looks like a lot of interesting things already happen in V63 without entering an option code [16:43:29] so that's the right procedure then [16:43:30] No wonder it's left there [16:43:44] Yeah it works fine, I incorrectly assumed pressing on with the normal V63 rdr stuff [16:46:10] not always easy to tell if a procedure is actually 100% step by step or not [16:46:20] Right [16:46:26] There are a few implicit steps [16:46:41] But that one seems to be verbatim [16:47:38] Let me know if there are any other Apollo 10 Checklist/MCC conflicts I will fix them on the fly [16:47:50] I took care of the uplink leaving it just copy the pad [16:48:11] yeah, that is done before LM ejection [16:48:30] and the calculation will now use the right LM mass, even on the RTCC MFD [16:51:04] Great that was a pain before [17:08:08] Hmm [17:08:15] I got a 1706 calling P40 [17:08:30] But I certainly am not staged [17:09:13] Ah dap load [17:20:23] So far everything has worked well with this timeline [17:21:22] water qty light comes on every time I load though :P [17:22:03] But so far the ECS looks good as well, heaters look good (other than the quads which arent implemented yet) [17:22:44] And even the o2 consumption is on par with how much was expected around DOI [17:50:45] This is great even the angles in the timeline are perfect for say a P52 [17:50:51] Within a degree [17:54:02] of course they are :D [17:54:40] the REFSMMAT will also be almost exactly identical to the real mission [17:54:42] that helps [17:59:42] It's been a bit since I have done a landing without an abort test of some sort [18:00:56] What are the keyboard commands for doing ROD commands and LPD commands? [18:01:48] LPD commands are simply pitch and roll on the ACA [18:02:03] works on keyboard and joystick [18:02:22] and ROD is [18:02:36] researches how a QWERTY keyboard works. [18:02:46] plus and equals [18:02:52] no [18:03:15] minus and equals [18:03:31] not on the numpad [18:03:31] on the normal keyboard, not numpad [18:03:33] ok [18:03:35] thanks [18:03:48] - is down i assume? [18:03:51] minus is "DescendMinus", = is "DescendPlus" [18:04:11] Ok so minus decreases the ROD [18:04:18] yes [18:04:23] so your first input will probably be = [18:04:32] so make the descent rate smaller [18:04:41] add 1 ft/s to your altitude rate [18:04:50] I think :D [18:05:21] the reaction is quick, easily to see on the tape meter [18:06:14] I will experiment I have really not done too many manual landings yet honestly [18:07:08] well, "manual" [18:07:12] you mean ROD mode [18:07:13] P66 [18:07:17] not P67, right? [18:08:11] P67 is with manual throttle [18:12:55] back when the throttle oscillations actually caused us trouble landing with P66 was quite a challenge, because you couldn't judge your targeted descent rate very well. [18:13:02] which is really important for the ROD mode [18:13:26] Yes [18:13:31] ROD mode [18:13:37] but now, in any mission, it works quite well. Takes a bit of practice of course. [18:13:42] Yeah haha [18:13:49] Oh can I make a PDI page request? [18:13:57] of course [18:14:01] TLAND in AGS time (DEDA 254) [18:15:05] Would fit nicely between DEDA 231 and the TLAND already there :) [18:15:28] where would the astronauts write that down? I don't see it in the PAD form [18:15:40] in the timeline book? [18:15:58] Its in the timeline book yeah [18:16:07] Has a preprinted one in there [18:16:28] Along with putting the RLS into 240 [18:16:38] I see [18:16:48] yeah, that TLAND is the time tag for that liftoff state vector [18:17:10] was that value updated? [18:17:23] I mean my TLAND is different than the actual from the mission [18:17:44] right [18:18:00] About 7 minutes difference [18:18:10] I would think that would be significant [18:19:39] But I dont think it was changed on the actual flight during the flight [18:19:57] But our padloaded tland is always different from actual from my experience with this mission [18:22:42] But I see your point it isnt in the PAD page [18:23:09] Maybe put it in the DOI page where the uplink for a new TLAND is [18:24:18] yeah, I'll certainly add it somewhere [18:24:29] Thanks [18:24:55] Are you adding DEDA entries to MCC? [18:25:37] I'm adding all the PADs [18:25:48] Perfect [18:26:00] Ok PDI time [18:26:02] and whatever else was given to the astronauts [18:28:37] I look forward to trying those [18:34:17] yeah, I am also going to add all the abort PADs that we don't have yet [18:34:52] So I left my RR in auto track per the timeline I am curious to see if I get any alarms [18:35:10] Or was it slew that caused the problems [18:35:57] slew I think [18:36:10] but we can't get the 1201/1202 alarms yet [18:36:20] we don't simulate that RR issue [18:37:15] we can fairly easily simulate it once the big yaAGC input/output pulses update is implemented in NASSP [18:39:18] Ah ok [18:39:23] I just left it per the timeline in auto [18:39:35] I just made my first ROD landing [18:39:45] However I have continuous dust around the LM [18:39:58] Ah there it goes [18:40:06] I dont remember that fine dust [18:40:21] Alex added that [18:40:25] Very nice [18:41:56] makes the landing a bit more immersive, doesn't it [18:44:20] oh and wait until you see what happens at staging [18:57:15] I look forward to it indeed [18:57:26] ECS report, everything is still ship shape after landing [18:57:49] cabin 68 suit 60 all glycol pressures and temps good [18:57:58] nice [18:57:59] lr rr and sbd temps good [18:58:02] great [18:58:09] time for a small step then [18:58:17] The one thing I had not tested was the LR operational heat [18:58:30] But at landing it is just above 150 [18:58:38] still have to open the door though [18:58:44] Designed to work between 0 and 185 [18:58:56] Haha yeah I am going to test and maybe tweak depress as well [19:01:18] But same with pressurization, that last little bit of pressure/mass to transfer takes forever [19:02:08] I have had a few random ctds with the LM [19:02:16] Happen when I switch panels fast but not all the time [19:02:44] Unfortunatly since I cannot debug properly and have no forsight to attach the process, its hard to figure out [19:04:19] I recently had a CTD when switching panels in the LM. Debug said it was the MFD's [19:04:36] https://www.dropbox.com/s/ac5cl549d22v4b0/CTD_Feb1.png?dl=0 [19:05:10] I cant wait to wipe my computer next week haha [19:05:16] Its been far too long [19:05:28] A while ago we had change an outdated function for the MFD's in the LM...thought that had fixed it, but guess not [19:07:15] Yeah sounds similar to my behavior [19:24:29] indy91, if one presses the CM separation from the SIVB stage, would the CM just separate from it with the rest of the SIVB/SM staying together? Right now if you do that, the CM separates, but the SIVB doors open exposing the LM and the SM just disappears [19:25:18] very non-nominal thing to do (flip the CM/SM switches while still on the SIVB) [19:27:05] If you do that from the SII stage or full stack config, a new vehicle is spawned with the entire stage, minus CM. But we don't have a model for the SIVB with only a CM on it... [19:27:39] SIVB with only SM on it* [19:37:19]