[21:42:43] NASSP Logging has been started by thymo [21:45:25] hehehe it might take a bit [21:49:15] the circuit number assignments match up with the core numbers [21:49:33] which... have nothing to do with the erasable addresses being selected [21:55:03] Okay, time to watch some The Orville. Enough Java for one day. [22:03:07] any java at all is too much java for one day :P [22:06:34] .tell indy91, I think that number is really low (10 J/s) [23:08:43] Liam Neeson guest starred in this episode. Not really used to seeing him play a minor role with just a handful of lines. [10:17:54] Hey [10:29:15] morning [10:45:12] did a bit of MiG-21 flying this morning [10:45:23] landing is not as bad as I thought [10:47:01] probably a different story with a more heavy configuration [11:28:07] good morning [11:28:22] hey [11:29:32] really distracted by fsx [11:30:41] how is 9 going? [11:31:53] still working on some calculations [12:11:28] Good morning [12:13:10] hey [12:15:35] So to what I asked yesterday, 10 J/s is what NASSP uses for a person's heat? [12:16:23] I think so, yes [12:16:53] It just seems really small [12:17:22] https://github.com/dseagrav/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_sys/PanelSDK/Internals/Hsystems.cpp#L1241 [12:17:36] that's a lot of Joule over the course of a mission though [12:18:00] Well yes [12:20:03] no idea what a realistic values is [12:20:53] Well I am using some EMU values for minimum heat as a reference now [12:22:05] Some minimum heat loads for the o2 and liquid transport loops in the EMU are 140 and 250 BTU/hr [12:22:26] 1 BTU = 1055 J [12:23:14] so 41 to 73 J/s [12:24:08] Yeah those are just minimum values though [12:24:50] Found a text from cornell about this and they say that the average human at rest generates 356 BTU/hr [12:25:17] being in zero gravity is a special kind of rest [12:25:29] so it might be lower. or not. [12:25:32] Yeah I know I am trying to find some sort of aeromedical reference [12:25:52] But that 356 does correlate with those minimum heat loads in the EMU [12:26:05] Where is it in the code I might play with it [12:26:07] right [12:26:16] https://github.com/dseagrav/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_sys/PanelSDK/Internals/Hsystems.cpp#L1241 [12:26:20] Because my suit temps are about 18 degrees F [12:26:52] Thanks [12:59:28] I made slow progress with the general purpose maneuver processor, but not much more to do now [12:59:55] I have no problem pushing experimental features for the RTCC MFD, but the previous version of the GMP was already used for the Apollo 7 and 9 MCC [12:59:58] Oh excellent [13:00:09] so I have to figure out those maneuver calculations properly to not break the MCC [13:07:05] Ugh I still get a cabin temp increase in time accel >10 [13:07:24] Its a result of the pressure increases [13:43:43] The clock sync with the CM works so well btw [13:45:32] great [13:46:21] it just was a sudden idea when I came across that sync ENTR press in the checklists again, haha [13:46:55] same procedure could be used for the docked alignment [13:47:01] Yeah [13:59:18] For the AGS RATE CMD portion of the cold fire, is it actually supposed to fire the jets? [13:59:31] I am assuming yes [14:01:41] And also my weights for the CM/LM on my first DAP load are a bit different than the padloads [14:02:14] 1300 lbs difference for the LM and 6300 lbs difference for the CM [14:04:02] have to check those [14:04:11] RCS has primary and secondary coils [14:04:21] primary need the QUAD TCA circuit breakers to be in [14:04:33] So even though its a cold fire [14:04:40] secondary need the ATT DIR CONT circuit breaker in [14:04:40] It is firing using AGS pulse in the sec coils? [14:04:53] Yes it was put in before it [14:04:56] pulse is only on the primary coils [14:05:33] so during the first procedure, where you advanced the ACA to the soft stop the RCS wouldn't fire [14:06:28] so, I don't think the RCS thrusters would fire during any of the cold fire procedures [14:07:12] Oh never mind, it was cut off by the MFD, its "AGS RATE CMD (Cold Fire) 4 JET SEC COIL (Hot Fire) [14:07:39] yep [14:07:44] second part of it is hot fire [14:07:56] and because you use hardover, the RCS will fire [14:08:33] I guess the cold fire procedures send RCS fire commands [14:09:06] but the thrust valves aren't actually opened [14:09:08] thruster* [14:10:44] I guess the activation procedures I used kind of blend the cold and hot fire [14:10:55] Where in the 9 FP, there is a cold fire and hot fire section [14:12:56] everything in that first activation is more spread out [14:13:25] Yeah i remember we talked about that before, separating them into cold and hot fire procedures [14:15:39] I think you had forgotten a part of the procedure in the Apollo 10 checklist [14:15:54] and then I was like "wait, the RCS should kind of fire now" [14:22:35] Yeah because it was missing switch/breaker positions [14:35:23] So why do I get a clock update during the docked DPS uplink? [14:36:15] Hmm also the computer is stalled after the SV updates [14:36:22] I had this problem before [14:37:45] I think it's the empty CM SV slot [14:39:33] I added the clock update before I came up with the new method [14:39:50] will rework that a bit, Apollo 10 is also using it I think [14:40:21] For the first SV uplink to 10, did the MCC uplink a SV in both slots? [14:40:26] not sure [14:40:28] I don't remember the computer stalling [14:40:39] but for Apollo 9 it's only the LM one [14:40:46] probably because the flight plan said so [14:40:48] But I remember this issue before, uploading a LM SV with nothing in the CM slot causes it to stall [14:40:49] but it's not good [14:41:06] If you uplink a CM SV first then a LM SV it works fine [14:41:57] hmm, let's see, what does P00 even do [14:43:21] aha [14:43:32] it only checks the CM state vector time tag [14:43:49] for state vector propagation in P00 [14:43:53] that explains it I guess [14:44:36] although [14:44:56] part of the padload should prevent this issue [14:45:50] How so [14:46:01] they are loading the max value into the CSM time [14:46:07] as part of the padload [14:46:18] "to inhibit initial P00 integration" [14:46:33] however, the LM SV uplink could screw that up somehow [14:46:47] so it might only work until the time of the uplink [14:47:12] The SV update will probably reset the integration timer yes. [14:47:20] that could be it, yeah [14:47:57] So how was/is this remedied? [14:48:37] uplinking a CSM state vector [14:48:39] first [14:48:43] or a V66 [14:49:09] A V66 first? [14:49:56] not before uplinking a LM state vector of course [14:50:04] I'll check the transcript [14:50:52] Ok [14:51:04] CC "And Gumdrop, you'll be receiving a vector in both slots" [14:51:10] Ah [14:51:11] uhh [14:51:13] Gumdrop [14:51:18] CM [14:51:34] yeah [14:51:35] Unless it's a mistake [14:51:47] Afterall its the first mission with 2 callsigns :P [14:52:05] haha [14:52:15] CC said P00 and accept before that [14:52:17] certainly CM [14:52:48] Oh yes [14:57:59] I don't know, only a LM state vector uplink is bad then [14:58:10] I'll probably include a V66 [14:58:59] It didnt help [14:59:04] It was locked up before the V66 [14:59:22] Unless doing it in the uplink before the P00 makes a difference [14:59:45] On the bright side, looking at the transcript my vehicle weights are very very close to actual [15:00:08] oh [15:00:23] hm [15:00:44] then I'd say the solution is to uplink a CSM state vector first, then the same one for the LM [15:00:53] Yeah that works [15:01:10] That has always been my workaround before MCC updates for a LM powerup [15:01:10] also, they usually would uplink a SV a bit into the future [15:01:32] but that doesn't help, if the CSM time tag is the relevant one and it gets reset to 0 or so [15:01:49] Yeah [15:02:11] I wonder if doing a V66 before a P00 would make a difference, or if it locks up right after the SV [15:03:45] Ah hah [15:04:02] So my "uplink" procedure has a P00 at the end of it [15:04:22] But if I uplink a LM SV, and then do a V66, it doesn't stall [15:04:29] Without the P00 [15:04:32] oh, I thought you were doing that already [15:04:35] No [15:04:45] I thought it was locking up right after the uplink, without V37E 00E [15:04:49] I did a V37 00 before the V66 because of the uplink procedure [15:04:52] that makes it a bit easier [15:05:02] I can omit that part [15:05:19] so uplinking a LM state vector and then uplinking a V66 should be ok? [15:05:28] if it is done together [15:05:33] Yeah [15:05:36] great [15:05:38] easy change [15:05:54] At least I tried it with the RTCC and it worked [15:06:12] And followed the V66 with a P00 and no stall [15:06:16] does anybody remember that dsky procedure for right before pdi for 11 [15:06:30] What do you mean [15:06:50] for the LR? [15:06:59] i think so [15:07:06] it should be in the Checklist MFD [15:07:09] V25 N07 110 40 0? [15:07:16] yes [15:07:28] and I'll delete the clock update uplink [15:07:35] are sure sure r3 isnt 10 i thought that was what alex told me [15:08:09] Yes [15:09:28] I thought that made it into the checklist somewhere [15:10:16] We found it in actual procedures I believe [15:10:25] flown Timeline Book [15:10:50] Yep and there it is in checklist MFD [15:10:59] DOI+10m [15:11:11] So it should be good [15:11:14] If you did that step [15:13:13] indy91, P00 is automatically selected after a P27, correct? [15:15:01] yes and no [15:15:14] I think it's not doing the same flag salad as V37E 00E does [15:15:27] P27 ends with a V33E [15:15:33] which is essentially PRO [15:15:53] it reverts to whatever program was running before [15:16:04] In Artemis, you can uplink while in P20 [15:16:07] Ok [15:16:12] so it would be P20->P27->P20 [15:16:23] I just am thinking I dont need a V37 00 at the end of my uplink procedure [15:16:34] That is probably the issue [15:18:52] Interesting, in the LM 11 AOH there is a value entered in the DEDA to prevent erroneous data going to it [15:19:12] Apollo 12 LM Activation doesn't do a V37E 00E [15:19:25] just updata link data, update goes in, updata link off [15:19:36] at least on the initial uplink [15:19:50] it doesn't hurt to do it afterwards [15:20:12] although that might be both SVs uplinked [15:20:44] The AOH doesnt specify doing it after either [15:21:37] Only before [15:21:47] I think that would solve the problem [15:22:09] Do you think the crew did a V66 after this initial uplink or it was transmitted? [15:23:38] And also, I thought cycling the CWEA breaker would clear TCA flags? [15:23:54] it usually does [15:24:01] but I have encountered some times, when it didn't [15:24:04] not sure wh [15:24:05] why [15:24:13] maybe the condition causing the flag persists? [15:24:15] Yeah its only clearing for of them [15:24:18] I'll have to debug that soem day [15:24:19] four [15:24:38] No I can reset the flag with the switch [15:32:26] so it worked with the switch, but not the CWEA breaker? [15:34:41] Correct [15:34:50] CWEA breaker cleared 4 out of 8 though [15:35:47] haha [15:35:48] If it helps, all 8 were red flags, cycling CWEA cleared the outboard 4 [15:35:57] The inner 4 stayed red [15:37:11] the reset in the LEM_CWEA::TurnOn() function looks right though [15:37:12] weird [15:41:17] ok, the switch does use a different method than the breaker to reset the flag [15:42:18] I have a vague idea what to change [15:44:16] the reset from the CWEA breaker isn't properly hooked up with the reset logic of the TCA [15:44:29] it doesn't reset the two thruster failure indications [15:44:50] Is that on the TCA side? [15:44:54] yeah [15:45:07] the TCA gets a reset signal from the SCEA [15:45:17] and that sets in motion some reset logic [15:45:25] which the CWEA isn't connected to [15:45:31] it only resets the flip-flop [15:46:00] I'll fix it soon [15:46:31] Ok [15:55:40] looks a bit confusing in the Systems Handbook [15:55:50] but then again, anything related to the CWEA reset bus is :D [15:59:54] Yeah no kidding! [16:01:26] I remember having about 10 versions of the schematics and Systems Handbook open to track that down [16:08:42] Hey [16:09:54] hey [16:10:11] what’s up? [16:10:47] still working on the general purpose maneuvers, haha [16:11:04] nice [16:11:24] adding the last calculation type, line-of-apsides shift [16:11:30] unfortunately not in the RTCC documents [16:12:21] any news on the RTCC docs from UHCL? [16:12:33] I haven't request any more [16:12:37] requested* [16:12:43] I got two AS-500 documents [16:13:32] Volume 1 of "Mission Planning" and Volume 1 of "Systems Integration" [16:13:38] ah right [16:13:44] I thought the Systems Integration volume would be the rest of Mission Planning [16:14:04] but it's just Volume 1 of a separate AS-500 part [16:14:16] I see [16:14:21] it's structured differently for AS-200, so I got a bit confused [16:14:45] there Volume 1 and 2 is Mission Planning, Volume 3 is Systems Integration [16:14:59] so the other way around for the logic of the structure [16:15:26] what I want to request next then is volume 2 of Mission Planning [16:17:46] hopefully has a lot of good TLMCC, RTE and LOI stuff [16:17:49] Hopefully some nice stuff to come [16:17:54] yeah [16:17:55] yeah [16:17:56] haha [16:18:12] lol [16:18:54] when I get home I’ll try and finish Apollo 15 [16:19:09] what needs some work still is user interface for the GMP [16:19:25] right now I have a solution similar to LTMFD [16:19:54] so instead of one button = one input like usually in the RTCC MFD you have a marker which you switch around to mark different inputs [16:19:55] general maneuver processor? [16:19:57] yep [16:20:38] although the acronym is used differently in some places [16:20:48] I have seen GMP, but also GPM Processor [16:20:55] general purpose maneuver [16:24:20] I guess that will make it easy to go through 50 different maneuvers [16:24:34] yeah [16:24:42] you cycle through maneuver type and maneuver point [16:25:09] Points are: Time, Longitude, equatorial crossing, apoapsis, periapsis, height, optimum [16:25:30] and there are lots of maneuver types and even more combinations of them [16:25:51] this was all part of the rendezvous support program [16:25:56] called ARRS or Monster [16:26:23] I guess Monster because it was a giant program with way too many features [16:26:32] Lol [16:26:48] it also had the DKI, concentric maneuver processor, two impulse maneuver processor [16:26:58] those are of course actual rendezvous programs, haha [16:27:41] Ah so they were part of the GMP in reality [16:28:21] other way around [16:28:43] GMP and all those were part of the Apollo Real-Time Rendezvous Support Program (ARRS) [16:28:49] Or part of the ARRS [16:29:27] yes [16:29:37] https://web.archive.org/web/20100519051814/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740075028_1974075028.pdf [16:29:46] here are all the displays and outputs of the ARRS [16:30:27] what I’m thinking of making is a “quick reference guide” for the RTCC mfd [16:30:55] It needs an updated one for certain [16:31:03] yeah [16:31:11] All the fun new toys within [16:31:13] manual hasn't been updated since the 7.0 release [16:31:46] I'll start on that when I am sure I don't want to do any major redesign for the 8.0 release anymore [16:32:03] Like not a manual that I would make, but a 1 or 2 page “cheat sheet” for it, to complement the manual [16:32:50] yeah, makes sense [16:33:18] With say for each maneuver, like say the aborts for instance, what Tig to use for PDI-0, No-PDI+12 [16:33:39] What TPI lighting to use, etc [16:33:46] ah right [16:33:51] so some default inputs [16:34:16] like the phase angle for the CDH point for the No PDI+12 maneuver, which I can never remember [16:34:31] Yeah [16:34:40] or for the tweak maneuver [16:36:39] Like for direct ascent, phase angle -1.7 [16:37:51] yeah [16:38:10] Not a tutorial of any sort, but just common inputs for each maneuver [16:39:42] When I was calculating the PDI-0 I was forgetting myself what TIG I was supposed to use even though I had practiced that one before lol [16:40:01] And that’s when I thought, I need a cheat sheet for this stuff [16:42:10] how to master the RTCC in 10 easy steps [16:43:06] piece of cake [16:48:19] morning! [16:49:07] hey [16:49:43] what's up? [16:50:00] flew the MiG-21 a bit this morning [16:50:26] hardest part was taxiing to be honest [16:51:31] haha [16:57:49] Even in a real plane people have trouble with that [16:58:12] Gotta use those brakes [16:58:40] I just entered the docked DPS data into P30 and my Ha Hp are both -34413 [16:59:54] I had a bad SV [17:00:06] And the only one I put in the computer was the MCC uplink [17:02:42] weird [17:02:45] it worked for me [17:03:44] of course it's possible that I changed something afterwards [17:04:30] could it have been messed up by any of your V66 and P00 tests? [17:05:16] No after I resolved that I went back to before the uplink [17:05:39] And all I did was omit the V37 00 [17:05:59] And I did my own V66 after the uplink completed [17:06:16] I uplinked a new one manually and the SV looks right [17:06:31] I am going back to that point and I will check the SV after the uplink [17:10:42] the uplink looks good in the code, not sure what could cause this [17:11:37] but yeah, that -3441.3NM is the radius of the Earth [17:11:43] so your state vector was 0 [17:12:40] Not sure [17:12:47] Just did it again and I have a good V82 [17:13:10] Not sure what could have messed it up [17:13:27] I will press on and check it periodically [17:14:07] did you get a PAD with V42 gyro torquing angles yet? [17:14:36] hmm [17:14:47] CMC update for the state vectors is at 48:00 [17:14:52] LGC update at 48:10 [17:15:10] then 3 minutes later gyro torquing angles [17:15:20] but there is only that one uplink to the LGC at that time [17:15:27] so it can't have been the wrong one [17:16:40] Yeah [17:16:55] The only thing I did with the computer after was all the AGS set up [17:17:12] Involving a SV at least [17:17:33] But as I said I am checking now [17:17:55] Probably just a goof up on my part somewhere, but I need to verify it wasnt a procedural issue [17:18:47] if the uplink didn't happen you also wouldn't have a REFSMMAT [17:21:33] Right [17:29:24] Haha this time the CWEA reset reset all but 2 TCA flags [17:36:56] there might a slighty hacky, but easy way to fix that bug [17:37:08] just let the CWEA reset the TCA directly, not just the flip flop [17:37:17] so also the thruster failure timer and counter [17:37:45] that would only require a bit of code changes [17:38:03] hmm [17:38:09] no, I don't like it, too hacky :D [17:49:21] https://www.orbiter-forum.com/showthread.php?t=39635 [17:49:24] weird issue [17:49:29] DAP padload is all broken [17:50:12] steering gains have somehow moved by 4 memory locations [17:50:24] and the other DAP related things don't make any sense [17:50:41] I wonder if switching between NASSP versions could cause this [17:50:45] 7.0 uses Comanche055 [17:50:54] 8.0 a modified Comanche055 for Apollo 10 [17:53:07] those modifications were only to some fixed constants though, right? [17:53:22] yeah [17:53:27] but it's a different binary [17:53:57] still, shouldn't move erasable things around [17:54:00] maybe CMC power loss at the wrong time? [17:55:01] but how could those gains move from 3014/3015 to 3010/3011 [17:55:04] that seems so weird [17:55:13] yeah, that is super weird [17:55:29] That is very strange [17:55:33] at least it's the same values [17:55:55] not the final Block 2 AGC design :D [17:55:56] Any idea how old the scenario is? [17:57:02] not the 7.0 Apollo 10 launch scenario [17:57:14] that had the negative value TEPHEM we had to use [17:59:37] the wrong addresses have to be the AGC copy and pasting memory in a bad, bad way [18:02:19] yeah, I just compared Comanche055.bin and Comanche055NBY69.bin [18:02:36] only differences are in the star tables and some constants (COSI, SINI, WEARTH, etc.) [18:03:06] why would the AGC ever copy and paste memory though? [18:03:08] yep, constants copied over from the AGC versions for the 68/69 coordinate system [18:03:44] oh, I just meant, AGC executing random instructions [18:04:01] ah, not on purpose, haha [18:05:11] hmm, ok, not all the erasable is bad [18:05:36] EMEM3032 and follow is still good [18:06:20] EMEM3000 is good [18:06:31] everything in between is not the same as the padload anymore [18:06:33] but it should [18:08:33] hmm [18:08:48] maybe it could be caused by some DAP issue [18:08:52] some wrong procedure [18:12:26] I am willing to bet its the DAP deadband/PTC procedures [18:12:31] doing those incorrectly [18:12:52] oh [18:12:58] I like that theory [18:13:48] so the DAP might have been broken with the first PTC [18:16:38] you have done those procedures throughout your Apollo 10 mission without any issues? [18:19:00] Yeah [18:19:04] They work perfectly [18:19:16] I let auto checklist do them as well to make sure [18:19:55] so it's not our fault, haha [18:20:02] if the theory is right [18:20:10] Thats what I am thinking, if I didnt goof the procedures [18:20:25] But I worked through them quite a few times [18:21:40] Easy to make a mistake, though [18:21:54] yeah [18:22:06] these kind of procedures are not very user friendly [18:22:28] which is why I like Artemis so much, haha [18:41:34] Oh so my gyro torquing angles are not computed using LVLH I do not thing [18:41:53] The ones that I get from MCC, because Y is -90 [18:42:43] And my V42 from PAMFD using LVLH are 0 0 0 [18:44:59] LVLH REFSMMATs were used in CMC and LGC during the rendezvous [18:45:07] during the docked DPS burn they had identical REFSMMATs [18:45:17] the LVLH ones are different between CMC and LGC [18:45:48] Ohhh [18:46:04] Derp [18:46:15] it can be confusing, haha [18:46:25] and supporting different REFSMMATs in CMC and LGC is new [18:46:53] Yeah [18:46:55] the docked DPS burn simply used a preferred REFSMMAT in the LGC [18:46:56] My first time through it [18:46:59] and the CMC had the same [18:47:39] And I didn't read my own warning in the checklist MFD... [18:47:51] which warning is that? [18:48:46] "Change Alignment Reference REF (LVLH for Apollo 9 Rendezvous, Identical for all others) [18:48:47] " [18:48:57] haha [18:49:03] that warning is correct [18:49:24] does the PAMFD default to identical REFSMMAT? [18:49:32] Ye [18:49:33] Yes [18:49:38] good [18:51:39] Could that be why my P30 spit out bad data? [18:53:18] I don't think so. Deciding between those options only has to be done in the PAMFD [18:55:13] MCC should give you the right REFSMMAT and gyro torquing angles [18:59:03] does it not give the right gyro torquing angles? [19:06:12] No I mean when I had the "0" SV [19:06:28] No relation? [19:07:51] that should only be because of the 0 state vector, nothing else [19:08:08] hmm [19:08:14] in V82 at least [19:08:44] probably also in P30 [19:08:53] just the SV, not REFSMMAT or alignment [19:10:49] Ok [19:10:57] So somehow I messed up my SV in that situation [19:11:26] yeah, weird [19:11:36] easiest explanation would be that no SV uplink happened at all [19:12:25] Well for better or worse I could not duplicate it [19:13:17] did you see the numbers getting into the LGC on the DSKY? [19:13:40] I'm not sure, but there might be some MCC bug that breaks uplinks, if you switch vehicles during the uplinks [19:13:42] uplink* [19:15:22] I may have done that [19:15:27] I usually don't [19:15:36] But I certainly won't discount it! [19:17:37] Because I did everything over again still by the checklist and I have a good SV [19:17:44] So I don't think anything is wrong [19:17:54] Could have been a bad uplink or switching during etc [19:18:44] yeah, could be many things [19:19:47] current state vectors are on telemetry while in P00, so a smart flight controller can figure out that one quickly [19:23:32] AGS values are to the 1 not 0.1 for fps, correct? [19:23:47] yes [19:23:47] For LEO [19:23:49] Ok [19:23:59] I wonder if the maneuver pad needs to account for those [19:24:14] It gives them currently to the 0.1 [19:24:33] Unless that always mirrors the N86 values from the LGC [19:24:54] I wonder if Apollo 9 flew an AGS flight program that had 0.1 inputs [19:25:06] the Maneuver PAD in the flight plan has decimal points for the AGS DV [19:26:19] Ah good point [19:28:13] Yeah probably because its a N86 and that is supposed to agree with what the LGC computes [19:28:43] But I am thinking you are right and the FP for Spider's AGS probably was written, and not rescaled, for LEO [19:31:17] shouldn't be a problem for Mike or Thymo to write us a good Earth orbit FP :P [19:31:52] I imagine it wouldnt be too bad, just some scaling here and there ;) [19:32:04] hey hey [19:32:10] Hell we already did that work, just gotta move a decimal point right? [19:32:13] I have my hands full with AGC 602 :P [19:32:39] how hard can it be [19:33:51] do we know that Spider used FP5? [19:34:00] or could it have been an earlier one? [19:34:03] early one [19:34:07] FP5 was Apollo 10 [19:34:09] oh right [19:34:12] earlier* [19:34:28] which we basically know from the changelog in the FP6 manual [19:34:45] I think we "guessed" it was "FP4" [19:35:03] Possibly written explicitly for an earth mission [19:36:21] "FF6 was first assembled from an early version of FP5 which was identical to Flight Program 3, Revision A (deck ID=0005) with the exception that all computer variables which contained a length dimension in their units were scaled for lunar ranges." [19:37:07] so, it may actually be as easy as rescaling [19:37:34] Hmmm I am in my countdown for docked DPS, in P40, and I got a 1210 [19:38:28] Two routines using device at same time [19:38:38] P40 is up, and I have a V78 going [19:38:45] Happened shortly after that V78 [19:40:16] Cleared and didnt reoccur [19:42:07] I am still amazed at the stability of the docked DPS [19:42:14] No RCS firing at all [19:43:19] Until 2:30 small burst haha [19:44:25] Writing a custom FP? I wouldn't have a clue where to start. I'm totally unfamiliar with the AGS' architecture. [19:46:46] Should be just scaling internally [19:48:01] Instead of all the memory being rescaled [19:48:24] Of course I say that with a lot of naivety :P [19:50:00] Hmm indy91, might need a feature specific to the docked DPS burn [19:50:11] pressing PRO on both DSKY's [19:50:21] At the T-5s mark of P40 [19:50:43] Hard to get them both in the 5 second window, possible, but challenging [20:17:24] hah, there's a chapter on what the Soviets were up to in Ignition! [20:17:55] and the author still didn't know the names of any of their rockets (like the R-4 or Soyuz) and instead uses the NATO designations for all of them [20:18:05] Oh nice [20:18:56] er, R-7 I mean [20:19:05] I knew what you meant actually :) [20:21:37] lol [20:21:47] "In short, the Russians tend to be squares in their choice of propellants." [20:22:45] Did you ever watch the BBC documentary I think called "Space Race"? [20:23:30] yeah, that is a really good series [20:30:33] also Thymo, the AGS architecture is much more straightforward than the AGC's [20:30:51] and rescaling is probably just finding and changing some constants ;) [20:30:59] I imagined so. I just never have taken a look at it. [20:40:07] except, their fixed memory is weird [20:40:57] it's destructive-readout but they removed inhibit lines so the writeback will always restore the desired contents [20:41:20] which means that as part of startup the flight program has to read once from every fixed location to "prime" it [20:41:28] And you guys have all our memory addresses already scaled if it helps to reverse engineer :P [20:42:03] hehe, ask again in a few weeks [20:42:28] spacefest is only a week and a half away and I only have Tray B schematics prepared for modules B7 through B10, with B11 halfway there [20:43:19] and I at least need to finish getting B11 ready since that module is potted [20:44:37] I *think* I should be able to fully recreate its internals with careful probing, though [23:20:05] I'm off to bed. Night! [12:24:25] good morning [12:24:59] just got fs2crew for pmdg 737 so now i have another distraction [12:28:02] @indy91 very excited [13:12:08] Afternoon! [14:12:47] hey Niklas [14:13:31] finally back on my home pc, ill try and do some testing on that PGNS->AGS RR marks issue I was seeing [15:26:22] hey [15:39:37] hey Niklas [16:45:18] morning! [16:46:11] hey Mike [16:47:22] what's up? [16:48:33] still working on the same thing [16:48:54] you as well, but with the Spacefest deadline :D [16:49:09] hehe yeah [16:49:26] module B11 schematics are "complete" although certainly incorrect [16:49:34] hopefully I'll be able to rectify that [16:49:57] and I now have printed out all of the material I want to take [16:50:15] just over a week away :D [16:54:28] I have everything for Apollo 9 figured out with these maneuvers at least [16:54:39] Apollo 7 has a few tricky ones I still need to do [16:54:43] awesome [16:54:47] then just RTCC MFD user interface [16:55:03] picked up anything new from the AS-500 manual? [16:55:06] and then we have 50 new ways to change your orbit [16:55:12] haha wow [16:55:14] that is a lot of ways :D [16:55:32] yeah [16:55:45] that's the state of the general purpose maneuver processor as of Apollo 10 [16:56:12] the RTACF Operational Support Plan has a list [16:56:20] the one for Apollo 7 and 9 doesn't, unfortunately [16:56:25] boo [16:56:36] the AS-200 document still has a short list [16:56:39] about 30 [16:56:45] lots of combination maneuvers missing [16:56:55] e.g. it has node shift and circularization maneuver [16:57:05] but not node shift plus circ maneuver as one [16:57:20] that's what they must have added until Apollo 10 [16:58:09] and to your question, I've mostly picked up things for the Analytic Ephemeris Generator from the AS-500 documents [16:58:26] that seems to be the program used for short term trajectory propagation in the RTCC [16:58:37] fast, but not super accurate over longer periods of times [16:58:48] and only works in orbits with low eccentricity [16:59:00] the AS-500 documents also have equations for numerical integration [16:59:12] which certainly were used for translunar trajectory calculations [16:59:20] and lots of support routines for that [16:59:25] lunar+solar ephemerides [16:59:31] runge kutta methods [16:59:34] that kind of stuff [17:00:34] the Volume I of Mission Planning has some pieces of the puzzle. When I get Volume II I can put them together and hopefully get use out of both Volumes [17:01:21] awesome [17:01:32] when are you going to get volume 2? :D [17:01:38] in a bit, haha [17:01:52] and about the general purpose maneuvers, there also is the difference between RTCC and RTACF [17:02:43] in general the difference is: it's separate rooms in the basement of the MCC-H building [17:02:59] was it RTACF that housed the monster? [17:03:54] I think so [17:04:06] often the RTCC and RTACF had the same processors [17:04:18] RTCC being a bit more advanced with dynamic displays, whatever that means [17:04:42] but the RTACF had version 8.0 Alpha of a processor and the RTCC had 7.0 stable release [17:04:48] as an example [17:05:08] for Apollo 8 the RTACF could have supported the whole mission [17:05:08] hm, interesting [17:05:42] sometimes they were diverging in terms of software [17:06:30] even worse, the flight planning branch had their own set of software, which is also sometimes diverged [17:06:39] flight planning branch at MSC [17:06:59] I have references to that in some RTCC requirements documents [17:07:01] oh boy [17:07:03] haha [17:07:12] where they wanted to unify the software again [17:07:56] or at least compatible [17:08:00] not flight planning branch [17:08:07] Orbital Mission Analysis Branch [17:09:04] "Since the Gemini 6 mission, the two programs have slowly diverged because part of the RTCC DKI has been eliminated and because changes have been made to the OMAB program as a result of mission planning requests" [17:09:16] interesting version history, haha [17:09:34] this is about the Docking Initiation Processor, one of the rendezvous programs [17:10:15] our version of that should be fairly close to the late 1969 to end of progam version of the RTCC DKI [17:11:06] what's DKI? [17:16:30] Docking Initiation Processor [17:16:46] "DocKing Initiation" I guess, haha [17:18:23] haha [17:18:25] obviously :P [17:36:20] https://archive.org/details/apollolunarexcuracel_0 [17:36:27] looks like the page for Volume I has been created [17:36:43] not sure about the rest, this one was just easy to guess the URL of :P [17:38:55] progress [17:39:11] yeah [17:39:17] so maybe scanning in the next couple of days [18:37:53] and I hope we don't die of old age before the LM data book review is completed [18:40:35] our children will have died of old age before we get a scan of the Apollo 11 checklists from the Smithsonian [18:40:52] lol [19:07:50] .tell rcflyinghokie I found some data on the heat load of the crew. 1420 BTU/hr for the whole crew in Earth orbit. From Consumables Analysis and the CSM Data Book. [19:09:20] the LM Data Book would have better numbers for the LM crew in lunar orbit... [19:20:23] haha [19:20:40] yes, yes it would [19:31:49] I'm totally going to try this: https://forum.nasaspaceflight.com/index.php?topic=45900 [19:33:16] I still have to try the LOI as a docked DPS burn [19:33:42] wow, very interesting [19:34:06] probably eats a lot into the DV reserves [19:36:10] yeah, I'm surprised there was enough capability to do that [19:37:11] you can choose a lower energy TEI that takes 1 day longer, if needed [19:37:54] the DV you save with that isn't super much though [19:39:35] how much DV is normally left over at SM sep? [19:39:42] in the nominal case? [19:40:11] after TEI you mean, the nominal case is just RCS course corrections during TEC [19:40:24] 5-10% or so [19:40:39] which is a lot of DV with a near empty CSM [19:41:05] oh, so TEI is normally the last time the SPS is used? [19:41:13] yeah [19:41:20] I guess that makes sense [19:41:29] only very large deviations with TEI would require the SPS [19:41:34] for MCCs [19:58:19] I have to find the attitude control configuration for docked SPS burn with LM ascent stage active RCS [19:58:33] probably, LM maneuvers to burn attitude [19:58:59] and then TVC DAP only needs roll control [19:59:13] that can be done in att hold mode for the yaw axis in the LM [19:59:17] everything else off [19:59:31] back to att hold in the LM in all axis after cutoff [20:01:20] and you have to use the TTCA [20:10:05] use the TTCA from in the LM? [20:10:35] during an SPS burn? [20:10:38] exciting, lol [20:11:53] not during the burn, for attitude maneuvers [20:12:21] att hold can be done automatically [20:12:40] in all configurations [20:13:02] at least the PGNS can do that [20:14:10] and during the burn it would be pretty easy [20:14:18] att hold in the yaw axis [20:14:34] SPS gimballing for pitch and yaw (in CSM terms) [20:16:03] LM Contingency Checklist doesn't have anything on SPS burns though [20:16:07] might be in the CSM one [21:22:45] night! [14:46:23] morning [14:46:43] hey [15:02:10] finally pushed the general purpose maneuver update [15:03:38] good morning [15:04:04] hey [15:12:35] hey [15:12:43] indy91, awesome, ill test right away [15:12:56] user interface probably can be improved [15:13:11] some calculations aren't compensating fully for non-spherical gravity [15:13:18] other than that, it's all in place [15:25:24] I can probably make good use of the GPM with the LOPC-2, shape burn which are comping up next [15:28:19] the GPM plane change is just a velocity vector rotation though, not targeting any landing site [15:29:33] ah right [15:30:25] the maneuvers are all self contained, pure orbit adjustments [15:31:31] I will add a few more displays for the page, like apoapsis and periapsis location [15:39:29] one thing that can now be easily done is the CSM maneuver for the time critical LM ascent [15:39:58] where you want to perform the maneuver lowering the perilune at a specific longitude [16:48:34] morning! [16:50:10] hey [16:51:15] what's up? [16:56:24] I can finally continue flying Apollo 9 [16:57:17] hey Mike [16:57:57] indy91, "no valid code" Does that mean that particular TYP/PNT combination will not work? [16:59:24] yes [17:01:17] the codes are from the RTCC and RTACF documentation [17:01:31] e.g. PCL means a plane change (PC) executed at a specified longitude (L) [17:03:00] hey Mike+++++++ [17:03:01] + [17:03:20] ++ [17:05:43] I don't understand your code language [17:05:51] lol [17:06:46] so as usual I'm the source of my own problems [17:07:20] "Hi Mike, Thanks for your efforts! We were not expecting these, and we are exploring adding them in. Will touch base before proceeding with the next foldouts." [17:07:48] they're currently figuring out if they can incorporate the stitched foldouts I made into ND-1021042 [17:07:54] right [17:07:55] so more scanning is on hold :D [17:08:00] hahaha [17:08:22] haha I had a keyboard malfunction [17:08:37] ++++ ++? [17:09:02] ++---++-+ [17:10:15] I had a coffee "accident" on my keyboard haha [17:11:49] I think it might cause a short circuit in my keyboard or something and made that strange message [17:11:53] oh no! [17:12:09] keyboards do get hyperactive in the presence of caffeine [17:12:19] thankfully I buy very cheap keyboards and I had a few spares :D [17:12:24] hahaha [17:12:33] we have to find a Windows workaround, so that the failed key doesn't cause a reboot [17:12:40] or something like that [17:14:00] I played a bit around with controlling the ascent stage + CSM from the LM [17:14:25] what you have to do is: ACA yaw for yaw, TTCA forward/backwards for pitch, TTCA left/right for roll [17:14:53] and for PGNS attitude hold, you have to use the docked DAP config [17:15:10] only problem is, that assumes a descent stage and the minimum weight input is 14700 lbs [17:15:20] while the ascent stage is quite a bit lighter [17:15:21] right [17:15:33] whats "wedge"? [17:15:50] you can compensate that with using a lower CSM mass to balance it out [17:15:57] wedge angle, that's the input for the plane change [17:16:06] basically how much the velocity vector gets rotated [17:16:10] ah [17:17:31] Apollo 14 LM Contingency Checklist says "consult MFSN" for the CSM mass for that configuration [17:17:33] great... [17:17:59] probably the mass that gets you the closest to the moments of inertia of your actual config [17:31:59] I could practice that right now, just docked Falcon back with Endeavour [17:32:36] I like the new GPM, having fun trying different burn solutions [17:34:12] I was trying it because of this: [17:34:12] https://forum.nasaspaceflight.com/index.php?topic=45900 [17:34:39] apparently there was a mission rule, that when you have 2 failed SM RCS quads, you keep the LM ascent stage for TEI [17:35:01] for attitude control before and during the burn [17:52:24] so for the CSM circ maneuver, lest say your initial orbit is 56x6, but you want to end up in 60x60, is there a way to do this? [17:52:44] landing site as altitude reference [17:52:45] The best I can get right now is 60x56 [17:52:51] and then what you want is circularization [17:52:54] ah [17:52:55] at a specified height [17:53:00] which is 60NM [17:54:56] hmm it doesn't seem to iterate at 60NM [17:55:22] does it not work at all? [17:55:26] it works if I put the height of the current orbits ApA of 56 NM, then it calculates a 56x56 [17:55:36] what happens if you use 60? [17:55:39] but if I put 60, nothing happens [17:55:59] hmm, it should find apoapsis for that case [17:56:05] I'll have check why it doesn't [17:59:06] hmm [17:59:10] it works for some cases [17:59:15] I took a pre-LOI-2 scenario [17:59:22] and used 50NM as the maneuver height [17:59:32] and it calculated a circ maneuver at perilune [18:00:15] ah [18:00:23] it has problems when the apolune is too low [18:01:41] I'll implement some fixes for that [18:04:14] also in some cases the Orbital Parameters solution side (right side) displays all nans after calculating [18:05:55] for example? [18:06:24] what were your inputs? [18:07:40] but I expect a bunch of issues, this was a pretty big update [18:07:43] expected* [18:09:02] its when I used HBT (ApA,Peri change/Time) [18:09:24] with certain GET inputs it gives nans [18:09:45] ok [18:09:45] but if I set it to 5 minutes before or after the GET that caused the nan, its fine [18:09:48] I'll check that [18:10:55] is the DV ok for that maneuver? [18:10:57] or not [18:11:22] if the DV is nan as well, then the parameters would of course be bad [18:13:40] the DV is not nan, but it did not calculate any new DV at all [18:14:20] ok, so even worse :D [18:35:38] yeah, there will be a bunch of bug fixes over the next time for the GMP [18:39:30] it looks very good for the 1st iteration of it though [18:39:39] looks like a very versatile tool [18:40:21] its nice that the RTCC MFD is looking more and more like an "RTCC simulator" [18:43:32] yeah, it's becoming more realistic [18:43:40] also thanks to actually finding more RTCC documentation [18:47:08] ok, the apolune issue is fixed, I think [18:47:11] now the issue with HBT [18:49:31] there is a suspicious arc cosine [18:49:59] probably a case where the desired apoapsis and periapsis can't be achieved [18:50:07] and then numerical precision strikes [18:50:13] acos(1.00000001) [18:50:16] and NaN [19:02:35] gotta go! Ill be back tomorrow [11:37:29] good morning [11:40:13] hey [11:40:42] have you played fsx? [11:41:15] yes [12:41:45] hey [12:42:57] Hey Alex [12:44:00] hey guys [13:15:53] indy91, any luck with getting the circ burn at the correct height? [13:16:07] yes [13:16:20] but you mean incorrect height, lol [13:16:23] and the nans [13:16:27] yeah lol [13:16:41] the NaNs were probably caused by a bad acos [13:16:48] although I haven't debugged it [13:16:56] but it's a educated guess [13:17:02] and that is fixed [13:17:39] the fix for the circ burn required a small change for a commonly used function [13:17:59] so there is a small possibility, that other things get broken by the fix [13:18:13] that function is a bit messy anyway [13:18:28] and my job is to find what is broken :p [13:18:32] yeah [13:18:37] I'll have a fix asap [13:18:44] fix pushed I mean [13:19:09] great [13:19:47] pushed [13:19:52] oh and can the LM deorbit burn be calculated with the GMP now? [13:19:55] just neede dto commit it [13:19:57] hmm [13:20:16] that is supposed to hit a specific point on the surface, right? [13:20:26] I think [13:21:05] can't be calculated then [13:23:48] not sure what was used for that calculation [13:38:25] So now the circ calculation works with 60 NM as an altitude. The resulting PeA and ApA is 56.86 x 56.86 [13:43:32] oh and I tried recreating the nans like it would do yesterday, but I cant so that does seem fixed [13:44:11] What input maneuver? [13:44:18] What's* [13:47:17] Oh is that just to manually see what a DV at a certain point in the orbit's orbital parameters would result? [16:29:13] AlexB_88, flight controller input [16:29:19] DV, pitch, yaw as inputs [16:29:27] and all the usual options for the maneuver point [16:31:17] ah thanks [16:42:16] hmm so Apollo 15 did not have a LOPC-2 burn actually [16:43:14] just a shape burn 1 orbit before TEI which seems to have just raised apolune to 78 NM [16:44:56] morning! [16:45:08] hey Mike [16:45:47] or rather... ++++ [16:45:50] :D [16:45:56] ++++++++++! [17:14:43] back later [17:31:01] hey Mike [17:33:48] hey [17:34:51] in exactly one week I will be boarding a plane :D [17:36:08] fun [17:36:27] what exactly will your booth have? [17:36:37] I'm not really sure, lol [17:36:53] it's a joint booth between me and Jimmie, and the guys making those 3D printed DSKYs [17:38:25] so you have DSKYs and an AGC [17:38:34] all you need is a CSM [21:25:31] thewonderidiot: So how's your Mig-21 flying? https://www.youtube.com/watch?v=k-xvVQtimrM [21:26:06] oh man lol [21:26:14] not that good :P [22:40:47] Another one for ya: https://www.youtube.com/watch?v=UtwH5ITzFGA&t=4s [23:17:56] night! [15:27:25] hey [15:59:14] hey Niklas [16:13:41] I am truing to understand this shape burn. It seems to be simply a 20 NM height maneuver that raises the apogee from 57.5 to 77.5 NM [16:13:48] I am trying* [16:14:28] is the maneuver even in the SCOT? [16:14:45] 20 NM increase should only be 26.6 fps DVX according to the RTCC MFD, but the flight plan has this burn with a VT of 64.2 FPS [16:14:57] nope [16:14:59] so a line of apsides shift as well [16:15:01] not in the SCOT [16:16:17] plus 0017.0; minus all zips, minus 0064.2 [16:16:33] so not just a height maneuver [16:16:46] I see line of apsides shift in the GPM [16:17:04] but there doesnt seem to be a combo with it and height maneuver [16:17:33] hmm, yeah [16:18:39] but I don't know what the objectives were for the burn anyway [16:19:32] I think there was something about it in the Apollo 16 SCOT [16:20:03] Apollo 15 SCOT has the subsatellite jettison during the CSM solo activities [16:22:10] oh wait [16:22:19] we have a bunch of RTCC documents for Apollo 15 [16:22:27] I've read about the shaping burn in there [16:25:45] from the 16 SCOT: "To place SC in an orbit so that, when the subsatellite is jettisoned at 218:02:08, at the ascending node on rev. 73, it will have a lunar orbit lifetime of at least 1 year." [16:25:56] pg 4-118 [16:26:12] the other Apollo 15 documents have the objectives [16:26:19] right [16:26:21] h_a 75 +/- 2NM [16:26:30] h_p 55 +/- 2NM [16:26:42] and longitude of perilune at 47°W [16:27:42] ah [16:27:47] I wanted to add displays for apoapsis and periapsis anyway [16:27:58] is that possible in the GPM? [16:28:21] pre mission target was: argument of perilune 90° [16:28:27] longitude of the ascending nodes 42° [16:28:59] so yeah, it would be a combination of line-of-apsides shift and targeting a 55x75 orbit [16:29:16] node* [16:29:28] the LAN is calculated inertially right now though [16:31:45] if you had proper a proper periapsis display you could calculate both line of apsides shift and the HA/HP separately [16:32:10] then add them together, and manually iterate on it with the manual input option [16:32:20] right [16:32:31] TIG might be from the optimum line-of-apsides rotation [16:33:38] it was close to perilune at least [16:36:17] if I splay with Shift Line-of-Apsides ROT option, it seems to change TrA [16:36:24] play* [16:36:32] yeah, that's pretty much all it does [16:36:44] and DVZ only burn [16:37:05] then optimum point for the line-of-apsides shift is one where it doesn't change the HA/HP [16:37:08] the* [16:38:42] who knows, by the time of Apollo 15 they maybe had a direct method for a combination maneuver for HA/HP change and line-of-apsides [16:38:58] yeah [16:40:34] which isn't easy, both of those change the current true anomaly [16:41:20] hmm [16:41:28] there actually is an option I haven't implemented yet [16:41:34] that already existed for Apollo 10 [16:41:45] "Maneuver to shift line-of-apsides to a specified longitude" [16:42:28] oh [16:42:33] and the most complicated one [16:42:38] also not implemented yet [16:42:39] haha [16:42:59] but I believe it's useful for the last SPS maneuver before deorbit on an Earth orbital mission [16:43:11] the longest maneuver definition [16:44:16] "Maneuver to change both apogee and perigee and place perigee a certain number of degrees from a specified longitude a certain number of degrees from a specified longitude a certain number of revs later" [16:44:21] now that I read that [16:44:30] the RTACF document might accidentally have that double [16:44:37] which confused me a lot [16:44:52] "Maneuver to change both apogee and perigee and place perigee a certain number of degrees from a specified longitude a certain number of revs later" [16:44:56] that makes more sense [16:45:13] and probably is what we want [16:45:52] the RTACF document has the "a certain number of degrees from a specified longitude" twice in there [16:45:58] I thought there was a significance to it [16:46:02] but maybe not [16:46:35] morning! [16:47:08] hey [16:47:36] hey Mike [16:48:15] what do you think Alex? [16:48:26] did they accidentally include that twice? [16:48:34] or can that be read differently... [16:49:49] hmm not sure, but that definetly sounds like what we want [16:50:47] I believe it also directly applies to SPS-7 of Apollo 7 [16:51:02] shapes orbit for the backup deorbit methods using RCS [16:51:20] both with a good apogee and perigee [16:51:32] but also by placing the perigee at a useful longitude [16:51:40] so that you can do the deorbit maneuver at apogee [16:51:47] which requires very little DV then [16:52:27] that is what the multiple revs input is for [16:52:39] so that the perigee gets placed correctly a while later [16:57:20] So I found a rough way to calculate it I think: Input maneuver, used Time, DV and the ORDEAL pitch angle from the flightplan [16:57:49] then fine-tuned the pitch angle and DV to get as close to 75x55 [16:58:02] sounds very rough, haha [16:58:07] yes lol [17:29:02] Another thing is that the TEI desired REFSMMAT was uplinked before the shape burn [17:29:47] so I guess it would somehow need to use the post shape burn SV as an input for the TEI calculation [17:30:05] in order to get the right REFSMMAT [17:36:30] hmm, I guess [17:37:46] sounds like another reason for a maneuver planning table, like in the real RTCC [17:37:57] so that you could stack maneuvers and trajectory calculations [17:39:30] yeah [17:49:17] remember when I said I changed something very low level to fix the apogee finding function? [17:49:20] I think I broke TEI [17:50:37] so I'll have to revert that change [17:50:50] and figure out a better way to solve the issue with the apoapsis radius finding [17:54:11] actually, it's not even working anymore when I revert that change [17:54:12] damn [17:54:57] hmm my TEI calculation worked [17:55:09] or at least seemed to [17:55:45] maybe one of my other temporary changes is the problem [17:59:17] it's just not working for me right now, at all [17:59:56] weird [18:00:03] what mission? [18:00:21] testing my Apollo 10 scenario after docking [18:08:42] ok, now it worked [18:08:44] weird [18:10:08] how exactly had it broke? [18:10:19] no idea [18:10:23] it just kept calculating [18:10:29] oh [18:10:36] the first time I properly debugged, it worked again :D [18:10:59] I'll rebuild and try again [18:11:15] although [18:11:20] there was one thing I changed back [18:11:27] have to check if maybe that was the cause [18:32:18] yeah, that other change was responsible [18:33:16] often used equation, moved into a new function [18:33:20] new function was faulty [18:33:25] classic [18:35:04] but that doesn't change, that I'll probably have to revert something [18:37:18] hmm [18:37:21] maybe, lol [20:26:17] good night [06:37:21] Does anyone remember what the fix was for the waste/urine dump visual glitch that had them being visible in the cmp window? I remember it being a topic with a solution on one of the forums but I can’t find it anywhere [06:38:01] Something to do with the vs redistribute package version I think [11:57:10] Good morning [11:57:22] Oh nice [11:57:59] Thats right on par with that 400 or so number I found [11:59:27] hey [12:00:39] good morning [12:01:39] hey [12:11:36] I think I am going to increase the crew heat a bit more and see how the LM reacts [12:11:54] And of course make sure it doesnt break the CM [12:11:57] hey Ryan [12:12:47] Morning [12:13:01] indy91, is the heat in hsystems in watts? [12:13:02] i wonder if there will ever be a dsky app [12:13:15] People have made progress towards that [12:13:32] for use with nassp [12:13:47] Just need someone to code it :) [12:14:05] there is an fmc app for fsx and the pmdg 737 which i just bought [12:15:05] Yeah [12:15:15] I have seen people use it [12:15:26] I learned that FMC so well thanks to PMDG [12:15:29] yes, watts [12:15:38] Thanks [12:15:40] and then it gets multiplied with the timestep time [12:15:53] which results in the joules per timestep [12:16:00] that is then used for the thermic function [12:17:19] starting a new 11 mission so i hope the ptc refsmmat works for mcc2 with the tig set to the tli time [12:32:02] Hmm [12:32:07] That could be iffy [12:32:14] Because watts is already per hour [12:32:26] second rather [12:32:34] J/s [12:32:48] Oh never mind [12:32:53] I cant math in the morning apparently [12:33:03] More coffee [12:39:56] yes, more coffee [12:42:43] rcflyinghokie, remember when I showed you that graph with the eccentricity changing so much in Earth orbit? [12:42:52] yes [12:43:21] the locally calculated apogee and perigee also change that much. So what I am trying to do now is the calculation of a maneuver to achieve specific apogee and perigee heights [12:43:30] but the actual ones, not the locally calculated [12:43:38] luckily the RTCC documents help with that [12:44:12] the Apollo 9 maneuver I can currently at reduces the perigee to 95NM [12:44:32] and depending on where in the orbit you are, the actually achieve perigee could be plus/minus 10NM of that [12:44:36] which is of course not ideal [12:44:43] achieved* [12:45:11] so I am trying to improve that by targeting the actual apogee and perigee heights [12:45:36] I thought I would have to add that to the Maneuver PAD as well [12:45:38] So what exactly is causing the differences in the first place? Just targeting? [12:45:49] Or orbiter versus real life [12:46:01] Orbiter is pretty realistic [12:46:27] Thats what i thought [12:46:45] you are calculating apogee and perigee heights from the orbital elements of the local state vector [12:47:10] if you advance the state vector e.g. 10 minutes then due to the non-spherical gravity you get differen orbital elements [12:47:20] and with that different apogee and perigee heights [12:48:43] so if you calculate the heights with local state vector throughout an orbit you get varying results for apogee and perigee [12:49:15] So by targeting the actual Ha and Hp you can reduce the error? [12:50:38] yeah, you kind of have to use mean elements, which are valid on average througout the orbit [12:51:08] the circularization targeting is affected as well [12:51:15] in a simple Kepler orbit it's easy to calculate [12:51:37] just need to bring your flight path angle to 0 at the maneuver time [12:51:45] Right [12:51:58] but again, with the local state vector at TIG you won't get a circular orbit [12:52:13] so the RTCC routines actually do an iteration [12:52:28] Now is the position of the spacecraft WRT the earth correct throughout these? [12:52:32] advance the state vector by 180° with taking non-spherical gravity into account [12:53:06] throughout what? [12:53:49] I thought there was an issue with 9 not being in the proper place for a deorbit because of perturbation of error [12:54:47] you mean for the actual deorbit maneuver? [12:55:40] I'm not quite sure what you mean, sorry [12:57:11] Well you can have the correct Ha and Hp but your actual position can be off (inclination, lon of asc node etc) [12:57:35] right [12:58:07] So how is targeting the Ha and Hp maintaining this [12:58:17] Unless that was something else entirely [12:59:10] well inclination and longitude of the ascending nodes specifically is easy to maintain [12:59:14] just don't burn out of plane [12:59:36] what you are asking is probably the argument of periapsis [12:59:46] so actual location of periapsis (and apoapsis) [13:00:25] it depends really [13:00:42] if you are targeting specific HA and HP, in most cases you will change that location [13:01:20] the optimum HA and HP change doesn't rotate the line-of-apsides at all [13:01:37] so that would maintain all the other orbital parameters [13:01:54] that option already exists in the RTCC MFD [13:02:10] what we don't have yet is proper placement of the periapsis for deorbit [13:02:34] and knowing the actual periapsis location, not just the locally calculated one, helps a lot with that [13:03:10] that should make it possible to place the deorbit point exactly at apoapsis with a resulting desired splashdown longitude [13:03:15] does this answer your question? [13:04:42] Yes it does [13:05:39] unfortunately that option wasn't in the RTCC yet in 1967 [13:05:47] so the documents I have don't have any equations for it [13:06:07] I only have the Apollo 10 list of options in the general purpose maneuver processor [13:06:13] and that is the last of the options [13:06:33] I was talking to Alex about it yesterday, it actually can also be used for the Apollo 15 shaping burn in lunar orbit [13:06:46] because that also has the targets: HA, HP, periapsis at specific longitude [13:07:58] and I am looking forward to trying some RCS deorbit options, when we can properly place the perigee location for a splashdown [13:11:05] Oh nice [13:14:14] the minimum DV technique is a maneuver at apogee lowering perigee to 40NM [13:14:20] just low enough for capture [13:14:56] and if you are in the 90x210 orbit that was used late in the Apollo 9 mission, then that's not a lot of DV you need [13:16:43] Nope [13:18:36] The CM doesnt like that heat load from the crew haha [13:19:33] Oh because Ryan couldnt math earlier and didnt convert hrs to seconds [13:19:57] bad earlier Ryan [13:21:38] Yes un-caffenated Ryan is no good [13:22:23] Hm or did I do it right [13:22:39] 1420 btu/hr is 416 watts [13:22:59] divided by 3 thats 138.7 per crew member [13:24:28] I think that's right [13:24:46] Thats the number I have in there [13:25:05] the CM implementation of temperature control might just be bad [13:25:11] I bet the cabin heaters in the CM were adjusted to provide the heat instead fo compensating for crew [13:25:12] how is it reacting? [13:25:13] *of [13:25:17] Climbing [13:25:38] suit temp is going up, in 5 minutes it jumped about 10 degrees after rebuilding [13:26:02] might just be lack of depth of the simulation in the CM [13:26:05] Yeah [13:26:10] Thats what I am thinking [13:26:19] LM seems to be handling it [14:01:35] So any idea what messed up the EMEM's in MrFickles issue? [14:06:57] not really [14:09:41] but I believe I have seen that once before [14:09:48] have to search in the old forum [14:10:44] one other DAP issue is when you exit the wrong way out of P40, after you have given TVC control to the CMC [14:11:02] then it can happen that the OCDUs aren't given back to the optics control [14:11:16] and auto optics are broken then, until you reset a flag [14:11:35] Ah yeah they share some addresses [14:11:47] that and the CDUs [14:11:52] optics and TVC [14:12:05] but DAP EMEMs getting scrambled is weird [14:15:09] Yeah thats why I thought it was the changes for PTC and rates [14:15:15] But those arent done until TLC [14:32:33] So with all of these out of plane burns in 9, is there a good check to see if I am actually where I am supposed to be? [14:37:12] doesn't matter much, to be honest [14:37:25] inclination should be roughly correct [14:38:57] Ok [14:39:39] the SCOT says that for late liftoffs some of the maneuvers would be adjusted, so that the lighting during the later rendezvous is as in the SCOT [14:40:02] so I guess with these bunch of maneuvers you theoretically should be on the exact planned trajectory [14:40:31] with the orbital plane but also sunrise/sunset times [14:40:45] our MCC doesn't target for that yet [14:41:00] just, specific nodes shifts in the latest iteration of the maneuver targeting [14:43:10] the SCOT has specific node shift values for SPS-3 and 4 and the docked DPS burn [14:43:25] SPS-2 would have been adjusted to make the lighting during rendezvous right [14:43:57] and I am using specific longitudes for the impulsive TIG of those maneuvers [14:44:06] same longitude as the main tracking station for the maneuver [14:44:13] that seems to give pretty good results [14:46:03] Ok [14:46:29] but I haven't test flown the complete sequence of maneuvers yet [14:46:44] I want to do that when I have implemented the propulsive LH2 venting [14:48:57] Ah thats right [15:06:41] how far are you into the mission now? [15:06:49] did you already do SPS-5? [15:07:01] the circ burn [15:13:13] Docked DPS [15:13:24] ah [15:13:33] just was curious about the TIG of that burn [15:13:36] it was way off for me [15:13:46] I can let you know [15:14:10] sure, when you get to it. no stress :D [15:15:08] that's one of the things that hopefully get better with the LH2 venting and the nodal shift targeting for the previous burns [16:43:53] morning! [17:04:27] hey Mike [17:08:57] what's up? [17:09:38] still more general purpose maneuver stuff [17:10:00] changing the display for it on the RTCC MFD to something similar in the real RTCC [17:10:12] something similar as* [17:14:29] haha nice [18:07:32] hey [18:10:33] hey Alex [18:14:05] hey [18:20:57] I can confirm TEI is very... not broken [18:21:49] 6.69 entry angle after TEI [18:22:00] who needs MCCs anyway [18:22:27] if there is anything broken, then it wouldn't be able to find a solution at all [18:22:35] right [18:23:01] kind of a similar issue as some translunar MCCs, where it finds a reentry solution in the past [18:23:24] but I guess we are lucky, and the orbital travel between TEI and EI is less than 180° [17:25:42] morning! [17:26:28] hey [17:27:10] what's up? [17:27:27] just woke up, heh [17:27:28] late morning [17:27:31] you? [17:28:23] was gone for the weekend, now back [17:35:51] only three days until I leave for spacefest :D [17:37:21] haha, awesome [17:44:05] Hey guys [17:45:35] yo [17:46:02] hey Thymo [20:26:49] Hello guys, how are you? [20:28:41] no one here? ok i ask my question on orbiter [22:01:33] Finally handed in all my college projects! Time for a celebration. LD [22:01:34] :D [15:25:30] good morning [15:33:06] hey [16:18:29] morning! [16:39:40] hey Mike [17:14:20] what's up? [17:15:14] for once something I am working on actually worked on the first attempt [17:16:11] apoapsis and periapsis height change, compensated for non-spherical gravity [17:16:38] whoa, nice! [17:16:46] I love it when that happens [17:17:11] except, I am always suspicious that something is actually wrong with it, just more subtle than usual :P [17:17:43] yeah, something like that is happening actually. But it might not be so bad [17:17:52] just an unattainable orbit [17:19:07] probably [17:19:39] hehe [17:20:36] but I am using pretty much full RTCC documentation equations for this [17:21:02] so that's good [17:23:16] :D [17:23:40] pages from November 1967. In the past I've always maintained, that they had no idea what they were doing then still. [17:23:51] But that probably doesn't apply for low Earth orbit maneuvers [17:23:57] hahaha [17:24:04] these maneuver calculations probably evolved from Gemini [17:24:47] I dunno man, '66 was clearly the best year for documentation :P [17:24:56] hey Mikael_ [17:25:32] Hello guys. how are you? [17:25:51] doing pretty great, super excited for this week :D [17:25:54] what about you? [17:26:07] hey [17:26:23] Super fine! Thanks [17:27:06] I have a problem :-) [17:27:31] P22 [17:27:35] ah [17:27:37] that's a fun one [17:27:41] lol [17:28:07] P22 we at least understand [17:28:11] I do not know what to do [17:28:29] which mission are you flying? [17:28:30] :-) [17:28:44] apollo 7 [17:29:06] in Orbiter 2016? [17:29:08] Forever it feels :-) [17:29:17] yes [17:29:23] that might be a bit of a problem actually [17:29:28] ok [17:29:37] in Orbiter 2010 we had the full list of Earth orbit landmarks as markers in Orbiter [17:29:46] but for 2016 the format of the marker files changed [17:30:33] so usually you would be directing the sextant or telescope at a landmark and mark on it [17:30:38] that's how P22 basically works [17:30:45] bit more tricky without those markers [17:31:10] but how do I do "Load previously computed landmark coordinates" [17:31:49] Where do I find these landmark? [17:32:25] aha in 2010 [17:32:44] the markers are only in 2010 right now, yeah [17:32:50] but we have a list of landmarks for Apollo 7 [17:32:54] with times and coordinates [17:33:03] that's in the Apollo 7 Update Forms document [17:33:08] page U1-9 [17:33:11] ok [17:33:35] I guess you are at about 122h GET? [17:33:55] can I use 2010 Update Forms in 2016? [17:34:06] 122 yes [17:34:18] yeah, those shouldn't have changed much [17:34:35] some of the landmarks might now be at an elevation [17:34:46] and not at 0 altitude as in Orbiter 2010 [17:35:01] interesting! [17:35:15] I think most of the landmarks are at the coast though [17:35:22] so it shouldn't be much of a problem [17:35:42] There is not any MCC support for Apollo 7 landmark tracking [17:35:43] were do I find "Apollo 7 Update Forms document"? [17:35:59] Doc\Project Apollo - NASSP\Flightplans\Apollo 7 [17:36:11] Thanks [17:36:17] that's the documentation meant for a MCC-less Apollo 7 mission, basically [17:36:36] without markers it is more difficult, but it can still be done with the original documentation [17:36:48] the first landmark is number 10 [17:36:59] so what you should do in preparation is look at the landmark maps [17:37:08] to know what you are looking for [17:37:25] Should I use a landmark just where I pass or how do I choose these [17:37:25] https://www.ibiblio.org/apollo/Documents/A8-Landmark%20maps+photos-1004.pdf [17:37:39] from the list in the update forms document [17:38:03] it has approximate time, landmark name and ID and the coordinates as input for P22 [17:38:17] cool! [17:38:27] the RTCC MFD also has a landmark tracking PAD page [17:38:49] I haven't tried that one in Earth orbit for a while, but it should give you good acquisition times and such [17:39:07] hell's a lot to learn [17:39:27] :-) [17:39:36] always is with NASSP, haha [17:40:22] ok, the landmark tracking page on the RTCC MFD might not be super useful [17:40:33] it wants the actual coordinates of a landmark as the input [17:40:37] I will start with the Update Forms document [17:40:42] the P22 DSKY inputs are a bit different [17:40:51] yeah, that is a good point to start [17:42:02] Should I choose a landmark near or far away? [17:42:32] or does not matter [17:42:34] you can simply use the list of landmarks, it gives all the ones you should be using [17:42:44] nice [17:42:59] but in general, directly below is tricky, because you are passing the landmark so quickly [17:43:07] right! [17:43:16] and far away from the groundtrack becomes less accurate [17:43:24] true [17:43:47] iirc, the list of given landmarks has a good mixture of both [17:44:16] iirc? [17:44:53] if I recall correctly [17:45:32] I have forgotten what the abbreviation means [17:45:38] haha, no problem [17:45:47] just don't forget too many abbreviations for the CSM ;) [17:46:28] :-)) [17:48:26] the first landmark (ID 10) should be easy to find even without marker [17:48:37] it's the westernmost tip of a big island in Mexico [17:49:05] should be easy to see in Orbiter 2016 [17:50:05] thanks for all help! I'll try again. Will return in a while! Thanks! [17:50:11] no problem [17:57:31] so, I just found out that Jimmie is taking his MOL computer to SpaceFest too [17:57:50] so we might end up poking around in that too, depending on how it's holding up internally [17:59:21] lots of MOL documentation has luckily been declassified [17:59:23] http://www.nro.gov/foia/declass/MOL.html [17:59:54] good luck finding anything useful about the computer in there .D [17:59:56] :D [18:00:57] that documentation is how we pegged this as probably being an MOL computer [18:01:02] ah [18:01:20] also, the Computer History Museum has several boxes from an IBM guy who worked on the MOL computer [18:01:32] unindexed, so I'll be going there in a few of weeks to sort through it :D [18:03:00] boxes full of LVDC code [18:03:06] one can hope... [18:03:48] hahahaha [18:03:51] that would be incredible [18:03:56] but I doubt they wouldn't know they had that [18:07:03] http://www.computerhistory.org/collections/catalog/102784971 [18:09:46] he worked at the right place at least [18:09:50] hahaha [18:10:12] yeah [18:10:19] could be not computer-related [18:10:23] but maybe [18:13:15] worth looking at least :) [18:15:07] for sure [18:23:13] Apollo 8 and 9 had the PRO button on their DSKYs, right? [18:23:44] I wonder if this AGC is going to have the backplane rework to make the PRO button work [18:24:11] Apollo 7 had as well [18:24:15] all of the flown ones [18:24:21] flown manned* [18:24:29] hehehe [18:24:30] right [18:25:48] and my bet is yes, it has the wiring for the PRO button [18:26:42] that is my guess as well [18:27:25] though I don't remember seeing any obviously added wires in that area in the pictures [19:51:43] thewonderidiot: Hey Mike. Did you ever manage to grab those logs for me? :P [19:51:52] nooooo [19:52:01] I've been too distracted by SpaceFest <_< [19:52:43] No pressure. :p [19:53:17] I haven't worked on it in a while. Got stuck with implementing the I/O. I need to look at that again. [19:56:18] I will look into it after spacefest [19:56:22] remind me when I get back :) [19:59:13] Will do. [19:59:41] .in 1w thewonderidiot: Can has logs. [20:00:05] lol [20:02:42] Also, we still need to do some DCS with everyone here. [20:04:50] agreed [20:05:06] my PC is starting to show its age though, lol [20:05:17] it was fine with DCS 1.5 but on 2.5 it's pretty choppy [20:08:18] Same [20:08:25] Need a new GPU [20:08:38] it was really good when I built it.... 7 years ago [20:09:15] I might need a new everything [20:12:45] I've done a few of the MiG-21 training missions, but not all of them yet [20:13:01] I get a bad frame rate drop when I look at other aircraft, haha [20:13:06] otherwise my PC is holding up [20:13:21] love the pmdg 737 [20:13:41] might be because the textures have to be loaded in and it's a HDD and not a SSD [20:14:23] have you flown that before? [20:14:50] from PMDG I had the 747 for FS2004 and the 737 for FSX [20:14:51] so yes [20:16:05] yeah, I got myself up to the point of not accelerating into a roll and crashing into a hillside upon entering a MiG-21 scenario [20:16:33] which involved disassembling and cleaning out my joystick, which was being a total jerk [20:16:51] once the whole setup appeared to be working again I had run out of time to actually try to fly anything :P [20:19:15] I am at 2/2 successfull landings [20:19:19] I hope I can keep it that way :D [20:20:28] oh, and the past 3 times I wanted to start DCS I had to let it update from 2.5.0 to 2.5.2 [20:20:50] which was very inconvenient for my world cup stream I wanted to watch at the same time [20:22:29] hahaha nice [20:22:34] your success rate is WAY higher than mine :P [20:22:52] the sample size isn't very high yet [20:23:15] most of my AOA management I learned from landing heavy Su-25Ts actually [20:23:19] the free DCS aircraft [20:23:23] which is actually a lot of fun [20:23:32] although if you go by the "any landing you can walk away from..." adage, most of mine were successful. the MiG was just missing some landing gear or wings after [20:23:33] hunting tanks is its specialty [20:23:49] oh nice, I've never tried any of those [20:24:09] it's not quite as high level of a simulation as e.g. the A-10C [20:24:21] right, not a clicky cockpit, right? [20:24:22] but it's pretty high up there for a free one [20:24:30] yeah, I think so [20:24:37] it's been a while since I flew it [20:25:18] the setup was my Sidewinder Force Feedback joystick and a Xbox 360 controller for slewing controls :D [20:25:24] same for the A-10C actually [20:25:35] best you can do without a really expensive joystick I guess [20:26:35] hahaha, nice [20:26:37] yeah [20:41:36] oh, it looks like the internet archive people may have gotten my stitched foldouts integrated into the image set [20:41:58] they haven't uploaded it yet but it seems like it should work from what I can see on the scanner [20:42:10] so perhaps we will get back to scanning soon [20:43:25] sounds good [20:46:40] ahh, crap [20:47:02] just saw that Mikael tried to ask his P22 question in the forum, but it was filtered because it was his first post [20:47:12] I just approved it, but I think you already answered is questions [20:47:21] *his [20:47:59] ah [20:48:23] I wish I could get email notifications about moderated posts [20:48:27] but I haven't found such a setting [20:48:50] weird that first posts in a general forum are being moderated by the moderators of the subforums [20:48:59] you would think that is something for the forum admins [20:49:19] he only posted it last night, so maybe they just didn't get around to it yet [20:49:31] I'm still not sure if this is something I'm supposed to be doing, but I do have the power to do it... [20:50:01] certainly doesn't hurt [20:51:26] good night! [20:51:32] night! [20:52:07] thanks, Guenter [20:52:37] I also specifically didn't use that exact phrase, since I saw in the log that Thymo implemented that :D [21:34:14] Ouch, he caught me. :P [21:36:55] hahaha [21:37:13] I thought you were pretty good at using .mute, I wonder what slipped through [21:38:09] Dunno [21:38:53] .mute isn't leaking information, is it? :P [21:43:51] Well we did briefly talk without mute. Maybe I forgot to remove something from the logs. [21:44:22] haha [21:44:58] maybe Niklas has a spy [21:49:07] Must be orbifan or mcarberry. They never say anything. :p [21:50:55] nah, mcarberry is my IRL friend, he wouldn't snitch :P [22:10:40] He isn't here very often. I only saw him active once I think. [16:47:37] morning! [16:47:44] he says to nobody [16:47:45] :P [19:03:23] hey Alex [19:06:23] good evening [19:08:47] hey Niklas [19:26:24] too busy again to make much progress [19:26:46] my latest state was that I had the apogee/perigee targeting working right, but not in all cases [19:27:48] that's all I really need to continue with the Apollo 9 MCC [19:28:02] so progress on that soon-ish [19:31:06] thewonderidiot, how many days until Spacefest? [19:31:57] this time tomorrow I will be on a plane :D [19:32:16] oh, and you don't have to ask about my DSKY. I've read they had some production delays anyway, and a free one probably hasn't much priority, haha [19:34:28] heh, yeah [19:34:37] how many days are you at your booth? [19:34:50] Thursday through Sunday [19:36:10] so pretty much the whole duration of spacefest, except when some talk or panel manages to pull me away from the AGC :D [19:37:29] how much time does that leave for working on the AGC? :D [19:37:45] and more importantly, are your preparations for that done yet :P [19:38:22] I don't think it is possible for me to ever be "done" preparing, haha [19:38:36] haha, fair [19:38:37] but I've got everything into a state of preparedness that I am at least happy with [19:38:50] and the daily schedule runs from 8am to 9pm [19:39:06] so it really depends on how long Jimmie intends to be at the booth [19:39:46] hopefully plenty of time, though [19:40:00] but if the plans to power it up proceed then there will be more time in the future to cover things that I miss :) [19:42:20] keep us updated here [19:42:36] will do :D [19:42:53] one of my tasks for tonight is to get IRC set up on my phone, just in case I don't have wireless on my laptop for whatever reason [19:51:59] you and the DSKY people together... [19:52:47] I don't know why and how, but somehow I have the feeling that will mean work for me [19:52:57] hahahaha [19:53:12] when have I ever caused work for you? :P [19:53:41] yeah, never [19:54:26] you have caused work for me I'm not even thinking about starting [19:54:33] i.e. the pulse simulation [19:54:35] hahahaha [19:54:47] fair, that is a _lot_ of work [19:55:12] will make simulating 1202 alarms more fun [19:55:22] and totally accurate! :D [19:55:29] and no more half implemented CDUs [19:57:17] sorry about not implementing and testing that yet [19:58:19] oh no worries at all [19:58:20] I might have given the impression that I would do that back then [19:58:35] it is a monster and is going to eat a lot of time for both of us [19:58:39] yeah [19:58:51] I still think it is worth doing, at some point [19:59:03] for sure [19:59:17] it's still sitting as a pull request, right? [19:59:19] but yeah, there's no rush [19:59:24] yeah, pull request on VirtualAGC [19:59:50] I still need to go through and add a compatibility layer so the things packaged with VirtualAGC can still talk to it [20:00:00] right [20:01:01] I am working on that super important project right now, called "getting lost in the details" [20:01:38] weeks of work + rewriting half of the RTCC = marginally improved targeting [20:02:46] hehehehe [20:02:56] getting lost in the details is my favorite project :D [20:03:21] I would count marginal improvement as a total win [20:04:08] I feel like at least half the time I get lost in the details and do big changes to a thing, I end up making it worse somehow :P [20:04:45] in that case I usually scrap the project and start from scratch [20:05:02] best example is the vehicle independant LVDC++ [20:05:06] hahaha [20:05:12] how many times did you scrap your work there? [20:05:59] also by worse, I meant functionally worse but historically more accurate -- usability be damned if it's not accurate :P [20:06:01] at least 3 times [20:06:07] hehehe [20:06:23] yeah I feel like that, and there was another thing or two that you seemed to restart a bunch of times [20:06:24] I really just needed a plan for it [20:07:11] and the solution was basically that I added the vehicle independant interface in addition to the old implementation [20:07:27] which enabled me to replace functions step by step and not all at once [20:08:00] right [20:08:28] so having two implementations side by side might not be very elegant [20:08:42] but often it's the only way you actually are able to succeed [20:09:30] my favourite failed example: [20:09:33] https://en.wikipedia.org/wiki/Windows_Vista#Development_reset [20:12:20] I think they tried to rewrite Windows from scratch [20:12:30] which failed and they haven't really done it to this day! [20:14:13] oh wow I didn't know about that [20:14:15] that's crazy [20:23:17] so let's test this [20:23:21] night! Guenter [20:23:24] thanks [11:55:09] Good morning [11:56:33] hey Ryan [11:59:25] So I havent been able to work on things much, but I inadvertently made progress stabilizing the glycol loop [11:59:33] I do not get MA's switching panels [11:59:54] that's great [12:00:13] I still get fluctuation in time acceleration, but not switching panels at 1x anymore, so I have a rough idea how to begin stabilizing things, it will just take a while to implement and test [12:00:36] what was the breakthrough on that? [12:00:55] Nothing "new" it was the valve sizes/tank sizes in the glycol loop [12:01:07] yeah, makes sense [12:01:45] Enlarged some and shrank some to find a balance [12:02:19] I was doing it mainly for temperature flow through the system and of course pressure, but the result was actually no hard jumps during a panel switch [12:02:44] So I have an idea where to begin [12:07:12] I also need to look at heat exchangers in a greater detail [12:07:48] That heating vs cooling thing may be causing me trouble [12:55:41] morning [12:57:42] good morning [12:58:29] hey [12:59:07] was just flying the pmdg 737 for fsx [13:01:04] Fun bird [13:01:15] I have a lot of hours in that haha [13:01:32] me too [13:02:41] So I still have a ways to go, but no more MA's on panel switching in the LM [13:02:51] oh nice [13:03:11] or during time accel? [13:03:22] Still get fluctuation in time acceleration though, but I am on the right track, it will take a bit to resolve it all [13:03:46] Its all a function of tank/valve sizes and getting them right [13:05:23] When I finish 9 I am going to rework the LM ECS to 1) make the systems generating heat generate properly to heat sinks/radiators and 2) stabilize the ARS and glycol systems for time accel [13:17:51] hey guys [13:27:23] hey Niklas [13:28:07] rcflyinghokie, sounds like some good goals [13:28:12] Yeah [13:28:23] I have a plan of attack it just won't be quick [13:28:37] better slowly but surely [14:15:21] slowly but surely is mky progress as well :D [14:15:25] my* [14:20:12] I got distracted with the glycol that I am just passing my docked DPS on 9 [14:20:33] Though I found a lot of powerdown issues (staged vs unstaged cb charts) [14:20:58] So those are getting fixed now [14:33:57] morning! [14:37:21] hey Mike [14:39:04] I talked to Jimmie on the phone last night -- we're meeting up this evening and doing some preliminary work on the AGC before SpaceFest starts tomorrow :D [14:39:31] great [14:40:49] trying to decide what I want to do first, lol [14:41:11] not breaking it [14:42:05] that is one of the goals, yes, haha [14:52:37] Hmm trying to switch power back to the LM but I have nothing on the system test meter [14:53:31] And no power in the LM from it [14:55:01] I had to hold the reset down [14:57:35] it might take more than one timestep, not sure [14:59:31] Also, should the reset be required? [14:59:42] I cant even connect LM power in the beginning without resetting first [14:59:55] But the checklists don't mention it [15:07:11] I have to debug that, no idea really [15:08:00] Sure [15:08:21] Maybe we can explore that when we dive into making the CM/LM connection be able to flow both ways ;) [15:15:30] sure [15:26:34] The TIG on SPS 5 is an hour early btw [15:26:54] Hour late I mean [15:27:15] FP has 54:25:16 [15:27:26] MCC has 55:26:32 [15:29:17] yeah, same here [15:29:27] that's why I still need to work on SPS-2 to 4 [15:31:50] Ok [15:32:10] SPS-5 is a circularization burn at a specific height [15:32:26] so its TIG is purely based on the trajectory before the burn [15:33:27] Gotcha [15:43:03] fun fact about circularization burns [15:43:13] in Earth orbit they are impossible to achieve [15:43:25] well, in an equatorial orbit it's possible [15:43:58] but due to non-spherical gravity, your apogee and perigee will be at least 0.5NM lower/higher than the mean radius [15:44:20] the perigee location probably does a 360 during the course of an orbit [15:44:36] Makes sense, actually [15:44:52] the old circ burn logic, which the MCC will still be using for you, isn't super circular [15:45:02] instead of 133x133 it will be more like 125x133 [15:45:13] the new one will be better [15:45:22] but needs some tweaks still [15:49:59] I look forward to it [15:51:05] same tweaks apply to any apogee/perigee height targeting [15:51:24] when I have that right, then finally finally I can continue with flying Apollo 9 [16:00:17] Hopefully I will have some better flowing checklists for you [16:39:55] alright, made it to the airport and I am configured for flight :D [16:41:12] now just gotta kill a couple hours, I may have gone a bit overboard on margin [16:52:21] play with the Virtual AGC on your phone? :D [16:52:33] hahaha, I'm playing with it on my laptop right now :P [16:53:39] haha, good [16:54:35] T-8 hours or so until hands on the real one [16:55:14] now maybe load one of the core files I created :D [16:55:37] lol, that is for a future meeting [16:56:00] for this time, I've carefully measured out everything to ensure that nothing I will be doing to the erasable memory module runs the risk of flipping any cores [16:56:05] I meant the scenarios I created for Ron [16:56:13] right [16:56:27] so that you can practice some procedures, haha [16:56:37] hehehe [16:56:55] like these: https://github.com/virtualagc/virtualagc/tree/scenarios/Colossus249 [16:57:07] or, start a fresh Colossus249 [16:57:12] and do a useless thing [16:57:19] like V37E 38E [16:57:28] doing the padload on the real one will need to use a program that has not yet been written, to interface with a tool that has not yet been designed ;) [16:57:30] congratulations, you used a program NASA didn't even want [16:57:35] hahaha [16:57:37] what is that? [16:57:45] stable orbit rendezvous program [16:57:48] P38 and 39 [16:58:06] https://www.researchgate.net/profile/Toru_Yamamoto2/publication/262494918/figure/fig2/AS:296803879669761@1447774967572/Typical-Rendezvous-Trajectory-Considering-AON-left-SOR-rightDCR.png [16:58:19] entirely different rendezvous concept [16:58:27] I really have no idea why it was ever added [16:58:32] probably a MIT idea [16:58:41] hmmm [16:58:41] weird [16:58:42] and it was removed for Apollo 12 or so [16:59:44] it was already in Colossus, before P32 and P33 for CSI and CDH was even added [17:00:02] wow [17:00:10] okay there, I'm running P38 :P [17:00:13] happy? [17:00:16] yes [17:00:34] I'm probably the only one here who has actually tried those programs [17:00:42] hehehe [17:01:16] the inputs I used plus the long run times we used to have wit hthe AGC lead to very long iterations [17:01:54] http://tindallgrams.net/66-FM1-107 [17:02:04] found a Tindallgram about it [17:02:36] wow, this program has a lot to tell me [17:02:39] I just keep hitting PRO [17:02:40] lol [17:02:45] haha [17:02:49] 0 GET TIG [17:03:03] it's flashing 16 45 at me now and counting up in R2 [17:03:21] that's impressive [17:03:32] that you got so far [17:03:35] now do a V32 and watch the program alarms [17:03:37] or a lock up [17:04:05] haha [17:04:11] I will try that next time [17:04:16] there are 2.5 programs for it in the CMC [17:04:24] I pressed PRO again and the COMP ACTY light came on solid for a few seconds, and then gave me an alarm [17:04:31] as I expected, haha [17:04:43] 1301, 1302 [17:05:14] ouch, double math whammy [17:05:29] arcsin/arccos argument too large, and sqrt with a negative argument [17:05:49] yeah, you might be missing some important things [17:05:53] like a state vector [17:05:57] humbug [17:05:57] or valid inputs [17:06:15] P38 option 1 is for the initial maneuver [17:06:27] the target is a point X NM behind the target vehicle [17:06:35] same orbit and everything, just behind [17:06:56] P38 option 2 is the targeting for the maneuver at that arrival point [17:07:05] then you would be in the same orbit as a target [17:07:22] P39 is midcourse corrections in between [17:07:54] right [17:07:59] P39 asked me far fewer questions [17:08:11] if you could also input a delta height, then it would be actually usable for some lunar orbit maneuvers that were ground targeted [17:09:01] not even one Apollo 11 CSM rescue case would have used those programs [17:09:09] so they were deleted then [17:10:17] but you are now in a very small group of people who have used those programs, haha [17:10:32] you, me and some people in the 60s probably [17:11:18] maybe some random NASSP user [17:11:46] hehehehe [17:12:01] P38 seems much happier on your Apollo 7 rendezvous core file :P [17:12:38] I'm surprised these programs survived all the way up to 11 if they were so useless [17:12:43] MIT must have really liked them [17:13:25] whoa, the COMP ACTY light was on solid for a good 20 seconds or so but it gave me results for whatever it was doing [17:13:31] up to a flashing 06 58 [17:13:41] yeah, you should be able to get a valid result with the right inputs in that core file [17:13:49] N58 is [17:13:52] perigee height [17:13:57] DV initial maneuver [17:13:59] DV final maneuver [17:14:02] if the right inputs are not "pressing PRO every time it flashes", then I am not giving it the right inputs ;) [17:14:18] hmm, where's the decimal point on that [17:14:21] DV [17:14:26] .1fps [17:14:37] okay [17:14:39] 0 input in N57 is no problem, that is just the offset [17:14:54] so +21740 for DV final maneuver sounds a bit high then [17:14:55] N33 needs a TIG in the future probably [17:15:00] slightly high, yes [17:15:03] lol [17:15:22] Tindallgram has some valid N55 inputs, I think that's where I initially got it [17:16:00] awesome [17:16:21] if you want to try it: 28:15:00 for N33, 330° for N55 [17:16:38] N57 anything you like [17:16:48] 0.01° is the decimal point [17:17:02] N57 is 0.1NM [17:17:23] hmmm [17:17:52] what's the normal method for entering things here? it's flashing 06 55 at me, but pressing anything other than PRO just makes KEY REL flash [17:18:03] V21E [17:18:10] +33000E [17:18:13] I would guess [17:18:21] oh, 55 [17:18:26] yeah [17:18:40] oh, that's nifty [17:18:47] or in whatever register it shows the angle [17:19:03] that's the travel angle between the initial maneuver and the final maneuver [17:19:14] 360° would be ideal actually [17:19:30] but that doesn't work with the Lambert targeting [17:20:03] but even in the Shuttle, which usually used stable orbit rendezvous, you have to use some tricky offsets and delta times to make it work [17:21:04] Shuttle had offset inputs for 3 axis, not just behind or in front of the target [17:21:23] other than that it really only had better displays, not any more advanced targeting than Apollo [17:22:26] I should know, I by accident wrote the default rendezvous targeting for one of the Shuttles in Orbiter [17:22:50] I didn't even know how to create an MFD then, so I wrote it in lua scripts [17:23:04] and the developer of the Shuttle Fleet addon wrapped an MFD around those scripts, lol [17:23:33] hahaha [17:23:34] awesome [17:23:53] December 2012, damn is that long ago [17:24:10] wow yeah it is [17:24:19] you have been at this for much longer than me :P [17:25:00] I mean, a while ago I've found some old printed NASSP checklists of mine from 2007 [17:25:14] I've used Orbiter for forever [17:25:21] hahaha [17:25:28] wow [17:25:56] okay, I have entered your inputs and it seems to be working [17:26:10] 16 45 is counting down from -14 45 [17:26:30] yeah, the core file is shortly after the coelliptic maneuver at 28h GET [17:26:38] so I chose a time for you 15 minutes in the future [17:27:07] so once this counts down to 0, I just press PRO? [17:27:11] is that how this works? [17:27:12] haha [17:27:14] not at all [17:27:15] lol [17:27:16] great [17:27:24] that's just a useful countdown [17:27:33] perfect [17:27:34] V32 to trigger a maneuver calculation [17:27:37] so far it didn't do any [17:27:40] aha [17:27:46] why V32 and not PRO? [17:27:53] PRO is on the final computation [17:28:12] usually you would recycle the program (V32) a few times, if enough time is there [17:28:19] hmm, okay [17:28:26] sequence: initial inputs, V32, marks of any kind, V32, and so on [17:28:37] and then at the end, some set time before TIG, you would do PRO [17:28:48] and after that no further marks can be done [17:28:57] marks? who needs marks [17:29:03] and you would go from the final calculation to one of the P4X programs to burn [17:29:25] the core file has decent SVs for CSM and S-IVB [17:29:30] so, nobody needs marks :D [17:29:36] haha [17:29:41] nobody needs marks when they have a Niklas [17:30:08] man, P38 computation takes a long time [17:30:13] yep [17:30:23] it might not like 330° too much [17:30:30] also, did you keep N57 as 0? [17:30:58] it started off as something on the order of -65000 [17:31:01] the behind/in from of target offset [17:31:10] I changed it to +00250 [17:31:11] 6500.0NM [17:31:13] ah [17:31:18] probably a good number [17:31:22] :D [17:31:23] I'm not sure about the sign of it [17:31:30] +25NM is probably in front of the target? [17:31:36] I took "anything you like" to heart :P [17:31:55] okay here we go [17:31:57] it finished [17:32:03] this does not look terribly unreasonable [17:32:16] +01051 [17:32:16] +01113 [17:32:17] +01083 [17:32:20] for N58 [17:32:27] positive is behind [17:32:38] and you are currently behind the target also [17:32:41] so that is good for the DV [17:32:54] very good numbers [17:32:59] hooray! [17:33:02] now what [17:33:04] HP a bit low [17:33:24] PRO until the 16 45 comes again [17:33:39] right [17:33:42] and then you can do a PRO for the final computation, if you want [17:33:51] excellent [17:34:01] what's the N81? [17:34:09] too late, it's doing the final computation [17:34:18] you will get N81 again then [17:34:28] the lowest DV would be just a horizontal burn [17:35:00] which probably could be done with a N57 that's a bit higher [17:35:33] I expect near 0 DVY and maybe 50/50 in DVX and DVZ [17:35:38] only DVX would be best [17:35:45] 50/50 percent that is [17:36:11] N81 is the relevant number for the burn programs, that's the DV vector given to them [17:36:17] gotcha [17:36:26] 100 ft/s is really nice [17:36:42] oh crap right, feet per second [17:36:44] and evenly split between the initial and final maneuver as well [17:36:53] I've only ever read DV in m/s [17:37:06] yeah that's a third of what I thought it was, haha [17:37:17] then you haven't ready many DVs on the DSKY so far, haha [17:37:26] s/many/any/ [17:37:36] okay, final computation complete [17:37:44] no marks were done in between [17:37:47] numbers are unsurprisingly the same as before [17:37:52] yep, should be same [17:38:03] lacking a sextant or VHF ranging system [17:38:04] okay, so PRO again and it will show N81? [17:38:08] after n58 [17:38:10] N58* [17:38:23] yep, it's on N58 right now [17:38:30] okay here we go, N81 [17:38:42] +00090 [17:38:43] -00021 [17:38:43] +01109 [17:38:48] haha [17:38:52] almost all in DVZ [17:38:58] and positive [17:39:05] so you would be burning mostly downwards [17:39:08] hahahaha [17:39:10] I was going to ask [17:39:14] explains the 105NM perigee [17:39:18] radial burns are the most efficient, right? [17:39:19] :P [17:39:22] nope [17:39:33] S-IVB is in a much higher orbit than that [17:39:33] just burn directly at where you want to go [17:39:36] that's how orbits work [17:39:38] oh [17:39:43] burn directly away from where you want to go [17:39:46] well, 200NM something [17:39:47] there we go [17:39:59] burn directly at the targeting is indeed how the TPI maneuver works [17:40:02] target* [17:40:27] that's in fact why they didn't use stable orbit rendezvous [17:40:45] coelliptic orbit below target, wait until target has reached a specific angle above the horizon [17:40:49] burn DV directly at it [17:41:00] that all works without any computer as well, should it fail [17:41:12] as happened to Buzz [17:41:17] on Gemini [17:41:22] anyway [17:41:27] after N81 is N45 again [17:41:39] yup [17:41:47] same display as before, but R3 shows the middle gimbal angle of the burn now [17:41:56] should be close to 0 [17:41:58] +35987 [17:42:01] yep [17:42:03] so, close enough [17:42:08] PRO again [17:42:14] and you probably have a flasing 37 then [17:42:17] flashing* [17:42:19] indeed [17:42:29] burn is large enough for the SPS [17:42:32] so simply enter 40E [17:42:36] when I got here the first time I didn't know what to do so I just put in POO, heh [17:42:44] no problem [17:42:49] you can go to P00 in between [17:42:55] right [17:43:11] okay, 50 18 [17:43:15] yeah [17:43:24] +00257 [17:43:24] +19082 [17:43:25] +35840 [17:43:27] input bits might still be set for the CMC Auto DAP [17:43:33] try PRO [17:43:46] does it keep the 50 18? [17:43:48] program alarm? [17:43:52] or 06 18? [17:43:59] no alarm, the display blanks and it shows 50 18 again [17:44:01] no registers change [17:44:23] this repeats if I press PRO again [17:44:26] yeah, that usually means the DAP isn't in the right config for an auto attitude maneuver [17:44:42] so you would have to flip the right switches [17:44:52] hmm [17:44:58] not much you can do then [17:45:09] can I use V01N10E to write to my switches? [17:45:17] probably [17:45:17] I don't think I've bothered to disallow that in the emulator yet [17:46:16] what switches to do I need to throw? [17:46:42] SC CONT - CMC, CMC MODE - AUTO [17:47:06] channel 31, bit 15 to 0 [17:47:34] bits 13 and 14 should be 1, I think [17:47:55] let's see, 31 is currently at 57777 [17:48:06] so make that 37777 [17:48:42] hah! [17:48:51] V21N10E 31E 37777E worked [17:48:56] what a crappy emulator :P [17:49:20] yeah, I guess in the scenario it was in SC MODE - CMC [17:49:25] but CMC MODE - FREE [17:49:46] okay, so should I try to PRO again? [17:50:02] yeah [17:50:09] should give you a 06 18 instead of 5018 [17:50:11] success! showing me 06 18 [17:50:14] which means it's maneuvering [17:50:17] or at least trying to [17:50:30] yeah, good luck with that, AGC [17:50:49] I assume this is going to throw an alarm after it fails to reach its target attitude? [17:50:49] you could try writing to the IMU registers, haha [17:50:54] hahahaha [17:50:58] maybe [17:51:12] if you disable all the thrusters it just stays forever in 06 18 [17:51:26] let's try to write to the IMU :D [17:51:40] basically you need to input the target attitude [17:51:47] so that is think you have reached that [17:51:49] thinks* [17:51:55] is that what N18 is displaying right now? [17:52:19] or are these the deltas I need to apply to what's there? [17:52:29] N18 is the auto maneuver target attitude [17:52:38] not delta [17:52:52] okay, so I just need to put these numbers, in CDU counts, into CDUX,Y,Z [17:53:03] yeah [17:53:12] I wonder if you could manipulate N20 [17:53:16] that might be more simple [17:53:30] oh yes, yes it would [17:53:47] seems like something they would have disallowed [17:53:49] but let's try [17:53:55] I'm not sure that coarse aligning will work [17:54:02] +00257 [17:54:03] +19082 [17:54:03] +35840 [17:54:24] coarse align -> IMU -> CDU -> AGC registers, so it's not directly the stored attitude [17:55:03] okay [17:55:05] it let me do that [17:55:14] and I now have V23 N20 [17:55:20] um [17:55:26] which I think is just leftover display [17:56:35] hmm [17:56:47] did you try V21 etc. or V25? [17:57:03] V25 [17:57:36] not sure that will work [17:57:50] boo [17:58:17] you know, I've been running this on my counters branch of virtualagc, and I can see that it pulsed out a whole bunch of things [17:58:26] I wonder if I connected the CDU drive pulses to the CDU inputs [17:58:28] are those 1:1? [17:58:55] not sure [17:59:15] but maybe you can actually do that with N20 [17:59:19] let me try it in sim [17:59:51] but it might not work for you, lacking a simulated IMU [18:00:36] nothing happened [18:01:00] yeah, probably best to write directly to the CDU counters [18:01:01] I guess that only leaves manipulating the CDU registers [18:03:01] right so my CDU registers are at 00352, 41731, 77556 [18:03:05] now, what to put in them... [18:03:06] or you could manually send IMU attitude pulses to the AGC or so [18:03:24] I don't have a good way to send simulated pulses in [18:05:19] okay, two's complement, 1 pulse is 0.01098633 degrees [18:06:50] my solution is: 364, 41731, 77556 [18:07:59] hmm, how did you get that? I'm getting 351 for the first [18:09:40] crap, plane boarding [18:09:53] this was an excellent way to pass two hours, thank you :D [18:10:05] I will continue to fiddle with CDU registers on the plane [18:22:00] haha, no problem [18:22:10] you can actually ignore that you aren't in the right attitude and just press ENTR on the 50 18 [19:39:21] indy91, the uplink before EVA on 9 seems to be missing a description text [19:40:05] Should have the SV and EVA orientation, looks like those two uplinked, but the MCC doesnt tell you that is what they are like it normally does with others [19:41:36] sprintf(upDesc, "CSM state vector, Verb 66, EVA REFSMMAT"); [19:42:22] so it should be there [19:42:53] Hmm [19:44:00] I redid ti and it indeed came up [19:44:02] *it [19:44:21] Odd [19:44:26] Oh well, never mind then [19:45:18] Certainly did not appear the first time though [19:45:25] Unless I was totally oblivious [19:52:52] weird [19:53:09] but you saw the uplink coming into the CMC? [19:53:18] when that starts, the uplink message appears [19:55:14] Yeah [19:55:20] I should have screenshotted it [19:56:11] It just said Ready for Uplink, and then Uplink completed [19:56:14] Nothing in between [19:56:27] But I repeated it and got the message and have not been able to duplicate it [19:58:50] weird things going on with the MCC [19:59:10] there are also these CTDs that I still haven't been able to track down [19:59:23] when you display certain PADs [20:01:00] I can duplicate it [20:01:07] I have a save right before it [20:01:44] great [20:01:54] I hope I can duplicate it as well with it [20:02:25] https://www.dropbox.com/s/lnvlot7i0tlpfcz/Apollo%209%20MCC%20-%20EVA%20Day.scn?dl=0 [20:02:34] thanks! [20:02:40] all I have to do is wait? [20:02:46] or manually go to the next MCC state? [20:02:51] Switch to CM [20:02:55] And uplink [20:03:10] It is already ready for uplink [20:03:36] Your checklist position will be very confused so ignore it haha [20:03:37] ah [20:03:57] I opened an older Apollo 9 scenario a few days ago [20:04:12] it was at a P37 checklist that was only used for Apollo 8, it seemed like :D [20:04:50] hahaha, I don't even need to debug this [20:04:55] the uplink description isn't saved [20:05:17] so if it calculates the uplink etc. and you save/load, you won't get the message [20:05:24] Oh ok [20:05:27] Makes sense then [20:05:28] simple fix, just have to save save that string [20:05:42] I am glad I wasnt crazy when I thought I missed the message [20:07:40] fixed, will be in my next push, whenever that is [20:08:14] all the MCC things you mentioned so far for Apollo 9 (and 10) should already be up [20:09:18] And I just made a PR of my changes thus far, a bunch of small ECS changes [20:09:29] And checklists through EVA prep [20:09:54] Nothing major, just tiny refinements along the way and nothing broken :P [20:10:45] you made a bunch of valves fairly large [20:10:50] did you test again NaNs? [20:10:55] against* [20:11:08] Yep [20:11:11] No NaN's [20:11:19] and the CSM can deal with 3x the crew heat? [20:11:22] Yes [20:11:29] The suit temp is higher [20:11:37] all questions answered to my satisfaction then, haha [20:11:38] But the overall handling seems normal [20:11:46] Cabin stays the same as it was [20:11:48] merged [20:12:02] And I really think the NaN's were fixed by one of your changes [20:12:08] Not the valve sizes [20:12:30] I cannot remember which one it was, something with Q transfer? [20:12:44] But ever since then, NaN's have vanished [20:13:03] yeah, might be [20:13:12] but it always was a combination of things [20:13:15] Right [20:13:30] Which is why i will be extra careful when i try to start stabilizing the ECS [20:13:36] Lots of all weather testing ;) [20:14:15] yeah. By now I have a bit more trust in the Systems SDK to not cause big issues anymore [20:14:22] but not too much trust [20:14:25] Me either [20:14:34] Incremental changes [20:14:38] Look for bad's [20:14:42] And then press on [20:15:03] I have a feeling I can get things to behave a little better [20:15:10] In time, of course [20:15:25] it already behaves quite realistic over longer periods of time [20:15:35] just those little instabilities and such [20:15:38] Right [20:16:00] I did have an alternate solution for propellant tank pressurization [20:16:01] way more dynamic than the CSM ECS appears [20:16:08] Not to jump ahead [20:16:19] I can emulate a bladder [20:16:29] So I dont have to worry about mixing gas and liquid [20:17:00] The bladder volume will increase with helium added and the propellant tank volume can decrease, thus increasing it's pressure [20:17:12] Which is how the water tanks pressurize I believe on the real LM [20:17:42] I have some ideas how to implement and code it jotted down [20:17:57] I can't be much of a help with that right now [20:18:04] Oh this is down the road [20:18:17] ok [20:18:18] My next task after the 9 checklists will be the ECS [20:18:20] maybe NASSP 9 :D [20:18:30] But it was sort of a random brainstorm [20:18:52] I think it can work with no changes to the guts of hsystems and some simple ideal gas code [20:19:27] sounds interesting [20:19:37] We shall see [20:19:42] I am off, take it easy! [20:20:58] me as well. I might be on for a bit in the morning (for me), to check on your AGC progress, thewonderidiot :D [06:18:56] .tell indy91 we were wrong, this thing does not support the PRO key [06:41:49] . [06:50:35] very little rework on this backplane [06:50:54] there's a couple wires in red, but I'm not sure the machine didn't put them there [06:51:17] they're pretty fundamental to the timer module working, and wouldn't have needed to be rerouted or anything [06:53:04] not a good procedures simulator then :D [06:55:00] no point in giving it any updated software as well [06:55:26] must have still been useful for stuff up to Apollo 11 [06:56:05] hehehe [06:56:17] also yesssssss [06:56:39] I just verified that F10A/ runs into the TC Trap circuit instead of F10A as all of our schematics show [06:56:44] as I have been suspecting for quite some time [06:57:22] and that is generally applicable? [06:57:37] it must be [06:57:56] if the schematics were right, the AGC would not be able to execute more than a single instruction [06:58:49] the hoax people were right all along! [06:58:53] hehehe [06:58:54] yes [06:59:15] the secret is hiding as a signal with incorrect polarity on the schematics, on pin 127 of module A13 [06:59:17] of course [06:59:22] I'm sure there is meaning to those numbers [07:01:33] so what is your general impression of the AGC? [07:01:37] is it well preserved? [07:02:14] it's immaculate inside [07:02:27] it's airtight seal held up over the years [07:02:38] not worried about any broken connections or anything [07:02:59] I haven't yet taken the trays apart, so I haven't assessed the aliveness of the erasable memory internal wires [07:03:58] hmm, unexpectedly, the RDBANK wiring is present for module A6 [07:04:22] which means even on these original AGCs, there is an extra RU control pulse in the STORE/FETCH sequences that is not documented anywhere [07:04:39] and the signal written as TO6| is indeed T06/ as suspected [07:05:40] I guess I should check that RU/ just for good measure [07:05:45] did you think these were separate signals? [07:05:54] I didn't think they'd be in this version [07:06:04] I thought they may have been a later addition for more Monitor features [07:06:14] partly because they're weird [07:06:21] and ND-1021042 doesn't show them [07:07:08] yeah, it's definitely hooked up to generate an RU/ [07:07:15] I have no idea why, but it is :D [07:07:50] a sentence I think to myself often [07:08:01] lol [07:08:55] HERB is there too [07:10:08] the wire I am pretty sure Herb Thaler named after himself [07:10:26] what about T7PHS4/... [07:12:49] doesn't sound like a first name [07:14:06] with so many wires, there has to be plenty of opportunity to name things in weird ways, haha [07:15:59] yup [07:16:11] not seeing this T7PHS4 wiring [07:16:17] must have been a very late change [07:16:42] oddly, there is something connected to the FUTEXT pin [07:16:45] but I don't know what [07:56:57] well, that was fun [07:57:06] but man am I sleepy, so I called it a night [07:57:32] almost done working through the Tray A backplane checklist, and all unknown Tray B module pins outside of modules B11 and B12 have been resolved [07:57:48] those need tray disassembly and module removal [07:58:12] but yeah, poor LTA-8 astronauts [07:58:21] having to type V33E all over the place instead of hitting PRO [07:59:24] haha [07:59:32] it's not that bad [08:00:07] say that after you do a show-banksum in Aurora or Sunburst [08:00:20] where you have to type out V33E between each and every single bank [08:00:43] that's a bunch of V33s [08:00:45] PRO is a godsend, lol [08:00:57] that was one of the first things I hacked into Borealis [08:01:47] man, so many good findings and confirmations so far [08:02:37] awesome [08:02:37] I stressed over that F10A/ thing for a long time, back when I was trying to get things running [08:22:59] cya later [13:49:47] good morning [13:50:56] good afternoon [13:51:39] i saw some apollo 9 checklist changes would it be flyable now? [13:55:48] up to a certain point it probably is now very much improved, yes [13:56:09] if you want to fly the whole mission without having to wait on updates for the later part of the mission, then I would still wait [13:56:17] okay [13:56:21] until Ryan is done with his LM ECS and checklist updates [13:56:28] and until I am done with the MCC updates [13:56:34] might fly apollo 8 [13:58:00] fun mission [13:58:07] and should be in a good state checklist and MCC wise [13:58:28] although I will give it a few updates some time before the next major NASSP release [13:58:40] and lots of p23's too [14:00:39] haha, yep [14:17:21] hey [14:20:37] hey Alex [14:20:53] Mike started working on the AGC yesterday evening :D [14:24:36] nice [14:25:00] he said he already has learned a bunch of things that were on his list [14:25:13] and it doesn't have the wiring for the PRO button [14:25:51] so LTA-8 wasn't a good procedure simulator, if it was used up to Apollo 11 :D [14:26:16] is this part of the "spacefest" thing? [14:26:53] yeah [14:27:05] the guy owning the AGC also presents it there [14:27:33] and while they are there, Mike will do a bunch of work on it [14:27:39] so this is a real AGC? [14:27:42] yes [14:27:45] ooh [14:27:48] early Block II [14:28:04] used in the LTA-8 vacuum chamber LM simulator [14:28:35] he wants to mostly check things that are confusing in the schematics [14:28:46] and maybe recover whatever is in the erasable memory of it [14:29:15] Does it have the CMC software as well? [14:29:43] LM if anything, but I don't think it has ropes [14:29:51] it has rope simulators or something like that [14:29:59] so that you can more easily change software [14:31:32] but we have no idea what the latest software used with it was [14:34:36] the end goal with this AGC is to maybe power it up [14:34:41] and load some software on it [14:35:00] it seems to be in good condition [14:37:09] that would be fun [14:39:26] but for now Mike just tries to figure out answers to questions, that brings our understand of the AGC from 99.9% to 99.99% :D [14:39:33] understanding* [14:39:54] might or might not lead to Virtual AGC changes [14:43:43] so can you load our digitized software binaries onto a real AGC? [14:44:48] yeah, should be possible via those rope simulators [14:45:08] probably not easy to accomplish though [14:45:12] but quite possible [14:51:00] Hi! [14:51:15] Hey Mikael_ [14:51:34] Hi Thymo :-) [14:51:59] Can you help me? [14:52:13] 'Sup [14:52:23] Program 23? [14:52:33] apollo 7 v8 [14:53:08] hey [14:53:16] Hi indy [14:53:17] ah right, they tested that [14:53:34] yepp [14:53:50] P23, which one is that again? Landmark sighting? [14:54:02] I think I understand program 22 pretty well now. Thanks [14:54:12] Oh midcourse. [14:54:18] but 23?! [14:54:52] First, which star, landmark and horizon field I will choose. [14:55:41] It's usually listed in the flightplan. Don't know exactly how it is in the checklist mfd, I don't really use it. [14:56:05] ok will check flightplan [14:56:27] not in checklist mfd [14:56:28] we haven't put it in the update forms document, it seems [14:56:45] true [14:56:51] Basically P23 updates your state vector by using the split line of sight in the optics to mark a start and a celestial body's (near or far) horizon (depending on what mode you are). [14:57:41] hmm i do not understand [14:57:47] Personally, I find it quite difficult to accomplish. Mostly due to the oscillating view we use because we can't create and actual split LOS due to orbiter limitations/ [14:58:07] what is the difference in a landmark and horizon mark Where do I find horizonmarks? [14:58:40] ok [14:59:08] P22 lets you mark a landmark (e.g. key west) while P23 marks the horizon of a body together with a star. [14:59:44] you superimpose the star and the Earth horizon below the star [14:59:53] yes! I am expected to carry out a superimpose star and landmark. How should I do this? [15:00:11] the keyboard key V is used to enable/disable the split LOS [15:00:26] Intressting [15:00:44] it cycles between the sextant view with 0° trunnion and where your trunnion angle actually is [15:01:01] that's how you get two directions in which you are looking at [15:01:30] this technique is exceedingly difficult in Earth orbit though [15:01:40] let me quote the Apollo 7 Mission Report [15:01:41] "A number of star/earth horizon measurements were scheduled, but all attempts to perform these sightings were unsuccessful." [15:01:57] :-)) [15:01:58] mostly because the horizon moves so quickly in low Earth orbit [15:02:07] right! [15:02:09] further away from the Earth it works fine [15:02:23] Apollo 7, being the first manned mission, just tested the techniques [15:02:39] so landmark and horizon mark are the same [15:02:40] you can also do lunar horizon/star marks, which was also tested during Apollo 7 [15:02:57] that is much easier to do, but with the lunar distance not any more accurate [15:03:12] true [15:03:37] so landmark and horizon mark are the same? [15:03:54] just at the horizon [15:05:29] no, it works quite different [15:05:41] oh wait [15:05:46] you mean landmark in P23 [15:05:53] yes [15:06:19] yeah, there you put the landmark on the 0° trunnion line-of-sight [15:06:24] instead of the horizon [15:06:43] P23 has a lmk mode? [15:06:55] I didn't know that. [15:07:06] F 07 70 I think [15:07:10] Was that ever used? [15:07:49] F 05 70 V25E Load Star Code ENTER Load Landmark Option ENTER Load Horizon Option [15:08:14] fron checklist mfd [15:08:58] Apollo 8 tested it, I think [15:09:09] the horizon option is the usual one though [15:09:15] I have an answer to your original question [15:09:20] the difference between code and option? I dont understand [15:09:50] we did a bad thing, we didn't copy over the data from the old Excel flightplan [15:10:05] there it says, for a P23 at about 123h GET [15:10:17] star 27( Alkaid), near Earth option [15:10:41] the code is just the number you use for a specific option for Noun 70 [15:10:44] The star and landmark codes specify which star/landmark to use. The option specifies which mode P23 will run in. [15:10:45] 123h 27 Alkaid.. [15:11:13] and, from my memory, you have to wait for the star to rise above the horizon [15:11:19] and then quickly start doing marks [15:11:21] So for star 23 near earth would be STAR/ENH mode. [15:11:45] because in just a bunch of minutes, the star will be too far away from the horizon [15:11:47] So: [15:11:48] R1 00027 [15:11:49] R2 00000 [15:11:49] R3 00110 [15:12:04] I think that's right, yes [15:12:20] I've got the word checklists pulled up. [15:12:24] hhmm, but 70 V25E 00027 00000 00110 confirm [15:12:44] Yes [15:12:46] OK? [15:12:56] cool I will try [15:13:06] and what also helps is if you are already tracking the local horizon with the sextant before starting the P23 [15:13:12] sextant in Zero mode [15:13:25] yepp [15:13:33] heads up, pointy end forward [15:13:48] and then quickly start once the star appears [15:13:52] 00110 if for using a star end near earth horizon, 00120 same but far horizon, 210 220 same thing but for the moon. and 000 for landmark. [15:13:56] should be directly in front, I think [15:15:51] so 00110? [15:17:21] Thank you very much for your help! I try and come back a little later [15:17:41] and they also tried the lunar option once [15:17:48] nop problem [15:18:00] mission report says star/lunar landmark [15:18:13] when do the try lunar option? [15:18:14] star Alphard, crater Diophantus [15:18:35] ok will take not [15:18:36] I'm not sure when [15:19:02] guess we have some things to add to the flight documentation before the next release, haha [15:19:18] I think so too [15:19:27] in any case, the Earth horizon option didn't properly work anyway, so it you get bad results, no problem [15:20:03] it just can't be done accurately in Earth orbit [15:21:27] Why not make an update releas for just 7apollo 7 and 8 v 8? I think I would appreciate it because most people use orbiter 2016 [15:22:41] Yea but I will try. Thanks! [15:22:43] right now we are focused on the Lunar Module and making the missions with it working [15:22:55] indy91: Might also want to look over the word checklists once again before the next release. I'm quite sure it needs some work. [15:22:57] but Apollo 7 and 8 will get updates soon [15:23:08] I understand [15:24:17] Great! [15:26:43] morning! [15:27:00] hey [15:27:17] Good evening [15:27:21] how is the fest in space? [15:28:13] it was a late night so we slept in a bit, heh [15:28:19] going to head over to spacefest proper in a bit [15:33:20] hey Mike [15:33:25] yo [15:33:41] So I hear you've got your hands on a real AGC :D [15:34:23] yep! [15:34:26] for the next few days [15:34:37] awesome [15:38:49] I forgot, but there aren't any ropes in it, right? [15:38:59] just those rope simulators? [15:41:05] right, just the interface boxes for a rope simulator [15:41:15] I'll be taking those apart too, and trying to reverse engineer them [15:41:21] once I'm done with the AGC [15:42:09] hopefully we'll be able to make use of them [15:49:35] sounds fun [17:05:01] hello again [17:06:04] just got the logitech radio panel for fsx [17:06:08] very excited [18:08:06] great [18:08:12] not much use with NASSP, haha [18:40:16] indy91, hmm really? So no one uses the new VORs I added to all the lunar bases? :D [18:40:26] damn [18:40:28] sorry [18:40:53] we need to make a modified LGC version for auto landings at the VOR, haha [18:41:26] might need something like a second RR [18:42:47] haha maybe make it work like an IRS that uses DME updates instead of LR updates [18:43:56] theoretically that would be easy [18:44:17] I could easily write GSOP equations for something like that [18:44:28] translating it to code is another story... [18:45:29] I guess DME updates would be good for updating position and velocity, but altitude would probably still need the LR [18:45:45] yeah [18:48:36] if you don't need auto landing capability, then all you really need is the LR [18:48:57] With Zerlina you can land super precise at any spot you can see [18:49:07] That would surely be interesting to implement. I bet it's possible by hooking up a custom peripheral to the LGC too. [18:49:15] But let's finish AAP first. :P [18:50:17] AlexB_88: You'll need the LR indeed. Otherwise you can't calculate the distance on the ground (Pythagoras). [18:50:47] which is why the RR only works good with a fairly accurate CSM state vector [18:51:53] right [18:52:05] When would we get around implementing stuff that hasn't already been done? I'm really looking forward to doing some custom AGC programming for NASSP. [18:52:17] it has to have an accurate point of reference (CSM SV) [18:52:47] well you can start with fixing the rendezvous programs in Artemis :P [18:53:32] Ah right. Let me just take a uni math program first. [18:53:46] coming up with and supporting custom missions is a bit of work, but in my mind it's less difficult than actually rewriting AGC software [18:54:08] so, if you have creative ideas, feel free to pursue them, haha [18:54:15] You can use Artemis as a base and just graft extra stuff to it. [18:54:32] yeah, it's a good baseline CMC to mod [18:55:15] But we'll need Auxiliary memory module for that. [18:55:19] winks at thewonderidiot [18:55:35] Unless we want to pull most useful stuff out of the rope. [18:56:23] yeah, we don't want to do that [18:56:29] we aren't Skylark programmers [18:56:41] program change request "remove lunar capability" [18:57:05] I already have some experimental code laying around so you can have multiple verb 'banks'. I added an extra verb that would swap a pointer to a different verb table. :P [18:57:56] sounds fun [18:58:03] for the astronauts to remember... [18:58:07] PCR "Add Venus capability" [18:58:28] One thing that it would need is a way to tell which bank you're in. [18:58:41] And then there's internal verb use by programs. [18:58:42] maybe an extra light [18:59:34] I guess, if we can add an extra light to a NASSP panel or something. [18:59:35] love it [19:00:22] Model an extra lamp box, similar in appearance to the ORDEAL and just have the front filled with custom AGC status lamps. :P [19:00:44] Or LCD displays. [19:01:08] If we want to throw historical accuracy out the window. [19:01:24] hey Thymo [19:01:29] Yo [19:01:52] CMC has 4 lights to spare on the DSKY [19:01:57] that's what I meant [19:03:05] That works. [19:03:39] might fly to Germany next as one of the airports is a trial for ground services x [19:04:56] .in 10d Prepare AGC reading material [19:05:25] I've gotta a feeling I'll be playing around with the AGC again during my holiday. :) [19:06:57] You guys have any holiday plans? [19:07:33] to get a job and lots of nassp and fsx [19:08:45] I'll be going to the Gulf of Roses in Spain for two weeks. [19:08:57] astronauthen96__: What sort of job are you looking for? [19:09:27] working in a kitchen i will be taking a ford course at a college starting in august [19:10:38] What do you mean by ford course exactly? Like a technician? [19:10:47] food sorry [19:11:24] Ah. I understand. Sounds like a lot of fun! [19:14:40] i would love to go to Europe one day [19:20:47] right now im flying from Munich to Vienna have you ever been there? [19:23:51] Not Vienna, but I have been to Austria on my way to Italy though. [19:26:16] Europe sound very fun [19:27:50] I would say so. However I've never really been out of Europe. Closest to being out if Europe was my trip to Turkey in 2010. [19:28:16] yeah i've never been outside of Canada or America [19:31:17] do you know if the Venus flyby mission will ever be simulated? [19:33:40] It will be. But it's gonna take a while. Niklas could probably plan a trajectory to it and I think the Saturn V has enough dV to make the trip. [19:33:57] Consumables might be a problem depending on the duration. [19:34:36] Biggest problem is the AGC. The AGC can not operate much further beyond the Moon because its state vector will overflow at too great a distance. [19:35:14] So we need to write our own software for the AGC if we want to have any kind of CMC guidance around Venus. That'll be an interesting problem to work on. [19:35:48] yeah and i guess you would need to make a flight plan too [19:36:46] It's going to be much easier to create a flightplan for a Venus fflyby initially since we don't have a crew that can die nor any experiments we need to run. [19:37:21] So the coast phase will mostly consist of purging the fuel cells and charging the batteries. [19:37:57] We could probably power down the guidance so we won't need state vector updates or realignments. [19:38:26] Could even do with the guidance system still powered since our IMU doesn't drift currently. [20:16:26] good night! [06:01:52] .tell indy91 productive first full day. We now have a 100% complete pinout for the main spacecraft connector. And the intertray connectors are about a third of the way there. All other unknowns in Tray A have been resolved. still haven't taken the two trays apart yet [07:40:09] Morning! [10:47:07] hey @Thymo [12:24:19] hey [12:24:45] that sounds like good progress [12:25:06] morning [12:25:30] great [12:25:58] and I've made some progress as well [12:26:19] I think I have the general purpose maneuvers working with the non-spherical gravity, just like the RTCC documentation [12:26:22] actually this time :D [12:27:28] so now I should be able to continue with Apollo 9, finally [12:27:36] haha nice [12:29:00] one thing I had to learn is that a circularized orbit just isn't very regular in Earth orbit [12:29:16] first, you can't have it circular everywhere in the orbit [12:29:25] except if you are in a 0° inclination orbit [12:29:33] well isnt the earth an ellipse anyhow? [12:29:34] non-spherical gravity just doesn't allow it [12:29:52] yeah [12:30:15] ellipsoid [12:30:23] that's the 3D version of ellipse [12:30:44] but I don't let the RTCC calculate the altitude above the ellipsoid [12:30:50] because that wouldn't apply to Orbiter [12:31:40] I'll show you the height over time in the "circular" orbit [12:32:08] first, this is the post SPS-6 orbit, as calculated by the new targeting: https://i.imgur.com/d1MVI7g.png [12:32:12] 95x133 [12:32:27] nice and regular, looks like a sine function [12:32:32] this is over one orbit [12:32:51] ah, it's not in meters anymore [12:34:23] here is the circular orbit: https://i.imgur.com/6oLPdln.png [12:34:29] same timespan [12:34:40] 2 apogees and 2 perigees per orbit! [12:35:05] the calculation for the burn is done with: 0 radial velocity at the maneuver point [12:35:10] the 1st one definelty looks cleaner [12:35:23] identical height 180° away from the maneuver point [12:35:56] so if you are calculating a circ burn with the GPM targeting in the future and it gives you nonsense perigee/apogee heights [12:36:18] finding the right points for that is just not really possible [12:37:23] it might even show both a lower apogee and perigee than the height at the maneuver point [12:45:09] Hey Niklas [12:45:20] I guess I just had to learn a few things about the behavior in Earth orbit with the non-spherical gravity, that's why this takes so long [12:45:22] hey [12:45:25] just flying from Munich to Vienna [12:45:33] FSX? [12:45:35] yes [12:45:46] I think I've flown that before in FSX as well [12:45:50] because Munich is one of the trial airports for ground services x [12:46:04] have you been to Vienna? [12:46:18] I have not, but a few times in Munich [12:47:21] the reason for Vienna is because its a short flight [12:47:34] yeah, that's not very far in the air [12:47:57] i would love to visit Germany one day [12:48:08] plenty of things to visit here, haha [12:49:15] and a ten hour flight from Vancouver would be fun [12:49:20] love flying [12:49:29] 10 hour flights are rarely fun [12:50:49] at some point you just want to be able to walk around again, haha [12:52:37] would love to be a pilot one day [12:53:28] you have a few of them in this chat as regulars [12:53:53] yeah and i am almost 22 so i don't know if its too late [12:55:10] also for the p23 am i supposed to align the star in the middle of the sextant? [12:55:14] that doesn't sound too late at all [12:55:20] yes [12:55:33] star and horizon both [12:56:23] I haven't properly looked into that, but I think it's more important to have the star and the horizon (or landmark superimposed) than it is to have them both centered [12:56:27] not quite sure though [12:56:51] (or landmark) superimposed* [12:58:34] a bit confused about this picture https://image.ibb.co/k3sxmd/P23_Sextant.jpg [12:59:49] I think that is supposed to be the Earth [13:00:59] actually, we also had/have a hard time figuring out this stuff, because not a lot of training material has survived [13:01:07] and what has survived isn't very detailed [13:02:57] look at this [13:02:58] https://www.ibiblio.org/apollo/Documents/ApolloTrainingGuidanceAndControl_09-67.pdf [13:03:14] PDF pages 98 and 99 [13:06:37] astronauthen96, 22 is definitely not too late :) [13:07:09] Hey Alex [13:07:16] yeah i just really love flying [13:07:21] hey [14:12:00] Afternoon [14:23:40] hey Thymo [14:36:39] hey [17:57:19] later! [00:12:16] .tell indy91 I should be on tomorrow to ask, but before I forget now, how can I make the actuator override switches on the LM suit isol valves spring loaded? [12:49:20] Good morning [12:53:47] hey [12:53:54] Ah yes [12:54:00] I knew I would forget! [12:54:34] I coded the suit isol valves in the LM because I was getting frustrated with the checklist and needed a lateral break [12:56:32] so what do you want to do? [12:57:23] Ok the actuator override switches themselves from what I am reading are just spring loaded switches [12:57:41] So they have to be held in actuate override and they spring back to the other position [12:57:42] so you have to keep them pressed? [12:57:45] ah [12:58:13] However they dont need any hold code like the asc o2 lock [12:58:34] if it doesn't need special code, then it's easy [12:58:43] If the suit is in flow, they simply force the suit into disconnect [12:59:09] what you want is the Register function of the switches in lempanel [12:59:40] CDRActuatorOvrd.Register(PSH, "CDRActuatorOvrd", TOGGLESWITCH_DOWN, SPRINGLOADEDSWITCH_DOWN); [12:59:47] Thats what I tried with no luck [13:01:55] that should be right [13:02:00] we had this problem before I believe [13:02:24] it was a problem with the panel area or so [13:03:39] someone did a bad job with the panel identifiers there [13:04:22] Ah [13:04:37] Well the rest of my code seems to work right for the valve behavior [13:05:13] no, not functionally bad, just bad style that potentially could lead to problems [13:05:18] I'll guide you through it [13:05:20] find [13:05:20] oapiRegisterPanelArea(IDB_LEM_ISOL_ROTARY [13:05:28] rename it from IDB to AID [13:05:56] then you will need to add that AID in lmresource.h [13:06:06] Ok [13:06:20] this is just to fix the sloppy code [13:06:31] SuitIsolSwitchRow.Init(IDB_LEM_ISOL_ROTARY, MainPanel); [13:06:36] change it to AID there as well [13:06:44] Sure [13:07:00] in lmresource you just need to add that additional line [13:07:17] #define AID_LEM_ISOL_ROTARY 2004 [13:07:51] the problem here is that the same identifier was used for the bitmap of the rotary as well as the identifier of the panel area [13:07:52] Wait am I changing it to AID in lmresource or leaving the IDB and adding a new line [13:08:07] Oh never mind [13:08:08] I see [13:08:12] add a new line, yeah [13:08:18] it should be separate things [13:08:35] it doesn't cause problems, because the bitmap is only loaded once there [13:08:41] still, bad style [13:09:52] the actual fix is in the oapiRegisterPanelArea(IDB_LEM_ISOL_ROTARY, line [13:09:55] or with AID now [13:10:01] it has [13:10:02] PANEL_MOUSE_DOWN [13:10:20] so it can only check the mouse click, not the release of it [13:10:28] it needs to be [13:10:29] PANEL_MOUSE_DOWN|PANEL_MOUSE_UP [13:10:32] just like the line above [13:10:42] that is required for springloaded switches to work [13:10:48] had the same issue with the ED switches [13:11:22] BAck to the adding the line in define, didnt I already change the line 778 to #define AID_LEM_ISOL_ROTARY [13:11:52] Or am I leaving the IDB and adding AID's in addition [13:12:05] in lmresource [13:12:06] don't change a line at all there [13:12:09] you need both [13:12:12] Ah ok [13:12:20] just an addition [13:12:39] one identifier for the bitmap of that rotary [13:12:57] and one for the panel area that includes both the CDR and LMP rotaries [13:13:07] IDB for the bitmap, AID for the panel area [13:13:26] I think this is Alex's fault, haha [13:13:32] and we've been slowly fixing it over time [13:14:12] Ok let me push it to my repo and you can take a look [13:15:45] https://github.com/dseagrav/NASSP/compare/Orbiter2016...rcflyinghokie:Orbiter2016?expand=1 [13:16:17] not right [13:16:28] you changed too much [13:16:29] LOADBMP (AID_LEM_ACT_OVRD) [13:16:44] that should be the loading of the bitmap [13:16:45] IDB [13:16:48] not the AID [13:16:53] Oh oops [13:17:32] did you add two new identifiers? [13:17:42] In lmresource? [13:17:44] yeah [13:17:51] you only need one new one [13:18:05] Ah ok [13:18:09] I guess AID_LEM_ACT_OVRD is the better name for it [13:18:17] so you don't need AID_LEM_ISOL_ROTARY [13:18:26] only IDB_LEM_ISOL_ROTARY [13:18:28] Forgive me for not knowing well how this all works haha [13:18:53] all in all just separate identifier for bitmaps and panel areas [13:19:41] the bitmap identifier is associated with the path of the bitmap file in LEMResources.rc [13:19:58] the panel area identifier with the oapiRegisterPanelArea [13:20:12] that's where the panel area is registered [13:20:35] Oh ok [13:20:46] Like putting the pieces together [13:20:53] yeah [13:20:58] overlaying the main bitmap of the panel [13:21:21] and in all the init functions the panel areas are associated with the switch row and the switches on it [13:21:31] SuitIsolSwitchRow.Init(IDB_LEM_ISOL_ROTARY, MainPanel); [13:21:35] this being the old version [13:22:07] took me a while to figure it out, so for a long time I didn't do any panel changes [13:22:23] my first attempt was the ORDEAL in the LM, and that didn't work out at all [13:22:32] tried again some months later, now it works [13:23:20] Well let me build and see what happens [13:23:45] I think the behavior of the isol valves is correct from what I have read [13:23:52] can you push it again? [13:24:01] Ah yeah [13:25:31] Pushed [13:25:53] ok, I am super confused now [13:26:24] Which part [13:26:25] ah [13:26:33] oh in general, not your changes [13:26:41] Lem_Act_Ovrd.bmp is a separate bitmap just for that switch [13:27:33] Hm build error [13:27:35] and then Lem_Isol_Rotary.bmp [13:27:42] Severity Code Description Project File Line Suppression State [13:27:43] Error C2065 'AID_LEM_ISOL_ROTARY': undeclared identifier LEM d:\orbiter 16 beta\orbitersdk\samples\projectapollo\src_lm\lempanel.cpp 1868 [13:27:47] yeah, yeah [13:28:25] so, I think, we should use AID_LEM_ACT_OVRD for the panel area [13:28:33] no [13:28:35] wrong again [13:28:45] AID_LEM_ISOL_ROTARY only [13:29:05] that's the only thing you need as an addition in lemresource [13:29:18] and not AID_LEM_ACT_OVRD [13:29:30] because, the panel area is for both of those rotaries [13:29:42] and the actuator override is just a small part of it [13:30:16] so if you used AID_LEM_ACT_OVRD anywhere, replace it with AID_LEM_ISOL_ROTARY [13:30:51] Ok [13:31:14] I think it is only that line [13:33:02] srf[SRF_LEM_ISOL_ROTARY] = oapiCreateSurface (LOADBMP (AID_LEM_ISOL_ROTARY)); [13:33:06] I think that also needs fixing [13:33:10] you changed it to AID [13:33:16] but that's the bitmap for the rotary [13:33:55] Guess the search failed me :P [13:33:58] But yes you are right [13:34:16] I'm looking at the compare on Github [13:34:45] Well I did a ctrl F in VS, but spelled it wrong :P [13:35:14] haha [13:35:33] this is only 3 lines of changes, I think [13:35:44] we made it more complicated than it needed to be, haha [13:35:57] haha I usually am good at that [13:36:16] Though I was pleasantly surprised I remembered how to do the coding for the isol valve [13:36:23] It had been a little [13:36:46] I *think* I have all the right components in the appropriate files [13:37:29] Ok latest pushed [13:38:26] https://github.com/rcflyinghokie/NASSP/compare/rcflyinghokie:06f0012...cc06ac8 [13:38:57] looks right [13:39:31] And for my isol valve code, I am 95% sure the behavior is correct based on the information I have [13:39:45] It doesn't break anything and the behavior matches the checklists at the very least [13:40:56] I will test it a bit further before asking it to be merged though, especially with the switch behavior changes [13:41:27] well, what else did you change? [13:41:37] not just the override actuator? [13:42:05] I added the behavior code for the solenoid in the valve [13:42:18] oh, a new LEMSuitIsolValve class [13:42:24] Yep [13:42:46] Thats what led me down this rabbit hold to the switches [13:42:51] hole* [13:42:56] not a very deep hole [13:42:59] Thankfully no [13:43:06] can you explain what this code does? [13:43:09] Very simple system, assuming I have the behavior correct [13:43:11] it needs the suit flow CB [13:43:12] Sure [13:43:35] The suit flow CB is what powers the solenoid in the valve [13:43:54] So that has to be powered for any solenoid behavior [13:44:03] Then we have the suit pressure switch [13:44:08] Which was thankfully already implemented [13:44:29] So if the cb is powered, and the switch trips, it puts the suits into disconnect [13:44:43] ah right, now I remember this [13:44:47] That way it isolates them from the LM ECS in case of a problem and they can connect to PLSS or OPS [13:44:59] makes sense [13:45:25] and what does the actuator override switch do? [13:45:28] And the actuator override allows the solenoid to switch the valve to suit disconnect if there is no problem [13:45:33] override actuator* [13:45:50] ah, so manual switch to suit internal [13:45:53] Yep [13:46:06] And there is a checklist step that actually tests this [13:46:11] So now the behavior matches [13:46:16] and that also needs power from the CB? [13:46:37] For the valve to turn on its own, yes [13:46:48] Now the one thing I was unclear about [13:47:01] I mean the override [13:47:08] with your logic, it needs the CB to disconnect [13:47:29] That goes with my unclarity [13:47:41] I dont know if the valve is held in suit flow if all is well [13:48:08] Right now I have it so if all is well, the crew can turn it freely from flow to disconnect [13:48:23] Even with power [13:49:03] But I do know for the valve to move using the actuator (be it from the pressure switch or the override) the solenoid needs power [13:49:14] hey [13:49:18] hey Alex [13:49:24] If it is unpowered it seems as if it can move as the crews leisure if that makes sense [13:49:28] Morning Alex [13:49:47] yeah, the logic is probably right then [13:50:15] whats up? [13:50:50] implementing one of the last LM ECS pieces [13:51:18] suit flow actuator override [13:51:27] But my only puzzle is does the solenoid prevent the suit from being turned to disconnect from flow if all is normal [13:51:37] I need to read some more eva checklists [13:51:52] I think the steps might answer that, as they did the override behavior [13:52:39] But the bones of the class is sound [13:53:58] The default position for the valves is disconnect, so I also need to see if deenergizing the breaker would make them go back to disconnect [13:54:49] yeah, not sure from the description in the Systems Handbook [13:55:15] I found a little more here [13:55:22] https://history.nasa.gov/apollo.engin.html [13:55:28] Under "The Suit Circuit" [13:55:42] And then the LM-8 schematics [13:55:47] But thats all I really have [14:00:27] Interesting, the iso vlv breaker was eliminated on J mission LMs [14:13:44] Ok it looks like, based on checklists, that my code is the right behavior [14:14:23] They can move them from suit flow to disconnect even with no pressure switch tripped and the breaker energized [14:15:07] Makes me wonder what powered it in J-mission LM's with the deletion of that breaker though [14:17:10] Oh never mind, wrong isolation valve breaker :P [14:27:14] Looks like the valve behaves properly [14:27:23] Now to press on with these EVA checklists [14:29:58] How do I connect this PR with my open issue about them? [14:36:31] I think I figured it out [14:51:08] Other than a hold in the checklist, is there a way to make the switch hold long enough to trigger the code to make the valve disconnect? [14:51:24] I think we had a similar problem with battery switches and the checklist [14:52:41] SetDelayTime? [14:52:56] yes [14:53:36] that should do it [14:55:27] I will add that [14:57:36] Works [14:58:47] what is the else { return; } for [14:58:59] in LEMSuitIsolValve::SystemTimestep [14:59:01] I guess it isnt needed [14:59:21] I originally had code there but realized that it was not necessary [14:59:38] Can I remove the else entirely? [14:59:43] yeah [15:00:51] How does that look? [15:02:32] Also I meant to ask, is there a cleaner way to have the breaker in the code? [15:03:24] Or is having the same breaker in both CDRIsolValve.Init and the LMP the best way [15:03:51] Just seems there is a way to not have to point to the same breaker twice if that makes sense [15:05:15] Hm I might have a way [15:06:51] just lem->CircuitBreaker [15:06:55] Yep [15:06:56] and not give it as a pointer in the init [15:06:57] Thats what I did [15:07:16] makes thing simpler [15:07:19] things* [15:07:56] Does that look right? [15:11:29] looks very good [15:11:31] can I merge? [15:11:44] Yep [15:11:46] Works [15:11:48] done [15:11:51] Thanks [15:12:28] Now back to EVA checklists [15:12:42] I also closed the issue on the implementation [15:28:33] Hmm this ins interesting, for an ARS purge procedure, the CO2 canister select is kept "midposition" [15:28:36] *this is [16:21:54] Any idea how designating the RR for EVA was performed? [16:22:09] I know it is slewing, but where they were supposed to park it [16:42:22] I've seen that on cue cards I think [16:44:08] hmm, can't find it there [16:44:26] but isn't it usually pointed straight up for thermal reasons on the lunar surface? [17:00:04] Yeah [17:00:24] But this is for the 9 EVA I would imagine the angles are different [17:02:32] oh, Apollo 9 [17:02:39] Yes [17:02:40] Sorry haha [17:02:52] We have many of the angles for LS park/stow [17:03:00] But this of course is a unique case [17:33:44] Hmm I just resumed from a few minutes of 30x and got a CMC light, PROG and RESTART in the CM [17:34:01] maybe a framerate drop of some kind [17:34:06] Ah possibly [17:34:09] I am on the laptop [17:34:13] Not plugged in [17:34:25] Hopefully nothing got messed up [17:36:29] Hmm I ran an RTCC nav check [17:36:41] Looks right [17:37:04] hopefully your DAP padload didn't get scrambled, haha [17:37:05] But the LONG is /2 in the pad, but not in the CMC [17:37:08] good morning [17:37:11] Is that right? [17:37:26] -11994 in the computer -06121 in the RTCC [17:37:35] Good afternoon [17:37:42] hey [17:37:48] what page did you use? [17:38:10] nav check [17:38:23] And a P21 [17:38:57] I don't think that page has long/2 [17:39:29] if it was, then it would still be more than 1° off [17:39:43] what is your actual longitude? [17:39:44] PAMFD [17:41:44] screwed up my first ils approach [17:42:09] Uh oh [17:42:26] I am very familiar with those if you need help [17:42:29] indy91, one sec [17:42:45] I would guess you now have a bad state vector [17:43:15] pad.lng[0] = lng*DEG; [17:43:18] no half [17:43:32] not sure why it says (VECTOR) in my route in the fmc [17:44:16] you called the wrong hotline if you need FSX support :D [17:44:39] yeah im searching about it now [17:46:17] I can give you the save if you wish to see [17:46:52] Oh VECTOR means the approach you are using is looking for vectors versus a published approach procedure [17:47:18] So ATC would give you those [17:47:28] I don't need the save [17:47:34] you should check P21 vs. PAMFD longitude [17:47:38] just to be sure [17:47:39] Ok [17:48:00] and if they don't agree, you probably better revert to an older save. No telling what else is broken [17:49:18] I think only the navigation programs P22 and P23 use the long/2 format [17:49:27] to get the extra digit for precision [17:53:44] yet another CMC restart? :D [17:53:50] Yep! [17:54:02] Didnt get my charger fast enough [17:54:27] hate when that happens during LOI [17:56:11] Haha [17:56:27] P21 all zeroes for N34 is present time, correct? [17:56:36] It's been a minute since I have used it [17:57:44] I'm not quite sure that was already a thing in Colossus249 [17:58:01] Maybe thats why it is hanging [17:59:07] Yeah my longitude is exactly twice what it displays in PAMFD [17:59:22] Just like it was with RTCC [17:59:44] I think its time to revert [18:12:47] trying to find when that was changed [18:12:53] found it for Luminary at least [18:13:06] PCR 807.2 "Add Present Time option to P21" [18:13:14] that was for Luminary 1B [18:13:32] so I would expect that it was added for Apollo 12 in Colossus also [18:14:40] Well looks like my CMC was corrupted [18:14:49] Upon revert the P21 and RTCC and PAMFD agree [18:15:38] annoying that that happens [18:15:47] but I would bet it was a framerate drop or so [18:15:58] Yeah low battery laptop probably throttled the gpu [18:16:00] same effect you would get, if you used too much time acceleration [18:23:22] Everything seems copasetic now [19:48:10] I've finished what I needed for the general purpose maneuvers yesterday. Just need to do SPS-6 once as a test, then I'll properly continue with Apollo 9 [19:50:00] so, progress within the next few days, haha [19:52:52] Wonderful [19:52:59] I am still hammering out the flow of the EVA [19:53:08] Once I pass this it should be very fast [19:53:26] I have the rendezvous procedures pretty well written and practiced [19:57:49] and the next time you fly the rendezvous, not this time, you will actually be in a circular orbit [19:58:40] with the new, better targeting [20:02:26] oh, I haven't shown you yet how a "circular" orbit looks in the non-spherical gravity field of the Earth [20:02:30] I find it very amusing [20:03:03] https://i.imgur.com/6oLPdln.png [20:03:09] this is one orbit, not two [20:03:15] one revolution* [20:03:39] two apogees, two perigees [20:07:10] Haha [20:07:21] Is that in orbiter? [20:08:44] simulated with a MATLAB script, but using the same harmonics of the gravity field as in Orbiter [20:08:49] J2-J4, no drag [20:09:36] Haha its funny to think about [20:09:45] Thank you mascons :) [20:09:59] And non spherical planet [20:10:11] it's mostly the Earth being flatter at the poles [20:10:20] the J2 value caused by that is very strong for the Earth [20:10:33] very regular and predictable, but strong [20:12:26] I guess you can't have a circular Earth orbit that has the same altitude everywhere [20:12:32] except for an equatorial orbit [20:12:50] that in turn wouldn't be so for a lunar orbit, because of the mascons [20:13:09] effect wouldn't be as strong, but irregular [20:13:56] I let it show me these graphs, because I wasn't understanding why the RTCC had problems finding the perigee and apogee positions [20:14:28] but I guess those calculations simply become meaningless for that kind of orbit [20:14:51] too circular [20:16:45] So the targeting should work for 9 now pretty well? [20:17:16] yeah, the version up right now is fairly bad for circularization and targeting specific apogee/perigee [20:17:27] that will work much better now [20:18:02] the early SPS burns are mostly nodal shifts and that targeting already works right [20:18:23] but this will be good for SPS-5, circularization, and SPS-6, lowering perigee to 95NM [20:18:48] SPS-7 is this maneuvering putting the perigee in a specific location, that I haven't added yet [20:18:51] maneuver* [20:19:03] and SPS-8 is your standard deorbit maneuver [20:19:18] so I just need to work somethin out for SPS-7 and we are good for Earth orbit maneuvers [20:20:24] Excellent [20:20:35] and the display on the RTCC is changed now to be 95% identical to the actual RTCC display for the general purpose maneuvers [20:20:45] RTCC MFD* [20:20:46] Oh cool [20:20:56] very detailed about the apogee and perigee [20:21:08] time, latitude, longitude, altitude [20:21:29] For earth orbit or earth and lunar? [20:21:50] I have focused on Earth orbit, but all this should apply to lunar orbit as well [20:22:14] it wouldn't have been used in many cases in lunar orbit [20:23:52] one application would be the shaping maneuver that Apollo 15 and 16 (I think) did [20:24:20] When was that performed [20:24:27] after LM jettison [20:24:42] 55x75 orbit [20:24:48] and perigee in a specific location [20:24:59] to minimize mascon effects, according to the SCOT [20:26:21] another application that can now be easily done is lowering the perigee for a time critical LM ascent [20:27:17] I didn't know about the shaping maneuver, that's interesting [20:27:24] but it's a very versatile tool in general [20:27:30] like 60 different maneuver options [20:28:16] but as I said, most useful for Earth orbit stuff [20:28:36] Right [20:28:40] I think it is another remnant of Gemini actually [20:28:44] just expanded for Apollo [20:28:46] Makes sense [20:31:31] Welp, dinner date time, take it easy and thanks for the help with that switch! [20:39:06] I'm off as well [05:38:34] .tell indy91 I have officially resolved all unknown pins in the entire AGC -- I think I finally have the whole darn thing mapped out [05:39:18] .tell indy91 I also had a much easier time of determining the internal configuration of B11 and B12 (the potted modules) than I thought I would [05:40:02] .tell indy91 also Charlie Duke and Fred Haise stopped by to check it out, and Walt Cunningham wished us luck [06:54:56] . [06:55:19] hey Niklas [06:55:41] hey [06:55:46] sounds all great [06:58:09] :D [06:58:42] I've also measured all the factory tuning resistors in tray B, other than the oscillator module [06:58:53] need to do that for the power supplies and interface modules tomorrow [06:59:03] yeah [07:00:14] had a food look at the rope simulator interface yet? [07:00:17] food?? [07:00:23] good* [07:04:01] lol [07:04:09] a bit [07:05:15] I managed to remove the side off of one of the boxes [07:05:30] it's pretty tightly interconnected so I only got the one side off [07:06:27] I'll upload the pictures of that, one sec [07:10:49] almost there [07:11:50] haha [07:12:33] indy91: https://imgur.com/a/ctqc9TA [07:13:41] incredibly well preserved [07:14:03] yeah, it's beautiful in there [07:14:25] it's really surprising too, since there's no gaskets or anything on this module to keep it air-tight, like the AGC itself [07:14:39] I'm not really sure why it is so clean [07:15:49] where was it all these years? [07:16:12] scrap metal warehouse, garage, possible rained on at times... [07:16:41] also interestingly, that LM109K has a date code of 7026 [07:17:16] which means that this box was built no earlier than mid-1970, unless this is just a replacement part [07:17:32] hmm [07:17:37] LTA-8 was done in 1968, so this AGC went on an adventure [07:17:39] must be replacement [07:17:43] and this box was for some other purpose [07:18:11] so you think this AGC was used for something else after LTA-8? [07:18:32] why else would it have a rope memory simulator box in it, and why would there be a part from 1970 in said box? [07:18:38] right [07:19:24] if it was used for something up to ASTP or so, then that would mean it had been preserved and maintained for 10 more years after LTA-8 [07:19:36] so 10 fewer years of being abandoned [07:20:14] scrap metal warehouse where? [07:20:52] somewhere around Houston? [07:21:31] yeah [07:21:41] it was rescued from the warehouse in '76 [07:21:46] not sure when exactly it went there [07:22:25] maybe not that much earlier [07:22:44] yeah, can't have been too much earlier or it would have been scrapped [07:24:22] LTA-8 wasn't used anymore from 1970 on and put on display, it seems [07:24:34] so they probably removed the AGC and used it for something else [07:25:08] what is the designation of this AGC? [07:25:43] I'll do a bit of reading, maybe I can find some mention of it from the early 70s [07:26:01] serial number 14, part number 2003100-071, designation 602 [07:26:35] thanks! [07:26:54] I gotta go to sleep though, early morning tomorrow because I gotta check out before dragging the AGC down to the booth to set it up [07:27:00] had to be used for something useful [07:27:06] good night! [07:27:22] night! [06:15:20] good evening [06:42:34] hey [06:44:41] have to go again, cya later [14:21:56] good morning [14:22:12] just did my first ils landing [15:07:56] hey [15:08:41] so what you are saying is that you did your first simulated, instrument aided lunar landing with a LM before your first instrument aided landing with an aircraft [15:08:58] yes [15:09:11] I find that quite amusing, haha [15:09:25] maybe you just like Grumman better than Boeing :D [15:10:01] yeah [15:11:35] but of course landing on the moon is harder than landing in Portland [15:12:17] especially setting yourself up for the lunar landing, takes about 100 hours [15:12:40] what do you mean 100 hours? [15:13:01] you mean from liftoff till the end of lem activation? [15:13:29] haha, yeah, but I guess that's not really a fair comparison [15:14:09] but what I meant was, that once you are in the position for a lunar landing, most of the difficult stuff has already been done [15:15:07] anyway, I've been stuck working on some calculations for a while, but now I am finally continuing with Apollo 9 [15:15:13] up to the day with the landmark tracking now [15:15:46] great to hear [15:17:34] still need to work on getting my p23's right [15:18:19] so does the Orbiter developer :D [15:18:25] the Earth isn't shaped right [15:19:11] i didnt know that [15:27:33] now i have 3 vehicles to memorize [15:31:31] morning! [15:31:33] https://photos.app.goo.gl/DFKiFgJ7piLSmuY2A [15:31:41] also ND-1021042 is being scanned [15:31:47] volume 1 of it, rather [15:32:20] Hey Mike [15:32:30] is that something your building? [15:33:10] that is a real, original Apollo Guidance Computer that I spent the past few days with [15:33:31] very cool [15:35:33] is that you in the space suit? [15:36:02] no, that's the guy who owns the AGC [15:36:36] https://scontent-sjc3-1.xx.fbcdn.net/v/t1.0-9/36736055_626636291051731_509722333527670784_n.jpg?_nc_cat=0&oh=3e43dd97990c5223d314c7c9a4141768&oe=5BDFB96C [15:36:49] https://scontent-sjc3-1.xx.fbcdn.net/v/t1.0-9/36774680_626636301051730_1129051051333255168_n.jpg?_nc_cat=0&oh=7ea0cc427c9d4f89e9dc446b38bb2650&oe=5BE44227 [15:36:55] those are some shots of me working on it [15:37:18] that's a few photos of the AGC [15:38:19] was there a dsky as well? [15:39:01] also, hey Mike :D [15:39:03] oh what is this [15:39:05] a Maneuver PAD [15:39:19] must be Apollo 8 [15:39:38] CAPCOM copy probably [15:40:14] not sure whether to do 7 or 8 next [15:41:22] I'd suggest 8 [15:41:45] probably easier [15:42:44] and nice and short [15:43:01] not much boring coasting to wait what system falls apart first [15:43:02] yeah, from 8 -- Chuck Deiterich gave me a copy of those [15:43:33] "use high speed procedure with -MA", haha [15:43:46] is that Charles Duke in some of your pictures Mike? [15:44:01] yeah, Charlie stopped by to see what we were up to [15:44:11] so did Fred Haise, Walt Cunningham, and Al Worden [15:44:17] and Rick Armstrong (Neil's son) [15:44:24] lucky you [15:45:12] yeah that pad is most likely from 8 because of the GET [15:45:50] and because the issue making that "high speed procedure" necessary was fixed by Apollo 10 [15:46:11] CMC software issue [15:46:53] and because Chuck Deiterich, who was a flight controller, told me it was from 8 :P [15:47:13] anyways gotta head to work, be back shortly [15:47:25] ok, cya later [15:47:58] our Maneuver PAD is complete, but some of those values on the Entry PAD aren't calculated yet in NASSP [15:48:08] mostly those reentry times [15:48:18] it requires a simulation of the reentry, which we don't do yet [15:48:55] RETBBO and RETEBO are black begin and end [15:48:58] blackout* [15:49:30] eventually I'll add that [15:50:45] do you think there will ever be a way to "create" the lem before ejection? [15:51:51] yes [15:52:14] when we have stages as separate vehicles docked to each other on the launchpad [15:52:19] that is a long term plan [15:52:38] already not a certain one, there might be obstacles that will prevent that from working well [15:52:45] although* [15:53:19] I've done some tests on that actually [15:53:29] I did a https://en.wikipedia.org/wiki/AS-203 style mission [15:53:40] basically docked to each other: S-IB + S-IVB + Nosecap [15:53:54] and there were some weird issues, but it got into orbit [15:54:19] so I am hopeful [15:54:37] that approach would also make things easier in some ways [15:54:55] you would be able to simulate a realistic S-IB as a standalone vehicle [15:55:04] or missions without CSM etc. [16:03:16] @indy91 well i have to head out now i will talk to you later [16:03:32] and keep up the good mcc work [17:03:55] back! [17:04:38] if I had known you would meet Chuck, I had a question for him I wanted David Woods to ask him two years ago, haha [17:04:47] hahaha [17:04:53] sorry [17:05:23] hopefully he'll be there next year [17:05:24] just an acronym we couldn't figure out, that he probably has long forgotten [17:05:34] what is it? [17:05:48] GERU [17:06:10] and what's the context it's used in? [17:06:23] the high speed procedure with -MA, as on that Maneuver PAD [17:06:58] it's the radius measured from the Earth of the CSM at the maneuver point [17:07:18] there is no program to display it, so you have to look at an erasable, in octal [17:07:35] there is a procedure difference between far away vs. closer to the Earth [17:08:04] hmmm [17:08:20] in source code it's called ALT [17:08:28] ah, so might be altitude, not radius [17:08:41] in any case, the display on P21 or V82 is only up to 9999.9NM [17:08:48] but the octal is double precision, actual altitude [17:08:59] so you can check the octal to find out the actual altitude [17:09:00] hmm [17:09:04] even beyond the display limit [17:09:23] and that's called GERU in the Apollo 8 CMP checklist [17:09:34] if GERU > 07990, do this [17:09:38] if not, do that [17:10:36] our theory was, that the -MA procedure is a bit unsafe, when you try to do a return-to-earth maneuver too far away [17:10:43] P37 would break down or so, not sure [17:10:49] so you iterate on the TIG [17:11:04] until the altitude is smaller than the threshold value [17:11:19] this is always for the case of an already completed TEI [17:11:56] hmm [17:11:57] I wonder if it isn't anything about altitude [17:12:00] so maybe ER is Earth Return [17:12:08] that could be, yeah [17:12:30] in the checklist it usually is: [17:12:36] F 06 43 LAT, LONG, ALT [17:12:41] to explain what is displayed [17:12:43] for this it is [17:12:48] V6N2E, 1107E [17:12:49] and then [17:12:52] F 06 02 GERU [17:14:17] anyway, not so important, just an acronym [17:14:20] probably [17:14:30] hahaha [17:14:31] probably [17:15:04] my other theory I just had is that it's something with Noun 2 [17:15:07] and not altitude at all [17:18:37] anyway, tell me a story about Erasable Memory Module B12 [17:18:47] haha [17:19:25] well, it doesn't have any signals that come out, go across the backplane, and go back in, as I was thinking it would [17:19:28] which made things easier [17:19:49] I was thinking it would do that because it had a lot of pins I couldn't account for [17:20:07] but it turns out, it just takes in some of the addressing signals on multiple pins [17:20:27] each individual addressing pin is connected to only 8 diodes [17:20:59] and I think I mapped out every diode in it, although I need to sketch out a schematic and see [17:21:12] anyways, addressing all looks good [17:21:23] I didn't have the time to assess the health of all of the rest of the wires (sense lines, etc.) [17:21:29] so that is on the task list for next time [17:21:49] which is next year? [17:21:55] nah, some time this year [17:22:05] Jimmie said I can drop by and see it whenever I want to, haha [17:22:13] and I think there might be an event in Texas in November [17:22:39] I heard Fort Worth is a nice citiy in Texas [17:23:07] really? seems like there would be nothing to do there [17:23:10] I don't know why anybody would want to go [17:23:44] yeah, just paper dust [17:23:49] some of that AGC wiring doesn't look like it would enjoy too many Gs [17:23:56] haha yeah [17:24:01] that is why it was all potted for flight :D [17:24:20] I think 20G was the design limit of most things [17:24:28] at least they shouldn't fall apart before that [17:24:55] 12G is the most you would ever expect for maneuvers you want to survive [17:25:37] hahaha [17:25:41] which is most maneuvers, I assume [17:25:55] Apollo 7 Mode II abort would come close to it [17:26:12] because its insertion altitude was higher than all the other missions [17:26:24] so if you had to abort at high altitude, but still low speed [17:26:29] you come it pretty steep [17:26:31] in* [17:26:55] ouch [17:27:27] they redefined that limit for Apollo 7 actually [17:27:59] "The current AS-205/101 launch profile forced the abort limit definition to be modified because of excessive entry loads for aborts from the nominal trajectory" [17:28:06] SpaceX style redefining limits [17:28:41] hehehe [17:40:53] man [17:41:26] they stopped scanning ND-1021042 volume 1 like... 5 pages before the start of the AGC section, for which we're missing all the pages in Don's copy [17:41:30] I want to see those darnit [17:41:31] lol [17:42:24] lunch break [17:42:48] or that's all there is in this document [17:42:51] haha, it is about that time there [17:42:55] nooooo [17:42:58] sorry [17:43:17] this one was thicker than volume 2 in the pictures ;) [17:48:38] have you ever played around with GMAT? [17:48:46] your company might be using it for some stuff [17:51:03] I played around with it a bit, a few years back [17:51:10] I think we might be using STK... not completely sure [17:51:27] I've tried it today for the first time [17:51:51] hahaha oh really? that is hard for me to believe [17:52:23] yeah, weird, not even used it at uni [17:52:35] all the functions I am using in the RTCC are mine, I only ever copied algorithms from text books [17:52:43] even my MATLAB scripts are all by me [17:52:57] so I wanted to verify them by an external program [17:53:09] GMAT sounds like a good choice for that :D [17:53:13] yeah [17:53:30] took the state vector from the "circular" Earth orbit of Apollo 9 [17:53:40] and created the same graphs as I did in MATLAB [17:53:42] Hey [17:53:49] and it showed the same, yay [17:53:51] hey Thymo [17:54:10] Those pictures look awesome Mike. You can't believe how jealous I am right now! [17:54:46] hehehe [17:56:01] GMAT doesn't seem to be very difficult to use [17:56:17] maybe I can use it for some free return trajectory planning [17:56:29] for planning of alternative launch date missions [17:57:54] mostly to come up with times for flight plans [18:00:20] thewonderidiot: What are these? https://photos.google.com/share/AF1QipN4bqCB86u-F627U9OwV6mQCVPHQvMeyLCZ8OIx_beaYW6Hb-Z6jPeK_SkJ150R0g/photo/AF1QipMDVpsyLS-r3OkUf9KqfqOu919mIkTjs0GvlMOc?key=UlJqMFNXZ1ZtVkJtNUM2RGI2anREcVpkUXM4elVR [18:00:39] that is a fantastic question, and I would love if you could figure it out :D [18:00:48] they're rope simulator boxes from some piece of test equipment [18:00:52] but I have no idea which [18:00:56] they're not simfam or portafam [18:01:32] and they were either constructed, or repaired, as late as mid-1970 [18:02:55] actually, I'm going to send an email to Hugh and see if he has any idea [18:03:24] yeah, he might know [18:04:50] Looking at the wiring it appears to do some kind of multiplexing/amplifying. [18:05:03] Or some buffer if this is a clock: https://photos.google.com/share/AF1QipN4bqCB86u-F627U9OwV6mQCVPHQvMeyLCZ8OIx_beaYW6Hb-Z6jPeK_SkJ150R0g/photo/AF1QipODqVZgfwgmU6LsXfhIInaFwy3_h5uij6Zr-8GA?key=UlJqMFNXZ1ZtVkJtNUM2RGI2anREcVpkUXM4elVR [18:05:32] the LM109 is a 5-volt regulator [18:05:40] I have no idea what in this box would need 5 volts though [18:08:11] Some of the wires appear to go directly to the AGC connector. Wonder if that's pulling or providing power/signal. [18:09:05] I also wonder why the alarm module is marked as non-flyable. Not so rigorous testing maybe? [18:12:13] if I had to guess, it's because of a design change they made to later versions of that module, that improved temperature stability of the oscillator alarm circuit [18:12:45] and I know the full pinout of the AGC-facing connectors [18:12:58] which wires do you mean? [18:14:17] These: https://photos.google.com/share/AF1QipN4bqCB86u-F627U9OwV6mQCVPHQvMeyLCZ8OIx_beaYW6Hb-Z6jPeK_SkJ150R0g/photo/AF1QipOTkGTyd2E-5CCg2D6ptZoZECcvZAb96QnV8HiH?key=UlJqMFNXZ1ZtVkJtNUM2RGI2anREcVpkUXM4elVR [18:14:32] there's a lot of wires in that picture :P [18:15:05] The white ones :p [18:15:19] Coming from the right side. [18:15:39] Those are coming from/going to the regulator right? [18:16:12] hmm [18:16:14] yeah [18:20:09] huh [18:20:14] one of them seems to be carrying XPCN [18:20:29] which is an input to the rope modules, from the rope drivers [19:19:31] of course the landmark tracking PAD in the flight plan is totally incompatible with the numbers the crew got as per the transcript... [19:20:17] because these things would be too easy otherwise [19:59:53] Ah [19:59:58] Yes [20:00:00] hahahaha [20:00:03] right [20:00:21] .in 7h thymo can has logs [20:00:36] let me just bump that to a little later :P [20:01:24] .in 7h Thanks Mike [20:14:26] lol [21:45:22] thewonderidiot: So what would normally connected here? I/O stuff? https://photos.google.com/share/AF1QipN4bqCB86u-F627U9OwV6mQCVPHQvMeyLCZ8OIx_beaYW6Hb-Z6jPeK_SkJ150R0g/photo/AF1QipO4EwiMOg3HJyshC8iZE6Wca8yl8iKG-B8dAmE8?key=UlJqMFNXZ1ZtVkJtNUM2RGI2anREcVpkUXM4elVR [21:48:52] nothing [21:49:12] normally there would be 6 rope modules plugged in where these two boxes are [21:54:25] Hmm. I guess I never really thought about the place of the fixed rope modules. I knew the erasable modules were with all the other logic modules but I never considered the ropes to be mounted there. [21:57:30] yeah, the ropes are placed to be changeable without taking apart the AGC [21:57:31] https://photos.app.goo.gl/Y6cDoz7gc5p7Epyn7 [21:57:45] you can see the markings for where they're supposed to be plugged in -- B1 through B6 [21:59:47] Yeah. It makes a lot of sense to make them easily replaceable. [22:00:28] So do you think we'll see this thing run again? :) [22:00:34] I really hope so [22:00:37] but it's gonna be a lot of work [22:00:44] and potentially pretty invasive [22:01:38] Have you tried powering any circuit yet? [22:01:48] I imagine some capacitors might be toast. [22:04:54] no [22:04:59] and yeah, that's the problem [22:05:11] it's all welded together [22:05:26] so basically what we have to do is go through, find a capacitor, cut the wires running to it, and then test it [22:06:02] and if it's bad, cut out the area over it from the plastic sheet with component names, and then drill it out or something because all of the caps are glued into the modules [22:06:09] like I said, invasive [22:07:07] A part of me feels bad for having to cut and drill into what is essentially a historical artifact. [22:07:13] yeah, exactly [22:07:32] but I don't think we can have it both ways [22:07:41] we either do this and get it to turn on [22:07:47] or leave it in the state it is in, and not turn it on [22:08:16] Right. I guess making it run is a pretty good justification. [22:08:21] which is really unfortunate [22:08:30] yeah, I want to talk more to the computer history museum guys [22:08:41] I might see if I can arrange coffee with one of them [22:09:10] And see if you can get their help in some way? [22:10:41] maybe, and just to talk through it more [22:10:48] see how they feel about all of this [22:12:01] That sounds like a good idea. Even if it's just to put your mind at ease. [22:13:55] It's not the end of the world, it is not like this is the only AGC that's out there. So if one of them, which is not on permanent public display anyway, has some holes and new caps in them there will still be AGCs that remain untouched. [22:18:17] well, yeah, but the difference is that this one is unpotted, complete and in working condition (except for possibly the caps) [22:18:22] and pretty pristine [22:18:28] this is the only one like this, that I know of [22:18:45] that also means, of course, that it is the only one that even stands a chance of being powered up [22:44:30] Have you tested any of the caps yet to see if some of them still work at all? [22:46:13] no [22:46:37] there's only a small handful (maybe only one) that can be tested without cutting anything [22:46:54] at least, I think so [22:47:04] this is another thing I want to talk to the CHM guy about [22:47:38] exactly how disconnected the capacitor needs to be