[16:15:41] NASSP Logging has been started by thymo [16:17:01] AlexB_88, what do you say, is the PGNS to AGS downlink ready to be merged into the main dev branch? [16:17:28] well I just did my last test [16:17:58] V47, followed by full descent and then AGS abort [16:18:06] its looking very good [16:18:25] im just comparing V83 with AGS after insertion right now [16:20:03] its still very close to each other [16:20:13] indy91, I give it a green light on my end [16:20:22] sounds good [16:24:04] merged and pushed [16:24:20] awesome [16:24:44] I flew the early AGS abort on Apollo 12 (straight into CSI/CDH) [16:24:57] 1st pass in P32 shows a DH of 14.8 [16:25:02] good job AGS [16:27:58] of course I did use AGS to fly the insertion, and not PGNS... just using PGNS now to calculate CSI itself [16:29:15] right [16:29:33] but all on state vectors coming from the PGNS [16:29:53] yes from the V47 before PDI [16:30:16] yeah [16:30:52] if the forum lets me I'll write an update post in the AGS thread [16:31:06] great [16:31:47] and what will also be interesting is the RR data downlink on later missions [16:32:11] ooo yeah [16:32:12] so that should work too? [16:32:29] yes, works the same way [16:32:45] FP8 is just looking for a different downlink list [16:33:07] during rendezvous [16:33:19] ah ok [16:33:21] which is not only meant for the AGS [16:33:27] general rendezvous downlink list [16:37:49] gotta go! cya [17:42:58] I like how Tom Stafford calls his CMP and LMP Chimp and Limp, haha [17:45:38] hahaha nice, that's great [17:52:58] predicted DV for MCC-6 and MCC-7 is both 0.0 ft/s, I guess that was it with any maneuvers [17:53:17] so I just have to coast Apollo 10 home and fix a few mission control things along the way [17:58:25] :D [19:05:00] thewonderidiot, Lunar Module Interface Control Drawings [19:05:12] are those the ones you partially had requested? [19:05:42] we have a set of LGC ICDs from Eldon Hall [19:05:46] does UHCL have ICDs? [19:06:04] Inside KSC has a bunch, probably the same as from Eldon Hall then [19:06:20] http://insideksc.com/downloads.php?do=cat&id=13 [19:06:26] website is fairly broken [19:06:37] but I have an old account and can download stuff via a very hacky way [19:07:25] yes, it's the same as here: http://www.klabs.org/history/lm-icd/index.htm [19:07:38] hahaha [19:07:39] nice [19:08:07] yeah the klabs ones are the ones we have [09:36:34] good morning [09:37:11] just wondering do you have a 10 scenario before the rendezvous? [09:39:54] hey [09:40:06] sure I have [09:40:15] at which point do you want it? [09:40:30] before the onboard targeted rendezvous phase? [09:40:39] sure [09:40:41] that would be after the insertion maneuver I guess [09:40:50] a bit after staging [09:40:53] i just want to practice the entire rendezvous phase [09:41:09] yeah, then that point is the best to practice [09:42:27] just have to find the right scenario [09:46:44] https://www.dropbox.com/s/lgu581aa0l1wmba/Apollo%2010%20MCC%20-%20After%20Phasing%200002%200001%200003.scn?dl=0 [09:46:55] this is 4 minutes after the insertion maneuver [09:47:10] you should get a CSI PAD from MCC-H shortly after starting the scenario [09:47:26] thanks [09:47:39] due to the latest Checklist MFD changes this scenario is outdated though, so you have to click yourself through the checklist until you reach the right point in it [09:49:07] okay [09:53:32] should i just click on the rendezvous checklist in the case [09:54:58] I would just press PRO or FAIL until you are at the right spot [09:55:17] it is ahead of the rendezous part [09:55:27] rendezvous* [09:55:28] I very much doubt that [09:55:32] let me check again [09:55:46] maybe i press fail by accident [09:55:52] pressed* [09:56:23] FAIL is good for skipping sections, but sometines a checklist item uses PRO vs. FAIL for a decision [09:56:45] hmm [09:56:52] it goes to no active checklist for me [09:58:54] ok, select the rendezvous checklist in the menu [09:59:09] okay [09:59:18] and then PRO or FAIL through the checklist until "Perform Insertion Burn" [09:59:25] and skip that as well [09:59:37] then continue with ORDEAL initialization and so on [09:59:54] the first real procedure is a P52 [10:01:39] so the scenario starts with the same stuff you would do just after an insertion from your lunar landing site on Apollo 11 [10:05:57] and i cant remember which letter to use on the aot for orbital p52's [10:06:59] F for front [10:07:06] okay [10:07:17] that's the code 2 on the DSKY [10:07:47] so for e.g. star 31 on the front detent it will say 00231 or so [10:08:23] in P52 [10:10:51] and what about 5 [10:10:57] on the lunar surface [10:11:14] let me get you the list [10:11:18] okay [10:12:29] it's in any of the P5X checklists in this: https://history.nasa.gov/afj/ap12fj/pdf/a12_lm_g&n.pdf [10:12:42] 1 = L, 2 = F, 3 = R, 4 = RR, 5 = CL, 6 = LR [10:28:35] very excited about the rendezvous [10:34:13] the CSI PAD should have everything you need for it, especially the CSI and TPI times [10:34:59] yeah i should proably print the csi page and write it down [10:35:53] and just like you remember from Apollo 11 being late in lunar orbit, my Apollo 10 mission was 15 minutes behind the flight plan. [10:36:02] real mission was 12 minutes behind, so quite close [10:37:44] so CSI and TPI times will be 15 minutes later than in the flight plan, and the checklist MFD times are 15 minutes too early etc etc [11:35:50] well i got no csi pad so i think i will stick with 11 for now [11:40:40] checked the scenario [11:40:57] 4 minutes after you start the scenario there is a LM state vector update for the CMC [11:41:10] so you first have to allow that to be done in the CSM [11:41:19] the CSI update is just after that [11:41:38] so I guess you just must have missed the message for the CMC update [11:44:05] i got the state vector update [11:44:21] i will try it again [11:44:49] CSI update is scheduled one minute after the uplink is done [11:45:01] the mission control feature in NASSP is quite linear [11:45:41] so nothing progresses unless you allow uplinks timely enough [13:19:41] hi alex [13:20:36] just about to do the apollo 10 rendezvous with a scenario that Niklas gave me [13:21:21] hey [15:00:00] hey [15:04:18] hey [15:20:38] flew a bit more Apollo 10 and doing Earth horizon P23s [15:20:42] pretty good results [15:26:53] nice [15:27:14] Does it keep the state vector accurate? [15:29:38] haha, I'll tell you after the whole sequence is done [15:29:45] DR and DV is nice and low at least [15:31:12] right [15:32:04] I havent done P23s in a while, but from I can remember I was getting low DR/DVs but the actual state vector was not converging for some reason [15:39:51] did you check that with V83 or how [15:39:56] yeah [15:40:21] comparing with an uplinked SV in LM slot [15:40:39] range just kept going up and up with each P23 [15:42:26] "V83 and V85 displays may be meaningless at altitudes greater than 432NM for both earth and moon if these verbs are exercised because of sharing with the integration routines." [15:42:48] "If V83 and V85 is desired in P00 key V96 first. Recovery procedure: reselect verb." [15:43:12] I'll try that [15:43:52] V96 probably sets the integrated perturbation as 0 or so [15:44:15] I also remember using P21 to check the earth perigee and it was also showing wrong values with the P23s [15:44:17] so maybe only a V83 after you just did a V96 is accurate [15:44:23] hmm, ok [16:02:32] cya! [17:39:00] morning! [17:41:54] hey Mike [17:43:18] what's up? [17:44:03] flying more Apollo 10 [17:45:40] how far into it are you now? [17:46:22] 20 hours before splashdown [17:47:03] nice :D [17:48:37] so Ron forwarded me a pretty crazy email this morning [17:49:32] so a email from Ron [17:49:44] hahaha yeah [17:50:07] apparently somebody has taken my AGC schematics and is building to them [17:50:13] I'm being beaten at my own game :D [17:50:21] can't let that happen [17:50:38] hahaha I think it's great [17:51:14] it's pretty awesome that somebody is building this version of it [17:51:15] yeah, there can't be enough AGCs [17:51:43] he's got the first 7 modules constructed, with the first 4-5 of them wire-wrapped on his backplane [17:51:59] and he has pictures :D [17:52:02] I'm gonna forward you this email [17:52:18] oh, quite far into it [17:52:24] sure [17:56:34] you are right [17:56:41] you are being beaten at your own game [17:57:01] hehehehe [18:06:30] looks like you did some useful prep work for such projects [18:06:51] and having Aurora is equally useful [18:07:54] I wonder what it would take to be able to use a physical AGC with NASSP... [18:08:15] hahaha that has always been my end goal :D [18:08:32] I think once the counters branch of virtualagc has been integrated it will be much easier [18:09:00] since the I/O of that is exactly like the I/O of a real one [18:09:42] wouldn't it be a physical AGC instead of the Virtual AGC? [18:09:54] ah, easier on the NASSP side [18:10:00] yes, easier to integrate [18:10:03] right [18:17:55] I can see a physical AGC being possible with NASSP [18:18:05] ...Provided you don't use time compression. [18:18:31] haha, yeah [18:19:52] thewonderidiot: Could you forward that email to me too? Would love to see it. :) [18:20:31] yeah, one sec [18:22:00] okay, sent :D [18:23:14] Got it. Thanks :) [18:27:17] Looks cool! [18:28:04] These PCBs would really make it easy for people to assemble their own AGCs/ [18:28:10] A DIY AGC kit. [18:30:01] haha yeah [18:30:07] a very expensive DIY AGC kit :P [18:30:33] I'd get it. [18:45:02] also "easy" is probably a bit of a stretch considering the thousands and thousands of wire-wrap connections still needed on the backplane [18:46:39] Couldn't that be done through a connector? If you throw historical accuracy out the window. [18:50:37] the two options are wire-wrapping, or a gigantic many-layer PCB that will almost certainly cost several thousands of dollars [18:51:01] I'd be kinda surprised if anybody would actually make it, heh [18:58:27] entry interface minus 10 hours [18:58:57] and half of that is sleep at 50x :D [18:59:59] Consistency between reloads is going to be fun too. [19:00:53] Well I suppose if you P06, turn the AGC off and then save should work. [19:02:47] yeah [20:36:13] night [11:02:46] .tell indy91 so i got the v32 and cant seem to find the elevation angles do you know where i can find them [11:10:55] .tell indy91 never mind i think i found them [11:12:21] good morning [11:13:26] hey [11:13:36] 26.6° [11:13:58] if that is what the question was about, haha [11:14:48] yeah the numbers i was looking for were after the csi ignition in the dsky [11:15:35] i think i found them in the rendezvous procedures [11:16:06] yeah, those numbers are the same for every lunar rendezvous [11:16:27] in the flight data file they were usually on the CSI Data Card [11:16:33] like this: https://www.hq.nasa.gov/alsj/a15/A15DC013.GIF [11:16:50] not sure if Apollo 10 had data cards like that yet [11:17:13] i checked the apollo 12 data cards but i wasnt sure if the numbers would be the same for 10 or 11 but i guess they are [11:17:19] right [11:17:28] it is always the same in lunar orbit at least [11:17:35] Apollo 7 and 9 used different elevation angles [11:17:55] and if the CSM has to rescue the LM, the it's doing a rendezvous from above instead of from below [11:18:06] so for the CSM the elevation angle would be 208.3° [11:18:22] also a constant number from Apollo 10-17 [11:19:00] and the 130° central angle travelled is also always the same in lunar orbit [11:19:16] once you have done a few rendezvous you will know these numbers in your sleep [11:21:32] and if i tried to fly apollo 9 how far into the mission would i get, i think you mentioned something about the rtcc mfd [11:24:02] Apollo 9 is probably possible to fly completely with the RTCC MFD. The issue is mostly that we haven't figured out all the right inputs for the RTCC MFD. [11:24:16] like, how some maneuvers should be calculated [11:24:27] one of the REFSMMAT for the CSM is a bit of a mystery to me [11:24:30] that kind of stuff [11:25:33] so we probably have all the tools required for Apollo 9 already, we just have to do some more research into how they should be used [11:28:16] so if you were flying Apollo 9 and have some question about a calculation with the RTCC MFD, we probably have the answer yet. You'll have to figure out some stuff yorself. [11:28:37] we probably DON'T have the answer yet* [11:32:09] yeah with apollo 9 i am mainly focuses on the rendezous [11:32:38] rendezvous* [11:37:23] for that there are two ground targeted maneuvers [11:37:31] phasing and insertion [11:37:59] for phasing I still need to figure out the right calculation method [11:38:09] okay [11:38:14] in the past we have done it with the Lambert page [11:38:25] but that's not really right [11:38:26] i think i will stick with your 10 scenario for now [11:38:40] for practice [11:38:44] how far have you come with that scenario? [11:38:47] CSI burn done yet? [11:39:08] nope i ad to find those angles [11:39:14] had* [11:39:20] ah, right [11:39:34] did the Checklist MFD not mention them? [11:39:54] not the actual numbers no [11:40:07] hmm, ok [11:44:56] well i am going to make some coffee and then get started on the rendezvous [11:44:58] bye [11:45:34] and do you think i will get it right the first time? [11:47:28] there is a good chance for that, yes [11:47:35] it's easier than the Apollo 7 rendezvous [11:47:51] with Apollo 7 you have to do manual sextant marks and that takes a bit of practice. [11:48:00] in the LM the RR does the marks automatically [11:48:22] thats convenient [11:48:47] and the Apollo 7 rendezvous timeline is quite tight [11:49:00] you have to do many things in a short time [11:49:13] and the AGC also takes longer to do the rendezvous calculations [12:22:15] so it is asking me to wait for 5 marks [12:23:21] right [12:23:30] are you on the 16 45 display of the DSKY? [12:23:48] cant remember but it was counting down the TFI [12:25:34] yes, that sounds right [12:25:47] register 1 of that display is the current mark count [12:26:01] register 2 is the time from ignition [12:26:10] so just wait unti R1 shows 5 or more [12:26:12] how long does it usually take for the marks to complete [12:26:19] okay [12:26:21] the RR does marks exactly 1 minute apart [12:28:48] how many marks does it show for you right now? [12:37:21] none [12:38:56] that's bad [12:39:09] has your RR locked on to the CSM? [12:39:19] didnt check [12:39:27] what setting should the aot be on? [12:39:34] for what [12:39:35] or does it matter [12:39:50] for P52 or what? [12:40:04] for thew marks [12:40:09] the* [12:40:50] the AOT isn't used for the marks [12:40:55] okay [12:40:56] the LM only has the rendezvous radar for that [12:41:03] is the No Track light on? [12:41:17] i can check [12:41:41] did you start P20 at the beginning of the rendezvous? [12:41:49] nope [12:42:19] i skipped ahead to 103 hours [12:43:04] without P20 the RR can't do any marks [12:43:13] and without any marks you can't perform the rendezvous [12:43:58] well, that's not technically correct [12:44:16] you could rely on ground supplied state vectors (RTCC MFD) [12:44:31] and just use P32 and so on to calculate the maneuvers that way [12:44:37] but that's not the nominal way of doing it [12:48:14] p20 in the csm? [12:48:39] P20 in the LM [12:48:56] during the rendezvous you are actually running two programs at the same time, which can be confusing [12:49:12] first you start P20, maneuver to the tracking attitude, lock onto the CSM with the RR [12:49:15] then you start P32 [12:49:23] so P20 and P32 are running concurrently [12:55:56] yeah [12:56:03] i thought i might be the attitude [12:57:10] P20 takes care of the attitude during the tracking [12:57:26] i remember the p20 from apollo 7 [12:58:37] also will there be new scenarios for these missions soon like V7? [12:58:47] not soon, but eventually [12:59:23] not that i need them right now [13:00:00] it's probably the last thing we will do before the NASSP 8 release [13:00:26] because any change or bugfix could already mean that the scenarios become outdated in some way [13:00:29] and what will happen with the 7 and 8 scenarios [13:00:45] there will be new Apollo 7 and 8 scenarios [13:07:14] just having trouble getting the program 32 and 20 to run at the same time [13:10:53] so, you usually don't start P32 until you have a blank display in P20 [13:11:21] the display will be blank when the LM is in attitude tracking mode and has locked onto the CSM [13:11:59] so don't even bother with P32 until you have everything in P20 [13:12:06] have done everything* [13:12:28] what's your trouble right now? [13:16:46] i jumped to far in the checklist there is a p20 before csi [13:16:51] too* [13:17:28] indeed there is [13:46:08] so i get a 50 25 when the dsky is supposed to be blanks [13:49:49] option code 201? [13:50:02] yes [13:50:43] then your options are: PRO for auto acquisition, ENTR for manual [13:50:49] you should press PRO [13:50:53] okay [13:51:15] then the LGC will drive the RR to the direction of the CSM [13:51:17] can take a bit [13:51:36] if all goes well, the No Track light will be out after this [13:53:57] forgot to push the rendezvous radar circuit breaker in [13:54:34] i think i am too far ahead in the checklist but i dont know by how much [13:55:00] yeah, giving the RR power is helpful :D [13:55:43] i guess maybe right after the perform insertion part [14:19:13] Good morning [14:19:22] h ryan [14:19:25] hi* [14:19:44] just gonna do the apollo 10 rendezvous [14:20:09] Be thankful for the MCC [14:20:15] yeah [14:21:07] hey Ryan [14:21:20] I think I might have a potential solution to these tanks if I can do it without breaking other tanks [14:22:04] did you read that we got the PGNS to AGS downlink completely working? [14:22:14] And that solution is to let the code work as is and ignore the liquid pressure, but recompute a new tank volume based on the substance and amount in the tank [14:22:29] I did not! I have been working like crazy this week and have barely checked into NASSP [14:22:38] weekend* [14:22:46] What was the solution? [14:22:57] a short queue [14:23:15] Mike did the analysis on when the AEA is trying to read the downlink register [14:23:58] and we concluded that if we implement a short queue for the downlink data from the PGNS that we could solve the timing issues that way [14:24:11] And the queue keeps the timesteps from having too much to do per every timestep? [14:24:15] the queue only has to be 3 long and that should work down to 25 frames per second [14:24:38] Interesting [14:24:40] the timesteps are actually like before, I didn't pursue that solution for now [14:24:44] Ah ok [14:25:02] But still thats a great non invasive solution [14:25:05] so every frame the LGC and AEA do its cycles independantly in separate loops [14:25:33] yeah, that such a short queue is working fine is very nice [14:26:36] but that is because the AEA is looking at the register very consistently [14:27:09] twice during the timespan in which there should be 1 new PGNS downlink word or so [14:27:29] Does it have any impact on the time for a V47 to complete? [14:27:41] nope [14:27:44] Nice [14:27:57] Well done [14:28:13] PGNS is writing at 50 words per second, AGS is (essentially) reciving at 50 words per second [14:28:39] so it's only a small fraction of a second until the outdated 3 queued words were read by the AEA [14:28:47] and then the new words with the useful data is coming through [14:29:30] so except for a 3/50 of a second delay, the V47 should work just like the real thing [14:30:05] and in the last bit of news, I splashed down with Apollo 10. [14:30:15] so the Apollo 10 MCC is basically done [14:30:22] now to your tanks :D [14:31:37] Excellent news! [14:31:39] So yeah [14:31:54] There is a section that computes air volume in a tank [14:32:13] And that is used to compute the partial pressure of a given gas in the composition [14:32:49] That made me think, if I can make it recompute a tank volume basically volume - volume taken up by the liquid, then it can work [14:33:53] I also realized that when i filled my tank and got an initial pressure, it was simply because I had put the total fuel quantity into one tank, and when i rechecked the math, it seems that there is a little room in the tank after it is filled with propellant [14:34:16] And then I did more reading and this space is pre charged with helium before launch [14:34:43] right [14:35:06] So, in essence, if I can precharge the tank with a bit of helium, and make it recompute the air volume to take into account the volume taken up by the liquid, the code as it stands would yield proper results [14:35:25] I am hoping it will be a simple 1 or 2 lines needed to make it work [14:37:02] I might need help figuring out the air volume code in here though, it seems redundant [14:37:07] NV = Volume - NV; [14:37:08] double air_volume = Volume - NV + Press * PNV; [14:37:21] I do not know why Volume-NV is done twice [14:37:59] Actually 3 times [14:41:05] hmm [14:42:54] I mean it seems like it is just recomputing NV after a step of course [14:43:17] But the additional Volume - NV in the airvolume line has me confused [15:35:42] If I want to just use the fuel and oxidizer in a tank, would a for loop like this work [15:35:51] for (i = 6; i < 8; i++) { [15:35:52] Volume -= (composition[i].mass / L_DENSITY[composition[i].subst_type]); //Recomputed air volume in L [15:35:52] } [15:36:10] Looking at just composition 6 and 7 [15:46:24] seems hacky [15:47:13] Yeah [15:47:16] It is [15:47:24] And doesnt work the way I intended anyways [15:47:52] I just need a way to subtract liquid volume from the total tank volume and then do the gas calculations [15:50:48] I mean, that doesn't sound difficult. Finding the most elegant and long term way of doing this is the tricky thing [15:51:42] Well yeah [15:51:51] That simple math in the loop is all you need [15:52:10] That computes volume of liquid in the tank [15:52:46] It might need to be hacky though because cryogenics behave a bit differently and have special handling [15:52:58] So this would be for non cryo liquids in the long term [15:53:08] So water and propellant [15:53:14] and glycol [15:55:59] Hmm actually it should be doing this already.... [15:57:05] tNV = (composition[i].mass - composition[i].vapor_mass) / density; //Units of L [16:04:37] one thing I have to work on for the RTCC/MCC is entry range [16:04:52] Ah yeah [16:05:01] it's fairly inconsistent, because it still uses CMC calculations [16:05:30] for the lunar returns they would use a fixed entry range from EI to splashdown [16:05:51] but in the CMC it's variable depending on velocity and entry angle [16:06:08] The fixed number is what is placed into the EMS? [16:06:16] uhh, almost [16:06:24] EMS starts counting at 0.05G [16:06:30] not entry interface [16:06:31] Ah so compensation [16:06:53] so in my case, MCC-7 would have been 0.7 ft/s, so it was scrubbed [16:07:00] it would have been a corridor control burn [16:07:37] so instead of calculating a new splashdown target based on MCC-7, it just did a prediction based on the current trajectory [16:07:51] which has a slightly different reentry angle [16:08:13] which with the CMC calculation I still use in the RTCC leads to a different entry range [16:08:46] so with the right reentry angle, my splashdown longitude would have been 164.99°W [16:09:08] but the Entry PAD gave me 164.15°W instead [16:10:21] so I need to make the range constant, independent from velocity or flight path angle [16:10:36] at least for the nominal lunar entries [16:12:17] which is also kind of required for Artemis, because it has a bug that needs short entry ranges :D [16:12:47] Oh nice haha [16:13:12] for some ranges Artemis choose lift down instead of lift up at an inconvenient time [16:13:54] That could be a bad time [16:14:58] "avoidance procedure: avoid 1215 to 1455NM range" [16:15:30] starting with Apollo 10 the CMC actually had a padload for a constant entry range as calculated by P37 [16:16:33] Apollo 8 just had a chart for longitude compensation [16:16:41] for nominal vs. CMC entry range [16:18:03] which kind of helps me with the fixed entry range issue? [16:18:15] but that padlaoded range is also not the one mentioned in the SCOTs [16:18:47] not range from 400K (Entry Interface), but 300K [16:18:53] too many altitude reference... [16:18:57] references* [16:18:59] Yeah haha [16:20:04] but it should be interesting to fly the shorter ranges [16:21:00] you can kind of do that with the coordinates from the splashdown page on the RTCC MFD, but I haven't used it to fly a shorter range [16:21:38] Shorter range would be higher aerodynamic load wouldnt it? [16:23:37] Also, for the tank code, is there an easy way to see what this code is computing for air volume for a specific tank? [16:25:43] the shorter range will be the same for the initial phase, lift up, peak 6.5G, then lift vector down [16:25:55] but it will roll to 0° again much earlier [16:26:03] and you will get a second G peak higher than usual [16:26:07] up to 6G again [16:26:25] hmm, an if that checks the tank name [16:26:30] and then a debug string in the if [16:27:22] I will try that [16:27:28] no, that isn't right with the roll to 0° [16:27:34] it will stay in lift vector down longer [16:27:40] that way around [16:28:01] Longer lift down would be shorter range yeah [16:28:34] the reentry has a few phase, I think the second phase in P64 is the first that does range control [16:28:39] phases* [16:29:11] I used to know those phases [16:29:23] it's similar to the Space Shuttle [16:30:13] Hmm how do I check the tank name in here [16:30:52] if (!strcmp(name, "LEM-LR-Antenna")) [16:31:05] Ah awesome thanks [16:32:03] hmm doesnt like name [16:32:32] uhh [16:32:41] what class is this in? [16:33:39] Hsystems.cpp [16:33:44] oh duh [16:33:48] volume [16:34:13] h_volume() [16:34:20] ah, so not h_Tank [16:34:43] No [16:35:04] hmm [16:35:14] so you want to look at a local variable? [16:35:40] Yes [16:35:52] I want to see what it is computing for air volume for the des fuel tank [16:36:18] add a temporary class-wide variable [16:36:37] save the stuff you want in that variable [16:36:41] Ah ok [16:36:48] and put the debug code in the tank refresh function [16:37:10] h_Tank has a h_Volume, so you can access it there [16:41:52] if ((!strcmp(name, "DESFUEL1"))) { [16:41:52] sprintf(oapiDebugString(), "air volume: %lf", space.void_volume); [16:41:53] } [16:42:11] morning! [16:42:15] looks right [16:42:16] void_volume being my class wide variable that saves air volume [16:42:16] hey Mike [16:42:45] oh, I have a few Apollo 10 checklist things [16:42:53] Sure thing [16:43:12] didn't make a list, so I'll tell you when I can remember [16:43:15] first [16:43:36] it probably would help to add a few "wait until EI-1:15h" or so [16:43:43] it's done already a bunch of times [16:43:53] but not everywhere where the flight plans says a time [16:44:23] and one thing was out of order [16:44:26] Based on the flight plan or entry checklist? [16:44:31] flight plan [16:44:37] you had the final entry update at EI-45 minutes [16:44:48] but flight plan has it at EI-1 hour [16:45:26] I think I was basing those off of the entry summary [16:45:50] ah, right, was just looking at that [16:45:58] from March [16:47:22] Yeah [16:48:18] Did I use a mission time for that?. [16:48:37] Yes I did [16:49:06] I can just make that Wait until EI-1 hour instead of a preset mission time [16:49:32] Unless adding 15 minutes to that time will line up properly [16:49:37] oh right, that was another thing [16:49:43] using mission time for those events [16:49:54] I got lucky, my EI time was only 5 minutes off the flight plan [16:50:14] but if it's more than that, then the entry checklist won't appear on its own in time for the next checklist itme [16:50:16] item [16:50:26] Yeah i can change those times to waits [16:51:10] sure. And in general, all those events before EI will be relative to EI time [16:51:42] Are the other times good based on the flight plan? [16:51:49] Like the RCS preheating and such [16:51:58] As far as the EI- times not the mission times [16:52:15] I think so, yes [16:52:18] Time of Entry Interface: 191 hours, 48 minutes, 54 seconds GET. [16:52:25] Ok I will hammer those out in a bit [16:52:26] 190:46:13 Stafford: We're in CMC and Accept. [16:52:35] Back in a few [16:52:36] 190:49:05 Lousma: Apollo 10, Houston. I have an update to your entry PAD. There are only five numbers that are different than the last PAD. Over. [16:59:37] thewonderidiot, made any progress in the AGC building race? :D [17:00:14] hehehe, no [17:00:51] it's not much of a race at this point, because I still haven't really started and won't for a while lol [17:01:15] he's a really nice guy though, he shared with me all of his modified schematics and things [17:01:36] fun [17:01:40] I did make progress on the real AGC though [17:02:11] I've been fretting about the tantalum capacitors in it blowing up [17:02:51] turns out these radiation inc logic modules contain the exact same family of capacitors, manufactured at right around the same time [17:03:22] so if we don't have problems with them, then chances are the capacitors in the AGC are doing pretty well [17:04:35] they can't even make reliable capacitors today :D [17:04:45] or they use cheap ones in satellite receivers... [17:05:00] had a capacitor blowing up in one [17:05:02] haha well [17:05:05] fun noise and mess [17:05:09] the other great thing about these particular capacitors [17:05:23] https://www.mouser.com/Vishay/Tantalum-Capacitors-Solid-Leaded/150D-Series/_/N-1z0zls5Z75hr3Z1yzvd7x [17:05:31] they're still made today, 50 years later [17:05:50] under a different company name (Vishay bought Sprague), but still :D [17:05:51] must be a good design then [17:05:54] yeah [17:06:35] the Soyuz of capacitors [17:07:47] lol [17:08:02] anyways I need to build a Monitor and possibly a DSKY first [17:09:03] this guy is also much smarter than me [17:09:26] "For power supplies I'm not going for authenticity.  I'm just using a 24 / 15 / 5 volt switching unit.  I'm needing to make judgement calls on where to spend my money and time and decided on cutting some corners on the power supplies, just as I'm doing on simplifying the I/O by removing the transformer coupled interfaces.  I'm also not going for latching relays on the DSKY.  Those are the major differences from the original.  Well those and the [17:10:13] partly why he has hardware and I don't :D [17:10:24] haha, right [17:10:35] he's actually applying judgment to things :P [17:58:20] tonight is the TESS launch [17:58:33] definitely will watch that [17:58:46] oh nice! [17:58:50] Kepler has been my favourite mission these past years, TESS should give similar great results [17:59:16] I know a lot of people who worked on that [18:04:49] I think the countdown on their page is wrong [18:04:54] 22:32 UTC launch [18:05:04] isn't that in 4.5 hours? [18:05:06] not 5.5 hours [18:10:59] haha, I think the timer is set to 18:32 EST [18:11:05] but the launch is 18:32 EDT [18:11:30] ah, daylight savings... [18:18:13] lol [18:20:09] metric to imperial has killed spacecraft before [18:20:18] but daylight savings time would be a new one [18:26:07] that's almost surprising, that it hasn't killed one yet [18:28:04] ah, I mean spaceflight related [18:28:11] I am sure it has killed someone on Earth [18:28:22] haha I know what you meant [18:29:04] I guess most spacecraft fly in GMT or UTC [18:29:19] or TAI, even [18:29:22] LVDC and AGC used GMT [18:29:41] UTC wasn't a thing back in the 60s [18:29:46] we're just using straight GPS time [18:30:14] yeah, that's useful [18:31:34] the lunar and solar ephemerides padload in the CMC are in ephemeris time [18:31:45] you can see that because their time tag is noon, but a few seconds off [18:32:08] however much off ET was then [18:32:27] I'll never forgive the bastard that invented leap seconds [18:32:40] I have spent waaaaaaaay too many hours stressing out over them [18:32:47] https://en.wikipedia.org/wiki/%CE%94T [18:32:48] this much [18:32:50] I think... [18:33:05] haha [18:33:09] I wonder if we have issues with that in Orbiter [18:33:44] Orbiter is most precise in 2000 [18:33:49] J2000 coordinate system [18:34:08] I never checked if e.g. the position of the bodies in Orbiter would be off in timing [18:34:24] in 1968-1972 that is [18:38:11] oh, interesting [18:49:34] hello mike [18:50:07] just got back home and i am gonna do the apollo 10 rendezvous [18:50:28] hey [18:52:25] yeah Mike, how are your rendezvous skills [18:57:55] I'm pretty decent at it in KSP :P [18:58:46] i have never played ksp before [18:59:42] I've rarely tried that stuff in KSP. I mostly built crazy rockets to see if they can make orbit [19:00:01] the the kind of thing you can't do in Orbiter [19:00:05] so the* [19:00:26] haha yeah [19:00:35] I was suuuuuper into KSP for a while [19:01:04] before I even knew Orbiter was a thing [19:02:07] it's a lot of fun [19:02:54] I usually built random planes [19:03:17] I'm not that good at building robots and orbital stuff. [19:03:49] s/robots/rockets [19:06:18] robotic rockets [19:07:55] I've been writing a bunch for robocode the last weeks. Hence the mix up. :p [20:04:56] Ok back and I have those EI times fixed in the 10 checklist [20:05:34] indy91, what did you say was out of order? [20:07:54] oh damnit [20:07:57] TESS scrubbed for the day [20:08:19] next chance on Wednesday [20:13:23] I am watching Scott Manley's video on it now [20:14:52] I didn't realize how small it was [20:16:18] The orbital mechanics of that are pretty awesome [20:20:02] rcflyinghokie, I think there just were some events between EI-1 hour and EI-45 minutes [20:20:21] and because the final update was at the wrong time the order of things was wrong [20:20:26] can't really remember thouggh [20:20:44] Ok well i fixed a few of those wait for's and got rid of the mission times for EI events [20:20:59] https://twitter.com/SpaceX/status/985975566535831552 [20:43:24] ah, too bad [20:43:26] night! [21:21:06] I think the paperwork for the new AC Electronics manuals has all been signed [21:21:12] hopefully scanning should commence soon :D [11:14:43] morning [11:31:55] Hey Alex [11:43:03] hey [11:51:31] hey Niklas [11:52:06] and Thymo [11:57:27] pushed my latest MCC state, Apollo 10 is done [11:57:41] except for some minor, general issues that are not Apollo 10 specific [11:57:42] awesome [12:00:03] how did the P23s go? [12:04:18] not bad, but I haven't really done the whole independent navigation thing in the long term [12:04:46] so no idea if the state vector was really good or not [12:05:48] right [12:07:10] I think on one occasion I flew a TLC direct abort with P23s all the way to re-entry (no SV updates) [12:08:02] I think I got the state vector quite accurate nearing re-entry but it took a ridiculous amount of P23 marks [12:09:02] and all the marks were landmark/star. Never had any luck with Horizon/star [12:09:51] I can get good DR/DV with horizon/star, but not sure if the state vector is good [12:10:39] I guess just comparing a P37 min DV solution with RTCC mfd [12:11:08] right [12:47:33] good morning [12:48:04] had a but of an issue with the csi burn [12:48:21] forgot the lem doesn't have an ems counter [12:49:21] hey [12:49:32] it has something even better: AGS :D [12:50:26] indy91, I now have a better texture for the gold foil on the lunar module [12:50:27] https://www.dropbox.com/s/pyz1ji4ksuv08cb/Screenshot%202018-04-17%2008.48.53.png?dl=0 [12:50:34] let me know what you guys think [12:50:53] looks pretty good [12:52:14] yeah I think it looks more natural then the previous one [12:55:35] and i keep forgetting +x means 6 on the num pad right? [12:58:37] also is there a way to control the impulse mode for the p52, it moves way too fast [13:01:20] +X is 6 on the num pad, yes [13:01:49] R2 (+/-Y) on the DSKY is controlled with 1 and 3, R3 (+/-Z) with 2 and 8 [13:02:17] about the control [13:02:48] switch off ACA/4 Jet [13:03:29] and then I usually use direct mode, with the attitude control switches [13:03:55] and PGNS Mode Control switch in off [13:06:18] if the ACA/4 Jet switch is on and you are using the keyboard, then you always have 4 thrusters firing for attitude control [13:06:22] which is way too mcu [13:06:23] much [13:22:22] i am a bit confused with the translation [13:23:14] so r1 is the 2 and 6 right [13:25:10] no [13:25:17] 6 and 9 [13:25:30] that is what i meant sorry [13:26:32] for the 2 and 8 and 1 and 3 which one is + and - Z? [13:27:00] hmm [13:27:02] actually [13:27:07] I think I said nonsense [13:27:32] 6 and 9 are R3 [13:27:42] 2 and 8 are R1 [13:28:01] it's different than in the CSM [13:29:00] so would 2 be +Z? [13:29:57] R1 is X, R2 is Y, R3 is Z [13:32:16] and would 1 be +Y? [13:33:50] I think so [13:34:00] and 2 for +Z [13:34:08] 2 is +Z, 6 is +X [13:34:14] no [13:34:18] getting it confused again [13:34:22] yeah [13:34:30] 2 is not Z [13:34:46] 2 is +X, 6 is +Z [13:35:22] in doubt, fire all thrusters to test what they do :D [13:37:12] so 2 = +X, 1 = +Y and 6 = +Z [13:37:21] hope i didnt get confused again [13:39:11] I think that is right [13:39:20] although I am not sure if 1 is +Y or -Y [13:39:27] i will find out soon [13:39:47] does it matter what order i do them in or does it have to be at the same time? [13:41:39] biggest one first [13:41:47] which was x for me [13:42:10] probably almost exclusively X I would think [13:42:22] because P41 maneuvers to the attitude for that [14:45:01] new and improved docking target: [14:45:03] https://www.dropbox.com/s/fiyyhpskrluqn9p/Screenshot%202018-04-17%2010.44.43.png?dl=0 [14:45:55] took out the 2nd red cross which wasn't realistic anyway [14:46:10] and added some brightness to it [14:47:34] uhh [14:47:45] how do you judge if you are rotated right without the 2nd cross? [14:48:33] with the markings on the the main circle [14:49:00] ah, I see [14:49:53] and I cannot find a single real picture of it with a red cross [14:50:39] the LM active docking target is red, right? [14:50:59] yes [14:51:34] so I guess whoever made these thought they were both red, or something like that [14:53:14] same person probably made them 45° rotated instead of 60°... [14:56:07] yeah lol [15:04:37] @indy91 do you have a before insertion scenario for apollo 10? [15:04:54] yes [15:05:05] do you want before or after staging? [15:05:12] that happens 10 minutes before the insertion burn [15:05:32] maybe before the insertion checklist [15:06:13] before staging [15:07:37] ok [15:10:15] hmm, I hadn't saved for a while [15:10:35] best one I have is about 40 minutes before the insertion burn [15:10:42] that is fine [15:10:45] ok [15:11:51] https://www.dropbox.com/s/7il7sniuzi8zah9/Apollo%2010%20MCC%20-%20After%20Phasing%200002%200001%200001.scn?dl=0 [15:12:00] thanks [15:12:08] no problem [15:12:21] then after this i really have to get back to 11 [15:12:29] and I checked, it's fairly easy to find the right pointin the checklist again [15:12:44] just PRO or FAIL through it until the insertion burn part [16:16:00] Ugh this air volume bothers me [16:41:02] indy91, I noticed AMSO has a second, red cross in their docking target too. But all the real pictures and looking through the LM10 Apollo Operations Handbook, page 1-20 (32 of the PDF) does not mention any red in the docking target [17:07:21] morning! [17:08:36] Hey Mikw [17:08:40] a/w/e [17:08:44] s/w/e [17:08:48] Ugh [17:08:55] Let's try that again... [17:09:00] Hey Mike! :) [17:12:03] lol [17:12:04] hi [17:15:22] What's up? [17:17:33] work work work [17:48:36] hey Mike [17:50:25] yo [13:37:45] good morning [13:38:11] so i started apollo 9 not to fly the full mission but just for fun and there is an extreme error in the checklist [13:38:48] oh [13:38:55] for the sep i think rc forgot to include the csm/;v sep button [13:39:02] lv* [13:39:16] hmm [13:39:30] CSM/LV sep can also be done with the THC [13:39:35] maybe that is used for Apollo 9? [13:39:43] that is what it calls for [13:39:49] then it's no error [13:39:51] i didn't know that [13:40:21] I think only the Apollo 8 checklist uses the THC for it [13:40:31] we don't have the flown Apollo 9 checklist for this [13:40:53] and later mission used the CSM/LV SEP button [13:40:59] missions* [13:41:00] and for the state vector update it says to do it in the rtcc mfd [13:41:07] something about gumdrop [13:41:36] Gumdrop is the name of the Apollo 9 CSM [13:41:50] and about the THC for CSM/LV sep, that is basically the same as during an abort [13:42:09] if the launch escape tower is still attached, then you cause an abort with that by using the THC [13:42:42] if the tower is gone, you just send a signal to the Saturn engines to shut down and you are separating from the booster [13:42:58] so this nominal procedure using the THC is basically like a Mode II abort [13:44:21] there isn't much of a difference to the CSM/LV Sep button [13:44:27] I think using the THC starts the event timer [13:48:03] i think you said you got the mcc's right up to lem activiation? [13:48:23] what MCCs [13:48:28] 9 [13:48:45] oh [13:48:55] well first, the acronym is confusing [13:49:00] MCC = Midcourse Correction [13:49:12] yeah i should have said updates [13:49:16] so in lots of NASA documents they usually say MCC-H, for Mission Control Houston [13:49:37] so what you are talking about is the Mission Control feature of NASSP [13:50:31] your "mcc's" confused me, MCC-H can't really be plural. Anyway, it's implemented up to, but not including LM activation. [13:50:35] but a lot of it is untested [14:16:38] yeah just looking at the press kit and flight plan apollo 9 looks pretty fun [14:20:45] hey thymo [16:51:51] morning! [16:56:24] hey [17:02:18] Hey [17:04:11] what's up? [17:05:40] Trying to get a patch merged in the linux kernel. [17:09:02] sounds ambitious [17:10:38] It's just a documentation patch really. Cleaning up kernel-parameters.txt a bit. [17:11:46] But I'm already moving to v3 of that patch because some parts go beyond the holy 80 column mark. [17:15:28] I imagine any change, even documentation, for the linux kernel has many obstacles [17:20:02] how does that even works? Who allows changes to be merged or not? How is the kernel maintained? [17:21:53] The NASSP Software Control Board currently consists of me alone. Fairly strict, but not too bad :D [17:24:48] You start off by cloning the git tree that subsystem uses (you can use others, but that might cause merge conflicts). Then you just change and commit stuff like always. After that you let git generate a patch using git format-patch. [17:25:23] indy91: you should start writing little memos called Niklasgrams (Beuggrams?) and sending them out to all of us :P [17:25:59] indygram [17:26:07] Then you look up the maintainer of a specific file using a perl script. That will give you the email address of the maintainer and the associated mailing lists. You use a cli email client (git send-email, mutt, etc.) to send that patch to the maintainer and cc it to the mailing lists. [17:26:07] haha yeah [17:26:34] Either it gets ack'ed by the maintainer or you need to make some more changes. [17:26:51] interesting [17:27:15] After it's acked, the subsystem maintainer will sign off on the patch and then include it in linux-next. That is the git tree with all the patches for the next kernel version. [17:27:35] I can't imagine being a maintainer for such a big thing [17:27:50] part of what turned me off of my first big public project was all of the tech support I had to do for my users [17:28:01] When the merge window for the next kernel version opens the subsystem maintainers will ask Linus Torvalds to pull their trees and then finally your patch will be in the kernel. [17:28:15] luckily we never have to do tech support... [17:28:22] virtualagc is fine since it's mostly just you guys that bother me :P [17:29:21] This video shows how the development process works very well: https://www.youtube.com/watch?v=vyenmLqJQjs&ab_channel=GitHub [17:30:03] Oh, and their is also a script that checks your code against the coding style rules. Quite cool. [17:30:11] thanks, I'll definitely watch that [17:33:23] TBH NASSP really could benefit from some style rules. Style tends to vary around the tree. [17:36:06] sure [17:36:09] write some :D [17:41:19] yay, I can now force a TEI solution to reach a specificed return inclination [17:41:28] that will help with optimizing TEIs [17:41:36] I will if I can find some time. College really likes to take all my time up lately. I haven't even looked at NASSP code in 2 months. [17:42:26] the CWEA is fully implemented, haha. I hope Ryan could use a bunch of the initial work you did on it. [17:43:14] Oh that's cool. Is it modeled with the individual relay behaviour too? [17:43:30] no, I think that is not done [17:43:51] Well, it's a good start anyway. That functionality can always be added. [17:44:21] yeah [17:45:05] I usually keep to these guidelines, I don't agree with all of them (8 char tabs is a bit too much IMO): https://www.kernel.org/doc/html/v4.13/process/coding-style.html [17:45:22] I'm sure the majority is applicable to NASSP. [17:45:34] yeah 4 spaces is the way to go [17:45:44] also I *hate* the 80 character line limit [17:45:48] so i am going to back to 11 now and land, for the p57 does it matter how far apart the two stars should be? [17:45:52] We just need to evaluate what we have used/ want to use. [17:45:56] that was nice a decade ago with tiny resolutions, but it's so short on modern screens [17:46:30] I sometimes still run into it when coding in split screen terminals or having a small editing window in an IDE. [17:46:47] what does Visual Studio do by default? [17:46:57] But it is a bit dated yes. [17:47:12] 4 it seems [17:47:22] astronauthen96__, probably not [17:47:37] I think VS even has some kind of option that adapts to the style used in that file. [17:48:05] ah [17:51:26] one thing about code style [17:51:41] it can't ever apply to our e.g. RTCC and LVDC [17:52:13] or any other part of NASSP that tries to emulate 60s code [17:52:28] LVDC uses labels and goto [17:53:24] which is probably not a good style nowadays, but the goal there is to be faithful to existing flow charts and equation documents [17:53:44] historical accuracy > style in that case [17:56:47] I'm not against using goto where it makes sense. [17:57:27] yeah, just saying that NASSP has some special needs :D [17:57:33] In fact scroll around any random kernel driver and you see goto's being used quite a lot. [18:01:46] ah, interesting [18:04:43] Goto really isn't any different than let's say break. You don't do: while (true) { stuff(); if (condifition) break; } [18:05:22] It's just a keyword that has specific uses. You can use it a lot of time, it's just a matter of if you should. [18:14:39] yeah, goto isn't any more dangerous than a bad while loop [18:48:17] Another funny thing that comes to mind while I'm writing this patch message. They want you to write it in such a manner that you're telling git what you want changed. E.g not, I changed X to do Y in the future. But, Make X do Y. [18:49:32] watching the talk you linked, I can relate a lot to the "path of blame" with git. [18:49:51] I have done that so many times, something was broken, I look through the commits, ah, Alex broke it [18:50:04] so Alex gets to fix it :D [18:52:13] obviously just an example, in 90+% of the cases it would be my fault [18:52:20] Haha [18:53:23] It really is a nice feature. [18:54:00] I want to find how to bisect with git sometime. It lets you find which specific commit broke something. [18:54:45] I know you specify a bad commit and a commit where you know it worked and then does a binary search. [19:27:18] ah, today the TESS countdown on the Goddard website is right [19:27:34] in 3.5 hours [19:27:41] 22:51 UTC [19:29:40] Hmm, 1am. Not sure if I'll stay up for that. [19:30:43] luckily it was scrubbed quite early 2 days ago [19:32:02] the launch isn't the exciting part for me anyway [19:32:38] and the science won't begin until TESS reaches its final orbit, which takes a few weeks [19:32:43] so, not sure if I'll stay up [20:07:20] hey [20:08:01] hi alex [20:08:09] hey Alex [20:08:22] you'll like what I am working on [20:09:09] I modified the TEI targeting, so that you can optionally specify a desired return inclination [20:09:21] ooh [20:09:38] it's all a manual process right now, but you can optimize TEI quite well that way [20:09:40] that does sound quite interesting haha [20:10:20] btw how do you guys find the new LM textures? [20:10:23] needs some more work and testing, not sure it's always going to iterate well [20:10:32] first testing went well though [20:10:54] haha, haven't merged it in my local copy yet [20:10:58] let me do that [20:11:23] just out of curiosity when do you think the apollo 9 mcc-h updates will be done? [20:11:41] I haven't decided yet if I will work on 9 or 11 next [20:11:43] probably 9 [20:12:04] so fairly soon [20:12:19] very looking forward to it [20:12:50] let me know if I can improve anything on the LM visuals [20:13:02] and Ill for sure be able to help test the TEI stuff [20:13:16] even tested an old Apollo 14 scenario [20:13:22] promising results [20:13:27] i will tell you how it looks alex when i download the build [20:13:52] and ascending/descending node is also an input, together with the inclination [20:14:00] and that makes the difference for Apollo 14 [20:14:24] hmm [20:14:31] I think there is a problem with the LM [20:14:35] the new docking target [20:14:37] yeah I think 14 was the mission with the highest out-of-plane dv I noticed [20:14:42] it's visible in darkness [20:14:53] all of the LM is dark [20:15:03] tracking light is on [20:15:16] and the docking target is lit, as if it was sunlight [20:15:47] yeah I made it emit some light , to be more visible [20:15:53] I may of added to much though [20:16:07] but I believe the real one emitted light too [20:16:19] according to the LM-10 handbook [20:16:46] oh, ok [20:17:00] powered in some way or radioactive [20:17:24] but that doesn't mean I got the level right, it may be too much [20:18:00] I just loaded my current go-to testing scenario for the LM [20:18:07] which happened to be in darkness [20:18:14] and all I saw was the docking target, haha [20:18:24] not sure if that's right or not [20:18:36] but if it does emit light, then it could be all good [20:19:02] "Tne docking target is a three-dimensional, self-illuminated standoff cross that is separated [20:19:03] by a shaft from a circular base." [20:19:27] "Illumination is provided by radioluminescent disks, which outline the [20:19:27] cross and circular-base markings." [20:19:34] I guess there are no photos of the LM in darkness... [20:19:39] waste of film, haha [20:19:44] yeah lol [20:20:24] I wonder how much lighting radioluminescent disks would emit [20:21:14] anyways I got that from the LMA790-3-LM10 doc [20:21:20] page 2.10-1 [20:21:31] right [20:21:40] yeah, difficult to tell how much light is right [20:22:39] Ill do more testing and might turn it down a little [20:22:47] very easy to do [20:23:05] AlexB_88: https://www.hq.nasa.gov/alsj/20090016336.pdf [20:23:09] page 37 [20:23:44] oh nice [20:23:59] So its only the small circles that are lit then [20:24:02] so all those dots [20:26:35] so, all Apollo 14 TEIs are targeted to 40° return inclination, ascending node [20:27:05] and our normal TEI targeting right now results in 40.2°, descending [20:27:24] so the inclination is fine, just not the orientation of the return at entry interface [20:27:46] switching that to ascending, and forcing it to use 40° gives a nice +1400 ft/s DVY [20:27:59] which is close to the TEI PADs they got during the mission [20:28:05] great [20:28:46] I wonder if those 2 parameters can also be added to the RTE fly-by page [20:29:07] yep [20:29:18] flyby and PC+2 use basically the same targeting [20:29:20] as TEI [20:29:29] ah right [20:30:02] as so often, I use heavily modified AGC routines for this [20:30:18] in this case, the AGC always calculates a return maneuver in-plane [20:30:36] that's always what P37 calculates [20:30:42] and I just had to modify that [20:30:54] to use an orbital plane calculate from a given inclination [20:30:59] calculated* [20:32:55] every calculation of the RTCC MFD that results in reentry uses at least some piece of P37, haha [20:36:08] I guess all the flight plans have the info of what to enter, be it ascending/descending, or the inc [20:37:13] nope [20:37:15] just Apollo 14 [20:37:20] I think [20:37:27] because it was a special case [20:37:40] and they dropped the 40° max for the J-Missions anyway [20:39:01] not sure if any mission before would have been close to 40° [20:39:04] 12 maybe [20:39:42] hmm [20:39:52] Apollo 15 SCOT also has a 40° return [20:40:45] ah, they dropped it for Apollo 16 [20:40:54] "62° ascending return inclination" [20:40:58] in the SCOT at least [20:41:07] not sure what their 24 hour early return resulted in [20:44:03] Apollo 16 must also have a been a lunar declination peak, if 62° is really the most efficient return [20:45:50] testing an old Apollo 16 scenario, around 60° has indeed the lowest DV [20:46:40] the only hard constraint is heating and the AGC [20:46:48] AGC wouldn't be able to deal with a retrograde orbit [20:46:53] 62° is no problem [20:51:13] oh really? it can't handle retrograde? [20:51:16] that's interesting [20:52:45] I can't say immediately what would prevent it, but I am pretty sure [20:53:04] general retrograde missions would also not work, at least if you wanted to perform rendezvous [20:53:39] the Lambert routine has it hardcoded: lunar orbit = retrograde orbit, earth orbit = prograde orbit [21:01:54] so the goal I guess is to keep iterating the inc to get the lowest DV? [21:02:39] on the J-missions that is [21:03:21] on any mission really [21:03:35] just that until Apollo 15 the 40° constraint applied [21:03:43] right [21:03:50] so Apollo 14 and 15 returns ar 40° [21:11:26] hmm, not sure about those inclination constraints right now [21:12:03] you were speaking of updating the 2-impulse processor (lambert page) for supporting the A12 no-PDI+12 for instance, I guess thats in the works too? [21:12:44] I guess we can already do that with the correct offsets no anyway though [21:12:51] now* [21:12:54] yeah [21:13:01] it would just iterate on T2 [21:15:31] thewonderidiot, thanks for that lighting doc btw, very useful! [21:15:51] sure thing! [21:16:13] Ill see if I can make the docking target behave accordingly [21:27:35] I have to try a retrograde reentry some day [21:27:49] maybe the constraint on heating is the only really hard one [21:28:29] didn't find anything on the AGC having issues with it. Still think I remember having read something about that though. [21:29:00] it would be interesting to try [21:29:41] higher g's maybe? [21:30:27] yeah, you are going against the direction of the Earth rotation [21:30:34] right [21:30:37] so a higher wind relative velocity [21:31:57] calculating such a TEI with Apollo 10 [21:32:17] 165°/D, slow return has close to 0 DVY [21:32:50] total DV is about half way between a slow and normal return with prograde return [21:32:53] which is quite interesting [21:32:58] so I guess you would have a higher velocity at EI then the usual ~36000 fps [21:33:10] i probably wont get this far but do you have any idea where i could find the numbers for the burns past lem activation for apollo 9? [21:33:32] well, inertial velocity at EI shouldn't be much different [21:33:51] 36210 ft/s for the 165° return [21:33:56] pretty normal [21:34:18] ah right [21:34:20] astronauthen96__, flight plan should have a bunch [21:34:33] relevant are number like: delta height etc. [21:34:36] numbers* [21:35:01] one thing I am sure though, P37 does not like retrograde orbits [21:35:34] it slaps a minus on the orbital plane vector, if it sees it's retrograde [21:38:00] hmm [21:38:05] Artemis has something interesting [21:38:35] it has a posigrade/retrograde flag in P37 [21:40:51] already there in Colossus II it seems [21:43:05] so I think P37 can deal with retrograde orbits [21:43:20] return orbits* [21:43:24] and why should it, if the AGC in general can't deal with it general? [21:43:35] so I guess the CMC isn't the reason for a constraint there [21:44:16] I think it's part of the trans-Earth slowdown capability added on Apollo 10 [21:44:30] if you slow down a lot, you might end up in a retrograde orbit [21:45:27] and would it be normal for the vertical velocity to be around +500 [21:49:14] at what point? [21:49:41] after docking [21:50:22] it was in a previous scenario [21:50:29] but not now [21:50:40] it was a t 500 then gradually went to zero [21:51:20] uhh [21:51:33] I need more context [21:51:51] mission, where do you see the vertical velocity (an MFD, DSKY...) [21:51:58] pamfd [21:52:02] apollo 9 [21:53:44] 500 ft/s? [21:54:17] I don't think you should have such a high vertical velocity at any time during Apollo 9 [21:55:33] maybe some time during S1C flight :D [21:55:55] lol [21:56:46] oh, that for sure [21:56:56] astronauthen96__, what are apoapsis and periapsis altitude? [22:01:50] i dont remember i restarted the scenario and its all good now [22:02:51] the first time is was maneuvering quite a bit for the docking [22:04:35] i* [22:32:27] https://www.youtube.com/watch?v=aY-0uBIYYKk&ab_channel=SpaceX [22:50:58] Launch coming up! [22:51:45] go TESS! [23:00:14] Very smooth landing [23:00:25] who cares about the landing :D [23:00:42] Me :P [23:00:44] but the camera connection on the stage itself is much better than the ship [23:01:00] no video cut! that was pretty awesome [23:01:09] usually the connection cuts out on the barge, this time as well. [23:01:23] but the stage camera barely had issues [23:01:27] Very cool seeing the ship coming up in the camera. [23:01:39] well, I'll just assume the second burn will be good as well [23:01:42] good night! [23:03:59] Same here. I'll get ready for bed and then watch an episode of Star Trek. :) [23:04:39] Then I can get back to studying for my algorithms & datastructures final tomorrow. [23:04:42] Night! [23:41:33] TESS sep! [10:51:18] good morning [10:51:34] burned sps 1 for apollo 9 [10:53:43] hey [10:53:55] yeah, SPS-1 is quite straight forward [10:54:15] just increasing the apoapsis a bit [10:54:35] very easy [10:54:53] I'm working on improved TEI calculations and after that I'll probably continue with the Apollo 9 MCC [10:54:59] okay [10:56:03] besides 11 i am looking forward to apollo 9 the most [10:56:21] looks action packed in my opinion [10:57:09] well, it's similar to Apollo 7 in that a lot of testing is done [10:57:15] procedures never done again etc. [10:57:54] there are some busy days [10:57:57] on Apollo 9 [10:58:03] like day 2 with lots of SPS burns [10:59:20] challenging SPS burns even [10:59:30] one has manual TVC [10:59:34] SPS-3 [11:00:07] have you ever flown Apollo 7 far enough to do the MTVC? [11:00:31] nope [11:01:13] it will probably help to read the TVC section in our wiki before you get to SPS-3, so that you know what to expect [11:01:14] http://nassp.sourceforge.net/wiki/Service_Propulsion_System#Thrust_vector_control [11:01:49] you will use the RHC to control the CSM+LM during SPS-3 [11:02:03] and fly the error needles. It's lots of fun [11:04:31] which sps burn in 7 has MTVC? [11:04:53] SPS-5 [11:06:50] think i'll try that first after some coffee [11:07:09] but this one is a shorter burn [11:07:45] yeah, you can probably use the Apollo 7 Before SPS-5 scenario for some training [11:08:22] and for 9 it says mtvc for last 45 seconds [11:09:06] yes, the MTVC capability is usually meant for taking over control, if the automatic control fails [11:09:17] so in that test you take over control during the burn [11:09:43] i thought it was going to be for the entire 279 seconds [11:10:31] not during that test, no [11:10:44] there is nothing stopping you from taking over control directly after ignition of course, haha [13:06:44] Good morning [13:06:57] hey [13:11:38] morning [13:12:41] hey Alex [13:21:56] just trying out the new inclination functions, very nice [13:22:28] yeah, seems pretty reliable [13:26:15] input 0° for the inclination to use the old method [13:26:31] proably a good start if you want to optimize the maneuver manually [13:28:31] tested a bunch of maneuvers with Apollo 10, the flyby maneuver to the mid pacific is optimal at 40° descending node [13:28:43] so there they also run into that constraint [13:30:48] and with the given inclinations in the Apollo 14 flight plan you can calculate all those RTE maneuvers [13:47:35] just tested my Apollo 13 scenario with it, DVY of -24.7 [13:47:42] with 40 ascending [13:49:52] oh [13:50:01] the flight plan for 13 also specifies the inclination [13:50:04] so 13 and 14 I guess [13:53:12] are 10-11-12 not 40 A as well? [13:53:29] maybe [13:53:41] but the flight plan doesn't have a list, I've only seen that for 13 and 14 [13:57:07] Apollo 12 nominal TEI should be about 19° [13:59:47] just tested the fly-by targeting on Apollo 13 [14:00:16] 40 D according to the RTE block data schedule [14:00:54] and calls for 335 fps in the flight plan, my DV is 336.8 [14:01:07] haha, nice [14:01:40] I guess there is no urgent need for those RTE Processor documents right now then... [14:03:01] yeah [14:23:33] is anyone here flying the j missions [14:23:44] not right now [14:23:55] Alex and I have flown them [14:24:11] well, I have flown Apollo 15 and 17 until the landing, but not any further [14:24:21] i think i might start 15 [14:24:40] you are starting many missions, haha [14:24:45] yeah [14:24:55] just not sure which one to focus on right now [14:25:09] Apollo 15 has the most spectacular landing site [14:25:14] and it's a fun mission all around [16:00:22] @indy91 out of curiosity when do you think you will be done with the TEI stuff [16:00:51] the only thing missing is some automatic optimization [16:01:03] to find the smallest DV [16:01:26] but I have no immediate plans of adding that, so, I am done with TEI... now [16:11:17] just debating which mission to start [16:44:02] morning! [16:44:53] hey [16:46:12] sad news from the AGC developer list this morning -- Charley Muntz passed away a few weeks ago [16:48:34] had to look it up, he wrote the Interpreter [16:48:41] sad news indeed [16:50:35] he was also the rope mother for SUNRISE, RETREAD, and AURORA (until Jim Kernan took over) [16:52:59] now nobody understands anymore how the Interpreter works :P [16:53:04] haha [16:55:02] I really should, considering I've transcribed that section for 5 different AGC programs [16:55:52] That's sad news indeed. Sorry to hear that. [16:56:08] What is this AGC dev list though? Not the AGC dev list I assume? [16:56:35] they have a mailing list [16:56:39] Mike is listening in [16:56:54] Is it public? [16:57:01] it's a mailing list for all of the AGC developers that are still around, that Ron and I got added to [16:57:04] no [16:57:15] Okay [17:46:16] @thewonderidiot i will be using Colossus 3 very soon [17:56:03] back in a bit [11:40:04] good morning [11:40:37] got up to right before lem ejection with apollo 15 [11:41:37] great [11:41:41] did you like P15? :D [11:41:51] there was no p15 in the checklist mfd [11:42:16] i probably could have used the 15 checklist for that [11:43:15] which i have on my tablet [11:44:10] oh, there is no Apollo 15 checklist for the Checklist MFD yet [11:44:16] it uses a default CSM checklist [11:44:26] which won't have anything specifically for Apollo 15 at all [11:44:56] and the default checklist might also not be 100% compatible with Artemis [11:45:09] what about like apollo 12? [11:46:59] nop [11:47:00] nope [11:47:15] only the missions that will be fully supported in NASSP 8.0 right now [11:47:17] so Apollo 7-11 [11:47:48] so you used P47 during TLI I guess. P15 is a program specifically for TLI that was added for Apollo 14. [11:49:19] i think i'll stick with 9 and 11 for now [11:52:19] so to calculate the sps for apollo 9 would just need the new HA AND HP numbers? and the TIG [11:53:06] the day 2 SPS burns? [11:53:11] SPS-2 to 5 or so [11:53:38] I think most of those are out-of-plane, so they don't change the HA and HP much [11:53:57] and if you are using the MCC scenario, those burns should already be covered [11:54:14] I'll continue with the Apollo 9 MCC soon as well [11:57:48] so many things to do and so many missions to fly in Nassp [11:58:54] yes, difficult decision, haha [11:59:27] some missions are easier than others. Because of their mission profile, but also how much they are supported by NASSP right now [11:59:46] so in that sense the easiest would be Apollo 7 and 8, flown in NASSP 7.0 and Orbiter 2010. [12:00:07] the next best thing is Apollo 10 in NASSP 8, because the MCC for it is already done [12:00:17] then Apollo 9 and 11 [12:00:42] 11 easier than 9, because all the procedures have been developed for the RTCC MFD [12:01:58] For Apollo 12-17 you need to find the right checklists yourself on the Internet [12:02:19] procedures have been mostly developed for the RTCC MFD though [12:02:35] just no Checklist MFD or MCC yet for those misisons [12:02:37] missions [12:02:41] so that are your options :D [12:09:10] we actually even have an Apollo 5 scenario [12:44:26] hey [12:46:40] hey Alex [12:47:19] I'm finally adding the AGC ephemeris generator to the RTCC MFD [12:50:25] but there is a problem [12:51:06] jarmonik gave me the code for it and removed it from the LTMFD version for Orbiter 2016. [12:51:35] and in this RTCC MFD version of it the lunar ephemeris is exactly identical to what LTMFD was calculating [12:51:39] but not the solar ephemeris [12:51:42] which is really weird [12:52:29] lunar ephemeris is identical down to the last digit of the octals. So, it can't be any small coordinate system conversion difference. [12:54:17] I've even tested if the ephemerides Orbiter uses changed from 2010 to 2016, haha. They didn't [12:58:44] hmm very odd [12:59:46] I guess jarmonik is still active, maybe we can contact him about it? [13:00:05] yeah, I probably will [13:01:09] I you're adding this as part of a general "padload generator" [13:02:46] mostly so I don't have to use Orbiter 2010 anymore to generate ephemerides for the CMC [13:03:03] right [13:04:22] I am working on the docking target right now, re designing it so the shading looks right between day/night [13:04:45] nice [13:04:46] I discovered some new tricks in Blender for that [13:05:00] I requested two Apollo Mission Technique documents from UHCL [13:05:12] for TLC through LOI [13:05:22] great [13:05:23] for Mission F/G and then other one H-2 and subsequent [13:05:48] the H-2 one might have more about the way they set up the trajectory to burn LOI-2 as DOI [13:05:57] yeah [13:06:39] well knowing Margaret you will probably get them today lol [13:06:46] Lauren [13:06:58] I mean, I'd like Margeret to scan some documents as well :D [13:06:59] haha [13:07:09] yeah Lauren [13:07:10] Hamiltom? [13:07:14] and the Mission F+G document already was scanned [13:07:18] so it's just the H-2 one [13:07:43] astronauthen96__, we suspect Margeret Hamilton still has copies of the source code for CMC versions we don't have yet [13:10:01] astronauthen96__ I was meaning Lauren Meyers, but for some mysterious reason my brain decided to say "Margaret" [13:10:29] so i guess she might know about Nassp [13:10:55] Margeret might not even properly know about the Virtual AGC project [13:24:57] Good morning [13:30:31] hey [13:38:23] I have figured out how it does all the pressure math, but I still have not found a solution to have both exist in one tank at the same time and compute properly [13:40:30] It isnt well written to handle a liquid and a gas existing in one tank at the same time, even the cryo tanks [14:17:58] hey Ryan [14:19:12] Hey [14:24:13] So as I feared, I have figured out how and why the code does what it does, but I have not figured out a safe way to compute a gas only air volume [14:24:34] Without being hacky, of course [14:26:33] classic Lauren [14:26:38] AlexB_88, documents are both done [14:26:49] nice! [14:27:36] I was worried for a moment because they were quite small [14:27:44] but they are both 70 pages, so probably complete [14:30:59] I like this quote from the Apollo 13 document [14:31:17] "in the unlikely event the flyby mode were used due to some contingency..." [14:36:27] I guess they got a little over-confident after 2 successful landings lol [14:38:27] Well 13 was "routine" :P [14:40:03] I had requested the Apollo Mission Techniques for TLC [14:40:17] F/G mission in one document, H-2 in the other [14:40:54] it doesn't exactly have the info I hoped for, but still useful for MCC execution decisions, among other things [14:41:52] "RTCC Requirements for Mission H-2: Non-Free-Return Modes of the Translunar Midcourse Correction Processor" is what I really would like, haha [14:42:11] but even that might not have any details on the DOI as LOI-2 [14:42:32] because it might just be hiddenin the "converge full mission" block [14:44:07] so I guess I need to do geometry [14:46:30] RTCC Requirements for Mission H-3: LOI Targeting [14:46:33] also not bad :D [14:47:16] just that these are at NARA, not UHCL [14:49:48] oh wow [14:50:00] UHCL has a bunch of these [14:50:03] "LAUNCH VEHICLE targeting FOR APOLLO 13" [14:50:07] for various missions [14:50:20] I wonder if those could be guidance presettings [14:52:23] hmm [14:52:26] maybe [14:52:44] who hasn't requested anything this month? :D [14:53:18] Guenter hasn't yet [14:53:21] true [14:53:36] these documents have MSC report numbers [14:53:36] I think Thymo needs to program Guenter to send requests [14:53:41] We need Thymo to program him to do that :D [14:54:05] haha [14:54:13] The LVOTs are Marshall documents [14:54:28] so no idea what these are [14:55:32] how many different missions? [14:56:04] 13-17 [14:56:13] with a bunch of different versions [14:56:24] 9 versions for Apollo 13 [14:56:33] wow [14:56:54] whats the full name? [14:57:00] dated 05/11/1969 to 03/06/1970 [14:57:10] just search for "launch vehicle targeting" [14:57:28] there are a few other for unmanned misisons [14:58:15] 05/11/1969 to 03/13/1970* [14:58:26] How about I request say 2 of them to start and we can see what they areÉ [14:58:37] yeah [14:58:42] what's the best one to request, hmm [14:59:19] the sole Apollo 15 one maybe? [15:00:09] Does it say if they are scanned yet or not? [15:00:34] none of them are [15:00:41] they would have a * next to their location [15:00:48] ah [15:00:50] why so many Apollo 13 updates... [15:01:05] so Apollo 15/17? [15:01:07] the landing site coordinates were changed fairly late [15:01:16] there are 3 for Apollo 17 [15:01:31] right [15:01:39] the last one is from July [15:01:47] quite a bit away from the launch [15:02:01] let me figure out from when the Apollo 17 LVOT is [15:04:20] flight evaluation report doesn't have a list of references, haha [15:06:18] I guess you are looking at the same search list on the UHCL as me, just request what you want [15:08:39] UHCL page* [15:09:18] even if these MSC documents don't have full targeting parameters for the LVDC, they probably will contain useful information of some kind [15:09:51] I still don't really know what this stands for "70-FM55-22" [15:09:54] 70 is the year [15:10:35] FM? [15:10:42] Mike might know [15:12:55] especially "FM55" I don't really have any documents [15:13:06] if I look in references they are all quite good [15:13:17] like, "final spacecraft targeting data" etc. [15:16:29] all Mission Planning and Analysis Division documents are "FM" [15:18:05] ah [15:18:09] F is for flight something [15:18:14] M is for MPAD [15:18:21] because, FS is "Flight Support Division" [15:21:17] the F is probably for " Flight Operations Directorate" [15:26:09] woah, there is even more [15:26:21] when searching for "launch vehicle targets" instead [15:27:38] so to end my monologue, these "FM55" documents could be quite good :D [15:39:40] great [15:41:52] since they are not scanned maybe Ill start with just the Apollo 15 one, then when we see it we can decide if we want more [15:42:51] sounds good [15:45:11] sent [16:51:56] morning! [16:59:47] hey mike [17:11:00] what's up? [17:20:14] just working on the docking target [17:20:15] https://www.dropbox.com/s/3utge8oo3686x09/Screenshot%202018-04-20%2013.19.53.png?dl=0 [17:25:05] hey Mike [17:25:17] how much do you know about the naming scheme of MSC internal memos? :D [17:25:45] example: 69-FM-195 [17:26:09] I believe F is for the Flight Operations Directorate, M for the Division, Mission Planning and Analysis Division [17:26:34] we just found one at UHCL and Alex requested it with "FM55" in the middle [17:26:40] ever seen one of those? [17:27:11] or, have you seen an organigramm of MSC in the late 60s? [17:47:10] @thewonderidiot [17:47:43] hmmm [17:47:53] I have not [17:48:13] maybe the 55 is a group number? [17:51:20] could be [17:51:24] we might know soon [17:52:43] potentially UHCL has the MSC equivalent of LVOTs [17:53:52] ooo, nice [17:54:05] one of the Sunburst documents also referenced a FM55 document [17:54:41] and UHCL has 100 of them :D [17:54:48] "Final Spacecraft Targeting Data for the AS-206 Mission," MSC Internal Note 67-FM55-33, 1 February 1967. [17:54:53] yep, exactly 100 [17:55:02] also targeting of sorts [17:55:04] they have that one [17:55:06] heh [17:55:16] FINAL SPACECRAFT TARGETING DATA FOR THE AS-206 ( APOLLO SATURN 206 ) MISSION [17:55:18] Alex requested an Apollo 15 document [17:55:32] and depending on what is in it, we probably could use a lot of those 100 [17:55:39] hehehe [17:57:09] they are all targeting [17:57:23] maybe some MPAD subgroup, yeah [17:57:28] all of the Launch Vehicle Targeting documents are written by Edward M. Jiongo, of the Lunar Mission Analysis Branch [17:57:56] how do you know which branch he is from? [17:58:15] https://archive.org/stream/NARASWSelectedApolloBoxes/NARA-SW-selected-Apollo-Boxes#page/n1325/mode/2up/search/jiongo [17:58:43] I have two documents from him [17:58:59] I started sorting the MPAD documents in each branch a while ago [17:59:22] 2 of the 3 documents currently in my folder for that branch are from him [17:59:34] but just FM, not FM55 [17:59:43] yeah, like this one [17:59:45] hmmmm [18:00:40] I already looked in that NARA folder [18:00:47] it has 68-FM-55 and 69-FM-55, haha [18:01:07] NARA index* [18:01:49] I actually have so many MPAD documents, I should look how many I have fo reach year [18:01:57] for each* [18:02:09] and if I can find numbers 1,2,3 and so on [18:02:15] hehehe [18:03:45] hrm [18:03:47] I have saved them with NTRS ID [18:03:53] I can't find anything with FM55 [18:03:55] and a lot already with name [18:04:01] yep, me neither [18:04:07] I wonder if these are even documents [18:04:11] or tapes or whatever [18:04:24] they're filed at UHCL as MEMORANDUM [18:04:29] which isn't generally helpful [18:04:38] yeah, they are all memos of sorts [18:05:04] lol [18:05:22] the FM55s could also be tables with numbers [18:05:23] yeah, ND-1021043, the giant manual they split into four parts, is filed as a "memorandum" [18:05:26] targeting data [18:05:30] so that's meaningless [18:05:33] haha, wow [18:07:47] I wonder why we didn't find these previously [18:08:04] launch vehicle targeting sounds like something I would have searched before [18:09:41] haha, maybe you were being too specific? [18:09:54] instead of doing something like "VEHICLE" in title and "TARGET" in title [18:18:52] maybe [18:18:57] AlexB_88, any news yet? [18:19:09] not yet [18:31:21] my docking target update is almost ready [18:32:19] it still emits light, but Ive balanced it so it looks good both day and night [18:48:36] woo, just got an email stating that all of the paperwork for scanning the Block I manuals has been completed on the archive.org end [18:53:12] great [19:27:50] oh [19:27:54] I found some FM51's [19:28:10] I think FM5 == Lunar mission Analysis Branch [19:28:18] https://archive.org/stream/NARASWSelectedApolloBoxes/NARA-SW-selected-Apollo-Boxes#page/n327/mode/2up/search/fm5 [19:28:48] hmm [19:28:58] MPAD has lots of branches, haha [19:29:03] hehe yeah [19:29:40] lunar fly-by modes for Apollo 14 [19:30:30] non free-return modes of the TLMCC processor [19:30:35] but none of the MPAD documents I have, have anything else than FM [19:30:57] yeah, I know about all those documents at NARA [19:31:04] I have a list [19:31:22] https://www.hq.nasa.gov/alsj/tindallgrams01.pdf [19:31:40] page 132 has a list of names and FM#s [19:31:49] might be able to attach FM numbers to branches, based on those names [19:32:20] there's another FM51 memo in that pdf too [19:32:44] so if FM5 is a branch, FM55 is probably a group [19:34:26] or section [19:34:34] I think section comes below branch at MSC [19:34:45] like [19:34:46] Chief, Mathematical Analysis Section, Mathematical Physics Branch, Mission Planning and Analysis Division, Flight Operations Directorate [19:36:50] hmm, yeah [19:37:09] Wollenhaupt is listed as FM4 there, and he's the author of "STATUS OF LOCATING SURVEYOR III ON LUNAR SURFACE" [19:37:17] aka "69-FM49-285" [19:39:13] and FM4 is which branch? [19:39:29] not sure yet [20:02:28] indy91, PR sent [20:03:11] merged [20:03:22] thanks [20:12:29] night [09:01:22] good morning [09:01:40] just a question about apollo 11 [09:02:19] hey [09:02:33] after doi there is something about a pdi +12 [09:02:54] that is abort maneuver [09:03:01] you would get a Maneuver PAD for it [09:03:10] it's called "No PDI + 12" [09:03:23] okay [09:03:40] so if you didn't ignite your engine at PDI, you would perform that maneuver at 12 minutes after the time of PDI [09:03:49] it's setting up a re-redenzvous with the CSM [09:04:21] I think you normally already do the P30 for that maneuver before PDI [09:04:53] just so that you are prepared [09:44:28] also i skipped the csm rcs sep maneuver would that affect anything [09:45:35] and the p20 in the csm [09:47:14] skipping the P20 doesn't matter [09:47:35] skipping the sep maneuver isn't so good, but overall, it doesn't have a large trajectory effect [09:47:51] it's just that DOI would happen close to the CSM then [09:48:05] i skipped it because i was more focused on seeing if i could land [09:48:16] right [09:48:23] it's not critical to do the sep maneuver [09:48:47] not in the simulated world anyway [11:19:42] so how would 00003 be for the p57 alignment? [11:20:08] very good [11:22:31] it was a bit difficult to get the lines exactly on the star [11:22:45] yes [11:23:01] in fact we still aren't 100% convinced the spiral is correct [11:23:14] we have been having P57 alignment issues [11:23:35] gonna stick to 11 now that the p57 is done [11:23:47] is that the P57 after landing? [11:23:51] yes [11:24:55] next up is a simulated countdown I think [11:25:17] and then powering down the systems that aren't needed [11:25:30] hi alex [11:25:36] hey [11:25:40] hey [11:25:44] finally got through the p57 [11:25:55] I received the Apollo 15 doc [11:26:05] not very big though [11:26:08] oh [11:26:22] ok [11:26:22] https://www.dropbox.com/s/pzrag47y56iqrvm/HSI-43433.pdf?dl=0 [11:27:26] I should have went for one of the main ones that dont sound like an "update" lol [11:27:43] yeah, this one is just an update of sorts [11:28:11] hmm [11:28:20] a full document might still have good numbers [11:28:56] Ill try another I guess [11:29:13] these aren't really precise enough for a launch azimuth polynomial [11:29:33] good numbers as in presettings? [11:29:48] yeah, or something that can be converted to presettings [11:29:53] right [11:29:58] a full document might be more detailed about the launch window [11:30:01] for the whole launch window? [11:30:13] launch vehicle targetS FOR APOLLO 13 APR 1970 LAUNCH WINDOW [11:30:18] how about this one [11:30:23] sure [11:30:39] any of the other Apollo 13 ones could also just be updates [11:30:42] I guess whatever one we can be sure is full [11:31:17] the earliest one for any mission probably will be a full one [11:31:58] this Apollo 15 one has some good numbers, like lunar landing times for alternative launch times [11:32:29] GMT of launch as well [11:32:48] might be possible to make a rough launch azimuth polynomial out of it [11:34:34] yeah, I think a full document might be quite good [11:36:20] "launch vehicle targetS FOR APOLLO 13 APR 1970 LAUNCH WINDOW" I cant find this one [11:36:51] what did you search for [11:37:04] search for "launch vehicle target" [11:37:11] that's what I did [11:38:21] ok found it [11:39:12] maybe I can request Apollo 16 as well [11:39:48] the main one, not the update [11:41:27] yeah, let's skip the updates for now [11:41:33] so not those 10 other Apollo 13 ones [11:42:19] right [11:42:20] so, in the worst case, these documents are just the targets MSC has come up with [11:42:35] as they said in the document, these targets have been submitted to MSFC [11:42:51] where they did the calculations for the presettings and the LVOT [11:43:33] so basically one step before any presettings [11:43:41] could still be very useful [11:45:23] So I am about to send requests for: [11:45:25] LAUNCH VEHICLE TARGETING FOR APOLLO 16 [11:45:29] this Apollo 15 document tells me something I didn't know. They didn't target a completely constant arrival time [11:45:31] LAUNCH VEHICLE TARGETS FOR APOLLO 13 APR 1970 LAUNCH WINDOW [11:45:33] due to performance reasons [11:45:36] sure [11:46:48] sent [11:47:04] when did you get the Apollo 15 document, today? [11:47:21] or yesterday [11:47:31] yesterday [11:47:35] ah [11:47:38] 5 min after you logged off again [11:47:40] :D [11:47:48] so they don't make poor Lauren work Saturdays :D [11:48:04] I guess not [11:49:30] and I am feeling like geez maybe I am requesting too much from her, but then again she must be pretty happy with me I keep requesting these 4-10 page update notices lol [11:50:39] haha, right [11:51:00] most of the effort for those is probably finding them in the archive [11:51:34] yeah [11:51:56] I've talked to Jarmonik, we believe that LTMFD 1.4 for Orbiter 2010 used the barycenter position of the Earth [11:52:05] and not the Sun-Earth relative position [11:52:23] I haven't been able to replicate the LTMFD solar ephemeris yet [11:52:43] but if anything the slightly different calculation in the RTCC MFD now is probably even more accurate [11:53:43] I've tested it, the position it's using right now is definitely identical to what oapiGetRelativePos returns [12:28:20] so are the 11 checklists pretty much complete at this point? [12:29:43] I think so [12:29:57] I'm sure there are lots of small errors, but the checklist should be fairly complete [12:43:29] found some interesting stuff by searching for "checklist" [12:43:57] whole bunch of Apollo 17 checklists [12:44:15] APOLLO 17 DECEMBER 6 LAUNCH CHANGE A LM ( LUNAR MODULE ) ACTIVATION checklist [12:44:25] yeah, I knew about those [12:44:25] APOLLO 17 ALL LAUNCH DATES CHANGE A LM ( LUNAR MODULE ) CONTINGENCY checklist [12:44:34] Apollo 16 as well I believe [12:45:06] I'd like to find a LM G&C check for Apollo 15/17 [12:45:26] and a CSM G&C checklist for Apollo 11 [12:46:40] we have the AOH Volume II for the J-Missions I believe [12:46:59] but that CSM checklist would be nice [12:47:09] we are really missing one in between [12:47:20] we have 8 and 14-16 [12:47:30] yeah [12:48:41] who knows, maybe a later LM G&C Checklist also has a backup padload [12:50:24] yeah [12:50:35] btw have you tested the docking target changes? [12:51:45] as usual comments good/bad and suggestions welcome [12:51:59] I'll look at it [12:52:10] I believe it's called G&N Dictionary throughout the program [12:52:13] the LM checklist [12:52:22] right [12:52:42] APOLLO 17 ALL LAUNCH DATES BASIC FLIGHT CREW G & N ( GUIDANCE AND NAVIGATION ) dictionary [12:52:51] haha [12:52:59] and the best thing [12:53:02] it's already scanned [12:53:08] ohh [12:53:24] alright I have no excuses then [12:54:03] its hard to tell if its LM or CSM though [12:54:26] "basic" I guess that could be a lot of things [12:55:08] the CSM one is G&C Checklist [12:55:15] right [12:59:41] sent [13:00:53] It would be great if it includes the AGS section like the Apollo 12 doc [13:01:47] yeah [13:19:44] about the docking target, the cross itself is now a bit thinner and is basically the correct shape now (square instead of cylindrical) [13:20:22] it might be harder to see and make docking more challenging, but it should be realistic like that [13:20:40] I think zooming in during docking to FOV of 30 or so helps [13:20:57] and probably more realistic too [13:35:20] docking target looks fine in darkness now [13:35:25] not so bright [13:45:56] yeah [14:05:42] ok, launching Apollo 9 again to work on the MCC [14:46:19] for the ascent pad do use the regular tpi in the flight plan? [14:53:44] no, the one from the RTCC MFD [14:54:14] lunar liftoff calculation page [14:57:03] for the one right after landing [14:58:13] did they get a full ascent PAD at that time? [14:58:27] it asks for an ascent pad [14:58:59] at 103:38 [14:59:02] yeah, found it in the transcript as well [14:59:35] 107:11:30 [14:59:42] is the TPI time in the transcript [14:59:55] just use that as the initial guess for the lunar liftoff time calculation [15:00:13] I don't think there is an Ascent PAD page on the RTCC MFD yet [15:00:19] but that page has most of the numbers [15:20:33] I thought of something, the lunar liftoff page could be used to calculate the T2 and T3 abort pads? [15:20:52] but I guess those can only be done after the landing right now [15:21:47] did they get the T2 and T3 abort PADs before PDI? [15:22:27] in any case, all that really needs as an input are the nominal landing site coordinates [15:22:36] so easy to calculate even before landing [15:23:48] I can change it, so that it always uses the landing site coordinates in the RTCC MFD [15:24:07] and doesn't calculate the coordinates from the vessel right now [15:24:38] yeah that is what I was thinking could be done [15:24:41] even after landing, but without having updated the landing site on the update page for that, the liftoff times should be quite accurate [15:24:58] because, it's not like you will be off many miles downrange [15:25:05] right [15:26:52] and T2 time seems to be referenced from PDI-1 TIG say on Apollo 13 [15:27:02] PDI 1+20:45 [15:27:51] although [15:27:55] but T2 seems to be for a multi-rev rendez-vous with BOOST and HAM [15:27:58] T2 and T3 have different rendezvous profiles [15:28:03] not the standard one [15:28:10] yeah [15:28:11] that needs to be taken into account [15:28:20] I think T3 is the normal one [15:28:46] doesn't look very normal to me [15:29:39] ah, I am looking at Apollo 11 [15:30:00] isn't T3 the 1 REV abort [15:30:58] with CSI TIG 50m after insertion [15:31:23] yeah [15:31:28] the PAD just confuses me [15:31:34] has CSM period and P+DT [15:33:40] but yeah, T3 rendezvous profile might be quite normal [15:34:06] haha yeah I wondered what that was [15:35:30] P+DT is explained in the flight plan [15:35:47] CSM orbital period plus the time interval between closest approach and liftoff times [15:36:04] maybe a way to derive liftoff times yourself for later revs? [15:36:39] you would figure out the closest approach time somehow, P22, P21, no idea [15:36:46] but then you add the P+DT time to that [15:36:54] and you have your liftoff time for the next rev [15:36:56] just an idea [15:40:00] I guess I just need to implement the T-2 rendezvous profile for the liftoff page [15:42:49] so for the plane change which refsmmat do i use? [15:43:12] which plane change? [15:43:18] csm [15:43:23] oh [15:43:29] they scrubbed that one on Apollo 11 [15:43:38] my dv was 4.7 [15:44:01] yeah, not much need for it with the short time on the surface [15:44:14] I'm not sure about the criteria for that burn, to execute it or not [15:44:22] I don't think it's necessary [15:44:35] okay [15:46:16] AlexB_88, CSI-1 on Apollo 11/12 is a HAM? [15:47:35] ah, and a change from Apollo 11 to 12 is to use fixed DTs between the maneuvers [15:47:50] Apollo 11 still would use maneuver lines, so CSI-1 at apolune etc. [15:48:16] or perilune rather [15:48:22] Boost at apolune [15:49:15] and also i dont see a lift off refsmmat option [15:49:25] same as landing site [15:49:31] okay [15:49:34] just with the input time being the liftoff time [15:50:21] I think yeah they called it CSI-1 pre Apollo 13 [15:52:53] and the 10 ft/s Boost is called Phasing or C1, in the rendezvous procedures [15:53:17] so what determines the T-2 time [15:53:21] is it fixed pre flight? [15:55:26] good that we have this Apollo 13 document [15:55:29] seems fixed [15:55:39] PDI-1 plus 20:45 for Apollo 13 [15:56:12] T-2 on 13 looks like the full BOOST+HAM [15:56:26] 50,60,50 DTs [15:56:53] yeah [15:56:55] So I guess the launch time would neet to take that into account? [15:57:13] the DVs take it into account [15:57:14] or its just fixed [15:57:18] liftoff time fixed, TPI time fixed [15:57:55] so really not much to calculate in terms of liftoff time [15:57:59] just the CSI and TPI times [15:58:03] ah ok [15:58:30] so we can literally just take the PDI1+ __ time from the data cards [15:59:21] Apollo 11 [15:59:27] PDI: 102:33:04.36 [15:59:35] T-2: 102:54:29.00 [15:59:51] rounded up, but yes, PDI+21:24 [16:00:15] the 13 data card does have a line to update the T2-1 time [16:00:21] hmm, ok [16:00:29] but what's to optimize there [16:00:49] CSI-1, CSI-2 and CDH are all nominally non-zero [16:01:07] variations in the CSM orbit? [16:01:45] that will just mean different DVs for those maneuvers [16:01:52] it could be timeline related [16:01:52] right [16:02:03] like, you want to have T-2 at X minutes after nominal landing [16:03:30] ah, the Apollo 12 document has something about it [16:09:34] hmm, trickx [16:09:36] tricky [16:10:30] Apollo 15 T2-1 is PDI+21:26 in the Apollo 15 data card book [16:11:02] but they were read up "T-2 is at PDI plus 20:39" [16:12:46] hmm, the plot in the Apollo 12 rendezvous/abort book is not identical to the procedures [16:13:16] well, almost [16:16:22] judging from that Apollo 12 document, it almost seem like they ignored the rendezvous profile for the T-2 time calculation [16:16:39] and once they got the T-2 time, they applied the profile to it [16:16:54] that's how you get all those non-zero DVs [16:17:02] it says the DKI was used for it [16:19:58] the DKI for what? [16:20:09] the T-2 time? [16:20:13] yes [16:22:29] top of page 3 [16:22:49] of the operation abort and rescue plan change from mission G to H-1 [16:22:57] one of those you requested [16:23:08] I'm not sure I fully understand that passage [16:23:38] the normal DKI sequence is always: phasing, height, coelliptic maneuvers [16:24:53] called NC, NH and NSR maneuvers [16:25:11] the document mentions HAM a lot [16:25:25] that is not what the onboard documentation uses, not until Apollo 13 [16:29:10] the Apollo 12 DTs after T-2 abort is 50,2h48,50 [16:30:22] so the DKI would have to use the landing coordinates to figure out the ignition time to have proper phasing at insertion? [16:30:27] sounds complex [16:30:41] I'm not quite sure [16:32:04] the T2-2 is back to the regular 50,60,50 [16:32:57] one less rev [16:33:26] right [16:33:58] CSI-1 (HAM) is an actual high adjustment maneuver in this case [16:34:14] it sets up CSI-2 at DH of 15NM, for the nominal trajectory [16:35:17] and CDH is nonzero, because the liftoff time is calculated with the normal DKI profile [16:35:20] or something like that [16:36:12] that's what they did I believe. They didn't implement some fancy new way of taking into account this rendezvous profile [16:36:31] but instead let CDH be nonzero, but used the standard DKI for it, in some way [16:36:45] so on T2-1, CSI-1 is not a height maneuver [16:38:09] it's a height maneuver in the nominal trajectory [16:38:41] and in the actual mission it's just like the later HAM, it's more of a "setting up a DH for later" maneuver [16:39:52] so procedurally, using the T2-1 time for Apollo 12 and the HAM chart for CSI-1 should work I guess [16:40:02] or "setting CSI-2 so that CSI-2 can be a height maneuver with the right phasing" [16:40:25] yeah, there is a chart in the rendezvous/abort book [16:40:29] or CSI1 chart as they call it [16:40:34] yes [16:40:36] that one [16:40:53] which is essentially a HAM chart [16:41:02] yes [16:41:24] in the DKI profile it would be the height maneuver [16:41:32] setting up the next maneuver to be at a certain DH [16:42:03] hmm [16:42:07] very confusing [16:42:56] main difference is that the CSI-2 maneuver is already at the right DH [16:43:06] yeah [16:43:10] that was not the case for the Apollo 13 profiles [16:43:28] that's why it's kind of creative use of the DKI [16:43:50] NH = CSI-1, NSR = CSI-2 [16:44:28] next rendez-vous Id like to try is an Apollo 11/12 style NO-PDI+12 [16:45:53] CSI seems to be nominally 0 on that one [16:46:01] in the Apollo 12 abort book [16:47:36] yes [16:48:14] phase angle and DH would be fixed [16:48:28] Lambert targeted [16:48:35] T2 varied to achieve TPI time [16:50:53] I had calculated that PAD on my last Apollo 12 run. I used offsets that targeted the position of TPI on the NO-PDI+12 plot [16:51:17] position of TPI? [16:51:21] not CDH? [16:51:45] something lie -77 0 15 [16:51:53] hmm [16:51:58] sorry yes CDH [16:54:46] yeah, those numbers should be good [16:55:40] UHCL only has the preliminary document for Apollo 11 [16:56:11] October 1968 [16:56:15] too early [16:57:10] which document? [16:59:23] operational LM abort and rescue plan [16:59:53] https://www.ibiblio.org/apollo/NARASWoverflow/TitlePageScans/E209B-26/E209B-26_010.tif [16:59:56] this one :D [17:02:19] its funny I can calculate a phasing burn for the No-PDI +12 which of course gives me only DVX velocity [17:02:46] yeah [17:02:58] with a manual DVZ input you could try to get CSI to 0 [17:03:21] ah right [17:03:33] because they want CSI to be 0 [17:03:39] but that wouldn't really be the correct way [17:03:55] those No PDIs were not calculated with the DKI processor [17:05:06] well switching from -50 to 0 radial component doesnt seem to affect CSI DV anyway [17:05:32] not much, no [17:05:39] mostly will affect CDH to TPI time [17:06:08] one thing I am trying is using the DKI computed CDH time an using that as my T2 time on the lambert page [17:06:20] with the -77 0 15 offsets [17:07:41] ah [17:08:15] PROJECT APOLLO 500 RTCC ( REAL TIME COMPUTER COMPLEX ) OPERATIONS SUPPORT PLAN FOR Mission G [17:08:17] from 1969 [17:08:25] that's a document I will request at some point [17:14:41] +115 0 +150 on the lambert page [17:15:09] which mission are you trying this with? [17:15:22] Apollo 12 NO-PDI+12 DV from the LM data card book: +118 0 +128 [17:15:24] Apollo 12 [17:15:52] I used the DKI to get the T2 time (CDH) then used that in the lambert page [17:16:49] should be about right [17:17:05] the DT between CDH and TPI might be off a bit [17:19:23] hmm its about right 40 minutes [17:19:46] ok [17:20:05] also a good estimate would just be the DT between No PDI+12 and CDH [17:20:09] the nominal DT [17:21:15] I put 45 minutes as per the abort book [17:21:59] uhh [17:22:07] I mean 1h45m [17:22:23] 45m to CSI, then 1h00 to CDH [17:23:33] so I set up the DKI with CSI/CDH sequence and specified DTs with 45,60,60 [17:23:50] all just to get the T2 time out of it of course [17:28:22] I guess one good way to test the solution is to fly it and see how close to 0 CSI is [17:28:29] ad the DH [17:39:26] morning! [17:42:42] hey [17:50:43] im out for a bit, later [17:53:32] hey Mike [18:05:07] hey, what's up? [18:06:39] launched Apollo 9 again [18:06:43] to work on the MCC [18:06:51] and Alex got the Apollo 15 targeting document [18:06:58] was just a few pages, it was an update document [18:07:33] a full document might be like a requirement document for presettings [18:07:50] so MSC says to MSFC: these are the lighting constraints and landing times etc. [18:08:13] and MSFC does a bunch of simulations, which results in presettings and LVOT etc. [18:08:22] hmmmm, interesting [18:08:45] so, a full document might have interesting numbers. Probably less for the LVDC than for the RTCC though [18:09:00] does that IBM doc about program development I have say anything about these? it lists everything that is used for an LVOT [18:11:14] I remember that one, where have I saved it... [18:11:55] where did we find that one? [18:12:12] or, wait, maybe it doesn't [18:12:41] it's more about the LVDC software iirc [18:12:57] and less about the mission dependent numbers [18:13:51] there's some about it in here [18:13:59] talking about the Final Flight Data Document [18:14:11] which is based on the operational trajectory [18:14:37] in any case, this Apollo 15 document said that the updated numbers from it were submitted to the MSFC [18:15:49] so I take it Alex has requested a couple of others that are probably not updates? [18:20:12] yes [20:07:04] night [21:02:36] thewonderidiot, yeah I requested the Apollo 13 and 16 targeting docs [11:21:44] good morning [11:22:01] got up to the eva wakeup last night [11:28:38] hey [11:29:17] had to use 15 time acceleration but thats fine [11:29:20] 15x [11:30:04] Apollo 9? [11:30:10] 11 [11:30:12] ah, right [11:30:38] I've launched Apollo 9 again and will work on the MCC soon [11:30:52] nice [13:04:52] hey [13:06:50] hey Alex [13:38:50] I think I will finally bring my Apollo 13 crew back home today [13:42:39] going to test a nice 40 A TEI [13:48:31] and i am about three hours from liftoff [13:55:03] from the moon? [13:55:14] yes for apollo 11 [13:56:52] nicew [14:05:30] indy91, the 2nd plane change burn on Apollo 13 was planned to be 825 fps, pretty high [14:06:11] is that after LM jettison? [14:07:15] seems like that burn was targeted to fly over Descartes on rev 42 [14:09:27] yeah [14:09:48] I wonder how that burn was calculated in the real RTCC [14:10:10] I guess they chose a TOA over Descartes [14:10:12] just like any other plane change targeting [14:10:13] yes [14:10:24] used the Descartes coordinates [14:10:57] and the TOA is only to specify the revolution of the pass over Descartes [14:11:13] I'll rework the plane change targeting soon [14:11:23] I believe there were some problems with it on some missions anyway [14:12:01] In my experience it worked well, except for the fact that it sometimes seems to calculate a prograde orbit [14:12:16] so like a 10000 fps + in VGX [14:12:41] right [14:12:49] shouldn't be too difficult to fix [14:12:53] yeah [14:13:38] Ill test it on this one Ill throw in the Descartes coordinates and calculate it [14:14:35] I find I get the prograde orbit problem if I use a TIG that is far off from nominal... but if I put a TIG that is close to the one in the flight plan, its fine [14:19:30] I really haven't looked at the plane change targeting since I first implemented it [14:19:40] it's based on an early GSOP [14:28:06] 1200 fps [14:28:18] vs. 825 in the flight plan [14:29:45] that using the plane change page with a TOA on Descartes for REV 42 [14:36:19] I've been just targeting the SCOT inclination for these types of burns and find it works quite well [14:48:19] I talked a bit more to Jarmonik [14:48:35] we have figured out what LTMFD was doing differently than the RTCC MFD for the AGC ephemeris [14:48:52] we weren't 100% sure until yesterday [14:48:58] so the ephemeris generator in the RTCC MFD is good to go [14:49:12] solar ephemeris will be more precise than calculated with LTMFD [14:50:05] great [14:50:15] hmm I wonder if this will help P23s [14:50:52] btw I am adding base configs for the remaining landing sites [14:51:04] we had tranquility and fra mauro so far [14:51:18] unlikely to help with P23 [14:52:00] but maybe I'll replace our solar ephemeris for all missions anyway [14:52:54] I guess the Earth ephemeris is identical anyway [14:54:28] that's just the state vector [14:54:38] at least inside the Earth SOI [14:55:31] the AGC uses Encke's Method for the state vector propagation [14:55:52] at the time of the first P23s that means: Earth Kepler orbit calculation plus Sun and Moon as disturbing forces [14:56:06] only the disturbing forces will be integrated [14:56:32] so yes, both solar and lunar ephemerides have an influence on P23 [14:56:44] not that much shortly after TLI though [14:59:12] and over a longer period of time P23 would be able to correct any ephemeris errors [15:06:22] uhh sorry lol I meant to say Lunar ephemeris [15:07:07] like you were saying yesterday I think, you were able to create identical lunar ephemeris in RTCC MFD as LTMFD [15:07:15] but not solar [15:08:39] yes [15:09:01] you know I think the bulk of my P23 troubles was in the region where the solar ephemeris might have the greatest influence ie. in mid cis-lunar space near SOI switchover [15:09:35] so maybe these new solar ephemeris might be better then we think [15:09:40] hmm, maybe [15:10:03] even now it is pointing almost directly at the SUn [15:10:30] the improvement is maybe up to 0.5° [15:10:36] probably less [15:10:42] could depend on the mission though [15:11:02] https://en.wikipedia.org/wiki/Barycenter#/media/File:Solar_system_barycenter.svg [15:11:14] barycenter vs. true position of the Sun is the difference from old to new ephemeris [15:13:35] I have a PR almost ready for the base configs [15:17:41] and for the launch time prediction change [15:17:47] vessel->GroundContact() [15:17:53] I'm adding this check [15:18:12] if the LM is landed, it's going to use the current position [15:18:25] if not, it's going to use the landing site coordinates saved in the MFD [15:18:38] great [15:18:42] there isn't enough space on the MFD page to make that user optional, haha [15:19:59] PR sent [15:20:25] I still have that Apollo 14 plane change testing scenario you gave me a year ago [15:21:12] Oceanus Procellarum? [15:21:38] is that Apollo 12? [15:21:43] yeah [15:21:55] PR merged [15:23:00] I also removed "base" from the 1st 2, because I did not want to add base to all of them [15:23:17] right [15:23:22] because Oceanus Procellarum Base sounds very good right [15:23:33] and it's only an informal term used on Apollo 11 anyway [15:23:39] yeah [15:24:20] I guess Oceanus Procellarum is Latin for Ocean of Storms [15:25:33] ah, that makes sense [15:25:41] Ocean of Storms is the name for it I knew [15:32:42] the VORs now are according to the mission to simplify things ie: Tranquility: 111.7, Fra Mauro: 114.7 and so on [15:33:23] must be those ALSEP VORs :D [15:33:44] so now is a good time to throw a VOR in that LEM :D [15:34:44] ILS would also be useful [15:41:20] I have a question about the PDI pad calculation [15:41:47] would it be possible for TLAND to be updated based on the actual trajectory when the PDI pad is calculated? [15:43:14] the reason I am curious is because if you lose the updated TLAND data after the DOI calculation/burn say if you close and reload without the MFD then the TLAND reverts to the pre-mission one [15:44:02] so unless you wrote it down, the only way to get it back is to recalculate a "fake" DOI [15:44:10] which works I guess [15:46:15] yes, that is possible [15:46:22] it's calculated internally anyway [15:46:34] with the input TLAND as the initial guess [15:46:46] essentially does the same calculations as the LGC [15:46:52] ah ok [15:47:12] should that be optional or always be done [15:47:14] so I guess it just doesnt yet actually update the TLAND in the RTCC variables [15:47:28] PDI PAD only returns the PAD [15:48:23] I mean I guess its trivial [15:49:20] so should the PDI PAD calculation always update the TLAND? [15:51:34] I am not sure if it should to be honest, it would just make sense to me. The other thing is I had the idea that they would uplink a new TLAND along with the RLS before PDI [15:52:31] The way I do it now is I just write down the new TLAND after the DOI (if it did not stay saved) and then uplink it along with the RLS before PDI [15:52:42] yes, they very likely would do that [15:54:03] or maybe a "TLAND refresh" button on the DOI page [15:57:04] oh, you mean a TLAND update between DOI and PDI? [15:57:27] yeah [15:57:58] well for the normal DOIs half a rev before PDI, there was a "descent target load" uplink shortly after undocking [15:58:27] that would include the abort constants, TLAND and RLS I guess [15:59:08] right [15:59:51] so maybe a "TLAND without DOI" button would be best [16:01:02] on the DOI page though, as you said [16:01:03] yeah [16:01:03] I'll be back later [16:01:28] so that on the missions with long stretches between DOI and PDI, if you lose the updated TLAND (from saving/relaoding) then you can just hit that button [16:01:31] cya [16:15:36] 20 minutes till lift off [18:09:41] morning! [18:10:28] hey [18:11:32] what's up? [18:13:36] just about to lift off from the moon [18:20:00] just about to burn TEI on Apollo 13 [18:20:34] testing Niklas's new RTE inclination functions [18:34:52] and I'm looking at plane change targeting [18:45:14] back in a bit [19:43:18] back [19:47:37] making progress on wiring up a counter with these logic modules http://i.imgur.com/x0BQ4DG.png [19:50:07] cool [19:50:23] looks like quite the task [21:18:32] it works!! [21:18:33] http://i.imgur.com/N3U4gEJ.png [21:18:47] counting edges on an input square wave [21:20:20] http://i.imgur.com/UEgPn6z.png [22:18:23] thewonderidiot, nice! [22:19:54] night [12:22:06] good morning [12:22:53] so there is this pulse thing right before csi [12:23:46] is it really necessary [12:23:47] ? [12:23:58] what pulse thing? [12:24:29] something about pulse until r1 and r2 = zero [12:25:49] found it in the checklist [12:25:50] hmm [12:29:46] I have no idea why that would be there [12:30:00] i know it was not on apollo 10 [12:30:07] it's nowhere in the documentation for Apollo 11 [12:30:30] we'll have to ask rcflyinghokie why he included that [12:30:55] oh wait, now I understand it [12:31:11] found it in the rendezvous procedure page 32 in the pdf [12:31:21] it wants you to change your attitude, so that the CSI burn is only in one axis [12:32:12] for Apollo 11? Final or Final Revision A? [12:32:29] mission g rendezvous [12:32:42] which one though, we have two [12:32:58] from May or June? [12:33:02] final rev a [12:33:09] ah, ok [12:33:22] found it [12:33:55] ok, the page before it skips the automatic attitude maneuver [12:34:15] and then it wants you to manually reach the attitude [12:34:53] I think the auto maneuver would cause the DV to be in R1 only [12:35:05] but for the CSI burn you want it to be in R3 [12:35:14] so that's what you have to do [12:35:27] a manual attitude maneuver until the DV is only in R3 [12:35:51] so just pitch a bit [12:38:04] might be easier this way with just one dv to burn which is Z [12:38:23] yeah [12:38:53] and the auto maneuver would give you an attitude so that you only burn in the +X direction [12:39:00] which is undesirable for CSI, for some reason [12:39:12] probably requires less maneuvering [12:39:30] i will try that [12:39:30] your attitude before, controlled by P20, will point the +Z of the LM towards the CSM [12:39:46] and the CSI burn is horizontal only [12:40:04] so the +Z axis is already close to local horizontal [12:40:19] also probably keeps the RR locked on [12:40:46] also i have a scenario right after insertion and when i re calculate the rendezvous the times are slightly different then from before liftoff will that be an issue [12:41:51] how do you recalculate the rendezvous after insertion? [12:42:04] type in the tpi time [12:42:18] on the lunar liftoff page? [12:42:21] yes [12:42:30] I'm surprised that doesn't give you a CTD [12:42:50] because that whole calculation assumes the LM is still at the landing site [12:43:20] there should be no issue with the CSI and TPI times you calculated before liftoff [12:43:43] guess i can just write them down [12:44:59] yeah, the astronauts would have it written down on the CSI Data Card [12:45:06] which they got before liftoff [12:45:11] CSI and TPI times [12:46:17] well got to get some breakfast then i will get started again [16:31:32] @indy i have one more question [16:31:37] @indy91 [16:31:52] sure [16:32:20] i asked this before but how do i get the rotation control down for the lem again? for the p52 [16:33:20] the simplest way is to make sure only 2 thrusters are firing time, not 4 [16:33:26] so the ACA/4 Jet switch on panel 3 [16:33:40] switch that off [16:34:03] okay [16:34:10] an even better way would be to use the minimum impulse mode [16:34:31] unfortunately a burst in that mode is shorter than a timestep in Orbiter at 60fps [16:34:50] so it doesn't properly work [16:34:59] the PGNS minimum impulse mode that is [16:35:15] that one is enabled with V76, and the normal attitude control mode is enabled with V77 [16:35:23] you probably already have seen those in the checklist [16:35:31] the AGS pulse mode could be usable [16:35:41] you could try that one, and just do whatever works best for you [16:36:51] AGS pulse mode is: GUID CONT to AGS, the 3 Attitude Control switches to Pulse [16:37:06] and AGS Mode Control to Off, I think [16:37:16] or at least Att Hold [16:37:18] never Auto [16:48:40] and im guessing there is no way to get out of gimbal lock once the NO ATT light comes on? [16:48:56] nope [16:49:07] only P51 and P52 [16:49:17] so you need a completely new alignment [16:49:18] morning! [16:49:35] hi ?ike [16:49:36] hey Mike, I found two new GSOP documents [16:49:55] not sure if they are really new [16:50:02] in the archived NTRS [16:50:12] both for AS-278 [16:50:54] http://wayback.archive-it.org/all/20100510101022/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19750069081_1975069081.pdf [16:50:59] http://wayback.archive-it.org/all/20100519195659/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19750069088_1975069088.pdf [16:53:16] whoa [16:53:21] so this is significant in another way [16:53:58] those have accession numbers starting with X (X68-) [16:54:29] so in 1968 when things were being processed, the ones that were declassified then were assigned N68- numbers and show up in the 1968xxxx range on NTRS [16:54:35] the X68 ones remained classified [16:54:46] right, I remember that [16:54:50] and I guess were downgraded seven years later [16:55:14] AS-278 is the dual launch mission, just with the Apollo 9 crew in the CSM [16:55:27] I think AS-258 was the exact same mission, but with the AS-205 crew, so Apollo 7 [16:55:36] so, I've found numbers X-numbers for some things like Saturn 5 EDDs [16:55:41] oooh [16:55:47] how? where? [16:55:55] gimme a sec [16:55:56] I've rarely ever seen a reference to them [16:56:34] you might have to give me until tomorrow to dredge it back up, heh [16:56:40] but yeah, very nice find [16:57:21] let's see [16:57:23] I've been searching the gaps, areas we hadn't properly searched before [16:57:37] there was an AS-204 EDD filed as X73-76995 [16:57:51] which means it may have gotten an N-number around '80? [16:58:05] I'm still hoping to find a nother large collection of MSC internal notes [16:58:15] also AS-201 EDD given X73-76996 [16:58:28] I swear I saw one for a Saturn V [17:11:27] so it doesn't look like the N-number these were assigned have anything to do with the X-number [17:11:36] other than they're both going to be in the 60000+ area [17:16:02] not that knowing the number would help us much anyway [17:16:15] but it would! [17:16:26] give me an N- accession number and I can tell you what the NTRS number is [17:16:44] hmm [17:16:51] if there was an easy way to go from X- to N- then the search would be trivial [17:17:00] that worked in one range of NTRS documents, because they were uploaded in the same order [17:17:17] it's worked for every range I've tried, across multiple years [17:17:26] I haven't found a counterexample yet [17:17:45] hmm, ok [17:18:01] MSFC No. III-4-423-12 [17:18:20] now convert that into NTRS, haha [17:18:27] that isn't an N- number [17:18:41] I need something like N73-75134 [17:19:09] and those Saturn IB EDDs are also another type of number I guess [17:19:28] the whole declassification thing [17:19:30] those are the classified X-numbers, yeah [17:19:37] X73 [17:19:43] so maybe they got N80-? [17:20:26] hmm, so would the first pages of the NARA documents help us in some way? [17:20:55] only if they're stamped/stickered with Nxx-xxxxx accession numbers, like most of the NTRS things are [17:21:03] right [17:21:09] which they probably areN't [17:21:17] probably not, but they could be [17:23:00] yeah, doesn't look like they are [17:24:21] ugh, flipping through these just makes me want to do the NARA trip [17:24:30] yes please [17:25:02] give me a few weeks head start, I'll need to condense my "need to have" list [17:25:21] you still have a few months of head start at least, sadly [17:25:26] there is a lot of large documents I don't need anymore [17:25:34] because we can get them from UHCL [17:25:38] you should keep removing the need for large documents :D [17:25:44] where even is Alex [17:25:51] slacking off [17:25:55] he requested a few new ones this weekend [17:27:34] yeah, there really aren't that many large documents I really need from NARA [17:27:40] excellent [17:27:54] Return-To-Earth processor, LOI processor [17:28:06] those are the most important ones [17:28:08] I want to spend as much time as possible exploring folders that Ron didn't index, and getting a feel for what all they have in the drawings collection [17:28:14] right [17:28:35] and a few Translunar MCC update documents, which probably aren't more than 20-50 pages [17:28:38] great [17:28:46] I wanted to refine the list anyway [17:28:54] I'll go through them again soon [17:29:14] take your time [17:29:20] it's not happening any time soon unfortunately [17:29:30] yeah [17:31:43] especially the mission techniques documents can be removed from my NARA list [17:31:47] UHCL has most of them [17:31:56] they weren't high priority anyway, but there are a lot at NARA [18:01:22] annoying PDF collection [18:01:40] I like that I can search for NTRS ID and title [18:02:02] I'd also like to be able to search for the MSC internal memo ID [18:02:17] but then the file names become really long [18:07:09] haha [18:07:34] yeah I feel like this really needs a database to properly catalog everything [18:11:09] maybe an online spreadsheet [18:11:26] where we catalogue NTRS, UHCL, NARA documents [18:13:02] although adding e.g. "69-FM-10" isn't so bad in the file name [18:13:19] what's the file name length limit? :D [18:13:57] generally, 255 characters with modern filesystems [18:15:20] good enough for NTRS ID, title, MSC ID [18:17:39] because with the number of MPAD documents I have, I really can look for the missing gaps [19:22:39] @indy91 so how far into apollo 9 are you now [19:22:51] just after SPS-1 [20:19:52] night! [11:16:01] good morning [11:16:46] just wondering for your first rendezvous from the moon how many attempts did it take you? [11:26:08] hey [11:26:10] hmm [11:26:25] well, at that point I had a lot of practice doing the Apollo 7 rendezvous [11:26:50] which is more challenging than a lunar rendezvous for a bunch of reasons [11:27:37] and I also did a bunch of rendezvous attempts from the Moon that I didn't continue, because our LM was still missing a feature [11:28:18] so, I don't think I ever had a completely failed attempt for a lunar orbit rendezvous [11:28:30] but only because I had a lot of practice before already [11:29:20] I knew all the LM systems and the rendezvous profile and calculations already when I did my first serious attempt at a "lunar liftoff to docking" atrempt [11:29:25] attempt* [11:30:00] how did your recent attempt go? Considering your question, not that great? [11:30:21] well i had the gimbal lock [11:30:36] just have to kill rotation after the p52 [11:30:56] how did you end up in gimbal lock? [11:31:03] not sure [11:31:05] and at what point? Before CDH, before TPI? [11:31:13] before csi [11:31:16] ok [11:31:19] during the P52? [11:31:22] after [11:31:26] ok [11:31:53] so, one thing to consider for gimbal lock is that the FDAI shows something different than in the CSM [11:32:12] in the CSM, the red marked area on the ball itself is the gimbal lock area [11:32:19] the LM FDAI doesn't have that [11:32:42] because, the relevant gimbal in the LM is the roll gimbal, in the CSM it's the yaw gimbal [11:33:08] https://www.hq.nasa.gov/alsj/MLSM-LM-8FDAI.jpg [11:33:17] the red areas on the left and right of the FDAI [11:33:24] those are the gimbal lock areas [11:33:54] it actually took us developers a while to understand this properly, haha [11:33:57] i also got it before pdi once too [11:34:09] it asked to maneuver to an attitude [11:34:32] the gimbal lock light or even the NO ATT light? [11:34:51] just the gimbal lock [11:35:03] yeah, that's a warning [11:35:10] that you are close to the gimbal lock area [11:35:28] once you go even further you get the NO ATT. At that point your alignment is lost [11:35:41] the gimbal lock light just means "careful what you do next" [11:36:15] gimbal lock in the LM usually occurs if the main engine (DPS or APS) is pointing directly out-of-plane [11:36:23] so if you are unsure, look outside :D [14:53:30] Hey Thymo, you there? [14:53:39] Yo [14:54:15] Hey [14:54:23] I'm thinking about asking the Orbiter Forum people if NASSP could move there. Just an initial request and proposal, nothing final yet. [14:54:32] ah, two people to talk about this, great :D [14:54:53] our forum is just annoying at this point [14:55:05] https://www.dropbox.com/s/fjpjqr8g4n8ngvh/HSI-40281.pdf?dl=0 [14:55:16] roll a dice and if you have a 6, the forum is working. Basically. [14:55:46] https://www.dropbox.com/s/8f9wxyce9ixpaf7/HSI-210078.pdf?dl=0 [14:55:56] Yeah, the downtime is really annoying. [14:56:30] oh, that last page! [14:56:37] EMP perilune latitude [14:57:29] And a full g&c dictionary for Apollo 17 w/ags section [14:57:33] https://www.dropbox.com/s/2wdbhtir3r6b83u/HSI-481245.pdf?dl=0 [14:58:37] thanks! [14:58:46] the Apollo 16 document will take a bit to go through [14:58:52] bit have some good stuff as well [14:59:00] might* [14:59:34] No prob! I gotta go later [14:59:53] haha [15:00:12] so, I guess I'll send this initial request [15:00:46] and then I'll open a new thread on our forum, for people to give input [15:01:04] and in a month or so, if it is decided, we can make that official request to move to the Orbiter Forum [15:01:06] sounds good? [15:02:38] Yep [15:03:32] I suppose we'll get permission to pin/move threads in the sub-forum? [15:04:40] yeah, there are "Forum Managers" for the SSU section [15:04:45] which are SSU developers mostly [15:06:40] submitted [15:06:45] I'm sure it would be no problem [15:06:50] for us to move there [15:10:35] We may also take a look at the wiki if we're moving the forum. Last thing I know is that new people still can't register. [15:12:06] right [15:12:19] moving away from Sourceforge in general seems like a good ideas [15:12:20] idea [15:12:36] The SSU guys seem to have a bunch of trouble with it [15:13:03] we might to manually move the wiki though, right? [15:13:09] wasn't that the main obstacle? [15:14:28] I think we don't have any backend access anymore. I did manage to make a dump through the front end and modify it so I could import it into a modern version of mediawiki. I wiped it though since it wasn't used. [15:14:46] I'll see if I can make another dump sometime soon. [15:21:25] yeah, I think an up-to-date wiki with lots of people being able to contribute would be good [15:21:37] especially because we soon move to the Beta phase of NASSP 8 [16:44:46] Hey again [16:44:48] hey [16:45:09] the Apollo 16 document is for May 1972 launches only [16:45:16] so wrong launch month [16:45:16] So the docs are not much bigger then the Apollo 15 one lol [16:45:20] Ah [16:45:24] the Apollo 13 has good numbers [16:45:31] including EMP perilune latitude [16:45:31] great [16:45:47] I checked, we were using 0.1 and -0.2 or so [16:45:53] and the document has 0 [16:46:05] for the April 11 launch anyway [16:46:14] pretty close [16:48:18] Now I have to get a new toner for that g&c doc :D [16:48:52] haha [16:49:01] nothing unexpected in that one, but a good reference [16:49:17] yeah [16:49:25] and I got a reply from the Orbiter Forum admins, we are welcome to move there and get our own subsection [16:49:41] so I guess I'll create a forum thread on our own forum about it [16:49:53] if it lets me... [16:49:57] awesome [16:51:30] TEI was good for Apollo 13 with 40/A inclination [16:51:41] great [16:51:54] oh, I found a DX9 setting to enable ambient lighting [16:52:03] Going to fly the rest of TEC/reentry tomorrow probably [16:52:11] the main reason I didn't make an Apollo 5 video yet, was because all relevant events happen in darkness [16:52:20] yeah [16:52:28] but with that setting, there is at least some light [16:52:48] Is it the one in the debug menu? [16:52:59] yeah, in-sim [16:53:06] where you would also go to the scenario edit [16:53:07] editor [16:53:12] D3D9 debug settings [16:53:13] right [16:53:15] and then ambient lighting [16:53:19] so I made this: https://www.youtube.com/watch?v=IDhsuCBViYM [16:53:39] I experimented with a new video editor and recording settings [16:53:47] the quality isn't very good, unfortunately [16:53:56] it's watchable I guess [16:55:31] Haha I love how the legs just “appear” at staging [16:55:39] But nice vid! [16:55:56] I have to fix that on LM-1 [16:56:31] ah right, that upper part of the legs [16:57:32] "504 Gateway Time-out" I think the forum doesn't want me to create a post about abandoning it, haha [17:07:39] I'm able to get on the forum now. [17:10:20] morning! [17:11:00] hey Mike. I made a new video, see above [17:11:15] oh nice! [17:14:25] Sunburst in action [17:14:37] which would be a fun alternative title for the video [17:19:54] :D [17:50:02] oh come on, I can't even post the thread about our forum being unusable... [18:01:43] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2961.0 [18:17:55] hahaha [18:18:04] it's finally happening :D [18:25:14] and now I want to read your thread, but I can't :P [18:27:46] try a few times, I think your odds are better than 1 to 10 :D [18:29:30] hehe we'll see [18:29:34] I'm up to 4 timeouts [18:30:45] 0/5 [18:32:27] got it on the sixth attempt :D [18:33:28] as I said a bit earlier, "roll a dice and if you have a 6, the forum is working. Basically." [18:33:59] hahaha, perfect [18:34:57] now, how many times will it take me to vote in the poll [18:35:07] not much more [18:35:19] usually it works quite well for a few minutes [18:36:03] I had one timeout before it worked [18:36:09] "quite well" is a bit of a stretch :P [18:37:03] yeah... [18:47:51] first try on the reply post though! [18:48:04] (after it took me four tries to get to the "post a reply" screen) [19:01:02] I've posted a reply with my opinion too. [19:01:50] 4 votes. I suppose that's already 60% of the active NASSP dev team> [19:01:52] ? [19:07:16] I'll keep it up a few weeks at least. dseagrav should have a say, and maybe even some of the long term, not so active people. [19:17:06] I'm sure he wouldn't mind not having to handle the registration pain anymore [19:20:09] Btw, getting a 504 on the wiki now too. [19:20:27] And that is not even on ibiblio. lol [19:21:01] yeah sourceforge is also a dying beast [19:21:02] works for me [19:21:08] indeed [19:21:20] it is working for me, though [19:23:50] Try going to any of the Special: pages [19:24:09] The rest of it also works fine for me [19:42:10] I remember using this: http://nassp.sourceforge.net/wiki/Special:Export [19:42:25] Not sure how I fetched all the page names though. [19:42:31] Might need some scripting. [20:18:19] night! [11:05:12] good morning [11:08:27] hey [13:00:37] hey [13:03:28] hey Alex [13:06:05] continued creating the Apollo 11 July 18 launch padload [13:06:28] I have to say, it's quite exhausting creating a new padload, especially for a fictional launch [13:07:23] we really need some better solution for it [13:14:35] hah I bet [13:14:54] and supporting such missions with the RTCC MFD as well [13:21:05] I've checked the landing site as well, to get an altitude for the RLS [13:21:15] it's even flatter than Tranquility Base! [13:27:45] lol that must be quite flat [13:28:30] So I guess we will finally have a working scenario in the fictional missions folder [13:29:38] yes [13:54:13] I'd love to try creating an scenario for the CSM/LM dual launch in Saturn IBs [13:54:32] it should be possible to do [13:58:07] hmm what mission was that planned for? [13:59:58] first AS-278, then AS-258 [14:00:42] for AS-258, AS-205 launches a Block II CSM from LC-34 [14:00:55] one day later, LM-2(?) launches with AS-208 from LC-37 [14:01:35] AS-205 into a circular 105NM orbit [14:01:46] AS-208NM into a 110NM orbit, 60NM ahead of the CSM [14:02:23] it was planned some time in Summer 67 [14:03:09] and the 105NM CSM orbit was meant to decay to 100NM at LM launch [14:03:43] https://web.archive.org/web/20100521095714/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19790072545_1979072545.pdf [14:06:27] I'd love to have a scenario with 2 LVDCs :D [14:07:34] yeah [14:08:10] so I guess the CSM then rendezvous'd with the LM [14:09:38] yes [14:09:48] CSM does an equiperiod orbit maneuver [14:09:52] then CDH and TPI [14:10:40] and it seems the LM stays in the S-IVB until CSM docking [14:12:07] so that sounds like a lot of fun [14:15:03] yeah [14:15:54] alright time to motivate myself to fly TEC/re-entry on Apollo 13 [14:16:38] haha [14:16:44] and I should continue with Apollo 9 [14:18:05] Do you remember what the trick was to get the proper input time for the PTC REFSMMAT? [14:18:18] I think it was a certain time after TEI [14:19:37] I don't remember [14:20:36] "average time of TEI for the monthly launch window and azimuth range" [14:20:37] Ill just use TEI time I guess [14:20:49] ah, right [14:21:02] so a few hours after the nominal TEI I would guess [14:21:32] I think I had used + 5 hours if I am not mistaken [14:22:45] oh and btw I still have 13.2 % fuel left after TEI [14:22:55] quite efficient that new targeting [14:23:11] but the real reason I think is I omitted that 900 fps plain change [14:23:26] plane* [14:23:27] probably [14:25:20] btw is that lunar liftoff fix almost ready? (with the position based on RLS) [14:25:42] *RLS in the RTCC MFD that is [14:27:20] ah wait [14:27:39] done [14:28:19] I modified the Landmark Excel sheet so that you can calculate a RLS padload with it [14:28:31] well it could before, but it didn't have an altitude input [14:28:35] for Orbiter 2016 [14:28:54] great [14:28:57] thanks [14:36:26] works great [14:37:25] so I used my Apollo 13 pre PDI scenario and put in the 1 REV abort TPI time and that gives a TIG very close to the T3 PAD TIG [14:42:26] also just tried the ephemeris generator, nice [14:55:31] good to hear [15:00:49] also, is there a reason why TPI times are so different when calculating a co-elliptic vs. direct ascent? There is almost 20 minutes difference... should they not both aim for TPI at orbital mid-night? [15:02:06] direct profile TPI was never at orbital midnight [15:03:53] I'll have to change the direction profile calculation a bit though [15:04:04] I think what was constant for them was the time between insertion and TPI [15:06:47] direct* [15:08:44] I see [15:28:05] back about the T3 liftoff time, I noticed that none of the PADs for it also include an insertion velocity and hdot, I guess its just the standard that is used here (+5095.0, +19.5) [15:28:19] like is used for the T2 abort [15:29:07] although RTCC MFD says it should be a +25 fps hdot, but I guess thats a small difference [15:29:53] RTCC MFD currently uses a fixed insertion true anomaly [15:30:15] so the Hdot would increase if the horizontal velocity also increases [15:30:18] that might be wrong [15:31:39] the default P12 inputs lead to an 30NM apolune [15:41:38] and normal co-elliptic P12 targets have HDOT at about 34-36 fps according to the LM datacards [15:41:55] maybe just using those targets is best [15:44:35] which targets now? the ones hardcoded in the LGC or with the 34-36 fps? [15:44:50] I could certainly add an option to use the default insertion targets [15:45:06] if those were used for T3 and any of the other early launches [15:45:13] they got a liftoff time for each revolution [15:46:10] any HDOT change for the nominal P12s are probably an adjustment to the CDH-TPI DT [15:48:38] by targets I mean say for Apollo 13 the LM ASCENT pad says V HOR: 5533.8, V VERT: 36.3 [15:49:06] which should be for the normal co-elliptic rendezvous [15:49:47] and I am assuming T3 (1REV) should be the same and not the preloaded 30 NM apolune ones (+5095.0, +19.5) [15:50:54] hmm, I'm not so sure about that [15:51:20] the one on the Ascent PAD is quite specifically for the nominal liftoff [15:54:45] at least I am sure the ascents on the following revs after T3 would be using the default P12 settings [15:55:12] unless there was time for an update [15:55:38] lunar surface checklist has the default P12 target in brackets and some space for updated values [15:55:59] ah ok [15:56:49] I just though that since the 1 REV abort would be a similar rendezvous structure then the nominal ascent, that the P12 targets would be similar too [15:56:54] for an emergency liftoff that is [15:57:57] Apollo 13 has fixed DTs for insertion/CSI and CSI/TPI [15:58:30] the rendezvous structure is always the same, I think. Different targets would adjust the phasing at insertion [15:58:44] to reach apolune earlier to get more time between CDH and TPI, I think [16:00:08] in the transcript of Apollo 11 they are loading some other target for T-2 [16:03:42] the Apollo 13 rendezvous document talks about these cases [16:03:44] 6.8 [16:03:52] "Pre-nominal correct phasing lift-offs" [16:03:59] I wonder what correct phasing means in this case [16:04:22] but it does say that a 9x45 orbit is used [16:04:31] so NOT the default P12 numbers [16:05:59] doesnt the nominal ascent aim for 9x45? [16:06:29] the nominal one, yes [16:06:40] but not the P12 default parameters [16:06:43] +5095.0, +19.5 [16:06:49] that gets you a 30NM apolune [16:06:54] right [16:09:54] so, what targets to use then for T2 and T3? [16:12:14] hmm maybe the default P12 for T2 and the nominal ascent targets for T3? [16:13:42] oh, wait [16:13:45] http://media.liveauctiongroup.net/i/27786/24378936_3.jpg?v=8D34E76CC907AA0 [16:14:56] that has nominal values for T2 and T3 [16:15:07] yep [16:15:49] so on Apollo 11 they probably would have used those [16:16:01] Apollo 12 doesn't have them [16:16:02] any any more pics from that? [16:16:10] http://www.icollector.com/Buzz-Aldrin-s-Training-Used-Apollo-11-LM-Data-Card-Book_i24378936 [16:16:23] 4 pages [16:18:48] Apollo 12 has them in the Timeline Book [16:18:55] T-2: +5513.5, +19.5 [16:19:23] fixed 19.5 I guess, horizontal different due to different landing site radius [16:19:39] but probably targets for 15NM DH [16:20:39] I guess T3 would always have an HDOT close to 32 [16:22:43] hmm [16:22:57] both horizontal and vertical are larger for T3 [16:23:10] I wonder what orbit that gets you [16:31:43] pre-flight T3 target and nominal ascent are very similar for Apollo 11 [16:34:09] still not sure what you would use in the no-comm case for T4, T5 and so on [16:34:20] you only have a liftoff time for that [16:39:38] probably all would be, just use the nominal ascent numbers for P12 in the event of no-comm I guess [16:39:55] not all but T3 and after [16:40:14] there still is a difference between any-time liftoff and the on-time liftoff on every rev [16:41:12] the ascent V HOR, V VERT on the liftoff page are definelty different then the ascent pads though [16:41:32] which liftoff page? [16:41:46] they come out between 25 and 30 fps HDOT, but all the real ones were 32-26 fps [16:41:58] oh, RTCC MFD [16:42:01] nominal ascent liftoff page in the RTCC MFD [16:42:04] yeah [16:42:15] 32-36 fps* [16:42:18] yeah, the RTCC MFD doesn't do any phasing adjustments yet [16:42:50] I think it's always the same insertion true anomaly [16:43:00] for now I am using the pre-mission numbers for that and with the launch time from the RTCC MFD, works quite well [16:43:14] yeah [16:43:14] morning! [16:43:19] hey [16:43:54] basically 5540.0 and 32 fps seem pretty universal as most mission's nominal liftoffs seem close to that [16:43:59] hey Mike [16:44:45] look at this [16:44:46] https://github.com/dseagrav/NASSP/issues/347 [16:44:57] I haven't started reading yet [16:45:05] but maybe someone figured out our issue with the spirale??? [16:46:16] oh very interesting [16:46:54] ooh [16:47:02] it looks believable [16:47:05] looks promising [16:47:31] maybe we should invite him on the chat lol [16:47:38] haha definitely [16:47:54] hired [16:54:13] hehe [16:54:19] just finished reading [16:54:49] I'd also like to know if his 1024p monitor has any issues with the LPD panel [16:55:12] haha, sounds like a good reason for him to join us here [16:55:23] 1050 pixels is the size of the AOT bitmap? [16:55:34] because it is 1080p and that would probably cause the same issue [16:55:38] yes [17:13:05] it's been too long since I've tried a P57, haha [17:13:41] haha [17:18:52] +000.06 [17:18:53] not bad [17:18:59] well actually [17:19:03] quite bad on my part [17:19:10] but I guess the new spirale code does work [17:20:12] :D [17:27:43] great [17:57:58] ok, the bitmap is 1050 pixels high [17:58:06] that's exactly my screen resolution [17:58:12] but how does it work for 1080? [17:58:32] how is the panel displayed in that case? [17:58:45] are there a bunch of blank pixels at the top and bottom? [18:02:56] well not really, it is stretched to fit a 1080p screen [18:03:25] hmm but thats the bitmap [18:03:33] maybe not the reticles itself [18:03:51] as its defined radius is 525 pixels [18:05:12] I don't think the bitmaps are stretched [18:06:13] are they? [18:06:49] how would that even work with bitmaps [18:06:52] on mine, yes [18:07:12] 1867x1050 is 16:9 [18:08:09] so I think if your res is higher but still the same aspect ratio (16:9) it will stretch the bitmap to accommodate [18:08:48] I have 1080p, but the 1050p aot bitmap fills my whole 1080p screen [18:09:28] but I dont think its doing the same for the cursor/spiral [18:11:52] so with this change, for 1920x1080, the aperture is about 29.8° [18:13:42] actually [18:13:51] I can't see the debug string, so no idea :D [18:15:10] it should be 30.7° [18:15:12] with the FOV handling he added, my AOT FOV becomes like 61.5 on my end [18:15:22] what is your resolution? [18:15:36] its 1920x1080 [18:15:42] so I probably dont need that code [18:15:43] ah right [18:15:46] 30.7° aperture [18:15:49] 61.4° FoV [18:15:54] because it should be 60 FOV [18:16:19] well, you might not need the code, but the question is, will the code be bad for you or not [18:16:34] it is bad, it make the spiral not work [18:16:36] we have to accomodate both 16:9 and 16:10 at least [18:16:45] and all resolutions if possible [18:16:46] at 60 FOV it works perfect with my 1080p [18:17:47] with the new code in DrawReticle? [18:17:52] but not in SetView() [18:17:56] yes [18:18:23] hmm, ok [18:18:24] but another reason may be that the reticle is still 1050 px large [18:19:13] does it only do the scaling of the bitmap with the identical aspect ratio? [18:19:28] yeah I think [18:19:45] if not it will cit the sides off [18:19:48] cut* [18:19:56] so to speak [18:20:01] or add borders? [18:20:08] yeah [18:20:11] hmm [18:20:13] tricky [18:20:49] what about limiting the aperture to 30° [18:21:06] ah, maybe [18:25:15] so at the smaller resolution like ggalfi uses, it cuts off part of the spirale [18:25:26] but it also uses a smaller FoV [18:25:29] so that works out then [18:26:29] yeah [18:26:39] ah, for the sextant and telescope we have 3 different bitmaps [18:26:46] 16:9, 16:10 and 4:3 [18:27:04] I guess the extremities of the AOT are not too important anyway [18:29:06] how does the large FoV mess up your spiral? [18:31:02] you mean the 61.4? [18:31:05] yeah [18:31:32] ah right, it stretches the bitmap [18:31:35] I know I thought it wouldnt either, but 1.4 degrees makes a big difference it seems [18:32:27] try to put the spiral on the star, and then change the FOV by even just one degree, the star is now completely un-aligned with the spiral [18:35:38] hmm [18:38:18] this whole screen FOV vs. reticle FOV makes my head hurt [18:38:40] haha [18:38:54] I think just limiting the FOV to 60 and less should work [18:38:55] we probably want bitmaps in each aspect ratio [18:39:12] it will work for any 16:9 screen with more than 1050p, yes [18:39:42] it probably wouldn't for any other aspect ratio beyond 1050p though [18:39:49] I have 1680:1050, 16:10 [18:39:51] so it still works [18:39:58] exact fit [18:40:07] right [18:40:23] It should not be too hard to make extra bitmaps [18:41:02] I still have to understand the stretching properly [18:41:16] I'm really surprised it does that at all [18:42:29] on my 16:9 UHD monitor (2160p) does major stretching with some of the LM panels of course [18:43:27] ok [18:43:31] the left and right LM window are pretty obvious on my screen, a bit of quality loss [18:43:49] I don't have that luxury problem :D [18:44:17] we also have bitmaps in 16:10 like the left rendezvous window [18:44:23] but they fill up the whole display even only being half the resolution, but 16:9 [18:44:26] that's an exact fit for my resolution [18:44:50] try windowed mode, 16:10, as large as you can [18:45:02] and if it still does the stretching then [18:45:16] I once did try but I could not come back haha [18:45:29] it was very weird actually [18:45:52] had to make a new Orbiter beta install [18:46:54] wait, what? [18:47:25] you chose 16:10 windowed mode in Orbiter and it broke everything? [18:48:05] the NASSP config might save the aspect ratio type in the config [18:48:14] slightly redundant that sentence [18:48:52] I think you are missing the word "config" maybe :P [18:54:52] ok I tried it and did not have the issue I spoke of [19:11:34] back in a bit [19:14:31] but did it get stretched at 16:10 or not? [20:08:20] night! [00:05:48] indy91, so I did a few tests with my UHD monitor (3840x2160). I tried various 16:10 resolutions with windowed mode, and using the latest code that ggalfi posted to limit the FOV at higher then 1050p resolutions. No problems encountered as the bitmap is always stretched vertically so the entire height of the screen is covered. FOV of course never goes above 60 [00:06:16] .tell indy91, so I did a few tests with my UHD monitor (3840x2160). I tried various 16:10 resolutions with windowed mode, and using the latest code that ggalfi posted to limit the FOV at higher then 1050p resolutions. No problems encountered as the bitmap is always stretched vertically so the entire height of the screen is covered. FOV of course never goes above 60 [10:37:16] . [10:41:53] good morning [10:42:30] now im flying three missions at once [10:46:44] haha [10:46:51] 9, 10 and 11? [10:47:12] yes [10:47:26] and i got one d3d9 ctd [10:48:25] oh noo [10:48:51] how did it happen? [10:49:12] right as the tli pad came in i was using 10x acceleration [10:49:32] but reloaded the scenario with no time acel and everything was fine [10:50:40] hmm [10:57:25] and i just loaded an 11 scenario and calculated about 10 evasive maneuver pads and switched panels and no ctd [10:57:52] maybe it wasnt the threading [11:00:05] threading wouldn't be a d3d9 ctd anyway [11:00:11] I have one theory what might have caused it [11:01:28] it was the TLI PAD on Apollo 10, right? [11:01:32] yes [11:02:13] hmm no, it's not what I was thinking [11:02:28] but it's still possible that the time acceleration could have indirectly caused it [11:05:30] first ctd i have had in a while [11:08:32] something with Apollo 5 is currently broken as well. Getting a CTD when I close the scenario. [11:17:04] just did it again and no ctd [11:17:08] very strange