[16:38:50] NASSP Logging has been started by thewonderidiot [16:54:25] Hey Mike [16:55:37] good evening [16:56:10] good morning! [17:00:02] @indy91 mission accomplished! [17:00:24] your CM is in the water? [17:00:29] yes [17:00:33] great [17:00:51] last I read (in the chat log) was that you had trouble finding the transearth MCC calculation in the RTCC MFD [17:00:56] I guess you found it then :D [17:00:58] after splashdown my crew was at critical for some reason [17:01:00] yep [17:01:25] a few minutes after splashdown? [17:01:38] yes [17:01:45] yeah, I think that is a known problem [17:01:57] it did that in the apollo 8 reentry scenario as well [17:02:13] when you open the hatch, it doesn't properly mix the "fresh sea air" with the air in the cabin [17:02:30] and the CO2 scrubber of the suit circuit, just like basically everthing else, is powered down [17:02:38] so the issue is the CO2 level in the cabin [17:03:09] we have to do some fixes on that [17:04:09] i've only been doing nassp for 5 months i never thought i would do the full 11 mission [17:04:16] now you have! [17:04:32] reentry and everything worked fine on your first attempt? [17:04:36] yes [17:05:12] i did some practice the the apollo 8 entry preparation scenario [17:06:13] had to do 2 course corrections on the way back [17:06:14] ah, good [17:06:32] how much DV were they? [17:06:55] i think they both were around 4fps [17:07:14] hmm, only the first one should be of any significance [17:07:29] in my experience [17:07:39] first one about 2-5 ft/s [17:07:52] oh, I know [17:08:14] you used the wrong calculation option for MCC-6 or MCC-7 [17:08:31] i burn 5 and 7 [17:08:35] well wrong as in "spends too much DV" [17:08:47] MCC-6 and 7 would only ever be corridor control burns [17:08:58] that should be one of the options, when you cycle through them [17:09:04] so no longitude control for MCC-6 and 7 [17:09:17] that will cut down the DV for those MCCs a lot [17:10:04] the options are Midcourse, Abort and Corridor Control [17:10:13] Midcourse is the usual one for MCC-5 [17:10:31] Abort would only really be used for the TLI+X abort burns, between TLI and LOI [17:10:51] and Corridor Control option only fixes your reentry angle [17:11:06] and that's what would be used for MCC-6 and 7 [17:11:12] Now you know for your next mission! [17:11:17] yeah [17:11:44] I guess it's similar to how slightly different options are used for MCC-1 and 2 versus 3 and 4 [17:13:36] not sure why my ptc refsmmat was putting my burn attitudes in gimbal lock [17:14:33] yeah, that's strange [17:15:08] but the direction of the necessary DV for the MCCs is also pretty random, so... [17:15:30] the entry refsmmat worked [17:16:37] ah, even MCC-5 would usually be a corridor control burn only [17:17:06] if the splashdown longitude would be way off with that, then MCC-5 would also do longitude control [17:17:34] and a corridor control burn should be always in a good attitude, even with the PTC REFSMMAT [17:17:55] the actual mission did just that [17:18:02] " minus 0004.8, plus all balls, plus 0000.1" [17:18:04] for the DV vector [17:18:29] having almost the whole DV in the DVX direction is an indication for a corridor control burn [17:29:53] Having some issues with the p23 navigation, my residuals are way too high. Just to confirm, the near Horizon option requires me to overlap the nearest point on the horizon to the star correct? [17:30:27] Also, if I do a state Vector update from the MFD does the p23 navigation really matter in the grand scheme of things [17:31:07] I'm certainly no jim Lovell lol [17:31:36] we all are no Jim Lovell [17:31:45] in addition to that, the Orbiter Earth is spherical [17:32:01] but the AGC expects an ellipsoid [17:32:26] nobody of us every managed to do a full return to Earth with just P23 navigation [17:32:32] ever* [17:32:46] but you understood the technique correctly [17:32:59] overlap star with horizon closest to the star [17:33:03] Well I feel slightly better now. So I can pretty much ignore my terrible p23 results then and just go with the MFD uploaded State Vectors? [17:33:24] you are using the MCC scenario that gets updates like Maneuver PADs, right? [17:33:31] correct [17:33:37] Then you basically never have to use an MFD [17:33:55] you will get state vector updated periodically [17:34:00] Even better then. I guess I'm still thinking of the old version 7 beta days from years ago [17:34:09] usually they come with midcourse correction updates [17:34:33] Ok cool. I guess p23 is just left in the checklist as a historical accuracy then [17:35:23] pretty much [17:35:35] P23 works pretty well when doing star/lunar horizon marks [17:36:09] also, one of the TEC days was all under the mcc6 part of the checklist [17:36:46] but Earth horizon marks, the majority of what was done on Apollo 8, are not totally to be trusted [17:37:19] the mission control feature is optional. That's why there are two launch scenarios for each mission [17:37:21] MCC and non-MCC [17:37:45] I haven't really updated the Apollo 8 MCC updates since the NASSP 7 release, but I don't think there are any big issues [17:38:25] astronauthen96__, might need some better checklist organization then [17:38:46] messierhunter, if the MCC runs into trouble, then I'm sure you will tell me :D [17:38:51] thanks for beta testing, haha [17:43:00] All the MCC has been working fantastic so far. Thanks so much for that feature it's really amazing [17:43:57] great that it's working [17:44:06] the PADs can be a bit buggy right now unfortunately [17:44:14] we are having some CTDs with it [17:44:44] only really the TLI PAD and the Block Data PAD for Earth orbit [17:45:12] I guess you made it past the TLI PAD, so, it's less likely that you will get such a CTD [17:46:26] the mission control updates is what I am working on right now [17:46:28] Apollo 9 [17:46:36] Apollo 7, 8 and 10 are basically complete [17:46:43] Yeah tli worked fine fortunately. I did miss the pad at t plus 5 hours and it won't come up when requesting the previous Pad but I think that's because I was too busy with a bunch of p23 frustration and I missed seeing it [17:48:16] the one at 5 hours is "Block Data 1" [17:48:25] that's for a direct return abort [17:48:35] so not necessary for continuing the mission [17:48:54] Ok, good to know [17:49:11] similar to the TLI+90 minutes and TLI+4 hour PADs you got in Earth orbit [17:49:20] I noticed the next item on the checklist for p21 asks for the LOI insertion time. Should I just use the historical time or was that included in one of the previous pads [17:49:21] oh and I read about that in the chat log [17:49:36] those PADs come up with a 5 minute delay between them [17:49:53] that's what I figured was a good time to write the whole PAD down by hand and check each item [17:50:09] hmm [17:50:22] I don't think it was included with a PAD [17:50:32] maybe use the flight plan time for LOI [17:50:59] Jim Lovell played around with that time to find the closest approach to the Moon [17:51:19] to also check how good the onboard navigation of the AGC is [18:07:23] I see [19:32:25] ohhh man [19:32:35] "So, I powered up my beast last night and managed to keep all the smoke inside the components,  :) [19:32:35] Powered up with only A01 and A02 and after jumpering ALGA, STRT1, STRT2, SBY, MSTP, and MSTRTP to ground I was able to check out the timing signals at several connectors.  I'm getting clean T01 - T12 and I'll be checking the R/W/C times as well as the phase timing soon." [19:32:50] this guy's AGC is coming to life :D [19:34:13] Hey @thewonderidiot [19:34:21] just finished Apollo 11 [19:34:34] nice [19:41:27] That's just awesome! [19:41:45] wow [19:45:10] gonna work on apollo 9 now [19:49:45] hopefully it continues to go that smoothly [19:50:00] I think two or three more modules and it should trace through GOJAM correctly and try to TC 4000 [19:50:32] and he has enough backplane in place to execute all of the instructions except for the I/O instructions [19:52:33] but yeah, this thing is going to be put together and running Aurora in no time :D [19:52:58] and then? [19:59:36] haha, I don't know what he's going to do with it after that [19:59:53] I guess the plan is mostly "build a function AGC" [20:00:13] yeah, it's about the journey, not the destination :D [20:40:02] night! [03:10:12] I wonder if that F-5 FBW AGC program was ever saved... [03:10:18] Was it a F-5? [03:14:15] F-8 [03:14:30] the program's name was DIGFLY, and the MIT museum has some info on it [03:14:41] I don't have any leads on an actual listing, though [03:15:19] if you happen to know anybody at the AFRL, that is our biggest potential score for AGC code [03:16:00] MIT transferred all of the change records for all of the AGC programs to Rome Laboratory, where they were all entered into a big database, stored on tape [03:16:36] if they still have that, we'd be able to reconstruct just about all of the versions of all of the programs from it [03:18:53] it made it up to at least revision 39 -- the MIT museum has "register maps" (presumably erasable memory layout) for DIGFLY 39 [03:53:01] hmm, I need to see if NARA has aperture cards for LDW 370-28001 [03:53:22] that's the level 3 PGNCS schematics for LTA-8 [11:59:25] morning [12:10:56] hey [12:11:22] working on adding proper support for the Apollo 11/12 No PDI+12 style maneuver [12:11:50] oh cool [12:12:11] I guess part of the lambert page? [12:12:14] yeah [12:12:20] there will be 3 options [12:12:30] General, NCC/NSR and TPI/TPF [12:12:40] the last two is what the real two impulse processor had [12:13:00] but it probably wouldn't be able to calculate the Apollo 7 phasing maneuvers [12:13:21] so that's what the "general" option will be fore, so that we don't loose any capabilities [12:13:34] right [12:13:47] and I guess the direct ascent tweak burn [12:14:12] that would be possible to calculate with the NCC/NSR option [12:14:15] but general as well [12:14:36] ah I see [12:14:47] the NCC/NSR option additionally calculates the NSR DV and then finds the TPI time [12:14:58] so the NCC/NSR TPI/TPF have the offsets pre-configured? [12:15:10] TPI/TPF uses no offset [12:15:30] and in the RTCC the offset inputs were always a phase angle and a DH [12:15:38] right [12:16:10] I don't think there was a option in the RTCC to automatically calculate the right T2 for the No PDI+12 [12:16:22] but there was a multiple solution display [12:16:39] where the DH and T2 would be varied and several parameters for that would be displayed [12:16:48] so easy to find the right T2 manually [12:16:58] I'm going to implement some variation of that [12:18:46] NCC/NSR is the same as CSI/CDH? [12:19:02] kind of [12:19:20] the No PDI+12 profile is the same as Apollo 7 rendezvous [12:19:42] first maneuver is NCC-1 (or the abort maneuver for the No PDI+12) [12:19:54] second maneuver is NSR or CDH [12:20:13] there can be a CSI maneuver in between, but it's nominally 0 [12:20:24] NSR (or CDH) can be ground or onboard calculated [12:23:48] so how it's probably going to be is that the TPI time will be calculated based on lighting [12:24:20] and on the Lambert page it will then display the difference between that TPI time and the one calculated by the NCC/NSR option based on elevation angle [12:24:35] and then T2 can be easily adjusted [12:24:41] or the DH as well [12:39:44] and before I tackle the Apollo 9 rendezvous, I'm going to request two relevant documents from UHCL [12:42:40] I can't find the final rendezvous techniques document, but there is a document with (maybe) the minutes of the final meeting for the rendezvous techniques [12:42:54] happened on January 20, Bill Tindall calls it a "gruelling session" [12:45:06] interesting [12:45:54] I think I know most things about the Apollo 9 rendezvous profile, just could use some additional details [12:46:04] yeah [12:46:05] good morning [12:46:14] and the other document I'll request is the rendezvous techniques document from December 1968 [12:46:15] hey [12:46:20] hey [12:47:09] oh lol [12:47:21] the document abou the meeting IS a Tindallgram [12:47:29] but the version I have isn't very readable [12:48:16] I should still request it and send it to the people running the Tindallgrams website [13:06:21] I see you fixed something in the coast integrator [13:07:46] something I broke in the previous commit [13:08:09] before both of them, some variables in dynamic memory were not deleted [13:08:27] before the fix, the variables were deleted before they were used [13:08:34] baaaaad [13:09:05] so pretty much everything using the coast integrator (half of the RTCC) would be broken or unreliable [13:09:09] should be good now [13:12:40] haha great [13:15:31] I was debugging it, saw a good state vector going into the coast integrator, returning a bad state vector [13:15:34] oh noooo [13:15:43] but luckily it was an easy fix [13:50:18] cant wait for the 9 rendevzous [14:25:27] are you kidding me Lauren [14:25:33] request sent: 15:50 [14:25:43] all three requested documents availabel: 16:11 [14:27:12] granted, only 21 pages (probably) had to be scanned [14:27:13] still [14:40:25] Niklas i got your last build but its not on the forum with buildbot [14:42:21] ah [14:42:27] it's on neither forum [14:42:44] dseagrav wanted to change it to the Orbiter Forum [14:42:54] probably doesn't work properly yet [14:49:34] but it should be a good build [14:49:37] tiny change [16:26:58] maybe Lauren is really a robot [16:34:01] one of the documents I requested is AMAZING [16:34:25] it's basically step by stpe instructions on how to calculate the Apollo 9 rendezvous sequence in the RTCC [16:34:29] with all inputs etc. [16:34:34] only problem, it's a bit dated [16:34:37] September 1968 [16:34:49] but it looks very usable [16:34:53] many good info in there [16:40:31] nice [16:57:10] morning! [17:00:14] so, buildbot did post the build this morning to the forum thread [17:00:19] and I as a moderator can see it [17:00:44] but it has been moderated by somebody else or something [17:00:49] can't yet see why it's not visible to other people [17:03:10] hey [17:03:13] ah, that makes sense [17:03:53] oh, is it just because this is its second post so it needs to be approved? [17:03:54] I don't really care much about the build bot. Just a nice check that it actually did a complete build [17:03:59] possible [17:04:06] let me try approving it [17:04:25] can moderators do that? [17:04:27] or only admins [17:04:35] I hope I'm allowed to do it, because I just did [17:04:38] can you see it now? [17:05:44] nope [17:05:50] uhh [17:05:51] yes [17:06:08] it's there [17:06:45] cool [17:10:04] AlexB_88, what offset were you using for the No PDI+12 [17:11:33] hmm I think I was using CDH -78 0 15 [17:11:45] so 78NM behind [17:11:50] any ideas what phase angle that is? [17:11:51] yeah [17:12:00] not sure [17:12:04] the input in the RTCC would be an angle [17:12:22] if it's close to a round number, then that should be the baseline input [17:12:24] I basically used the plot chart to judge those offsets [17:12:48] right [17:13:08] I'm just trying to find the input the RTCC would have used for this [17:17:59] -4.5° it seems like [17:18:08] that would be 78.266 [17:18:10] NM [17:35:21] so I'm fishing around in the NARA drawings collection again [17:35:44] I figured out that LDW 370-28001 is the LTA-8 equivalent of the level 3 PGNCS drawings [17:35:59] so hopefully they have that; I don't know if they ever made system handbooks for LTA-8 or anything [17:48:16] also blindly grasping at drawing numbers associated with the Computer Test Set and the Portafam, which they are pretty much guaranteed to not have :P [17:50:34] haha, that would be some luck if they have it [17:55:53] also over the weekend I put this together: https://docs.google.com/document/d/1muPH5ap9-qlfIZuDXAt5kTqBeansX5WasZ6TPzwDJT0/edit?usp=sharing [17:56:03] as a preliminary thing, I'm sure there will be more things I think of to add [17:59:53] looks like ALSEP deployment in the cuff checklists [18:00:07] or the cuff checklists in general :D [18:00:38] quite the test plan [18:01:26] hehehe [18:01:29] oh! [18:01:33] speaking of checklist [18:02:10] https://www.rrauction.com/bidtracker_detail.cfm?IN=177 [18:02:18] they really went overboard on the preview images for that one [18:02:41] and I have them all saved :D [18:02:45] perfect [18:02:46] lol [18:02:58] just wanted to make sure you had seen it [18:03:10] yeah, thanks [18:03:22] there's also https://www.rrauction.com/bidtracker_detail.cfm?IN=109 but there are less previews there [18:03:25] looking through the, there is the auto rate procedure again [18:03:30] it* [18:03:43] and the PTC initiation procedure with the DAP [18:04:33] we have revision A of the Apollo 15 LM Data Card Book [18:04:44] let's see if these are a later revision... [18:05:29] oh, these aren't in the data card book [18:05:48] these would be in the timeline book [18:05:52] which we don't have for 15 [18:06:17] hmm [18:06:18] no [18:06:30] apparently there was a separate "rendezvous chart book" [18:08:10] and I hadn't saved these yet. Good to have it [18:11:04] on Apollo 12 these charts were still in the Rendezvous/Abort Book [18:11:20] on Apollo 13 and later this was the separate book for charts [18:19:25] haha, look at this crazy chart [18:19:25] https://dyn1.heritagestatic.com/lf?set=path%5B9%2F6%2F3%2F3%2F9633572%5D&call=url%5Bfile%3Aproduct.chain%5D [18:19:46] must have been added after the Apollo 16 trouble with the re-rendezvous [18:19:56] hehehe [18:20:09] looks like something that you would find useful [18:20:13] and very few other people :P [18:20:38] I didn't know that 16 had trouble with the rendezvous [18:20:45] not the normal rendezvous [18:20:48] the SPS had trouble [18:20:55] so the LM temporarily returned back to the CSM [18:21:00] after undocking [18:21:12] oh, this was the backup TVC actuator failure? [18:21:17] yep [18:21:22] I didn't know they redocked after that [18:21:28] I'm not sure they did [18:21:37] oh, just rendezvoused to stay close [18:21:38] got it [18:21:39] LM just returned back to the CSM until they could figure it out [18:22:02] yeah, if the LM had followed the normal trajectory it might have been "phasing away" [18:22:10] right [18:22:16] not sure how late their landing was then [18:22:17] which isn't ideal if the resolution is a return-to-earth abort [18:22:31] yeah, all of the DPS propellant would have been needed for TEI [18:23:10] they couldn't waited all that many revs with continuing on [18:23:15] right [18:23:17] eventually the landing site is rotating away [18:23:47] PDI at about 104:17 [18:24:17] does the 16 transcript have a lot of nice padloads for the late landing or did they just silently uplink the changes? [18:24:18] normally 98:35 [18:24:36] probably just uplink [18:24:40] damn you uplink [18:25:00] so 3 revolutions late [18:25:16] they stayed in the low orbit for that time, so one rev is less than the usual 2 hours [18:25:32] CSM circularization burn was at the normal time relative to PDI [18:26:08] "plus 0003.6" [18:26:14] that's the crossrange from the PDI PAD [18:26:20] up to 8.0NM is ok [18:26:26] normal is 0 [18:26:47] I'm not sure if the 8NM also applies to the terrain model [18:27:53] yeah, only manual padload related change during that time is a PIPA bias update [18:32:51] boo [18:38:05] a second PDI was planned anyway [18:38:18] so normal PDI and one revolution later [18:38:27] 3 revolutions later isn't super different [18:39:09] name of the procedure to stop the PDI preparations and transition to the second opportunity? "Go-Around" [18:39:11] because pilots [18:40:20] hahaha, that's awesome [18:40:45] although to be fair, that is probably technically even more accurate than the original use of the phrase [18:40:53] since they are quite literally flying all the way around it [18:41:14] haha, yes [18:41:21] well [18:41:32] traffic pattern [18:41:57] going once around the airfield [18:42:04] that's probably where it's coming from [18:42:18] so kind of similar [18:42:28] PDI go around is even more circular though :D [18:43:34] AlexB_88, I am out of buttons on the Lambert page [18:43:35] what do [18:43:52] I'd like an elevation input there [18:44:07] but I might have to settle for having it somewhere else [18:44:21] same as you can't input the landing site coordinates on each page they are used [18:51:02] eventually I'd like a setup like LTMFD [18:51:10] where you have just generic buttons [19:01:24] ooooh, they did have LDW 370-28001 for LTA-8 [19:01:32] looks like I need to do some aperture card stitching tonight :D [19:02:15] this was made when the computer was still 2003100-021 [19:02:46] was that one of the in between states? [19:02:49] I forgot [19:03:07] it's kind of difficult to remember these number, unless you are you :D [19:03:11] numbers* [19:03:53] I don't remember exactly what the difference between -021 and -071 was [19:03:57] pulling up the compatibility charts now... [19:04:18] oh damn [19:04:59] 2003100-021 was before ECP 301, unfortunately [19:05:05] which is what introduced the thermal instrumentation [19:05:14] I was hoping to see some of that instrumentation in here [19:05:21] ah, sad [19:05:51] no bother, just more things to beep out [19:06:08] I'm still going to run through all of the pin numbers in here to see if there are differences between it and LM-4 [19:07:06] actually [19:07:11] some of it might be shown in the mechanical drawings [19:07:58] so you got a quick response from NARA about what they have? [19:08:30] I think you mentioned that they are quite quick about ti [19:08:53] but then they want moneys to actually do something :D [19:26:21] they want moneys to do some things [19:26:31] yeah they didn't have the other two, unsurprisingly, lol [19:26:36] but this PDF I just got sent for free [19:27:11] it is hard to predict -- for aperture card scans it seems like I get one for free, assuming I wait long enough between requests [19:27:22] I think every time I've asked about a document they have wanted money though [19:27:32] like, a physical document vs. an aperture card one [19:30:49] right [19:31:31] the LOI and Return-to-Earth targeting documents are constantly fighting for the number 1 spot on my NARA wish list, haha [19:31:57] after I've had some progress with the TEI targeting, LOI is currently in the no. 1 spot [19:32:03] recently* [19:32:11] yeah the first time I asked for a document from them, they responded and said it would be $24 to scan [19:32:26] after I gave them my payment info, it took them just under 24 hours to turn around the PDFs [19:32:30] at least I would know how many pages it is [19:32:42] and they didn't charge me because there was "a delay" from scanner issues [19:32:43] lol [19:32:52] haha [19:33:08] sabotage + well timed request = profit! [19:33:16] a flawless plan [19:33:44] will just work for the top spot of the list though [19:33:50] not the 1000 documents below that [19:33:52] yeah, it's worth a shot [19:34:11] I think you should email them about one single document and see what they say [19:34:17] do they even work for non-US citizens? [19:34:28] no idea! [19:34:34] I guess foreign money doesn't stink [19:35:00] they have no way of knowing until they ask you for payment info anyways [19:35:07] haha, right [19:35:13] Lauren never asked [19:35:17] just don't use an @*.de email address or have german in your email signature or anything :P [19:35:18] but it's different [19:35:35] NARA is a government entity of sorts [19:35:42] yeah [19:35:58] what's the worst that can happen? [19:36:18] RTE targeting suddenly getting the top spot again! [19:36:21] lol [19:36:36] you could use Alex or Ryan for that one [19:36:37] yeah, I think I'll ask for the Apollo 14 LOI targeting document [19:36:51] yeah, Alex has shown some interest in it [19:37:30] not sure how much of that is left after he can now enter a return inclination and get good results for most missions :D [19:37:40] hehehe [19:38:21] the main thing that is still problematic is the targeting that achieves a trajectory so that the DOI and LOI-2 burns can be combined into one [19:38:39] not sure if the LOI targeting is even the right document to request for that [19:39:08] did you read in the chatlog about my UHCL requests from today? [19:39:58] hmm, I think I skimmed over it [19:40:00] anything good? [19:40:36] oh yeah [19:40:48] one is the Apollo 11 Rendezvous Mission Techniques [19:41:06] quite nice, although the similar "Abort and Rescue Book" has usually more useful data for me [19:41:28] then a Tindallgram that wasn't readable in any of the Tindallgram sources [19:41:39] about Apollo 9 Rendezvous [19:43:03] I sent it to the guy running the Tindallgram website [19:43:03] and showed him the ways of the JSC History Collection [19:43:04] he was quite happy about it [19:43:04] last one was a real first [19:43:05] step by step instructions on how the Apollo 9 rendezvous is calculated in the RTCC! [19:43:05] really awesome, just a bit dated. September 1968. [19:43:06] but it already has the right profile [19:43:16] the SCOT from August 1968 still has a very different rendezvous profile [19:43:37] that's the first time I've seen a document with actual, direct RTCC calculation inputs [19:44:47] in parts, it reads similar to the step by step instructions I compiled for Apollo 7 and 8 for the NASSP 7 release, haha [19:47:22] oh, and from request to reply with the scans it was only 21 minutes [19:47:35] 26 pages still had to be scanned in that time [19:50:12] nice! [19:50:22] that is really awesome [19:50:31] and goddman, 21 minutes? [19:50:36] that is nuts [19:51:04] beat that, NARA [19:51:42] looks like this morning it was about 3 hours from request to a reply with 38 aperture card scans [19:52:09] that turnaround time will go down if you keep showing people how to use the JSC History Collection :P [19:52:15] Evening! [19:52:19] weren't you going to request something from the Archive Search too? [19:52:22] heya Thymo [19:52:33] 'Sup [19:53:02] talking about new things we got scanned today :D [19:53:14] Niklas hit a real winner [19:53:33] Nice! [19:53:38] hey Thymo [19:54:19] yeah, I think I have everything for the rendezvous for the Apollo 9 MCC now [19:55:52] thewonderidiot, this Apollo 9 stuff was more urgent, but I have a bunch of things I eventually want from the Archive Search [19:56:05] like 20 Skylab and ASTP checklists [19:56:10] hahaha [19:56:21] including the one for the HP-65 calculator [19:56:30] O_o [19:56:32] that was used instead of backup charts [19:56:36] checklist for the calculator? [19:56:47] yep [19:57:21] https://hpinspace.wordpress.com/2009/09/06/hp-65-apollo-soyuz-test-project-checklist-binder/ [19:57:43] ASTP flew a HP-65, and SL-4 a HP-35 [19:57:45] or something like that [20:03:25] probably just a user manual on how to get rendezvous solutions from it [20:10:13] hah, nice [20:14:36] night! [20:21:00] how's that app coming along Thymo? I still owe you the logs [20:30:31] I haven't looked at it since I got the AGC to step. I really should work on it again. [20:30:42] I need to write all the channel stuff [20:30:51] Then that needs to be interfaced to my DSKY. [20:32:10] I might put it onto the play store. That should give me the ability to get logs remotely. [20:32:15] ah nice [20:32:29] It's $25 bucks though to register as a developer. [20:32:55] that's lame [20:32:57] And you need a credit card to sign up. Which I don't have. [20:33:07] Most people in Europe don't. [20:33:19] I guess it serves to stop people from spamming apps to the store -- just a barrier to entry [20:33:24] oh really? I didn't know that [20:33:57] https://play.google.com/apps/publish/signup/ [20:34:36] can you buy a visa giftcard or something and then use that instead? [20:34:50] or is that forbidden [20:36:30] I can probably borrow my dad's and just pass him the 25 bucks cash. [20:36:40] that works too [20:42:53] Have you ever coded in Java Mike? Or have you just kept things to C? [20:44:20] I did in high school, for AP computer science [20:44:42] it is quite possibly my least favorite thing, though, and I am pretty sure I would rather quit programming entirely and do something else than have to write code in it :P [20:47:25] Haha [20:47:47] I'm just glad the syntax is sort of similar to C. [20:49:03] I don't like that it's not running baremetal, there's so many libraries by default and that you can not do things like: if (!integer). [20:49:15] You've got to do: if (integer == null); [20:49:20] Which pisses me off. [20:49:50] I must say that I'm more fluent in Java than in C at this point. Just because I code in Java every day. [20:56:31] yeah, that happens [01:01:32] oh crap [01:01:51] ggalfi may have solved the cross-range landing error [01:04:09] holy shit [01:04:15] that guy is freakin awesome [05:24:41] guss I'll do a LR test run at 7am... [05:24:43] guess* [05:30:26] Hey Nikas [05:33:43] hey [05:33:57] someone on Github figured out a problem with our landing radar [05:34:06] just checking if his fixes are correct [05:34:54] that would be for all missions right? [05:36:27] yep [05:41:05] no latitude error [05:41:11] but a bigger longitude error than before [05:41:15] which is good though [05:42:00] so something is working better with this fix for sure [05:42:03] cya later! [06:12:14] hmm [06:12:17] what the heck is the LOTS [10:13:55] Hey [10:15:07] hey Thymo [10:16:38] I got an email this morning with a linux kernel documentation patch, even though I'm no longer subscribed to that list. Maybe people think I'm important enough to directly CC me? [10:17:04] well, you worked on that, so, maybe :D [10:17:53] Yeah, he probably looked in git and noticed I last worked on some lines he was modifying probably. [10:18:10] yeah, could be [10:21:00] Just read over this radar issue on Github. I don't even understand half of what this guy is saying other than "I fixed it because math". [10:23:59] yeah, it's the complicated transformation from range and velocity readings you can get from the Orbiter API to what the LR would actually be measuring [10:24:04] and which is the input to the LGC [10:24:17] I just did the transformations a bit wrong [10:24:48] LR range is simply calculated as the current altitude [10:25:02] and then a bit of math to calculate it as the range along the LR range beam [10:25:09] which is pointing in a specific direction [10:25:33] the GSOP has most of these transformations actually, because the LGC needs to do them the other way internally [10:25:59] back to a global coordinate system in which the state vector is stored [10:26:06] I just did it wrong [10:26:13] now it works great [10:29:37] I'm not bad with geometry, but different coordinate systems are my Kryptonite :D [10:30:45] I could calculate an angle and distance between two positions. How about that. :p [10:31:27] good enough for some applications, haha [10:31:48] one possible enhancement is still possible for the LR range [10:31:51] because of terrain [10:32:04] right now it' using the elevation directly below the LM [10:32:14] and not where the LR is actually pointing at [10:32:26] but that requires some iterations etc. [10:32:32] might not be worth the effort [10:32:38] it's a bit noticable on Apollo 15 [10:32:43] because the terrain is so extreme [10:33:11] I'll have to study how Luminary 1E is doing these calculations... [11:07:46] Thymo, I think it would be good to have some more info on the current state of NASSP on the Orbiter Forum [11:07:59] a stickied thread with links [11:09:26] and I can also make one with the things that are currently being worked on [11:09:33] I was thinking about that yeah. Something also needs to be written up on how to contribute. [11:09:37] right [11:09:50] I think a summary of things being worked on would be nice. [11:10:14] Maybe a list of easy things to do to get people started with contributing? [11:10:24] sure [11:10:34] I think we have some panel improvements to do [11:10:47] http://nassp.sourceforge.net/wiki/Development_Roadmap [11:11:09] probably should make an issue for some of them [11:11:18] I would love an update for the CSM panel at some point. It's really hard to read some of the indicators. [11:11:20] like, the LM panel needs some small corrections to switch positions [11:11:45] separate CSM optics switch (CMC vs. Zero) [11:11:53] that kind of thing [11:12:06] I can update the development roadmap [11:12:47] Orbiter 2015 support surely is one thing to be relabeled as Orbiter 2016 and moved to NASSP 8; [11:13:48] yeah [11:13:51] editing it right noe [11:13:53] now [11:16:36] I'm also reinstalling the wiki to my box. I just need to get a db dump so I can import it. Then we shouldn't have any more issues with people registering. [11:23:39] that would be great [12:18:43] hey [12:19:57] hey Alex [12:20:10] Glad that LR thing is finally fixed [12:21:31] yeah, it seems to be working fine now [12:21:47] what was your longitude error during the Apollo 12 landing you did? [12:21:55] 0 [12:22:32] I've had 0.04° in the Apollo 11 PDI demo scenario and 0.01° in my Apollo 15 scenario [12:22:42] 0 without N69? [12:23:26] no N69 [12:23:41] great [12:25:45] I've commited the LR change and the first part of the Lambert targeting update [12:26:48] still need a better way of inputting elevation, comparing calculated and desired TPI times etc. [12:29:45] cool checking that right now [12:31:06] I am confused about something, it says elevation angle on the bottom right, but the button calls it "phase angle" [12:31:32] two different things [12:31:36] elevation angle at TPI [12:31:39] e.g. the 26.6° [12:31:52] phase angle is how much the chaser is trailing the target [12:32:01] e.g. -1.32° for the Apollo 7 rendezvous [12:32:23] or in NM, 78NM for a normal lunar orbit rendezvous [12:32:32] or whatever that number was [12:32:39] the elevation angle is just as a reminder there [12:32:50] and the time below it, TPI time, gets calculated for that elevation angle [12:33:14] all this still needs some work [12:34:01] ok I see [12:38:45] is there a way to find the T2 time? [12:41:52] that's the next step [12:42:06] first you would have to calculate your desired TPI time [12:42:17] from lighting conditions, fixed input or at a longitude [12:42:28] that's the options in the real RTCC [12:42:54] and then you would have the desired TPI and the one calculated on the Lambert page with the NCC/NSR option [12:43:18] I'll probably implement a code to add the DT between the two TPI times as the new T2 [12:44:00] so you would calculate the Lambert targeting solution once and then there should be an easy way to adjust the T2 time as desired [12:45:49] that's still easier than it probably would be in the real RTCC [12:46:18] a bunch of manual inputs, transfering the post burn state vector etc. would have to be done for this [12:46:55] in the Apollo 9 document I found they talk a lot about "refining the maneuver plan" [12:47:08] that's basically that had to be done, in a bunch of manual steps [12:47:14] so right now when I want to calculate the initial TPI time, I have to go to the DKI I guess? [12:47:28] yeah [12:47:38] there are too many TPI times in the MFD [12:47:42] I need to unify that a bit [12:48:46] DKI has TPI calculation, the Skylab rendezvous page has another etc. [12:50:22] so I calculated a TPI of 113:00:09 on the DKI, now where do I transfer that? [12:51:49] oh I just iterate on T2 until the time under elevation angle matches my DKI TPI time? [12:52:12] yes [12:52:21] and that step is what I want to simplify [12:52:44] display both TPI times on the Lambert page, easy way to adjust T2 to achieve the right timing [12:53:27] in the case of Apollo 7, they actually would keep T2 constant [12:53:30] and vary the DH a bit [12:59:44] I probably have enough information to implement this all this much more similar to the real RTCC [12:59:53] but I don't think that is what we want [13:00:11] that would be about as complicated as using the CSM or LM, from everything I know :D [13:02:25] yeah I think a bit of user-friendliness is also important [13:44:28] did a bit of cleanup and a more general TPI time parameter is used [13:44:47] then, I calculated a TPI time at orbital midnight on the Skylab rendezvous page [13:44:59] I'll probably give that calculation an extra page or so [13:45:10] and let it display that on the Lambert page [13:45:29] TPI time was only 12 seconds off [13:45:43] then I adjusted the DH from nominal 8NM to 8.012NM [13:45:56] and that made TPI on time [13:46:19] same process would be used to get a modified T2 time [13:47:31] let's try this workflow with your PDI minus 5 minute scenario... [13:48:05] calculate PDI PAD [13:48:24] set T1 on Lambert page to PDI+12 [13:48:47] T2 with "T1+80min" to an initial value [13:50:33] all the other inputs [13:50:37] then manual adjusting T2 [13:50:39] isn't so bad [13:51:01] got a good maneuver plan that way [13:51:11] process just needs to be refined [14:20:25] nice [14:20:28] sounds better indeed [14:23:08] just don't know what to do right now in nassp [14:25:16] @indy91 would it be possible to skip the MTVC part of sps 3 i have a feeling it is going to take a while [14:30:18] not sure what you mean with "going to take a while" in this context, but sure, you can just let the CMC finish the burn on its own [14:40:47] DCS: F/A-18C just got released. I'll be gone for a while! :D [14:42:02] those DCS modules always seem so expensive [14:43:55] but I want to try the F-86 and the MiG-21bis some day [14:44:23] They are. But a lot of research goes into it. They probably also have some contracts to give X% revenue to the manufacturer and lots of NDAs. [14:44:45] ah, right [14:45:01] I would work under NDA if we could get LVDC software for that :D [14:45:14] just need to have it as a closed source part [15:30:46] just testing one last PDI and landing and I will close the LR issue on git [15:32:56] what i meant was it might take me a while to get the manual attitude control right [15:54:07] I see [15:57:38] annnd another super accurate landing [15:57:58] on Apollo 13 [15:59:14] NASSP lunar landings are now precise enough for the precision landing requirements on Apollo 12+. Now I have no excuse to get Surveyor 3 included in NASSP [15:59:37] haha [15:59:52] I have a theory on the small longitude errors we are getting [16:00:12] when LR measurements are incorporated, but the RLS is wrong in radius [16:00:19] and the LR beam is not pointing directly downwards [16:00:38] then the position update is basically done along the LR beam [16:01:03] and that can probably cause an error downrange, while the DH is not 0 yet [16:01:46] I had 4000 feet DH in the Apollo 11 PDI demo scenario [16:01:57] I guess thats a quirk of the real thing too maybe? [16:02:02] yeah [16:02:15] that scenario might still use the mean radius for the RLS [16:02:16] because we know they did lots of N69s [16:02:36] nah, the N69s are due to mascons mostly [16:02:46] one thing I know is that in my tests I have been updating the RLS before PDI, with the actual Orbiter 2016 RLS height [16:02:48] but Apollo 15 for example [16:02:50] right [16:02:56] they actually had a RLS loaded that was quite wrong [16:03:01] because they didn't know any better [16:03:13] the sextant tracking of the CSM helped with that [16:03:27] yeah [16:03:33] I have an Apollo 15 post-flight document that might have something on this [16:08:29] didn't find anything [16:08:55] but that might be the cause still [16:09:16] previous that error might have not only been down-range, but partially cross-range as well [16:09:41] now any remaining error like that would only be in the downrange direction [16:11:59] what is weird is that RLS height in Orbiter 2016 does not seem to be the same as post-flight values [16:12:12] like Fra Mauro in Orbiter is -0.57 NM [16:12:34] if you measure with the LM at the landing site [16:13:02] but I think it should be -0.77 NM or something, Id have to check the docs [16:14:44] hmm [16:14:51] usually it's fairly close [16:15:10] could also be that the terrain elevation data is not super accurate everywhere [16:17:33] hmm for me its never really close though, like for example Apollo 17 pre mission RLS height: -1.95 NM [16:17:51] After landing in Orbiter 2016: -1.41 NM [16:18:04] Orbiter vs. actual Moon is usually quite close, is what I meant [16:18:13] ah right [16:18:14] the pre-mission RLS can be bad like that [16:18:21] for Apollo 15 it was also off by 0.5NM [16:18:43] but I think I noted somewhere the post-mission Apollo 17 RLS height and it was still way lower then 1.41 [16:18:47] Ill have to find it [16:19:00] -1.41* [16:20:35] could be caused by the latitude being off [16:21:08] latitude? [16:22:05] oh you mean the latitude error before? That only had me 1-2 km to the left of the real landing site, probably only a few m difference in elevation at most [16:22:31] for Apollo 17 at least which actually seems quite flat [16:23:06] but I think I found a site that agrees with the Orbiter 2016 elevations: http://www.lroc.asu.edu/featured_sites/ [16:23:36] I don't remember that Apollo 17 being very flat, haha [16:23:40] valley* [16:23:48] It says Apollo 17 is -2631 meters which is 1.42 NM [16:24:38] yeah but in the valley I find it is relatively flat compared with say Fra Mauro or Descartes. [16:24:58] right [16:25:30] trying the landing near Tycho crater with Zerlina right now [16:25:59] probably will still be off in longitude, because I forgot a clock update before P63 [16:26:11] but at least it's now precisely on track to the target site [16:34:32] yep, it got me to the nice flat spot [16:37:02] nice [16:37:35] so I guess it will be important for users to make sextant marks on the landing site to update the RLS before the landing [16:37:44] at least the RLS height anyway [16:38:46] But it will ne super important on Apollo 12 because the pre mission RLS was a few km to the right of surveyor 3 and we obviously are using the pre-mission RLS in the RTCC MFD [16:38:49] that would still need the MCC doing some calculations and uplinking the modified RLS to the LGC at some point [16:39:00] right [16:40:16] like maybe during the P22s in lunar orbit, MCC could downlink the CMC data at the correct time, or have the user hit a key when the DSKY is the correct part of P22 during the landmark tracking [16:40:53] doing a whole telemetry processing thing in the MCC seems like a lot of work [16:41:07] yeah I bet lol [16:41:14] but something you are suggesting might work [16:41:19] something like* [16:42:44] What I did when adding the surface bases was put there actual locations (not the pre-mission location) so that when we do the sextant marks, the surface base marker will show up at the correct spot [16:43:22] which is what we want I think (not have them at the pre-mission location like the RLSs in RTCC MFD constants) [16:50:04] morning! [16:53:05] hey Mike [16:53:11] what's up? [16:53:51] working on rendezvous stuff and testing the new LR code [16:54:25] ggalfi is a wizard [16:54:28] hey Mike [16:54:50] first AOT and now this [16:54:58] I'm glad someone is checking some of my code :D [16:55:08] hehehe [16:56:52] I stitched together LDW 370-28001 last night: https://drive.google.com/open?id=1wM17RZgUXx1WxTtbGEZXbh08Hy0PLUYo [16:57:30] it is quite old -- the CDU schematic page has inputs coming "FROM LOTS LDW 370-21004 OR R/R LDW 370-21000" [16:57:51] so, before they had settled between the rendezvous radar or an optical rendezvous system :D [16:59:08] haha [17:15:55] @indy91 which mission are you using to land at Tycho [17:18:00] I was using Apollo 14 [17:18:53] but the way I flew it, the astronauts can't come back [18:01:05] hmmmmm [18:01:07] I just had a thought [18:01:16] I might try to make a big list of every document at UHCL [18:02:00] and sort it by record number -- make an easily-searchable text file and see if there is any useful information to be gained by looking at nearby record numbers [18:16:23] sounds potentially useful [18:17:35] already have all the data down, just need to write a script to process it into a useful and sorted file :P [18:52:07] okay I have requested information about the SIMFAM, as well as the rope module processing procedures [14:44:18] hey [14:47:30] hey Alex [14:48:27] can you send some cold air from Canada please? [14:49:30] haha I would but im afraid its not very cold air where I am either lol [14:50:54] damn [14:54:32] pushed the last Lambert targeting update for now [14:54:51] the NCC/NSR option now uses only phase angle and DH as inputs [14:54:54] just like the real deal [14:56:11] and the reference TPI time can be calculated on the DKI page or Skylab rendezvous page [14:56:18] Skylab rendezvous page is probably the easiest [14:57:10] but that only has the orbital midnight for lighting conditions [14:59:39] started with the Apollo 9 rendezvous planning, the step by step instructions from the computations technique document I request from UHCL work pretty good [15:00:21] written by Dave Reed actually, FDO during the Apollo 11 lunar ascent and rendezvous [15:00:46] great ill test the updated lambert page [15:01:25] should be pretty easy to generate a good solution for e.g. Apollo 7 rendezvour Apollo 11/12 No PDI+12 [15:01:41] just requires a bit of manual iterating on T2 [15:01:47] right [15:01:53] brb [15:19:21] someone was a volunteer at the Smithsonian wrote on their linkedin: [15:19:23] "Digitized Astronaut Michael Collins' CMP SOLO book for the Apollo 11 mission and Astronaut William Anders' checklist for the Apollo 8 mission using a Epson 10000XL Photographic professional flatbed scanner" [15:19:35] where is this available???? [15:19:46] damn you Smithsonian, always teasing us... [15:20:50] back [15:21:06] nice [15:21:27] I guess Anders' checklist should be similar to the ones we have for 8 [15:21:33] yeah [15:21:38] just that this doesn't help us at all [15:21:45] if they didn't make it available [15:21:58] and they might as well scan those other documents Ryan requested [15:22:13] probably all gets released in July next year, haha [15:25:13] we could use some better versions of the CMP checklists for rescue scenarios [15:25:29] the Apollo 12 CSM Rescue Book isn't very readable [15:26:39] I'm not finding such a rescue book in the Apollo 11 stowage list [15:26:46] I wonder where these procedures were stored [15:42:56] seems to be the storyline of the search for Apollo 11 procedures [15:43:09] which checklist has which procedures? :D [15:54:40] yeah [15:54:55] Do you have a pre-PDI scenario for Apollo 14 by any chance? [15:58:07] the one you gave me about 1 year ago [15:58:12] want it back? :D [15:58:38] or wait, is this pre LOI.. [15:58:48] it's post landing [15:59:00] and I have no other one [15:59:06] so unfortunately I don't have one [16:10:02] I thats an excuse for me to fly the whole mission then :D [16:14:30] Thymo, hows the Hornet? [16:18:15] AlexB_88, am I missing anything important? https://www.orbiter-forum.com/showthread.php?p=577157&postcount=2 [16:20:25] Looks good [16:20:55] Maybe in systems implementation part you could add some green items for the things that are complete? [16:22:11] like vAGC/vAGS implementation and all the various subsystems that are essentially ready for release (minus o course the LM ECS which needs tweaking) [16:23:04] right [16:23:16] although a loooot of the LM would go there, as compared to NASSP 7 [16:24:00] right [16:26:10] but that overview looks good [16:26:40] mostly wanted to show what is currently being worked on [16:28:42] good morning [16:28:56] hey [16:29:00] hey [16:29:06] flying two missions now [16:29:07] ah, I never shared the documents I requested from UHCL [16:29:15] .stoplogging [16:29:21] uhh [16:29:35] Log ended by indy91, total logging length 258644 seconds [16:29:36] .endlogging