[15:31:26] NASSP Logging has been started by n7275 [15:31:27] good morning [15:34:54] hey Matt [16:09:33] good afternoon [16:13:11] hey [16:14:35] found the reason for the missing venting effects after CSM sep [16:14:48] ClearThrusterDefinitions clears even particle effects that aren't tied to a thruster [16:14:59] I just need to do something in a different order [16:15:13] and it was only the effects that were the problem [16:15:20] ah [16:15:25] S-IVB is still accelerating towards you :D [16:17:23] yeah I noticed it was still accelerating [16:17:30] btw I managed to get a launch and TLI on the MPT using the Tycho mission numbers I generated [16:18:16] first try and calculating an MCC-2 went very well, calculated plan looked ok and the DV for MCC-2 was about 10 ft/s [16:18:24] non-free option 5 [16:18:30] right [16:18:34] good that it is still working [16:18:49] I had even lower DV actually [16:18:54] however when I put in a launch delay then the DV MCC went up [16:19:10] there might be an inconsistency still, even if 10 ft/s doesn't sound bad [16:19:15] like a 2 hour delay, the DV MCC was about 70 ft/s or so [16:19:22] yeah I figured that [16:19:38] I have not implemented a proper "launch azimuth as a function of launch time" calculation [16:19:44] it's just a linear function [16:20:02] ah ok [16:20:04] they had some sort of analytical method to generate the data, but the QRTP Volume I doesn't give the calculations [16:20:16] so, they didn't run many, many launch sims to get this [16:20:29] it's a function of lunar declination at pericynthion arrival [16:20:36] and of course based on the 72° and e.g. 90° launch times [16:21:13] I had MCC-1 of 0.5 ft/s I believe [16:21:37] oh wow [16:22:16] just in the RTCC [16:22:31] as the trajectory calculations are basically the same in my new tool compared to the RTCC [16:22:48] actual TLMCC option 5 after I burned TLI was 2.5 ft/s for MCC-1 [16:22:51] still very good [16:23:11] did you simulate the launch at the suggested launch time? [16:23:24] which is 72°, rounded up to the next minute? [16:24:03] yeah the time it suggested in the tool on the last tab [16:24:27] and then ran P10 with it [16:25:11] oh and I used 5 sets per opportunity [16:25:27] and I tried to simulate a constant time of arrival at the moon [16:25:58] so for each set I would slightly lower the DT TLI to PC value [16:26:04] is that the correct way to do it? [16:30:27] right probably yes [16:30:32] right now* [16:30:44] still a very manual process [16:31:34] and 72° first TLI opportunity would probably have the PC+2 DV constraint for that [16:31:45] I think what would help is if it could also output a "PC GMT" on the output on the left side of the Mission Planning tab [16:31:51] because the gain in doing non-free return is by going slower to the moon [16:32:05] and later launches (or 2nd TLI) will need to go faster, to catch up [16:32:25] right side* [16:32:27] so the nominal trajectory (72°, 1st TLI) are probably the most non-free return [16:33:43] ah so PC GMT in addition to PC GET [16:33:48] that can be easily done [16:33:58] yeah it would greatly help I think [16:34:07] you would probably adjust the translunar flight time so that you get 2000 ft/s PC+2 [16:34:13] for 72° 1st TLI [16:34:19] and that becomes your fixed PC GMT [16:34:37] ah yes [16:34:59] and then you can just keep reducing it visually for each further set [16:35:32] I can even add an additional option to keep the PC GMT fixed instead of TLI to PC travel time [16:35:43] oh [16:35:47] even better :D [16:37:07] morning! [16:37:13] hey Mike [16:37:26] hey [16:38:51] what's up? [16:40:24] learning the ropes of creating a custom NASSP lunar mission :D [16:41:54] nice! [16:42:26] same [16:42:46] which is why I have already changed my mind a bunch of times when developing this new tool... [16:43:07] hahaha [16:43:09] I still don't really know the process they had at MSC for this [16:43:12] not even close [16:43:15] I know the names of a few tools [16:43:54] the name giving program for my tool was something by TRW. Likely it's only the initial step, I think it's patched conics [16:44:09] I might add it to the NARA wish list :D [16:46:05] potentially they ran the real TRW Apollo Trajectory Design Program to get some initial guesses [16:46:25] and then put it in the Apollo Reference Mission Program, which is a much more powerful tool. Basically like GMAT and such. [16:52:50] particle effects fixed [16:53:33] oh interesting [16:53:37] what is it that NARA has? [16:54:47] oh, I thought it was in the scanned front pages [16:54:51] but it's not [16:55:07] just mentioned here [16:55:08] https://www.ibiblio.org/apollo/NARASWoverflow/SystemsIndexSupplement.pdf [16:55:31] Apollo Trajectory Design Program - Program Manual [16:55:37] so it's not clear if they have it [16:55:57] ahh [16:56:03] I hate that document :D [16:56:17] so many good things listed, no idea where they are [16:56:18] even a worse tease [16:56:25] than already knowing NARA has it [16:56:35] there are a lot of TRW memos they definitely have [16:56:43] E209H [17:03:54] why do I have a picture of the front page of the real ATDP burned into my brain though [17:03:59] maybe I did see it somehwere [17:05:30] I will add other stuff to the wishlist though [17:05:34] oh man that is the worst [17:05:46] one document where I know it has 45 pages (plus potential change documents) [17:05:52] because it was up to auction at some point [17:06:23] "Apollo Mission Trajectory Control Program" what is that now :D [17:09:07] there is a 1974 JSC document that has been quoted in many other documents and was the base for some Shuttle calculations, too. An improvement from Apollo. That is the other document that has been consistently high on my wishlist. [17:10:29] but mainly I need to write to NARA still to figure out if they have anything from the IBM RTCC documents [17:22:23] indy91, can the LVDC presettings be copy/pasted into the scenario as-is, or does it need a few more parameters for the scenario? [17:22:57] ah yeah, I remember I needed something extra. let me check [17:23:19] I noticed a few things like LVDC_XLunarAttitude and LVDC_XLunarSlingshotAttitude are missing [17:23:46] in the LVOTs the LVDC parameters are in three sections [17:24:06] general parameters for boost to orbit, general parameters for TLI, targeting presettings [17:24:17] my tool will probably mainly output the last part [17:24:32] I think that would be correct behavior, but I have to check again what the QRTP output all has [17:25:47] I tried just using the QRTP output presettings in the launch scenario and the behavior after SII/SIVB sep was...a little wobbly [17:26:12] haha [17:26:28] I pushed an update, GMT of pericynthion is now displayed [17:27:33] right now it's a bit all of the place, but in the future these three LVDC presettings sections should probably be a bit more separated in our scenarios as well [17:27:37] all over* [17:27:43] what scenario did you use as the basis? [17:28:22] LVDC_XLunarSlingshotAttitude does likely not come from the QRTP [17:28:29] LVDC_XLunarAttitude might actually [17:28:40] I think it's in the LV targeting presettings punch cards [17:29:09] but then, in a few actual Apollo 16 cards, they don't appear anymore [17:29:23] the attitude [17:31:29] I used the Apollo 17 launch scenario as a basis [17:32:09] but I replaced all the LVDC parameters in the scenario with the ones output by the QRTP [17:32:16] I imagine I have some missing ones [17:32:29] yeah [17:32:53] I definitely needed to move around some numbers, I also used 17 [17:33:48] https://pastebin.com/phFVvkxS [17:34:02] this is what I have in addition to the presettings from the QRTP [17:34:16] I bet especially these [17:34:18] LVDC_T_1 246.5 [17:34:19] LVDC_T_2 144.04 [17:34:26] are quite important for S-II/S-IVB behavior [17:34:43] but copy them all [17:34:57] we will definitely need a system [17:35:23] the QRTP, aside from TLI targeting, also has a detailed simulation of the whole launch through TLI [17:35:31] for that it needs all presettings [17:35:43] so at least as input, it uses them all [17:35:51] right [17:37:15] is there an error code description somewhere? [17:37:19] found it, yeah the QRTP TLI option only outputs the TLI targeting presettings [17:37:23] I have seen error 5 and 6 [17:37:39] I wanted to change the numbers to error descriptions [17:37:43] 5 and 6 are with TLI [17:37:46] uhh [17:37:48] TEI [17:37:54] also a flaw of the current logic [17:37:55] right [17:38:01] just change the estimated TEC time [17:38:07] and it will work [17:38:14] for Tycho I found approach azimuth default of -91 always gave erroe 5 [17:38:15] adding/subtracting 5-10 hours usually works [17:38:26] just a TEI problem [17:38:30] which is really unimportant [17:38:37] so I reduced the approach azi to -70 and it seemed to work [17:38:43] nah, don't do that [17:38:44] ah ok [17:38:54] only fix it by adjusting TEC time [17:39:02] approach azimuth is for weight optimization [17:39:16] ah ok [17:39:17] I need a better system for TEI [17:39:59] I will re-calculate my Tycho mission, thanks for the PC GMT that should help make the process quicker [17:40:11] one problem is, with later arrival at the Moon the TEI DV is increasing, TEC time getting shorter to land in the same longitude [17:40:22] so there is actually a 24 hour jump at some point [17:40:26] of TEC time [17:40:45] oh and of course, only optimize approach for one launch azimuth [17:40:58] only 72°, or maybe 90°. But better 72° if you launch there. [17:41:14] they definitely wanted to use a constant approach azimuth for the daily launch window [17:41:23] so not something to be tweaked for every azimuth [17:43:31] right [17:43:35] -90° is typically a good first guess for the approach azimuth [17:43:39] but for Tycho I didn't get that really [17:43:44] as the optimum value [17:43:50] I had -80° [17:44:35] I also still want to implement threading [17:44:49] so that the program doesn't just freeze while it calculates :D [17:44:58] so to optimize approach azimuth, your looking at what value? [17:45:15] remaining DV, at the very bottom [17:45:29] ok [17:46:00] minimum was 900 ft/s [17:46:08] otherwise you have an illegal mission:D [17:46:15] 600 ft/s for rescuing the LM [17:46:33] 300 ft/s for sudden bad weather during TEC, requiring a large longitude shift midcourse correction [17:47:44] I tweaked my Tycho mission to be barely acceptable non-free return [17:47:49] 2000 ft/s DPS, 800 ft/s APS [17:48:10] I could get even closer to free-return though, I have 1346.6 ft/s [17:48:11] spare [17:48:45] when are you launching? [17:48:58] I was on 8th Februar 1973 [17:51:15] my first try was July 20th 1969 [17:51:22] haha, fun [17:51:58] but now I am trying again with the Apollo 17 launch date as a basis and going from there [17:52:15] ill try your date [17:52:44] I'd rather you don't really [17:52:52] every new day I found a new bug [17:53:01] ah right [17:54:19] you might have also noticed Pacific vs. Atlantic window [17:54:35] I don't have a good system for that yet. But basically, there are two launch windows every day. [17:55:00] there are lunar geometry differences, so one will be better than the other [17:55:14] Atlantic seems to lead to more night launches somehow [17:55:27] on the actual missions, all except Apollo 17 launched at the Pacific window [17:55:34] 17 was Atlantic [17:55:38] made TLI later, too [17:56:58] interesting [17:57:01] whats error 4? [17:57:55] the PC+2 calculation didn't converge [17:58:01] not sure I ever got that one :D [17:59:03] as a general rule for Tycho, closer to -80° seems to be better than -90° always [17:59:11] maybe because of its lat/long combination [17:59:24] what coordinates are you using for Tycho? [17:59:40] where I landed with Apollo 14 once [17:59:44] Zerlina [17:59:46] north rim [17:59:49] so not in the crater [17:59:59] -41.79122° and -11.5° [18:00:07] ah ok [18:00:18] I just put the LM in the crater and copied the lat long [18:00:26] but its close to yours [18:00:30] shouldn't make a huge difference [18:00:38] not for trajectory design [18:00:40] I just wanted a check to make sure I had found the right crater :D [18:00:55] I have -43.11 -11.81 [18:00:56] north rim landing was one thing they considered [18:01:04] right [18:01:05] a Surveyor in reach [18:01:18] and going to the actual rim of the crater as well [18:01:31] when I actually fly the mission I will use the proper coordinates [18:01:35] but still problematic, unlikely they could afford the weight of a LRV [18:01:44] very far south [18:01:48] oh yeah [18:01:55] not sure how far actual planning ever got [18:02:04] if they had a definitive site [18:02:37] I have 10th December 1972 now [18:02:45] Atlantic opportunity [18:03:12] better than Pacific [18:03:44] -80° again [18:03:48] 80 hours TLC time [18:03:59] give 2800 ft/s PC+2, the absolute DPS+APS maximum [18:04:03] and enough spare DV [18:05:06] can't tweak it better than -79° approach azimuth really [18:05:17] I tried that in the lighting page but 10th December 1972 hour 1 gives me an elevation of -33 degrees [18:05:26] for Tycho [18:05:51] launch time? [18:06:01] on the lighting page it is landing time [18:06:06] oh of course [18:06:10] then the first guess subtracts a few days [18:06:20] makes sense [18:06:21] and on the first guess page you should really find your launch day [18:06:27] but first guess is near free return [18:06:37] so you might still have a low sun angle there [18:06:45] and then with non-free return, extending TLC, it's ok [18:06:51] if not, add a day [18:06:59] should you play with "Orbits LOI to Landing" or leave it at 13? [18:07:17] that's also just a very rough initial guess [18:07:24] just to get you an approximate landing time [18:07:38] main purpose of the first guess page is to select a launch day, nothing else [18:07:50] ok [18:07:56] 13 is correct for Apollo 11 at least [18:08:00] it was 12 on 10 [18:08:07] but later they reduced it again I think [18:08:11] only makes a 2 hour difference [18:08:19] is there any reason you would select a higher launch azimuth then 72 for the 1st set? [18:08:30] launch vehicle performance [18:08:36] wasn't it Apollo 15 that launched on-time at 80 or so? [18:08:37] that's why Apollo 15 launched to 80° [18:08:44] yeah [18:08:55] but this tool can't really calculate that [18:09:15] ok [18:09:37] well [18:09:54] if I ever implement the whole launch vehicle simulation program (part of the QRTP) it might :D [18:10:27] I'm sure Apollo 15 could have launched to 72°, just the spare prop would have been bad [18:20:22] I definitely need to do something about the TEI errors (5 and 6) that's the most annoying right now [18:20:27] aside from free-return issues [18:22:20] whats the best way to reduce PC+2 DV? Increasing TLC time? [18:24:30] usually reducing TLC time [18:25:03] non-free return trajectories always have a longer TLC time, to make the trajectory slower, LOI DV smaller [18:25:26] but the later the PC time gets, the higher the PC+2 DV gets [18:26:41] whats the date limits for Artemis072 & Luminary210 again? [18:29:19] Launch before 18 February 1974 [18:29:22] sorry [18:29:26] 17 [18:29:59] ok [18:30:09] that's definitely pushing it with some accuracies [18:30:17] mostly Earth orbit being a problem [18:30:27] so for lunar missions not as relevant [18:30:49] it's basically a hard limit on TEPHEM [18:30:53] 963.2 days [18:31:07] https://www.ibiblio.org/apollo/Documents/LUM215-WR_text.pdf [18:33:46] we already have modified ropes though [18:33:50] for NBY 70 and 71 [18:33:54] of Artemis and Luminary [18:34:14] the only problem with NBY 73 and later would be that I have no source for the numbers [18:34:23] but I can probably calculate them [18:46:09] Atlantic windows seem to work better for Tycho [18:46:19] booo night launches :D [18:46:41] I think I found a window for January 10th 1973 [18:46:49] Atlantic [19:18:56] indy91, maybe a dumb question but would I use AGCEpoch 1973 for a launch in Jan 1973? [19:19:26] or does Artemis072/Luminary210 still need 1972? [19:21:53] 1972 [19:22:08] AGCEpoch is tied to both the AGCs and the RTCC [19:22:12] they use the same coordinate system [19:22:29] and because of hardcoded stuff, Artemis072/Luminary210 need to continue using 1972 [19:22:34] and therefore the RTCC does too [19:23:24] right [19:25:02] that is, sort of, a downside of my move to the correct RTCC coordinate system. It changing yearly, too. There are now things that, like the AGC, depend on being close to the correct epoch. [19:25:23] so if we want to ever want to launch in 2000 or so we need modified ropes for AGCEpoch 2000 [19:25:44] and not modified ropes that use a generic coordinate system like 1950, like Skylark and Shuttle [19:43:46] hmm [19:44:10] I have sets up to 108 degrees azimuth [19:44:38] but if I simulate a launch with a 3 hour delay with P10, it gives launch azimuth = 0 [19:46:28] interesting [19:46:45] probably more issues with how the tables for the launch azimuth as a function of time are build right now [19:49:55] how many launch azimuths did you have as LV targeting objectives for that? [19:50:25] https://www.dropbox.com/scl/fi/r8sfk3mm6actnb7h76yfe/Screenshot-2023-12-04-14.49.06.png?rlkey=psjvk2zo45g9guvyzbl8cxfpq&dl=0 [19:51:00] 5 [19:51:08] right [19:51:12] 72,81,90,99,108 [19:51:17] these are the preprocessor plots [19:51:21] just 2 of them [19:51:30] was experimenting putting this in the GUI [19:51:35] vs writing them to file [19:53:07] what possibly might happen is that only the first 3 azimuths are processed properly for the launch time vs. launch azimuth polynomials [19:56:57] would this be only a RTCC/P10 issue? [19:57:06] LVDC as well [19:57:13] hmm [19:57:16] although [19:57:21] launch azimuth 0 is a bit confusing [19:57:45] also this iteration of my Tycho mission gives higher MCC-2 DVs [19:58:10] azimuth 72 opportunity 1 shows 120 ft/s [19:58:23] but I wonder if actually flying it would give better results [19:58:32] probably not better [19:58:45] I need to run my latest Tycho as well [19:58:52] it's likely a new bug [19:59:08] that I didn't have before I took apart the QRTP and build it back together [19:59:33] https://www.dropbox.com/scl/fi/idydtwu2t1dabq1x031ke/Screenshot-2023-12-04-14.59.03.png?rlkey=n3wksujxn90yadlurpu7hfge7&dl=0 [19:59:47] thats my current mission on-time [20:04:41] ouch, I get 164 ft/s [20:04:48] maybe I entered something wrong [20:04:57] in the RTCC calculations for my launch day [20:08:31] I'm in my SIVBPropulsion branch. Already found a bug with the venting taken into account for the trajectory... [20:08:39] but that shouldn't cause DV differences [20:08:48] venting or not should barely matter [20:12:54] not much else to do than go in the depths of the QRTP and find the bug and implement more debug outputs [20:16:34] I know I had it working much more accurately. Probably one small bug. [20:17:32] yeah [20:32:51] so I see the padload generator does a lot of things we needed to do manually before? [20:33:18] like find 504LM, sun/moon polynomials [20:34:32] yeah [20:34:47] awesome [20:35:00] I was worried about needing to figure out that stuff [20:54:04] I'm reverting one change temporarily to see if that makes the difference [20:54:17] from what I see in the changed presettings, it actually might [20:55:20] ah [20:58:06] hmm well. DV is lower. 24 ft/s. [20:58:15] I need to switch out of the venting branch [20:58:34] I think there is a bug in its trajectory propagation [20:58:36] with the venting [20:59:42] maybe in the Orbiter2016 branch I am back to the accuracy I had previously [21:00:05] 24 ft/s is definitely better then 164 ft/s :D [21:00:46] don't forget to do the SFP interpolation on your side [21:01:08] wouldn't make the MCC calculations any more accurate :D [21:01:42] insertion orbit is 90x90 of course [21:01:58] the potential bug I saw made it have about 70x70 at current time [21:02:05] T-4 hours [21:02:11] but venting should only be enabled at 0.2 hours after liftoff [21:02:29] so the RTCC shouldn't continue to make the orbit lower by going back into the past from insertion :D [21:02:54] 70x70 would be a bit low [21:03:13] ...without wings [21:03:17] haha [21:03:20] yeah I did the interpolation [21:03:24] but probably what you would get if you had normal venting enabled before insertion [21:03:32] and then propagate into the past for 4 hours [21:03:48] I think that tracks with the amount of venting you get just after insertion [21:04:03] but like I said, I thought the RTCC takes that into account. Must be a bug. [21:04:37] let's see what I get in a branch without propulsive venting... [21:07:22] ah yeah, there we go [21:07:26] option 1: 0.7 ft/s [21:07:33] nice! [21:07:36] option 5: 1.3 ft/s [21:08:00] the funny thing is, the code I just reverted, the new numbers it calculates look very good [21:08:12] it's the other numbers the additional calculations screwed up :D [21:08:27] I might just push the reverted solution for now [21:08:39] it's just a bit of commented code [21:08:43] ok [21:08:45] great [21:08:56] once I figure out what happens I can re-instate it [21:09:06] and this is only the QRTP part of the tool [21:09:21] can I just reload my saved plan and re-export the presettings, or must I re-calculate each data set? [21:09:32] you can go from the preprocessor on [21:09:41] load the LV targeting objectives [21:09:46] ah ok [21:09:49] and calculate the files from there [21:09:54] so no mission planning changes [21:10:00] just copy over the new files [21:10:08] and LVDC presettings of course [21:10:14] ok [21:11:23] pushed [21:11:42] thanks [21:12:11] could that be what caused the launch azimuth showing zero for the late launch test I did? [21:12:21] probably not [21:12:53] and yeah, I think I see the venting bug [21:14:27] TLI targeting tool helping to find S-IVB venting PR bugs [21:14:32] it's actually useful :D [21:17:31] haha [21:23:33] MCC-2 4.4 ft/s [21:23:39] on time launch [21:23:47] not bad! [21:24:39] TLI-2: 1.2 ft/a [21:24:47] ft/s* [21:26:13] with the venting bug fixed I still get higher DVs [21:26:18] lower than before [21:26:27] not quite where it is without the venting [21:26:36] I wonder why... [21:26:54] maybe it does some venting after TLI when it shouldn't [21:27:04] need to check that [21:28:07] ah yeah, very likely [21:28:17] there is special TLI logic [21:28:30] don't know quite where a fix has to be done, but that will likely be it [21:28:46] after TLI it continues venting as if it was before TLI [21:29:01] I didn't do a MPT undocking maneuver [21:29:10] but that's not all there is to it [21:30:04] hmm, I see there is already logic to take that into account [21:30:06] weird [21:30:10] but there could be a bug with it [21:30:29] I tried a late launch of 1h30 minutes [21:30:44] TLI-1: 3.9, TLI-2: 2.4 [21:31:01] looks very good [21:31:04] great [21:31:25] indeed the azimuth issue still stands, I could only get it to give valid azimuths for 1:30 late [21:31:55] might be any time after the third launch azimuth [21:32:14] the part I had to revert is how the LVDC takes into account if the EPO is a bit different than planned [21:32:37] but the initial guess shouldn't be bad [21:40:41] post-TLI venting confirmed [21:40:55] when I completely disable that I get the same MCC-1 as in the Orbiter2016 branch [21:41:09] in the SIVBPropulsion branch [21:41:30] shades of Apollo 13 [21:41:40] they screwed up their MPT a bit and got the exact same issue [21:47:56] night! [21:59:30] n7275: more fortran has appeared on ebay: https://www.ebay.com/itm/266549128962 [16:27:04] hi Alex [16:28:46] thewonderidiot, thanks for sending that. it looks like someone bought it before I could though [16:29:02] hey [17:28:55] what's up? [17:31:06] n7275, playing around with a custom NAASP mission [17:31:38] using Nik's new tool [17:43:44] nice [17:46:25] hey guys [17:47:14] morning! [17:50:40] hey [17:51:48] indy91, I think I figured out the azimuth issue, at least with the TLI data set for the RTCC MFD [17:52:02] hi Nik, Mike [17:52:43] AlexB_88, I figured it was an issue with the way I "calculate" them at the moment [17:52:56] when I was using 72,81,90,99,108 it would give the issue [17:53:08] but then I tried making just 72,90,108 [17:53:11] not much of a calculation yet. Only really accurate for the specific input launch azimuths. [17:53:17] yeah, that makes sense [17:53:19] or 72,90 [17:53:36] and then P10 gives the full range up to 108 degrees [17:53:38] the LVDC has three segments of polynomials [17:53:54] what I did so far is just 3 linear linear segments [17:53:57] -linear [17:54:07] or maybe even only 2 [17:54:22] so the "polynomial" is from the first to the second, second to the third specified azimuth [17:54:27] and if you had more than 3 input azimuths [17:54:37] then the ones beyond that weren't really available [17:54:45] gotcha [17:56:02] so when I used max 3 segments, the RTCC MFD was suddenly happy with the whole launch window [17:56:05] but [17:56:10] yeah, but in between [17:56:25] on some launch days it's not very linear [17:56:31] so that can be a bad assumption [17:56:41] so only the input launch azimuths will give nice MCC DVs [17:56:51] yeah makes sense [17:57:15] but one weird thing is the LVDC does not fly the azimuth predicted by P10 [17:57:25] its a few degrees less [17:57:39] oh that's not good [17:57:52] was that for 72°? [17:57:54] despite using the presettings generated in the same iteration as the RTCC TLI data [17:58:20] or which launch azimuth did you try [17:58:32] well its good for 72 but its slowly diverges after [17:58:58] like P10 and LVDC will agree for 72 (LVDC being the number given in UTILS->LVDC) [17:59:21] but 1 hour later P10 will give 83 but LVDC gives 81 [17:59:59] then P10 96, LVDC 93 and so on [18:00:19] but I wonder if its how I put the pressetings in the scenario [18:01:06] I simply put in the base presettings you posted yesterday, then put in the TLI presetiings under [18:19:48] I just need to look at the launch azimuths as a whole. It's less of a bug, more of a project still to do [18:20:14] but the azimuth difference could be something simple [18:21:14] yeah I figured it could be as simple as me having screwed up copy/pasting the pressetings over :D [18:23:04] probably not [18:24:28] what other presettings are responsible for launch azimuth, other then hx,AZO,AZS? [18:25:57] there are a few confusingly similar named variables, have to check which one of these is used [18:26:06] TDS, TD, TSD [18:26:10] 1-3 for each [18:26:41] ah well [18:26:45] all of them are used haha [18:27:02] TDS is how it decides which of the three segments is used [18:27:21] TD1 are offsets, TSD are scaling [18:27:28] all of these are also used in the RTCC [18:27:41] should be the same way as in the LVDC [18:28:12] right [18:28:26] I need to compare them between preset tape, RTCC TLI file and LVDC presettings [18:29:01] for a 3 segment plan, the RTCC TLI file seems very accurate [18:29:16] when doing P10 launch + TLI on the MPT + calculating an MCC [18:29:43] and I tried it for multiple launch azimuths and MCC's are quite low [18:29:56] as long as I use max 3 segments [18:30:15] but the only issue is the LVDC does not want to fly the same azimuth haha [18:30:20] unfortunate that I had to revert something for that, but, we will get there again [18:31:42] does not want to fly the azimuth P10 predicts* [18:34:05] yeah, first I will do a comparison of the three files where the data is saved [18:34:19] there could be a dumb unit conversion that screws it up [18:37:57] right [19:10:19] ok, first check preset tape. Pretty sure all those time scale factors are right in there [19:12:13] also can't see anything wrong in the LVDC presettings [19:14:59] RTCC file confused until I remember it is in hours there... [19:15:04] confused me* [19:18:00] also correct [19:18:13] it could also be RTCC loading the file where there is an issue [19:18:25] or the actual polynomial data [19:18:31] next thing to check [19:23:31] polynomial data, also looks correct [19:28:32] AlexB_88, can you make sure you don't have any of the values with TD, TSD, TDS twice in your scenario [19:28:39] that's my only idea about this right now :D [19:28:59] otherwise I will have to try and replicate it with your files [19:29:10] not that I tried a late launch myself yet [19:32:53] hmm [19:33:18] should TD,TSD,TDS be showing in a saved scenario? [19:33:40] absolutely [19:34:05] they are definitely in my Apollo 18 launch scenario and only once [19:34:14] LVDC_t_SD1 [19:34:18] like this actually [19:34:34] if you CTRL+F for TSD1 it probably didn't find it [19:34:56] oh [19:34:57] oooooh [19:34:59] hahaha [19:35:02] that's the issue [19:35:38] my tool wrote the parameters in the wrong way in the presettings file [19:35:46] e.g. [19:35:48] LVDC_TSD1 1.810268e+03 [19:35:57] but it looks for [19:35:57] LVDC_t_SD1 [19:36:05] that will be the issue [19:36:14] easy fix [19:36:23] I'd call that a bug and not missing feature :D [19:37:27] ah [19:37:41] so for you it will have tried to use some default parameters [19:38:23] so its just the name of the parameter that was wrongly written [19:38:26] yep [19:38:32] so our LVDC code didn't load them [19:38:45] I thought it was weird that none of the other launch scenarios had them :D [19:38:56] oh they sure have them [19:39:01] just slightly different :D [19:39:27] just not called LVDC_TSD1 etc [19:40:10] yep, the missing underscore will have caused it to not load it [19:40:43] so I guess I can quickly test by renaming [19:40:47] yeah [19:40:56] I have a fix in a minute, too [19:41:33] same bug in all of thes [19:41:36] e [19:41:38] TD, TSD, TDS [19:43:02] done [19:43:55] ah much better :D [19:46:00] how can you check so quickly? :D [19:46:21] well that's at least one launch azimuth issue fixed [19:46:52] I believe you can use 4 launch azimuths, too. Just not 5 at the moment. [19:47:07] up to 4 should not run into the other issue [19:47:09] I think [19:51:30] I already new what the azimuth should be from doing P10 before [19:51:57] and with the issue the utils=>LVDC page was 5 degrees off from what it should be [19:52:05] but now it matches perfectly [19:52:27] so with a 4 hour late launch P10 gives 105.396743 [19:52:49] and Utils->LVDC: 105.3967 [19:53:25] ah so 4 azimuths should work eh [19:53:45] I guess that is better then 3 [19:53:58] I mean right now I am doing 72,90,108 [19:54:06] but thats quite big steps [19:54:22] maybe I should do 72,81,90,99 [19:54:32] and just forget about 108 [19:58:16] or maybe in steps of 12 degrees [19:58:32] 72,84,96,108 [20:05:29] shouldn't be too long until I have a solution for this [20:05:48] then you can use any number you want. well, 2 or more is a must. [20:06:21] unfortunately the QRTP Volume I gives lots of graphs for the analytical launch azimuth model and none of the math :D [20:07:04] right [20:18:57] what is Split Launch Time? [20:19:16] only Optimum 1st Opp seems to not crash the tool [20:26:09] so I think 4 doesnt work yet [20:26:50] jsut did one with 72,81,90,99, but P10 gives 0 for launch azimuth when passing 90 [20:28:38] hmm ok [20:29:56] 1st and 2nd TLI opportunities have different launch times where TLI is completely in-plane [20:30:13] I did notice the LVDC_hx values only seem to go up to 90 [20:30:23] ah ok [20:30:24] so on the early missions they launched at a compromise time [20:30:35] especially noticable with Apollo 8 and 12 [20:30:43] yawing to one side during TLI [20:30:56] but on the 2nd opportunity they would yaw the same amount to the other side [20:31:11] ah so that would have been split time [20:31:15] basically, weight after TLI cutoff theoretically identical between the two opportunities [20:31:16] yep [20:31:45] on the last few missions (I think 15 and later) they made the 1st TLI opportunity in-plane [20:32:16] I guess with the 2nd opportunity being so unlikely, they rather have spare propellant for something like an S-II failure of sorts [20:32:20] than for a TLI delay [20:32:40] I don't have a proper split launch time calculation yet [20:32:45] although I thought it would already work [20:32:57] maybe I broke it when I reverted some code yesterday [20:33:14] I tried both split and 2nd opp and it crashes the app [20:33:27] I think I did that before yesterdays update [20:33:30] I think [20:33:34] oh ok [20:33:41] ah well, most of the code for it is already in place [20:33:52] shouldn't be too hard to make it work, find the issue it currently has [20:34:36] as a tool for custom missions we are mostly interested in non-free return and how they design trajectories for later missions [20:34:41] so at least that part works already [20:36:45] oh lol [20:36:56] I didn't disable enough code yesterday :D [20:37:02] not too much [20:39:00] for my Tycho launch day [20:39:10] optimum 1st opportunity: 00:54:26 [20:39:23] optimum 2nd opportunity: 00:58:49 [20:39:43] and split is just the average of those right now [20:39:46] but it does run [20:39:56] with a few more things commented out, which I forgot yesterday [20:40:43] the same things commented that fixed the tool yesterday [20:40:56] just in the code for optimum 2nd TLI and split time [20:42:09] I pushed that version [20:42:17] but I would still recommend using optimum 1st TLI [20:42:40] ok [20:43:28] oh how close to actual launch time is Apollo 11 now... [20:44:06] 13:29:30 and 13:31:46 [20:44:52] my current average time solution (and rounded up) would get 13:31:00 launch with that [20:44:56] and not 13:32:00 [20:45:01] but not that far off haha [20:45:07] 13:32 being actual [20:46:38] hmmmm [20:46:39] or [20:46:47] this QRTP version actually only has two options [20:46:52] split launch time [20:46:57] or optimum 2nd TLI opportunity [20:47:08] they did want to retain a possible third opportunity at some point [20:47:19] if I look at the Apollo 11 TLI cue cards [20:47:28] it looks like the 2nd TLI wouldn't have a lot of yaw [20:47:31] but 1st TLI would [20:47:41] maybe that was optimized 2nd TLI opportunity [20:51:30] 12 clearly used split time for 1st and 2nd [20:58:50] ah hmm, it's not that simple. One opportunity might need a higher TLI energy, so the compromise launch time might have one opportunity using less yaw than the other. [20:59:54] but that could also mean the compromise launch time is a lot closer to one optimum launch time than to the other [21:00:16] we will see with the proper split launch time logic implemented :D [21:00:36] the QRTP documentation is very detailed about that at least [21:14:36] is the DVREM accurate when doing a P10 launch simulation? [21:14:43] for TLI I mean [21:19:46] it's just the default values on the MPT [21:19:54] P10 doesn't simulate it [21:20:09] and yes, I think it should be somewhat accurate [21:20:24] I'm getting like 500 ft/s or so [21:20:32] on average [21:20:39] right [21:20:57] my later TLI-2's were to fuel expensive I think [21:21:10] like one was up to 16000 ft/s haha [21:21:19] probably bad launch window planning on my part [21:21:21] oh that's bad [21:21:41] haven't tried much with second TLI yet [21:21:53] I kept trying to keep a constant arrival GMT [21:22:29] I guess its going to get very expensive for TLI on some days for late launches and TLI-2 [21:22:44] yeah [21:22:47] although [21:23:02] the 72°, 1st TLI solution would be non-free return in that TLI is slow [21:23:06] not fast [21:23:17] so later in the launch window it would get closer to free return [21:23:31] but I would be very surprised if it reaches and "overtakes" free return [21:25:14] but maybe it does and on those days you couldn't do constant arrival [21:25:16] it's possible [21:26:00] right [21:26:22] it looks like it is like that for my Januray 10th 1973 window [21:26:52] once I get past 95 degrees TLI DV starts skyrocketting [21:26:59] TLI-2* [21:27:30] no pun intended [21:28:32] it's also going to be Tycho being difficult to reach [21:28:59] right [21:29:13] maybe another idea for an output in the tool :D [21:29:17] if you use the TLC time that is close to free return you still have the very, very different latitude of pericynthion [21:29:19] TLI DV [21:29:40] Tycho missions are non-free return just because of that [21:29:43] the latitude [21:29:47] oh yeah, I will add TLI DV [21:29:52] also already available [21:29:58] just has to be shown [21:34:05] aaaaaand it's implemented. Pushed. [21:35:44] thanks! [21:43:02] I think next I want to tackle the TEI issue, errors 5 and 6. Probably not very difficult to fix, but definitely annoying right now. [21:43:16] after I try the launch azimuth thing [21:43:31] hmm I dont think TLI DV was the issue, the tool gives not more then 10415 ft/s even with TLI-2 and 108 azimuth [21:43:35] I have looked at the Apollo 8 free-return issue (Apollo 11 converges fine), but it's very confusing [21:43:49] oh weird [21:43:57] but RTCC gave 15000? [21:44:26] I mean, this is in the mission planning stage. It could be something with the QRTP part. [21:44:43] optimized 1st TLI, something goes wrong in the 2nd TLI calculation or so [21:45:00] ah yeah, also remember that [21:45:15] the mission planning page will calculate the optimum TLI [21:45:17] always in-plane [21:45:25] where the QRTP page will have an actual launch time [21:47:06] maybe there is excessive plane change during TLI or so [21:49:03] well, every day a few improvements. Good night! [21:49:11] yeah over 16000 [21:49:12] https://www.dropbox.com/scl/fi/6bwvyhqlvqbu4yl234xf7/Screenshot-2023-12-04-23.09.47.png?rlkey=rdrv4x8kc5bt2lx8i2mb9u62a&dl=0 [21:49:35] uhh [21:49:42] I see 10395.6 [21:49:53] lol [21:49:56] whrong one [21:50:03] looks very nominal [21:50:10] sorry [21:50:16] https://www.dropbox.com/scl/fi/y69dt9myy7k4l9qtu5m4p/Screenshot-2023-12-05-16.49.40.png?rlkey=z9pnsi3ww6vh4w1eh8u8aoznt&dl=0 [21:50:37] not quite as nominal [21:50:55] this will also be where the QRTP output plots will be useful [21:50:58] this is with a 3 segment plan 72,90,108 [21:51:14] better install gnuplot already [21:51:29] right [21:51:42] just have to make it a customized link to the exe [21:51:48] the code for the plots is already done [21:51:52] all 32 of them [21:51:55] version 5.4? [21:51:59] probably doesn't matter [21:52:11] downloading [21:52:13] I don't use any fancy commands [21:52:21] right now the link to it is hardcoded [21:52:37] I will add a text field on the init page where you can specify a link to the .exe [21:52:53] that's not a great system, but the best I can offer at the moment haha [21:53:21] there isn't a plot for DV, but there are for the TLI energy and eccentrcity [21:53:24] any special settings to put in the setep wizard? [21:53:29] 16000 ft/s would be quite noticable there [21:53:33] no, don't think so [21:53:52] ok installed [21:54:01] I can try adding that tomorrow. Anyway, good night! [21:54:08] night! [15:22:02] good morning [15:24:56] hey Matt [15:34:57] what's the idea for the h_ExteriorEnviormnent pull request? Is it something you want Ryan to test in his battery vent update? [16:03:49] hey [16:04:10] hey Alex [16:04:16] I already improved a few things [16:04:23] old error 6 is fixed [16:04:34] it shows a error message text now instead of a number [16:05:05] for all errors [16:05:53] and I found a simpler solution for gnuplot. When installing gnuplot, if you had selected that it adds gnuplot to the PATH system variable then the ATDP should now be able to use it [16:05:58] without specifying a path to it [16:06:46] ah nice [16:08:32] I think next I would look at the launch azimuth thing [16:08:52] ill try and debug my high DV TLI-2's with gnuplot I guess [16:11:01] what kind of TLC flight times did you end up having with that? [16:12:03] I think it ranged from 68 to 62 hours [16:13:29] pretty short [16:16:02] but not 15000 ft/s TLI DV short :D [16:18:17] does gnuplot have to be already open? [16:19:41] nope [16:19:50] my tool will call the exe file [16:19:57] make sure you have created a Plots folder [16:20:21] and when you installed gnuplot, did it add a PATH to your Windows system variables? [16:20:25] that was an optional checkbox [16:20:34] I didn't add it, so I had to do it manually now [16:20:45] yeah I just re-installed and checked that box [16:20:58] that's the two possible approaches for that :D [16:21:21] you know it works when for a few seconds a command line window opens [16:21:56] and of course that happens when you run the LV Targeting [16:22:01] not mission planning [16:22:06] oh my Plots folder is populated! [16:22:13] fun [16:22:15] should be 32 [16:23:22] hmm [16:23:39] I wonder where the clue would be for the high DV TLI [16:23:50] eccentricity and C3 (twice specific energy) [16:24:15] C3 is usually around -1.4 [16:24:27] eccentricity around 0.97 [16:24:44] definitely can vary, but C3 shouldn't become positive (hyperbole) [16:24:49] same for eccentricity above 1.0 [16:30:28] https://www.dropbox.com/scl/fi/jfdh4u5w5l0nzu5lhcblw/plots.zip?rlkey=aiytfsvbsnn86otburmta3567&dl=0 [16:30:59] C3 varies from -1.61 to -1.44 1st opportunity [16:31:31] and -1.55 to -1.37 2nd opportunity [16:32:11] eccentricity looks normal [16:33:00] yeah, doesn't sound bad [16:33:12] I wonder if it is an excessive plane change during TLI [16:33:17] wouldn't appear in these plots [16:33:23] and there is no plot for it [16:33:44] with optimized 1st TLI then 2nd TLI has to do a plane change. It could even be a bug in that calculation. [16:37:53] right [16:38:19] I noticed with a very late launch (4 hours) even TLI-1 DV was high [16:38:24] like 11900 ft/s [16:55:09] but MCC calculation with that was still good? [16:55:15] always good, even for TLI-2? [16:57:21] yes I think [16:57:38] I think it showed a slightly higher MCC DV, like 20 ft/s [16:57:51] so not ideal I guess [16:59:05] unless you use a launch azimuth that is exactly like one of the input ones (72° etc) we right now will always get larger MCCs [16:59:28] because the launch azimuth polynomial is just linear functions [16:59:38] especially late in the launch window it can be very non-linear [17:00:55] right [17:08:57] ah [17:09:32] so I just put in a P10 4 hours late launch (within the window) [17:09:42] and TLI-2 on the MPT shows 0 DV [17:10:57] and if I try 3:30 late its 15600 ft/s [17:11:56] 3:00 late 10600 ft/s [17:12:45] 2:30 late 10575 ft/s [17:12:48] all TLI-2 [17:13:09] I think even down to 2:30 late, its still too high [17:14:55] even a 108 degree opp 2 launch only gives 10428 ft/s according to the ATDP [17:22:10] morning! [17:23:08] indy91, I have a few more functions to add, then I think we can merge it. then Ryan can pull it from upstream to use [17:23:24] hi Mike, Alex [17:24:41] hey [17:27:23] n7275-, sounds good. We can do all the testing when something actually uses the branch. The code right now looks fine to me, aside from the one thing I had already mentioned. [17:28:05] AlexB_88, yes but the mission planning page will have the 2nd TLI in-plane, where with an actual launch it is not [17:28:19] but I am still not sure if the additional DV comes from a plane change [17:30:19] right [17:30:38] maybe Ill try testing the presettings with optimum TL-2 [17:32:28] my first improvement with the launch azimuth will fix the issue with the number of input azimuths [17:32:32] but still linear functions [17:33:50] ah nice [17:34:19] at least there will be more data points despite being linear in between [17:49:07] indy91, just tried TLI-2 optimized presettings but the DV is still 15800 ft/s for a 3h30 late launch and TLI-2, so I guess it must be something else [17:49:23] right [17:49:32] thanks for checking [17:49:48] I hadn't checked yet in my Tycho test [17:50:01] didn't use constant arrival time I think [17:50:15] right [17:55:13] I think I'll leave removing the old vent class as a seperate project [17:55:34] oh yeah, that is a good idea [18:11:05] ok, part 1 of the launch azimuth fix is implemented. It now writes the table with 53 azimuth vs. launch time combinations [18:11:18] that needs to be improved later to not be linear [18:11:54] and now in reality they would run a least squares curve fit on that table to generate the presettings [18:29:36] ah interesting [18:30:35] I imagine if you used all 53 azimuth you could get pretty close to the same accuracy as if you used just 5 with non-linear interpolation :D [18:30:57] if I understand that correctly [18:33:10] yeah non-linear interpolation through the existing data points would make it quite accurate [18:34:48] at first I am just trying to make it independent from the number of input azimuths [18:37:37] and I am going to let it plot for me [19:01:07] just need to figure out multiple plots in a single graph in gnuplot :D [19:17:57] any good way to get an average time of TEI for the monthly launch window? (for an ATDP built mission) [19:20:43] for the PTC REFSMMAT? [19:21:09] yeah [19:21:18] I know that in reality those were constructed using specific angles and not times [19:21:20] or maybe just use the TEI time [19:21:23] like, moon phase = 30° or so [19:21:27] ah [19:21:36] eventually I will replace our logic with that [19:21:57] don't think the time is that import for a custom mission [19:22:08] we don't have to match a flight plan or so [19:22:13] just has to be good for PTC [19:23:18] I am sure there will have to be many refinements for the process of setting everything up for a custom mission [19:33:14] right [19:52:38] indy91, I though of something [19:53:04] my scenario is based on the Apollo 17 one and has all Apollo 17 weights [19:53:34] but I did not change anything on the Init page of the ATDP, except for setting the parking orbit to 90 [19:54:29] maybe I have to set all the other values to the same weights in my scenario? I imagine they default to Apollo 11 weights but I didn't think it would make much of a difference [19:55:09] at least not to the point of making my late TLI 15000 ft/s [19:56:03] hmm, I don't think that makes a big difference [19:56:37] yeah [20:17:59] uh oh [20:18:10] my Tycho mission had launch azimuths on the wrong launch day :D [20:19:44] and something runs super slow with it now [20:19:54] I hope that's not my TEI fix breaking something [20:27:43] hmm, I must have had a bad LV targeting objectives file or so [20:27:51] re-calculated that and now it's ok [20:28:35] and I think I have good launch azimuth numbers now [20:28:45] just need to make the graph prettier, then I can show it [20:31:51] phew :D [20:42:54] it's something I have to keep an eye on. Who knows, maybe your 15000 ft/s TLI wants to get to the Moon 24 hours faster :D [20:43:28] would also show up in the SFP though, I think [20:43:34] SFP also needs plots [20:43:43] the new format for NASSP is not very human readable [20:47:06] indy91 gnuplot has "multiplot" which works very similar to Matlabs "subplot" [20:47:50] yeah I might use that, or the number of files becomes excessive [20:52:06] don't underestimate my wish to print 2000 pages of mission planning documentation tho ;) [20:53:07] in color [20:54:06] here, I made the plot pretty: https://i.imgur.com/02QMjoa.png [20:54:14] all I changed was the output file resolution... [20:55:02] we'll that's odd [20:59:42] https://i.imgur.com/emSB20l.png [20:59:45] Apollo 11 [20:59:47] pretty linear over all [21:00:12] the 5 input points are the actually converged trajectories. 72° launch azimuth, 81 etc. [21:00:36] "Table" in green is the data table generated from that, 53 entries [21:00:48] and "LVDC" is simulating the LVDC polynomial [21:01:57] here Tycho, definitely shows the flaws of my linear assumptions right now [21:01:59] https://i.imgur.com/f2O1BZR.png [21:02:38] I probably better implement at least a quadratic appoximate between line segments [21:02:45] approximation* [21:03:39] so I guess the realistic plot would have a curve rather then straight line between segments? [21:03:50] yeah [21:04:02] both the data table and the LVDC should have a real curve [21:04:22] right now it's linear segments. But different segments for the LVDC as it has 3 segments max [21:04:38] each segment could be a proper polynomial, too, but right now it's also linear [21:05:25] just linear between regular intervals from the data table, right now [21:06:58] and not linear between the input data points [21:08:09] I will improve that all a little bit before I push this launch azimuth update [21:10:04] in the end, ideally, both the data table and the LVDC polynomials are identical [21:12:34] right [21:37:01] night! [15:28:29] hey [15:44:14] hey Niklas [15:47:30] time to figure out something for these launch azimuths [15:49:38] and when I have something I can live with I can check your high TLI DVs [16:04:34] great [16:04:48] I have been toying with plans using longer TLC times [16:08:36] least squares should be easy to figure out, I can re-purpose some RTCC code [16:09:04] the analytic model, so that we don't have linear segments, I have some ideas for at least [16:22:46] I guess it will make the blue line match the table a bit better [16:23:22] yeah, that is my first step [16:24:41] those were great graphs btw (launch azimuth model) [16:24:52] will those be output by the new version? [16:26:25] yeah, for RTCC and LVDC [16:27:10] even these linear segments should be pretty ok in terms of MCC DV [16:27:17] MCC DV in between the input launch azimuths [16:36:48] right [16:44:42] I think I will be flying Apollo 18 soon [16:44:56] to Tycho crater [16:45:30] I have faith in my current presettings at least up to 2 hours into the launch window :D [16:46:47] as I obviously don't have a flight data file for this mission I decided to try and create a mission that closely matches Apollo 15's lunar orbit geometry, at least up to the landing [16:47:12] so same LOI, DOI time and 11 orbits to landing [16:47:40] that way I can use the times in the LM activation checklist and timeline book I think [16:47:57] I mean from Apollo 15's flight data file [16:52:04] ah yeah, that makes sense [16:53:55] also found that setting a REVS2 value optimized for 72 azimuth opp 1, also works pretty well for the later launches [16:54:06] to get the DOI DVz close to 0 [16:55:01] uhh, the mission profile right now is 60 NM circular, with a LOI-2 [16:55:25] the timing of e.g. PDI would be quite off [16:55:36] ah right [16:56:36] I can implement support for that soon-ish, but, my priority is really to fix all the major issues [16:56:39] and not add more features [16:57:10] based on an MPT mission simulation from the launch pad, I think it should work ok I think [16:57:29] I mean the landing time is different then predicted by the tool of course [16:58:17] TEI time and such could be a problem using TLMCC option 4 [16:58:27] but if it converges, you can fly any mission you want :D [16:59:46] right [16:59:52] aha! least squares calculation works [17:00:00] nice! [17:00:10] https://i.imgur.com/f2O1BZR.png [17:00:16] this is before [17:00:20] from yesterday [17:01:08] https://i.imgur.com/LI6t8tQ.png [17:01:11] and this is now [17:01:23] still tries to follow these linear segments of course [17:01:38] wow [17:02:32] mostly creative use of functions I already had in the RTCC haha [17:03:00] I'll clean it up and push this later [17:09:52] oh but when I implement LOI/DOI geometry it should be much easier than with the RTCC to get the right REVS1 etc [17:11:16] I mostly want to get rid of the RTCC init file, but for now I can also output it with the ATDP [17:11:19] on the last page [17:11:35] for landing site coordinates, some geometry stuff [17:24:07] right I figured you won't need to play with those constants when the SFP will have optimized LOI/DOI geometry built-in I guess [17:24:34] hmm, but the SFP doesn't come with parameters such as REVS1 [17:24:49] hmm right [17:25:35] the init function right now has various parameters that are: launch day specific, might be changed during the mission and are not part of a data table that is loaded pre-mission from tape or so [17:36:38] init file* [17:39:44] morning! [17:42:26] hey Mike [17:43:43] what's up? [17:44:50] still hard at work fixing the worst TLI planning tool issues [17:44:53] and you? [17:46:25] I think I'm mostly prepared for Sunspot. did more work up-front this time in terms of setting up scripts to fix any potential bad diodes [17:47:23] I am definitely not prepared for Sunspot :D [17:47:31] what should I even be prepared for... [17:47:50] how to write a TFF routine in Block I AGC assembly??? [17:48:09] wasn't that of the potentially missing things [17:48:14] one of* [17:48:27] and I'm getting a cheap picoscope in tonight to see if it will work as a replacement for the full-size oscilloscope I usually fly with, in case of two bad diodes in the same strand. if it works it'll be much smaller and lighter, and also less likely to break [17:48:46] it is in the list of things, but if Jay Sampson's memo is to believed, Solarium includes the Sunspot TFF package unmodified :) [17:48:56] AlexB_88, launch azimuth update pushed [17:49:26] please show a launch azimuth plot of your Tycho mission :D [17:49:55] ah nice with Solarium. The luxury of already having a few ropes available [17:51:48] indeed! [17:52:42] really the best possible scenario is that module B23 in Sunspot contains the same stuff as module B23 in Corona and Solarium [17:53:07] but regardless, you have a while to prepare, because figuring out what's even missing is going to take a while lol [17:53:43] indy91, awesome [17:53:52] Ill get you a plot asap [17:54:14] let me just rebuild my mission with some more azimuths [17:55:50] I wonder if this "launch on the next day" issue I had is just a fluke or actually the explanation for your 15000 ft/s TLI [17:55:58] I saw that I had such an issue on the new azimuth plot [17:57:29] the issue came from the LV targeting objectives I believe [17:57:36] so it would be a bug on the mission planning page [17:57:42] so I can now put 5 azimuths? [17:57:45] yes [18:14:08] indy91, https://www.dropbox.com/scl/fi/2yvbyvlgp1a0337hguz66/Screenshot-2023-12-07-13.13.14.png?rlkey=80r8izrwqjjk3xm15cz6debny&dl=0 [18:14:36] you copied my screenshot :D [18:15:00] well, mine was a bit steeper [18:15:09] looks good [18:15:39] haha [18:16:16] also I see the LVDC_hx block seems a little more populated :D [18:20:13] yep, I make full use of it [18:20:22] hopefully everything loads right... [18:20:44] they didn't actually make use of all 3 segments. They only use 2 if the behavior is more linear [18:21:09] https://i.imgur.com/HsTqUQe.png [18:21:12] actual Apollo 11 [18:21:23] July 21 is less linear, so they use 3 segments there [18:21:37] but it doesn't hurt to use them all I think [18:28:51] can you also check if you still get high TLI DVs? [18:29:03] I need to check with my Tycho launch day, too [18:29:15] its still 17000 ft/s at 4 hours late [18:29:31] but then already at 3 hours late its 10390 ft/s [18:29:44] before it was much higher [18:29:49] at 3 hours late [18:30:28] 4 hours late is still in the launch window though, right? [18:30:34] yes [18:30:40] its 105 degrees [18:30:49] my last azi was 108 [18:31:06] and that is TLI-2? [18:31:09] yeah [18:31:16] does it happen at all with TLI-1? [18:31:43] TLI-1 at 105 degrees is about 11900 ft/s [18:32:19] definitely high [18:32:30] can you show your DELTL2 vs C3KM2.png [18:35:40] I also should add a plot for TLI plane change [18:35:56] quite surprised it wasn't in the list of 32 plots by the QRTP documentation [18:38:32] https://www.dropbox.com/scl/fi/26zxcxjk7a42wjp7j9pam/DELTL2-vs-C3KM2.png?rlkey=7kwhpctcd3digypejkgjmxcgj&dl=0 [18:39:43] definitely going up, but not really by an amount that should give 17000 ft/s [18:41:28] https://www.dropbox.com/scl/fi/v2xjphaz9g4hvangzfa6q/TLIdebug.txt?rlkey=kln5frjclh6hgh275k0q664jl&dl=0 [18:41:40] that is just a breakdown I made [18:41:59] for the TLI DV [18:42:07] right [18:42:20] QRTP uses the same TLI simulation, so it could show a TLI DV graph as well [18:42:27] same as the mission planning page [18:44:44] the mission planning page does not seem to show the issue [18:45:05] even my 108 degree TLI-2 shows 10382.5 ft/s [18:45:22] could be excessive plane change then [18:45:26] for some reason [18:45:40] right [18:45:46] mission planning page wouldn't show that, as it's simulating TLI-2 as a coplanar burn [18:46:39] whats the "launch on the next day" thing you mentioned? [18:47:44] well for me, when I for the first time generated this launch azimuth graph, I had a sudden jump in launch time [18:47:55] basically I had 72° and 81° like normal [18:48:04] but then I had a jump in launch time, by 24 hours [18:48:11] where the other azimuths were [18:48:25] it turned out to be a problem in the LV targeting objectives file [18:48:35] I re-generated it and the problem went away [18:48:45] but maybe the mission planning page gets confused about something [18:48:55] ah [18:48:59] and actually wants to laucnh on the next day for some azimuths [18:51:24] ok, added plane change graphs [18:51:29] TLI-1, no plane change [18:51:32] surprise, surprise :D [18:51:41] for my Tycho mission it is 0.2-0.3° for TLI-2 [18:51:47] I think that's fairly normal [18:52:06] ok, now the number of plots does get excessive [18:52:18] I might combine them for first and second opportunity :D [18:53:22] I will also add TLI DV so that you can check [18:53:41] btw, can numbers be generated to know the manual TLI yaw angle? [18:54:53] oh wow, not before we don't actually run a full TLI simulation in this [18:55:01] we actually* [18:55:14] then it would be able to show the nominal yaw angle during the burn [18:55:22] and the manual angle would be an average of that [18:55:31] these TLI simulations right now are just curve fits [18:56:53] ah ok [19:08:33] pushed the update for the additional plots [19:08:44] just have to run the LV targeting part again [19:10:36] inb4 10 degrees of plane change [19:15:43] a great [19:16:57] indy91, btw I noticed at 1.5 hours late launch to 2 hours late, the TLI-2 DV inexplicably bumps back up to over 11000 ft/s [19:17:17] I updated https://www.dropbox.com/scl/fi/v2xjphaz9g4hvangzfa6q/TLIdebug.txt?rlkey=kln5frjclh6hgh275k0q664jl&dl=0 [19:17:28] to show the DV at every 30 mins [19:20:40] now ill check the plane change plots [19:24:57] ughh [19:25:07] https://www.dropbox.com/scl/fi/105b4dul2fmohcxb6ljh1/DELTL2-vs-PLCH2.png?rlkey=qewpdhf0jdkzgxiy2seztht41&dl=0 [19:25:11] is that normal? [19:27:02] TLI-2 just show a flat line at 0 [19:27:07] TLI-1* [19:28:22] looks like a normal plane change for 2nd TLI, when 1st TLI is optimum [19:28:32] and optimum TLI means no plane change [19:28:46] https://www.dropbox.com/scl/fi/dns7gezidzfxh17uu5xu1/WELTL1-vs-DVTLI1.png?rlkey=6v2bh4mxcg5jp9qyhzalytudu&dl=0 [19:28:53] https://www.dropbox.com/scl/fi/qlaswrzju35k73h58ysrx/WELTL2-vs-DVTLI2.png?rlkey=ijn8ye69egtvstfdtnvdtim7l&dl=0 [19:29:03] very interesting [19:29:11] might be a RTCC bug then actually! [19:29:22] but it's confusing [19:29:33] how can that be if the TLMCC calculation is consistent with the TLI [19:29:45] you said the TLMCCs with that still small, right? [19:30:16] I did actually try and launch one of the high DV TLI's and the thing actually looked like it was going to fly the monstrosity of a burn [19:30:28] like the SIVB was pitching way up for the initial burn attitude [19:30:33] oh ok [19:30:51] so probably another bug in the conversion from simulated trajectory to presettings I gues [19:30:52] and I kept adding fuel during the burn for it to finish it [19:30:55] both for LVDC and RTCC [19:30:57] lol [19:31:17] the resulting trajectory needed a 120 ft/s MCC Ithink [19:32:07] so likely not a RTCC loading issue. That seemed like it could be it, as I've recently changed the format [19:32:09] of the files [19:32:46] can I see the LVDC presettings file? [19:32:53] maybe I notice something in there [19:33:31] https://www.dropbox.com/scl/fi/6riznxxw8ddej4b52pe6a/Tycho-Presettings-1973-01-10.txt?rlkey=e3h1pan65zt1ay32432xjz05q&dl=0 [19:33:40] with the RTCC file it also could have been a problem with the fixed width format [19:33:42] but not LVDC [19:34:40] want the RTCC file as well? [19:36:29] LVDC file should be enough, if the issue is consistent between LVDC and RTCC [19:37:32] it might be something with the time related presettings [19:37:44] because at the beginning of the launch window the DVs are right [19:37:49] but it gets progressively worse [19:46:45] but it wasn't doing a big plane change? [19:46:51] just pitching up a lot [19:47:13] hmm I didnt notice a plane change in particular [19:47:19] maybe it's a problem with the restart time calculation [19:47:25] that wouldn't appear in any of these graphs [19:47:32] as TLI is simulated from ignition, not TB6 [19:47:44] but it could be a TB6 related problem, would explain the TIG [19:47:47] the pitch* [19:47:58] I am testing another TLI [19:48:03] like, the desired trajectory to the Moon gets calculated correctly [19:48:09] but not the TB6 time [19:48:30] RTCC says 1:30 late should be 11200 ft/s [19:48:33] TLI-2 [19:48:40] well see if the LVDC does that [19:49:19] would be interesting to compare TLI TIG as the QRTP expects it [19:49:25] compared to what we actually get [19:49:31] that's where the issue could be [19:49:37] sure [19:50:11] there are some presettings that are only loaded once per TLI opportunity [19:50:17] constant for the launch window [19:50:37] and in most cases I took the number from the initial (72°) launch azimuth [19:50:46] that could also be potentially it [19:51:04] the real numbering varying over the launch window [19:51:31] but that can't really be it, even a compromise value would be a problem for all other launch azimuths [19:54:40] other potential issue [19:54:53] maybe I chose the wrong time for when the LVDC starts checking for TB6 [19:55:28] then it would start TB6 immediately at that time [19:55:42] but if it's too late, no good TLI [19:56:38] I chose 10 minutes before the TB6 time of 72° [19:56:44] could be too late [19:57:33] it should probably look for the earliest TB6 of all the azimuths [19:59:46] can you give me the TB6 time of one of the launches with a high DV? [20:00:02] or TIG would also work I guess [20:00:30] from looking at it in-sim or is the value somewhere? [20:00:35] I just got to insertion [20:00:41] and flying a TLI-2 [20:00:54] 1hr30 late [20:01:09] I can check the TB6 time and ignition [20:01:21] RTCC would be enough [20:01:28] you can calculate a TLI PAD now I guess [20:01:42] ok [20:01:51] hope it doesn't crash :D [20:02:54] if your TB6 time is around 4:45h then we could have found the issue [20:03:07] TLI-2 [20:03:09] ah wait [20:03:32] can you even switch manually to TLI-2 on the TLI PAD... [20:03:41] might need the MPT again [20:04:29] I think I'll add a graph for TB6 time where it also shows the time when it starts looking for it [20:04:45] ok so I have TLI-2 on the MPT [20:04:53] GETBI 5:00:03 [20:05:26] maybe cutting it slightly close with the restart test time, but, that should be ok [20:05:40] DV 11157 [20:07:31] hmm, I definitely think I am cutting it too close with the test time [20:07:40] my Tycho mission might run into it [20:07:42] for later launches [20:07:53] maybe I did the math wrong and it's the same for you, I will check again [20:09:24] and that's with the same LVDC presettings as you gave me earlier? [20:09:34] yes [20:10:56] GETBI should be actual TIG [20:11:10] the DMT shows both TB6 and TIG, but I am pretty sure this is TIG [20:11:57] it should be ok, I get 5 minutes between first check and TB6 time [20:12:05] too close for comfort, I will probably do a change [20:12:13] but should cause any difference in behavior [20:12:16] should not* [20:12:30] TB6: 4:50:24.8 [20:12:37] from the DMT [20:13:23] TB6 test starting at TB5 + 4:34h [20:13:33] add about 11.5 minutes to that [20:13:37] for GET [20:13:42] should be ok [20:13:55] not for all my cases though, need to add a graph [20:14:12] maybe your very late launches also run into this [20:22:53] on my Tycho mission it would currently run into this constraint from 100° azimuth on [20:23:28] same for the 1st [20:23:50] might explain at least the 17000 [20:23:52] ft/s [20:24:36] its kind of funny how the TLI-2 DV peaks at 1hr30 late, then goes back down to normal by 3hr late, then skyrockets [20:25:15] by now I find it likely that it's two different issues [20:27:12] at least for the super high DV I probably have the explanation [20:30:12] do you want my launch scenario/RTTC files to test? [20:30:36] don't think I need it for the super high DV [20:30:53] I'll have the potential fix for that in a few minutes [20:34:26] ok [20:34:36] about to fly TLI-2 1hr30 late [20:35:04] 1.5 hours late will be interesting for the actual behavior [20:35:14] I don't necessarily expect the pitch [20:37:27] my mission has TLI over the south Atlantic/ South Africa [20:37:44] update pushed, pretty the super large TLI are fixed with that [20:37:48] pretty sure* [20:38:18] TLI GET can vary by up to 15 minutes in the launch window [20:38:35] and I think the later launches have an earlier TLI [20:38:54] I used the 72° TLI TIG, subtracted 10(!) minutes and used that as the earliest possible TB6 time [20:38:57] that was the issue [20:39:17] ohhh [20:39:29] now it looks for the earliest TB6 time out of the whole launch window and subtracts 5 minutes, for any possible deviations [20:39:47] my TLI was only 10380 ft/s [20:39:58] uhh [20:40:07] what predicted 11157? RTCC? [20:40:26] it did not go to 11157 as predicted by the MPT TLI [20:40:30] so it's only the RTCC prediction that was off [20:40:36] interesting [20:40:58] so maybe this, smaller, issue is RTCC file writing or loading [20:41:00] its weird that my 4 hour late TLI-2 the other day was so wird [20:41:16] 4 hour late will have run into the TB6 test limit [20:41:21] what I just fixed [20:41:26] ah [20:41:32] TB6 started immediately when it was allowed to check for it [20:41:37] lets see if this TLI was accurate [20:41:41] which could have been up to 5 minutes too late [20:42:29] now I want your RTCC file :D [20:42:36] because the remaining issue seems to be in there [20:44:32] MCC 8.6 ft/s [20:44:36] ok [20:44:41] awesome [20:44:55] very happy with that, especially with a launch that isn't at exactly at 72° etc. [20:45:16] https://www.dropbox.com/scl/fi/lh4daep7ax598qscsqm9n/Tycho-RTCC-1973-01-10.txt?rlkey=0wmmwlw824im1u63ursyn0tiy&dl=0 [20:45:26] that was option 4 [20:45:49] even better [20:46:03] option 5 might have lower DV, as that is the mission it was planning to do [20:46:58] next you could go back to prelaunch, update your files with my latest fix, and check if the RTCC now has a nicer DV for a very late launch [20:47:23] hmm [20:48:50] GET LOI is 78:27:0 [20:49:10] but that should be the GET LOI for launch at 72 azimuth [20:49:31] I launched 1hr30 late and did the RTCC liftoff time update after insertion [20:49:51] shouldn't it show a GET LOI that is 1hr30 earlier? [20:50:28] which RTCC liftoff update [20:50:33] syncing CMC to RTCC [20:50:36] or the uplink to CMC [20:51:15] can you run an option 1 as well [20:51:21] what DV and GET it gives [20:53:37] option 1 gives GET 77:00 [20:53:41] DV 113.6 [20:54:27] hmm, not so good [20:55:10] any noticable plane change during the burn? [20:55:27] did you run out of propellant? :D [20:55:30] probably not [20:55:49] and any pitching at ignition? [20:56:11] not reall any yawing [20:56:29] nice [20:56:53] a little pitching but nothing very major [20:57:22] definitely not like that other attempt [20:58:04] YAW MCC is 0.810 for option 1 [20:58:43] probably under or overburn [20:59:34] I have 0.0277 fuel in the SIVB [21:00:17] I think that's pretty normal [21:00:52] could it be one of the presettings for TLI cutoff? [21:01:33] it's in there, but it's just a constant value [21:03:19] so both LVDC and RTCC seem to still have an issue with this TLI :D [21:04:08] what P30 DV does your option 1 [21:04:20] give [21:04:32] I want to get a feeling if it was overburn, underburn or something else [21:06:14] VX -95.7 [21:06:20] VY -1.3 [21:06:29] VZ -61.2 [21:06:56] hmm [21:06:59] inconclusive :D [21:07:05] MCC-2? [21:07:20] doesn't look like a plane issue anyway [21:07:23] yeah [21:07:27] GET 30 hours [21:07:28] what does a TIG shortly after TLI give [21:07:33] also option 1 [21:08:29] at GET 6:0:0 [21:08:34] 122 ft/s [21:09:47] and P30? [21:11:28] VX -96.5 [21:11:33] VY -2.8 [21:11:39] VZ -74.8 [21:12:19] ok, still inconclusive [21:12:31] I did find one RTCC file typo so far [21:12:45] in one case it writes an eccentricity from the 1st TLI instead of 2nd TLI [21:12:59] bug causes basically just one wrong number for the whole file [21:13:09] but potentially enough for the difference to the LVDC [21:17:03] had you already tried a 72° launch with this? [21:17:09] To see if any launch is accurate? [21:18:22] typo fix pushed [21:26:19] havent tried an actual 72 launch yet [21:26:44] Ill quickly try the fix with the prelaunch P10 + TLI on MPT [21:27:25] great [21:32:52] all fixed! [21:33:09] TLI-2 4 hours late shows 10415 ft/s [21:33:17] and 1:30 late was 10377 [21:33:24] anyways I have to run [21:33:31] thanks for the hard work on this! [21:33:33] cya! [21:34:12] now the LVDC just needs to agree that it is fixed :D [21:48:00] night! [16:11:12] hey [16:14:11] hey Alex [16:15:09] I think we made the RTCC happy, but the LVDC not quite yet [16:17:56] yeah [16:18:03] LVDC_FSPFileName Config\ProjectApollo\J-Mission Flight Sequence Program.txt [16:18:21] did you still have that in your LVDC section of the scenario? [16:18:39] I'm not sure I included it in my non- presettings text file [16:18:51] don't think it would make a difference for TLI though [16:19:43] and the other thing, did you do the interpolation of the SFP step using the right launch azimuth and also the 2nd TLI opportunity? [16:20:08] would make a difference for TLMCC option 1 at least [16:21:32] testing with TLMCC options 2-5 can hide any issues with RTCC files, so, for our prelaunch P10+TLI on MPT tests it's probably better to use an option 1 calculation shortly after TLI [16:24:50] I'm doing an actual launch today as well [16:24:59] an hour into the launch window [16:25:03] will use 2nd TLI [16:26:03] yeah I have that file in my LVDC section and have been doing the interpolation [16:26:52] hmm, I hoped that you didn't haha. That was my mistake I did at first, forgot to change it to the second opportunity with the SFP [16:27:01] had a 58 ft/s MCC-1 [16:27:08] TLMCC option 1 [16:27:20] with the right SFP interpolation it was then 3.8 ft/s [16:27:28] for a late launch [16:27:35] 72°, I had 0.3 ft/s haha [16:27:38] first TLI [16:27:57] at least now the TLI PAD should work completely right [16:28:05] another point of comparing RTCC and LVDC [16:29:37] the only actual launch I did so far was 72°, first TLI [16:29:41] with good results [16:29:44] was that simulated or actual TLI? [16:29:46] simulated [16:29:53] it wasn't much worse on the actual [16:30:51] hmm [16:31:01] after an actual TLI I had 3.5 ft/s with option 1, 2.5 ft/s with option 5 [16:31:02] I just noticed something [16:31:03] at MCC-1 time [16:31:19] but that was 4 weeks ago, before I had done some major changes [16:31:25] that temporarily broke some things [16:31:38] on-time launch shows a TLI-2 DV of 10383 [16:31:47] 1 hour late 10374 [16:31:55] 2 hour late 10383 [16:32:05] and then goes up normally [16:32:15] but why the downward dip on the 1st hour? [16:32:32] your QRTP plot doesn't have that? [16:32:39] the TLI Delta V chart 2nd opp doesnt not show such a dip [16:32:51] I would definitely expect a bit of a difference between QRTP and RTCC there [16:32:57] RTCC will use different masses [16:33:00] the default MPT ones [16:33:10] RTCC will also fully simulate through TLI [16:33:19] while in the QRTP it's only curve fits [16:33:29] they would do verification runs using a full simulation in the QRTP [16:34:01] https://www.dropbox.com/scl/fi/jrwka2gp6u32aagp80h58/DELTL2-vs-DVTLI2.png?rlkey=wgbt2ny61t2knnxrqgagnawjx&dl=0 [16:35:40] I'm not that worried about it, could be so many things. And only 10 ft/s difference. [16:37:54] oh one inconsistency, the QRTP doesn't output the time of MRS during TLI to the LVDC presettings right now [16:37:58] I should add that [16:38:33] technically wasn't part of the presettings [16:38:53] a general performance thing [16:39:06] probably would be the same for every launch day [16:39:11] at least with a specific Saturn V [16:41:18] I think the RTCC file gets it [16:41:31] in my scenario I have the Apollo 17 value still [16:41:37] as part of the non-targeting presettings [17:08:34] on orbit, predicted MCC-1, with TLI-2 on MPT, is 5.7 ft/s [17:08:43] I still like it [17:09:50] not bad [17:12:02] now a bunch of coasting [17:12:06] comparing TLI PAD [17:12:13] let's see what I get [17:20:37] morning! [17:24:10] hey Mike [17:24:28] hey [17:24:52] how goes trajectory design? [17:26:07] RTCC is happy [17:26:12] LVDC, not always yet [17:26:19] trying that for myself again [17:26:50] I added two documents to the NARA shopping list btw [17:27:50] nice :D [17:29:17] one document I know is 45 pages (plus however much is change 1) [17:29:45] the 1974 one... no idea. It's an all time favourite of mine, quoted in many other interesting documents. [17:30:18] hahahaha [17:30:58] sounds like a good document :D [17:32:23] I'm sure they both are [17:32:38] it's possible the 1974 one is missing [17:32:53] the finding aid says there are gaps [17:33:07] the other one Ron has scanned the front page, and the first page of Change 1 [17:33:11] so we know it's there [17:49:31] ok [17:49:35] good agreement on TB6 time [17:49:55] almost forgot I had the TLI switch in safe :D [17:52:43] haha [17:54:20] just a tiny bit of pitch and yaw at ignition [17:59:48] seemed like a good burn [18:00:41] still venting a bit haha [18:01:16] very close agreement on a MCC-1 with TLMCC option 1! [18:01:21] with the pre TLI prediction [18:05:24] now we have to figure out why that was not the case for you [18:05:47] ah interesting [18:06:34] could the late fixes to the tool last night be why the issue is gone? [18:06:54] hmm, one of them was RTCC TLI prediction only [18:07:05] the other one affected both, TB6 happening late [18:07:21] but I don't think that was the case for your launch azimuth [18:07:27] only for the very late ones [18:07:32] that had the 17000 ft/s [18:07:35] right [18:07:41] it seemed weird to me that you got a good option 4 (or 5?) [18:07:55] basically the same result as I have right now, just at MCC-2 time [18:08:06] maybe it was just a SFP disagreement [18:09:57] I do one to mention one thing, I am very lazy [18:11:12] so I didn't actually run through any checklists in my test, just let it run through prelaunch, fired up the CMC but thats it [18:11:42] the astronauts died shortly after insertion obviously [18:11:48] haha [18:11:57] but I didn't think for the purpose of this test it would matter [18:12:16] I just made sure the EDS was activated [18:12:41] but you had a valid CMC padload? [18:12:47] yes [18:12:54] I had generated one [18:13:10] I guess I need to check your post TLI scenario [18:13:19] standby [18:13:20] to see if it might just be a RTCC only issue [18:14:17] that would simplify things :D [18:14:24] LVDC issue could be more complicated [18:15:25] https://www.dropbox.com/scl/fi/42ao0t2bw2fbs53hu4e7u/Apollo-18-Post-TLI.scn?rlkey=01s7gr5ybidha0ce8jgxw55zk&dl=0 [18:17:23] ah you made it Apollo 18 [18:17:33] we use that for Skylab right now actually [18:17:39] Skylab 2 [18:17:46] not sure if that causes any problem [18:17:54] I just used Apollo 17 for my Tycho mission as well [18:17:58] no mission file changes [18:18:32] haha, yeah I bumped skylab up to 30 in my copy [18:19:28] maybe I should have used 19 [18:19:35] I need your SFP file as well, don't think you posted it yet [18:20:02] ... one of these days we can have non-numeric mission designations [18:20:08] I don't think we are far away from it [18:20:24] then Skylab 2 becomes SL-2, and we have no such naming issues [18:21:35] https://www.dropbox.com/scl/fi/2bw74w8wupf2te6rzxhxg/Apollo-18.zip?rlkey=hq2v5siwk6ljqwl4xpo8nu8wx&dl=0 [18:21:40] there, the whole package :D [18:22:57] ah you made an init file as well [18:26:01] uhh [18:26:10] never in my life have I seen such a broken scenario [18:26:25] you really didn't do many prelaunch steps :D [18:26:53] did I at least close the hatch? :D [18:27:19] it's closed [18:27:26] I just let the auto checklist run for these cases [18:28:16] would the lack of certain steps affected the weight of the spacecraft for TLI maybe? [18:28:33] hmm, probably not [18:28:39] what was your launch azimuth? [18:31:00] 88.3425 [18:31:28] hmm [18:31:43] I just remembered that the LVDC state vector uplink page has a way to update that [18:31:49] 1hr30 late [18:31:58] it says 105.397° [18:33:18] weird [18:33:58] LVDC in the scenario agrees [18:34:25] is this a different launch maybe? [18:35:02] ughh [18:35:05] let me check [18:35:13] maybe I gave you the wrong scenario [18:35:33] all the TLMCCs I am calculating are 240 ft/s btw :D [18:35:39] ohhh [18:35:54] thats the post-TLI scenario from the test I did a few days ago lol [18:35:56] is this the scenario where you had a fuel truck flying alongside [18:35:58] sorry [18:36:02] standby [18:36:28] haha [18:36:34] probably the 17k ft/s burn [18:37:41] https://www.dropbox.com/scl/fi/65asvxo8ga9bvgqsem391/Apollo-18-Launch-0004.scn?rlkey=dgii750htbz7zpqyu4ltjgyf8&dl=0 [18:37:44] yes [18:43:29] hmm, so, the flyby altitude of your current trajectory is actually very reasonable [18:43:35] 210 NM [18:43:45] it's just the timing of pericynthion that is off somewhere [18:43:47] LVDC or RTCC [18:45:52] if I simulate the TLI and MCC then it seems to give a good solution (option 1) [18:46:20] maybe it's a mismatch between SFP and QRTP [18:46:26] not using the same targets? [18:46:37] they would have been generated on different steps using the tool [18:46:59] it should all be from the same pass through the tool [18:47:01] I would like to see the LV targeting objectives file that was used [18:48:03] and GMT of pericynthion might need to be another plot of the QRTP :D [18:49:20] https://www.dropbox.com/scl/fi/dsjcrsqne78ajzzywjqqy/Tycho.zip?rlkey=jcpiozf5pz1uplh9u9t68slfd&dl=0 [18:49:25] thats the whole set [18:49:35] for the mission flown in that quicksave [18:51:23] ah sorry [18:51:38] actually that was the plan I made before the azimuth update [18:51:59] let me get you the correct one (flown with that quicksave) [18:53:34] ok [18:53:52] that same link should have the correct set now [18:54:02] its my latest one with the 5 azimuths defined [19:06:25] hmm [19:06:44] can't see anything wrong yet [19:07:11] Im flying it again [19:07:25] this time with auto checklist [19:12:11] I still have more things I can check [19:13:47] using your LV objectives, I am getting consistently 80.6h GMT for pericynthion [19:13:53] of the converged QRTP solutions [19:14:12] SFP has the same, so that looks correct [19:15:03] hmm [19:15:14] I see a pretty bad LVDC state vector in your scenario [19:15:31] bad enough to potentially be responsible [19:15:36] oh [19:15:59] when I quicksave, FPS drops very low sometimes [19:16:02] they tend to be bad after TLI, but, this one is over 200km off [19:16:16] clean up your saves folder, that makes quicksaves fast :D [19:16:24] store your old saves somewhere else [19:16:28] not just quicksaves, all saves [19:16:30] yeah [19:16:48] no idea if that is related [19:16:57] but a frame drop at a bad moment [19:17:03] or excessive time acceleration [19:17:19] I used 10x [19:17:22] in orbit [19:17:26] prelaunch 100x [19:17:44] hmm ok [19:17:45] oh but I used 10x also during boost [19:18:01] I know the auto checklist has issues with 60x and more [19:18:10] I think the RSI alignment or so [19:18:21] well on my run right now I am doing max 30x prelaunch [19:18:33] the 100x was when I was lazy and used no checklists :D [19:19:13] in doubt, uplink a new IU state vector [19:19:19] I actually did that on this run [19:19:30] to make sure that isn't causing any additional trajectory issues [19:19:34] but I didn't really have to [19:19:47] I'm in the venting branch, using Apollo 17 LVDC venting numbers [19:20:00] by Apollo 15 or 16 they finally understood what numbers they had to use [19:20:25] all the time before the difference in venting caused the largest part of LVDC state vector inaccuracies, by far [19:20:36] right before TB6 ill check the IU accuracy [19:20:43] and uplink one if needed [19:20:48] I think I had a 4km downrange error before the uplink [19:21:02] better then 200km! [19:21:05] a lot more is allowed before they would do an uplink [19:21:13] the 200 km is 1000 seconds after TLI cutoff [19:21:15] but still [19:21:20] that is much more than usual I think [19:22:00] LVDC is still writing the accuracy in the lvlog [19:22:10] but it would also be available with the vector comparison display [19:24:54] maybe it was the 10x during boost [19:25:02] that's something I very rarely do [19:25:19] and I know that something in our IU navigation still is less accurate than it should be [19:25:27] maybe it's a timestep thing, made worse by 10x [19:25:30] potentially [19:34:46] flying launch right now [19:35:19] 88.3425 azimuth and Ill fly TLI-2 [19:35:48] once I get in orbit, ill take a look at the lvlog [19:43:28] SV Accuracy: 158.839408 -6.168700 150.902701 [19:43:43] at insertion [19:45:02] damn [19:45:23] my quicksave folder is empty and it still drops to 10 fps when saving [19:47:49] I often go to 0.1x for saving [19:47:54] I need to clean it up, too [19:47:58] then I won't have to [19:48:06] that SV accuracy after insertion is fine actually [19:48:15] that's in meters :D [19:50:23] hmm [19:50:34] is the MPT needed to calculate TLI PAD? [19:50:47] no [19:50:59] valid RTCC file is needed [19:51:04] its just giving all zeros [19:51:54] RTCC file is loaded, launch day and time and all set? [19:52:08] ah [19:52:13] that was it [19:52:57] RTCC files (except init file) can be loaded individually now [19:53:07] so I didn't even put anything in the scenario for it [19:53:13] just loaded it as it was for Apollo 17 [19:53:19] changed the files and launch day etc. [19:53:20] all in-sim [20:02:27] btw, LVDC_XLunarAttitude and LVDC_XLunarSlingshotAttitude [20:02:36] are those always the same? [20:04:43] nope [20:04:54] slingshot for the later missions is the LOX dump attitude [20:05:04] LVDC_XLunarAttitude is TD&E [20:05:08] that is based on lighting [20:05:26] I think I have read a bit of the logic behind that [20:05:32] but I don't have a calculation for it [20:10:50] so, with the current value set for LVDC_XLunarAttitude [20:11:13] will the TLI PAD sep and extraction angles be valid? [20:11:30] even though the lighting might not be correct [20:13:55] yep, that it pulls from the LVDC [20:14:16] it only gets two things from the LVDC anymore [20:14:23] 1st vs. 2nd opportunity [20:14:29] although that should probably be an input button [20:14:41] and it gets lvdc->XLunarAttitude [20:14:56] ah ok [20:26:15] alright [20:26:20] 5 minutes before TB6 [20:27:33] indy91, -4235.066642 219.737357 -28.739002 [20:27:40] SV Accuracy [20:27:42] that is perfectly fine [20:27:52] save :D [20:27:55] ok [20:27:57] yep [20:28:02] we might want to debug with this scenario [20:28:16] would you like it now? [20:28:18] how close the TB6 time prediction is, that's the first indication [20:28:35] I have nothing to check yet really [20:28:40] PAD says 4:50:45 [20:28:57] annd [20:29:28] bang on to the second [20:41:10] alright cutoff [20:41:18] 10 fps on the EMS [20:41:23] -10* [20:42:05] 33 seconds into TB7, SV Accuracy: -4366.422096 -209.875319 263.754216 [20:43:42] DV MCC-1 is...... [20:43:48] 3.8 ft/s!!!! [20:43:51] :D [20:43:58] option 1 [20:44:16] at 10 hours [20:44:54] at 30 hours it climbs to 6.7 ft/s [20:45:15] that's what I like to hear :D [20:45:31] I'm starting to gain some confidence in the QRTP :D [20:45:59] yep me too :D [20:46:15] just have to polish my padloads and I think ill fly this mission [20:47:16] so what is left to do before I could really make it public... [20:47:28] I think the output files need a bit of a better system [20:47:39] maybe with naming [20:49:02] the LVDC scenario editing is a bit annoying still [20:49:19] I need to fix free return on the mission planning page [20:49:22] and of course [20:49:24] a manual [20:49:54] dummy file for the plot folder [20:50:05] so that I have the folder in git [21:06:59] oh man you already have QRTP working? that was fast :D [21:07:28] to be honest, there are only a few things I actually could use so far from the actual documentation [21:07:45] one of the major things I implemented from it wasn't working and I reverted it... [21:09:12] but yes, it can generate good presettings now [21:09:37] many things still to improve of course [21:09:47] very nice! [21:10:23] hello [21:10:33] thanks to Alex' insistence to launch at weird azimuths and using the 2nd TLI opportunity, we found a lot of bugs [21:10:36] hey Matt [21:16:53] AlexB_88, what sort of user friendliness updates would you like to see [21:17:12] on the last page of it, should it output a RTCC init file? [21:17:34] maybe could even be on the mission planning page [21:17:45] for now it would only output a landing site [21:18:25] my next test is launch azimuth 270.0 :D [21:18:28] kidding [21:19:02] indy91, yeah maybe that would be a good idea to output a RTCC init file [21:19:52] also I think you mentioned of the possibility of having a field to input the desired PC GMT, then it would automatically adjust the TLC time? [21:19:54] yeah good luck with the performance margins if you launch in the opposite direction of Earth rotation :D [21:20:00] hehe [21:20:28] yeah constant PC GMT could be added [21:21:04] I already like the general feel of the tool and the GUI as it is [21:22:04] what was important to me is to separate tasks done by MSC vs. MSFC [21:22:23] so you can always load up a LV targeting objectives file as the first step when doing something with the tool [21:22:45] because that is what MSC sends to MSFC [21:23:15] by air mail [21:23:35] in IBM card form [21:27:43] googling names from Apollo memos is so depressing [21:27:57] most of what you find is obituaries [21:28:08] recent ones often [21:28:51] yeah I bet [21:29:08] at least the previous owner of the QRTP documentation is still alive [21:29:17] just donated his collection of documents [21:52:55] night! [13:55:21] n7275, I see your new vent pipe class. Don't call a destructor of a base class directly. Both in h_ExteriorEnviormnent and h_ExteriorVentPipe. The destructor is called automatically if the base class has a virtual destructor. [14:14:01] oh whoops. I did not know that. [14:14:43] what I get confused by is how it works with derived classes of derived classes :D [14:14:54] if every class in between needs a virtual destructor [14:15:06] the pipe class currently seems to not have a destructor at all [14:15:37] in doubt one can always put an oapiWriteLog in the destructor to test if it gets called [14:15:49] c++ things [14:17:19] I think I like the new concept [14:17:37] Tank -> Valve -> Venting Pipe -> Valve -> External Environment [14:17:44] Venting Pipe has thruster [14:18:06] not sure which of the two valves we should usually set on/off [14:18:17] the second valve belongs to the external environment [14:18:22] probably needs to always be open [14:18:28] so it's the first valve we switch on/off [14:22:20] yeah, so it would be the valve on the "in" end of the pipe that gets opened and closed [14:22:43] and its size determines how much venting can happen [14:26:35] yes. [14:28:12] I need to look into thrust level a bit more closly [14:28:38] it looks like it's been commented out for a while in our vent class [14:29:37] now that it is in a pipe class it can make use of the current flow [14:30:11] but I think it's not a high priority yet to get that to work [14:30:22] agreed [14:30:34] more important to rig this up and remove the old vent class [14:30:50] but maybe in a separate PR [14:39:41] I think that makes the most sense [14:48:22] hey [14:51:32] hey Alex [14:52:17] RTCC init file is now written [14:52:29] just the landing site coordinates and the TLAND for 72° launch, 1st TLI [14:55:18] ah nice [14:55:35] now I am thinking about non-targeting presettings [14:55:46] just flew another launch last night (not a test) and flying to a landing at Tycho [14:55:46] so that scenario creation is a bit easier [14:56:02] launch and TLI went beautifully [14:56:06] well [14:56:26] my IU state vector was 10 KM off right before TLI [14:56:31] make sure to make everyone on Discord jealous once you land :D [14:56:43] 1st TLI opportunity? [14:56:47] might not be too high but I did an IU SV update anyway [14:56:52] hahaha [14:57:03] 4 hours late 2nd opportunity [14:57:08] oh ok [14:57:14] sounds like a test then :D [14:57:27] I think it's not unusual for 2nd opportunity [14:57:39] yeah I probably should have done on-time and 1st opportunity [14:57:51] but I felt the urge to do a liftoff time update :D [14:58:14] we can replicate the exact process of determining if a IU navigation update has to be done or not [14:58:25] although, I'm not sure if there are additional checks for a 2nd TLI [15:04:23] whats the limit threshold for doing a IU nav update? [15:05:06] whats the threshold* [15:06:44] ah it does mention the second TLI opportunity [15:06:51] just the check is the same apparently [15:06:57] so, Apollo 17 mission rules [15:07:40] https://i.imgur.com/uvflxFE.png [15:08:54] ah [15:09:13] so I was right on the limit [15:10:32] and all of these numbers can be checked with the vector comparison display [15:10:42] at what GET did you check your IU error? [15:11:13] the downrange error always increases [15:11:24] if you had 10km error just before TLI then I really doubt you were close to the limit [15:11:43] 10km already at 56min GET would be close [15:12:05] at 1h45m it already allows 56,000 ft [15:12:20] and your check was probably even much later [15:13:53] the check on semi-major axis ensures that the error doesn't become much larger later [15:15:31] how about I add a file with non-targeting presettings. Which in the future can be edited through the tool as well. But for now it would just stich together the target and non-targeting presettings [15:15:44] so that you can copy the LVDC numbers in one go to a scenario [15:17:58] I was looking at 56 MIN but forgot is was TLI-2, so yeah nowhere near the limit [15:18:47] ah yes that sounds good [15:18:53] you would use these GETs as the comparison time on the display [15:19:26] oh btw, shouldn't there be an option for the launch pad? [15:19:42] ah yes, problem [15:19:55] I'm using the same launch polynomial as the RTCC [15:20:04] so it doesn't matter what launchpad coordinates you would have [15:20:17] the resulting EOI state vector would be the same for now [15:20:29] ah right [15:20:39] I don't think I have the RTCC EOI processor numbers for Apollo 10 [15:21:05] so basically just LC-39A support for now [15:21:21] ok [15:21:30] maybe I can tweak the numbers for LC-39B [15:21:42] it's definitely on my list of features to add [15:23:11] oh wait, I do have the RTCC Requirements for Mission F and G [15:23:44] maybe in the RTCC they would just use the same set of numbers [15:24:21] technically the orbital plane is the same for any launchpad, but the coordinate system depends on the launchpad longitude [15:24:56] so it's not actually the same [15:25:21] I can at least add support soon with input boxes and such for launchpad [15:28:52] we do not have the real process for this yet [15:29:08] the very step of a LV targeting would be to generate non-targeting presettings [15:29:17] simulate launches for different launch azimuth with that [15:29:25] no TLI, just Earth orbit [15:29:31] that goes into an EPO state tape [15:29:36] which gets sent to MSC [15:30:13] and then instead of simulating launches they take Earth orbit state vectors from the tape [15:30:22] we will use this process eventually too [15:30:36] but first I need to implement the launch vehicle simulation for launch [15:31:07] and the data on this tape would be a bit different betwee LC-39A and B [15:32:47] The init page would contain everything to set up these launch (and EPO coast) simulations [15:33:02] right [15:33:06] but I would already have an EPO state tape file for the typical launch azimuths [15:33:40] and then these azimuths are the only ones available on the mission planning page [15:40:19] btw, question about the padload generator [15:40:59] it automatically generates the lunar and solar ephemerides? [15:42:44] yeah [15:42:49] based on a few inputs [15:42:52] launch MJD etc. [15:43:05] right [15:43:22] padloads are so easy these days [15:44:42] I started the padload generator because I was tired of all the manual steps involved [15:44:47] especially for new ropes [15:45:15] I actually started the project for Comanche 67 which we still don't have :D [15:45:44] I remember a time when padloads were so elusive, requiring days of sifting through excel files and reading complicated procedures on the old meadville forums on how to create the lunar/solar ephemerides :D [15:46:27] but yeah the padload generator is great! [15:53:25] people have been visiting different landing sites with the help of the padload generator [15:53:40] for now it just had to be sites that are close in longitude to one of the actual misisons [15:53:48] so that they could use that for launch from Earth [15:54:39] btw once the tool ("ATDP"...is that the correct general acronym?) is advanced enough we should probably generate full presttings for all the missions that don't have them yet [15:54:55] and SFPs [15:57:10] the only problem with that is if we don't get exactly the same launch times [15:57:19] we will have to see how close we get [15:57:53] the real ATDP was a TRW program which is probably only equivalent to our first guess logic page [15:58:04] but I just kep that name :D [15:58:09] at first I started a QRTP project only [15:58:29] but quickly realized it needed a lot of input data supplied by MSC [16:00:43] right [16:00:55] so ATDP it is then :D [16:01:28] the term is general enough haha [16:08:30] oh and I fixed my frame rate dropping when quicksaving [16:09:11] turns out I needed to not only empty my quicksaves folder, but all of the scenarios that I had been piling outside of it (in the scenarios folder) [16:10:38] yes [16:10:41] that's what I said :D [16:13:13] ah [16:13:17] right you did :D [16:13:46] it's some annoying Orbiter code searching through all the save files [16:14:00] to make the filename unique I guess [16:14:15] doesn't make much sense to search through anything but the quicksaves though [16:26:23] ok, the procedure with the non-targeting presettings works [16:27:04] not the ideal solution yet, but, better than having to go through everything manually in the scenario file [16:27:22] ah damn, it needs the flight sequence program file... [16:30:01] so on my list of things to do, which really need to be done before a real release, is just fixing free return for mission planning and a manual [16:58:59] right [16:59:05] coming up on MCC-2 [17:01:42] that's fast [17:08:18] option 4 or 5? [17:08:58] 4 [17:09:05] 12 ft/s [17:09:43] if you go for a CSM DOI you will definitely arrive at the landing site early [17:09:50] I hope you didn't cut it close on lighting :D [17:14:53] did you generate a LGC terrain model? [17:21:26] I simulated the mission up to landing the MPT, doing a CSM DOI [17:21:39] also figured out a REVS1 [17:22:01] and took the TLAND from the results for the init files etc [17:22:22] I think it was an hour or so off from the ATDP flight plan [17:22:36] but it matches perfectly the Apollo 15 profile [17:23:02] the main reason was so I can basically use Apollo 15's flight data file [17:23:18] and yes I made a terrain model [17:23:21] model* [17:24:30] you know about the Excel file we have for the terrain model? Makes it easier, don't have to do any of the conversions manually. [17:24:45] https://www.dropbox.com/scl/fi/bc5aw20b2r0wodygh6h0q/Screenshot-2023-12-05-19.37.27-Copy.png?rlkey=3c5yhlqaqpso2s80mjy81e5f8&dl=0 [17:25:00] yeah its great [17:25:39] holy elevation change [17:25:46] and yes im landing IN the crater :D [17:26:29] probably a good idea to not enable the LR before that huge gap [17:27:07] and I hope the reference trajectory doesn't want to take you through the mountains :D [17:31:04] ah what can go wrong :D [17:32:57] sadly I have had a hard time calculating the exact reference trajectory [17:33:14] don't know why, I put it in a script but something annoying must be wrong haha [17:33:34] whats reference trajectory? [17:34:27] the trajectory (padloaded) that P63 and P64 want to follow [17:34:42] you can, in theory, calculate the exact nominal trajectory from the padloads [17:35:04] and it shouldn't be that difficult even, maybe I had a wrong scale factor or something [17:35:12] btw on the ATDP plan, the landing was at 105.46 hrs, with a 15.7 sun elev [17:35:56] and my CSM DOI will cause the landing to be at 104.7 hrs [17:36:31] ah that's perfectly fine [17:36:58] you do need a high angle or otherwise you see nothing, due to the mountains [17:37:16] yeah [17:37:29] rough estimate is 10° for that [17:37:35] from your graph [17:38:22] 1 hour earlier would be 0.5° [17:38:44] ok, found Apollo 14 trajectory parameters [17:38:57] which might still be less steep than the 15+ descent padloads [17:39:26] critical range is at 30km [17:39:28] for the clearance [17:41:20] looking at the Apollo 14 numbers I would estimate you are 5.8km above the landing site at 30km range [17:41:38] that works [17:41:41] landing in Tycho should be pretty spectacular [17:41:43] but close :D [17:42:44] yeah [17:43:04] you aren't visiting any Surveyor on this mission, so much is clear [17:43:21] there is one close by, but not inside the crater [17:43:42] that was one thing they were thinking about with landing site selection [17:44:14] Surveyor, but also visiting the rim of the crater. But if you want to do both you need the LRV, which might be difficult given the difficult to reach site [17:44:44] I can only imagine the view they would have visiting the rim [17:59:58] I didn't do an EVA back then, but, I got pretty close to it [18:12:03] I am actually using MCC for this mission, which I based from my Apollo 17 MCC branch [18:12:09] very watered down though [18:12:16] no abort pads [18:12:22] just the nominal burns [18:13:34] haha [18:13:36] basically only nominal uplinks and burns, so no landmark tracking pads or custom stuff they got (photo pads etc) [18:13:52] "just flew another launch last night (not a test) and flying to a landing at Tycho" [18:13:56] not a test :D [18:15:21] well I meant not another test-run of the presettings :D [18:15:31] for everything else, yeah very much a test [18:15:37] right, right [12:32:10] waaaaaaait [12:32:29] n7275, https://i.imgur.com/zfzHNQi.png [12:32:32] did you know about this? [12:51:05] :o [12:51:16] ...I did not [12:52:07] then let me give you the exact AGC revision numbers for that [12:52:28] Luminary 106 [12:53:50] don't know exactly, but for the CMC the change was also from Apollo 11 to 12 [12:55:18] and I can confirm that from the padload documents [12:55:31] and CMC vs LGC also have different scalings for those padloads anyway [12:55:41] but this PCR was the same for both [12:55:53] 1/4 of former values [12:57:30] I should be able to load those from the mission file, so it should be an interesting test. [13:09:29] I will make a note for the padload generator as well, when that gets supported :D [13:35:31] might be useful to you as well, I am implementing a little display in the RTCC MFD to show the current IMU missalignment. [13:35:34] relative to the actual world [13:36:27] I must have had an inflated opinion about my coordinate conversion skills, because I thought I would get it working on the first try. And now, after the second, I am letting it output all the matrices in the Orbiter log and try to get it working in a MATLAB script :D [14:40:20] I'm just hoping that the LM imu drift is as simple as loading drift rates with mu existing code [14:40:55] s/mu/my [14:41:05] hahaha [14:41:09] nice job Guenter [14:41:24] lol [14:43:58] ok, got the misalignment calculation working [14:44:04] now also for the LM [14:44:27] was about 0.01° if I combined the axes in the CSM [14:44:35] in our Apollo 11 MCC-2 scenario [14:44:44] I think that tracks with an average P52 [14:45:34] not working yet for the LM :D [14:47:58] I thought it was easier for the LM, as the axes in Orbiter only disagree in one way [14:48:01] apparently not [15:00:47] do you want more precision than V42 angles for the IMU misalignment display? [15:01:10] it uses the REFSMMAT in the calculation, so at some point you don't get actual IMU precision, but run into AGC double precision limitations [15:03:57] angles are already jumping around, can only mean the REFSMMAT isn't a perfect rotation matrix. Hmm... [15:12:03] I think as long as it's not rapidly diverging over time, it should be okay [15:13:46] the testing I had done so far indicated that the AGC was capable of keeping all axes below 0.1 meru [15:13:59] it's just jumping around a bit. At less than V42 level, maybe in 0.001°. I think our V42 calculations have shown the same. [15:14:17] could also be a timestep mismatch [15:14:21] but my rates were low [15:15:29] I am pretty confident that the REFSMMAT downlink function is exact to the bit [15:15:38] not quite as confident in uplink... [15:16:00] there could be e.g. 1 bit off for negative numbers, or something like that [15:16:14] have never done a full test on that really [15:19:51] still jumping around with a RTCC calculated REFSMMAT, instead of downlink [15:20:21] not anymore if the attitude rate is exactly zero [15:20:27] well [15:20:30] obviously haha [15:21:05] but at a different attitude, also zero rates, the misalignment is the same [15:21:14] so my conclusion, just a small timestep difference [15:21:28] between IMU updating and actual attitude in the simulation having been updated [15:21:56] nothing to worry about [16:38:00] good morning [16:38:34] hey Alex [16:56:32] lol [16:57:24] I try to download the latest ATDP but it says "Couldn't download - Virus detected" [16:57:32] but I somehow doubt that [16:58:49] did I even update anything? :D [16:59:03] all I did was readme changes really [16:59:25] maybe the non-targeting parameters file [17:03:24] ah [17:03:59] I think I narrowed it down to the "ApolloTrajectoryDesignProgram.exe [17:04:01] " in the commit "Also include the FSP file in the non-targeting presettings" [17:04:17] I can download all the other individual files except that one [17:04:26] but I wonder if the issue is only on my end [17:05:14] because people on the discord seem to be bale to download it just fine [17:06:55] how are you downloading? [17:08:18] using Edge's regular download interface, downloading the zip file generated by git [17:17:01] I didn't do anything else than usual with the exe file [17:17:06] for that specific commit [17:27:15] weird [17:38:56] morning! [17:42:06] hey Mike [17:43:50] hey Doctor Diode [18:31:20] I am sad that I have earned this title :D [18:35:48] but earned you have it nevertheless :D [18:47:37] n7275, what do you think. Should I make add another friend class to the IMU or should I make the IMU::GetTotalAttitude function virtual so that the RTCC MFD is allowed to access it [18:47:54] right now the IMU has [18:47:57] // Allow the MFD to touch our privates [18:48:01] friend class ProjectApolloMFD; [18:48:03] // And the RTCC as well [18:48:04] friend class RTCC; [18:48:06] but I am adding it in RTCC MFD only code [18:48:09] so not RTCC class [18:48:16] doesn't really belong in it [18:48:51] other than this decision, this little debug MFD display is ready. Not much to test, it won't affect any other part of anything [19:00:07] I would go the virtual route [19:00:36] will do [19:16:16] indy91, my PC says ApolloTrajectoryDesignProgram.exe is infected with the "Trojan:Win32/Wacatac.B!ml" Ive did a bit of research on it and it seems it can be often a false positive with some user-made apps [19:16:43] ah damn, it caught me :D [19:16:51] maybe its just my windows defender that can see it [19:17:04] it's so weird that only this last build of it is the problem [19:17:08] I used VS2022 to build [19:17:12] in doubt [19:17:18] make your own exe :D [19:17:24] Ill try [19:35:23] and I really didn't change anything in the way I build [19:35:38] since your last download, probably just added the non-targeting parameters file [19:35:41] and loading for it [19:45:23] yeah its weird [19:45:51] anyway I built the file myself and it works [19:47:09] now you created your own Trojan instead of "relying" on mine [20:00:49] do you guys need me to make my "Uninstalling Windows" to remove malicious software, joke? [20:15:31] I'm thinking that every time there was a bigger Windows update and after rebooting I have to click through all the things I don't want it to do... [21:08:11] night! [15:11:37] hey [15:12:18] hey Niklas [15:13:38] I was thinking of another value that could be added to the ATDP generated RTCC init file [15:13:41] LOI_psi_DS [15:14:20] ah true [15:14:22] I'll add that [15:15:13] I forgot it once and couldn't figure out why my LOI DV was like 4000 ft/s :D [15:16:37] haha [15:16:41] yeah that is easily added [15:17:38] I've already undocked on my Tycho mission [15:17:47] now up to the PDI-O pad [15:18:52] fun [15:21:10] you should clear the mountains [15:21:15] but it might be slightly exciting [15:21:22] not much worse than Apollo 15 I think [15:24:45] yeah [15:25:06] the Apollo 17 profile may of been more appropriate [15:25:28] I don't know if that would help a lot [15:25:49] you would be higher at PDI, but, by the time you get to the rim it should be pretty normal [15:26:00] right [15:26:09] in fact, the descent guidance reference trajectory is the same on 15-17 [15:26:20] ah [15:26:31] so at least by the time of the P63/P64 transition you would be roughly in the same place [15:26:34] relative to the landing site [15:26:36] altitude and downrange [15:27:30] approach azimuth added [15:27:37] oh [15:27:39] or not [15:27:52] I don't have the readme edit merged yet [15:28:52] now it's up [15:29:38] nice [15:29:44] btw, no virus :D [15:30:06] good... that you believe that [15:31:59] the Trojan ATDP [15:39:17] of course Residuals and MaxQ immediately used J-type mission LM weight and an absurdly long lunar stay times [15:39:37] pushing the mission to its (Delta V) limit :D [15:40:32] I'm not going to implement three burn LOI and TEI mission planning when we don't even have that in the RTCC yet [15:43:26] haha [15:44:23] actually im flying a J mission LM, but my TEI is like at 135 hours [15:45:22] yeah, both the LM weight and long lunar stay times are problematic [15:45:29] long lunar stay because of the LOPC [15:45:54] I wonder if doing multiple LOPCs is more efficient [15:46:01] probably not [16:42:22] n7275, ok the worst thing about your PR: environment is spelled consistently wrong. And I see you are loading an external environment by default for each H_system. I'll check a bit if that works fine. But then with the typos fixed I say we merge it. [16:46:55] oooh there is a problem with that [16:47:37] we have in some cases now more than one HYDRAULIC or one ELECTRIC section in the systems config [16:47:52] because of inter dependencies [16:48:12] every time we do a [16:48:14] [16:48:20] it would build a new external environment [16:49:09] yeah in the LM we have two sections [16:49:31] first, the electric and then again for stuff that depends on electric system already being defined [16:49:36] then electric* [16:51:25] maybe the external environment should just be defined in the config file [17:58:02] hello [17:58:30] how did I manage to spell that wrong lol [17:59:03] I'll look into the two-hydraulic section issue tonight [18:00:13] hey Matt [18:00:19] you typed it wrong once [18:00:27] and then everything else was copy and paste :D [18:02:30] maybe if a check if there is already an object of that name would be enough [18:02:33] maybe a* [18:02:46] then it doesn't have to be put in the config [19:38:23] I think that's what I'll do. [20:00:10] could search for the name, if there is already one defined. Or, because it is basically an important part of h_system now, h_system just has an Init bool for it [20:00:16] if (Init == false) [20:00:23] { [20:00:28] CreateExternalEnvironment(); [20:00:32] Init = true [20:00:34] } [20:00:39] like that basically [20:00:44] just an idea [20:20:31] yeah, I like that [20:27:23] I get nervous when the number of our open pull requests exceeds 10 :D [20:27:27] yours is next [20:28:10] just switched to my failure overhaul branch. We still have open a very old PR for failures by abr35, that could then be closed, too. My update covers a few things in that PR. [20:42:22] is there a way to check the time tag of an SV through the DSKY? [20:44:29] of a state vector current being integrated, V16 N38 [20:44:33] currently* [20:44:46] a time tag in general, use the RTCC MFD, vector panel summary. Will show the GMT of the time tag. [20:48:01] thanks [20:52:01] did you get an integration to 0 or infinity? [21:13:03] actually, I put in a bad time by accident though an MCC thread [21:13:33] so yeah it wasn't showing anything good on the 16 38 [21:14:23] https://www.dropbox.com/scl/fi/jmthhr6ims2t8ce2hseyd/Screenshot-2023-12-11-16.12.04.png?rlkey=7oa6w5kovw24bms2dza5plvpf&dl=0 [21:14:33] last pass before landing [21:16:23] that's a lot different lighting than I would have though [21:16:30] thought [21:17:01] is the sun approximately at the right angle? [21:17:12] as on the ATDP? [21:18:03] https://www.dropbox.com/scl/fi/cgc3oaahqdte3r3wkaa4d/Screenshot-2023-12-11-16.17.28.png?rlkey=jo72728sb1xqic3b4739a58fr&dl=0 [21:18:14] if that gives an idea [21:18:24] I think the ATDP gave 15 degrees [21:18:27] yeah [21:18:38] that's the current date and time? [21:19:38] what's* [21:20:00] Jan 14 1973 08:52:11 [21:20:51] yeah my tool says 15° [21:21:16] surely it doesn't get something so basic wrong haha [21:21:58] I wonder if the very high inclination gives an illusion [21:23:10] and 15° is also higher than average [21:23:15] not like Apollo 11 [21:23:19] which had a lot lower [21:23:56] alright 1st pass through P63 [21:24:17] indy91, your padload generator's now in the spotlight :D [21:24:44] only one 1406 alarm per day please :D [21:24:51] well, I guess also the accuracy of my TLAND uplink [21:25:01] haha [21:26:59] I put a DG at your coordinates and current time [21:27:07] and let it display the HUD [21:27:10] it agrees with the elevation angle :D [21:30:16] nice [21:30:19] and P63 is happy [21:31:33] great [21:51:02] night! [22:41:53] AlexB_88 those acreenshots look epic [22:44:01] thanks! just added a few more on Discord [15:14:24] hey [15:16:01] hey [15:16:19] https://github.com/orbiternassp/NASSP/pull/1119/files [15:16:27] CTRL+F with ENVIORNMENT [15:16:32] not quite done yet :D [15:36:34] ok, that solved all the ENVIORNMENT in code [15:37:01] one left in a debug string, two in the description of h_ExteriorEnvironment in Hsystems.h [15:37:12] but I don't care too much about that [15:51:42] one sec, trying to fix them through the web interface [15:52:24] then I will merge the PR. We can always improve things in the process of getting rid of the vents. [15:54:02] that should be all of them [15:54:07] *should* [15:54:21] "ENVIORNMENT 0/0" [15:54:25] yes :D [15:54:39] ah [15:54:41] uhm [15:54:47] uh oh [15:55:06] https://github.com/orbiternassp/NASSP/pull/1119/files [15:55:13] CTRL + F [15:55:14] ENVIOR [15:55:17] sorry :D [15:55:37] of course I am not going to make you fix the branch name which also has the typo lol [15:55:52] but there are more sadly [15:55:54] including [15:55:55] ExteriorEnviormnentCreated [15:57:24] if you are only fixing these through the web interface I will also do a build test before merging. But I don't think anything else will need testing. [15:57:58] actually, if it's inconvenient for you to fix things right now, I think I am able to force fixes into your branch [15:58:41] Would you mind? I don't have a lot of condfidence that I would break something [15:58:48] will do [15:59:13] I could do it over ssh, but every time I do that I worry about CRLF stuff... [15:59:31] thank you [15:59:40] it's a fun way to circumvent our merging model. One person just creates a branch and PR, then I could do everything I want in that branch AND also approve it myself. :D [16:00:06] only works for the repo maintainers of course [16:00:56] At least we require revewers, the Orbiter repo scares me [16:17:04] hey [16:30:20] hey Alex [16:30:26] n7275, feels wrong pushing to your repo :D [16:31:14] had a good landing at Tycho [16:31:36] awesome [16:32:33] there is one more thing I want to check in this exterior environment branch, I see something potentially bad... [16:32:41] in the future, I'll try to add new objects only if I can spell them, I feel like that should be a requirement haha [16:32:44] oh? [16:33:07] need to check in debug mode [16:33:30] could be a "bad in a funny way" sort of bug :D [16:34:50] indy91, think I found a small bug in the ATDP [16:34:55] very easy to reproduce [16:35:11] is it the launch day becoming negative? :D [16:36:24] on 1st guess tab, put in this launch day: August 26, 1971 hour 23 [16:36:35] then save and reload the project [16:36:44] should get an error [16:36:51] ah saving/loading issue [16:36:58] ah sorry, lighting tab* [16:37:05] I had seen one but couldn't reproduce it [16:37:44] the bug I saw was, from lighting tab to first guess tab it only subtracts the days [16:37:55] so if you have e.g. the 1st of a month [16:38:04] for landing day [16:38:15] then on the first guess tab, for launch day, it just is the same month with a negative day [16:39:03] your bug might be related to some text box that is empty [16:39:18] something doesn't like it, need to figure out what [16:40:20] n7275, ok the potential bug I saw was in h_ExteriorVentPipe [16:40:30] but we currently have no h_ExteriorVentPipe, so it doesn't happen yet [16:40:48] that class has a constructor with nothing in it [16:40:58] I don't think anything set "Num_Vents" to zero then [16:41:16] so as soon as we would have a pipe of that type, the class would create a random amount of thrusters :D [16:41:48] I'll fix it [16:55:07] done [16:55:13] and approved my own fixes [16:55:28] and merged [17:09:42] indy91, https://www.dropbox.com/scl/fi/57ajs4r2yaasiovp961pn/Screenshot-2023-12-12-12.09.10.png?rlkey=rsfnvh515d6ooegos59x2ovz2&dl=0 [17:09:51] thats how close it got to the rim [17:30:11] pretty close [17:30:19] not much worse than Apollo 15 I would say [17:33:42] just have to have tighter LR vs PGNS disagreement rules [17:36:02] morning! [17:52:05] indy91, ahh good catch. Thanks. [18:01:22] hey Mike [18:03:33] sad news from Sunspot -- P22, P23, P41, and P42 are all in the missing module B23 [18:03:44] ah annoying :( [18:03:52] yeah :( [18:05:43] P42 would be "Return to Earth"? [18:06:29] yep [18:06:38] whatever that has different [18:08:14] from some GSOPs it seems they had different programs planned that mainly differed if and how Lambert aimpoint guidance would be used [18:24:14] AlexB_88, there is basically a strange sort of memory corruption happening. The loading code then tries to apply 0 to the opportunity number, which is illegal and crashes [18:24:27] I thought I was doing a fancy thing with this kind of saving file [18:24:37] but maybe I just do things I don't properly understand [18:26:42] hahaha [19:02:08] I did think that file was pretty fancy when I tried opening the .sav file with notepad :D [19:02:20] thought I could just edit things outside the app [19:03:41] haha [19:03:57] I wanted to have a file format that doesn't take a lot of work to expand [19:04:24] if I do what we do for scenario saving/loading it's slow and more work to expand [19:06:49] so it's basically a save/load the entirety of a data struct [19:07:32] I think I solved it [19:07:44] I had to explicitely open the file in binary mode and not text reading mode [19:08:13] when loading [19:10:18] right [19:10:30] fix push, would be nice if you could test it [19:10:57] if your Windows Defender lets you [19:15:53] sure [19:19:45] works [19:20:33] great [15:29:37] hey [15:31:33] hey Alex [15:35:54] flying a new mission [15:36:35] this time to Censorinus [15:39:55] beating MaxQ to it? :D [15:40:07] or was it Residuals who wanted to land there... [15:54:11] ah right [15:55:07] maybe I won't spoil it for them and not post a bunch up pictures :D [15:55:28] well on here I can I guess [17:08:05] morning! [17:29:18] hey Mike [18:11:02] hey guys [18:19:07] yo [18:19:40] hey [18:19:58] indy91, my pericynthion is 95 NM [18:20:18] after TLI? [18:20:20] in order to do a CSM DOI for Censorinus :D [18:20:24] oh [18:20:27] uhh [18:20:31] interesting :D [18:22:12] this is the pre-flight simulation run from the pad: https://www.dropbox.com/scl/fi/8uyqvb91igsximsli3x3y/Screenshot-2023-12-12-01.32.07.png?rlkey=k42i0k4pzhxgfh1b0mbpweel0&dl=0 [18:22:44] I guess that REVS1 of 1.8 is really what makes the pericynthion so high [18:23:02] but the landing site is way east so it needed a but of a rotation I think [18:23:36] 32°E? [18:24:14] yeah [18:24:21] well, a bit east [18:27:34] similar to Apollo 17 [18:30:49] but they had a very different perilune location at PDI [18:30:55] 25° different than normal [18:31:17] would probably make sense to set everything up like 17 [18:31:53] SITEROT +10° instead of -15° [18:33:12] right [18:35:46] at some point we can have an automatic optimization for the geometry [20:24:49] can the LLDP combine a plane change into a DOI trim maneuver? [20:25:20] lets say if you were not quite aligned with the landing site [20:25:29] not that it happened to me, just curious [20:33:53] probably not [20:33:59] maybe it should though [20:34:09] Apollo 15 did their DOI with a plane change [20:34:18] my LDPP sources are likely outdated [20:34:30] and the LDPP needs a big update [20:35:09] so if Apollo 15 could calculate a DOI + plane change then DOI trim + plane change should work too [20:36:39] maybe the closest would be mode 1, sequence 3 [20:36:53] first maneuver is plane change plus Hohmann transfer [20:36:58] second is a circ burn [20:37:01] third is DOI [20:37:19] maybe you can trick it into doing the first burn with PDI altitude as target [20:37:33] but right now I have very little trust that any of these additional modes work [20:41:43] right [21:46:51] night! [15:08:16] hey [15:42:36] good morning [15:42:38] good morning [15:43:42] hey guys [15:47:54] I'm thinking about the sextant again. For the VC but also split LOS [15:48:02] I wonder if we could use a custom camera for the 2D panel, too [15:48:10] semi transparent [15:48:13] for the split LOS [15:48:19] just draw it on top of the normal view [15:48:41] my eyes would like that [15:49:47] I don't see why that wouldn't be possible [15:50:02] just the semi transparent thing is something I have no clue about [15:50:14] I've looked a bunch already how SSV handles cameras [15:50:30] they draw stuff on top of the camera surface [15:50:37] but nothing semi transparent or so [15:50:52] maybe I'll ask Jordan if he knows something for that [15:51:03] I would probably just ask jarmonik [15:51:56] also, no idea how the Mercury addon draws a round periscope on a mesh [15:52:02] I only know how it works with the bitmaps [15:52:15] it's like bluescreen, but pink instead [15:52:26] you define a color code [15:52:28] yeah [15:53:39] the Soyuz 7k(t?) addon also has a periscope implimented with cameras. I forget the addon author's name [15:54:09] is the source code available for that? [15:54:23] sadly it isn't for the great Mercury addon [15:55:47] oh yeah that Soyuz looks pretty nice [15:56:12] yay [15:56:14] it has code [15:57:41] good to have a second example of an addon using it [15:57:48] custom cameras I mean [15:58:24] yeah [15:58:34] I didn't realize that was under an MIT license [15:58:41] that's awesome [15:59:50] those meshes are supprisingly old (circa 2005ish) [16:06:02] back in a few [16:06:58] I think it just draws it on a rectangular surface of the mesh. It becomes round by the mesh obstructing the view to anything else. [16:08:25] hmm [16:08:39] or maybe not quite like that [17:44:29] indy91, had an interesting issue while using the PDAP operated by my custom MCC [17:44:58] the passive state vector was a CSM one but that had a CIRC burn integrated into it [17:45:20] but the CIRC burn made the orbit very circular I think [17:45:38] and I thick the PDAP did not like that as the thread would fail [17:45:58] so what I did was add DVX 0.1 ft/s to the simulated CIRC burn and it worked [18:00:19] morning! [18:02:31] hey Mike [18:04:41] hey [18:05:14] AlexB_88, interesting. The failure would be where the PDAP runs the SPQ processor? Or in PDAP's own code. [18:08:21] its when I ran PoweredDescentAbortProgram [18:09:03] using opt.sv_P with a CSM SV using the simulated CIRC burn [18:09:52] Im not sure where in the PDAP the issue happen, if its before or after the call to the SPQ [18:10:31] but it just seems like "orbit too circular" issue like I think we've seen in the past [18:12:25] I kind of doubt the issue could be in the PDAP itself [18:12:33] but I will check [18:12:36] probably SPQ [18:21:51] there is one place where potentially something could be too circular, but very difficult to say [18:21:56] in the PDAP itself [18:36:02] right [18:50:44] coming up on PDI to Censorinus [19:04:57] after that, could you give my failure PR a bit of testing? It's ready, I would like to merge it soon [19:10:16] and after that S-IVB venting. Also ready :D [19:20:17] no problem [19:20:50] I meant to review the venting PR already I flew it once with no issues [19:21:19] well except that bug where the venting graphic disappears at CSM/LV sep I think [19:21:27] but I think that is fixed [19:21:36] got it fixed [19:21:47] and I found a bug with the RTCC venting simulation, also fixed [19:21:51] the post TLI venting thing [19:21:57] ok Ill approve that one now [19:22:06] and I will test the failures PR [19:22:19] after that was fixed the whole P10 procedure looked exactly in the venting branch vs. normal branch [19:22:23] smae DV [19:22:33] right [19:22:35] same* [19:23:00] it's a pretty complicated PR, the failures one is simpler :D [19:23:27] but I think it's a good change, it was in the top 3 of unrealistic trajectory things [19:23:36] the next one is drag [19:23:53] and of course lunar gravity, but for that we will need to move to Open Orbiter [19:24:08] approved [19:24:11] after that it's mostly these little vents that also cause a trajectory change [19:24:16] waste water etc. [19:24:29] a boiler in the LM that Tindall was so agitated about :D [19:25:24] "I just cannot believe that in this day of great technological achievement we have to put up with spacecraft which make maneuvers we don't want" :D [19:25:59] I'll just do one last Apollo 9 TD&E to have a better feeling about the branch haha [19:26:06] but I've done many tests through LOX dump in it [19:26:47] if people don't help finding the bugs before it gets merged, they surely will complain about them after it is merged... [19:27:19] ah wait [19:27:22] "This branch has conflicts that must be resolved" [19:27:27] just have to fix some things [19:27:31] should be easy [19:27:46] will likely dismiss the approval again, oh well [19:30:51] just my recent IMU misalignment comparison display breaking it [19:31:57] I'll start a drag update draft PR soon after this gets merged [19:32:05] there are a few more RTCC things I want to implement for it [19:32:21] ah nice [19:32:48] but I have already test flown both Apollo 7 and 9 with full drag [19:33:07] only remaining confusion is about aerodynamics of docked vessels [19:34:40] yeah sorry, the merge conflict fix broke your approval :D [19:40:39] haha no problem [19:40:48] is it ready for re approval? [19:44:09] I just want to ask Ryan if we need to do anything about checklists, there are a few minor points where it could now lead to confusion [19:44:35] it's probably minor enough for him to fly the early part of Apollo 9 after this gets merged [19:44:39] and makes checklist tweaks [19:45:08] better don't approve yet, or Thymo ninjas the merge before this has been 100% cleared up :D [20:20:17] AlexB_88, for the failure PR, a lot of it is replacing ugly code with slightly better code. PAMFD interface stayed the same, just added a button to clear all failures. [20:20:30] I gave the failure code access to the same Saturn events as the checklist [20:20:34] Checklist MFD* [20:20:44] so you can now schedule e.g. a failure at a specific time during TLI [20:20:59] specifically you give it time from TB6 [20:21:09] but ignition time is fixed, so, same thing really [20:21:59] and when the PR I gets merged I will give our wiki page about failure an overhaul [20:27:26] ok [20:27:34] just building the failures branch right now [20:29:50] any particular way to test? [20:33:58] I didn't add all new capabilities to the PAMFD, so some things need to be done in scenario editor (for now) [20:34:07] but all of the failures accessible in the PAMFD have changed [20:34:14] you could test a random one of them [20:34:31] I have tested an S-IC engine failure [20:35:12] not scenario editor [20:35:17] just, by editing the scenario :D [20:35:44] how about an IU platform failure and a S-II engine failure or so [20:35:48] but mostly, do something random [20:35:51] ill try a platform failure [20:35:55] ok [20:36:57] There are a few addons that actually extend the functionality of the scenerio editor with some menus etc. I wonder If there is anything we do via MFD that would be easer to do through the scenerio editor? [20:38:22] ah true. Coding wise it's probably not easier, but it could be more user friendly. [20:38:32] have to investigate how that even works [20:39:00] I have no idea, just thought of it right now [20:39:15] do you know an example of a vessel that does that? [20:43:40] found one myself [20:43:48] the Delta Glider XR vessels [20:43:52] at least XR5 does it [20:58:58] I think the regular DG does too [20:59:02] for animation state [21:04:11] indy91, platform failure went well [21:04:43] now used a randomizer of 5 and launching [21:05:00] SII engine fail at 79.5 s [21:06:05] that was also a little bit annoying previously, there was some special code in the S-II systems class that counter up from staging [21:06:11] counted* [21:06:41] to be able to schedule S-II engine failures not on mission time but since the S-II actually got fired up [21:07:08] now there has to be no special code and the failure class just uses the same staging event as the Checklist MFD [21:07:27] it's not accessible in the PAMFD, but S-IVB can fail now too [21:09:37] hmm [21:10:03] "S-II Eng 4 Fail: 1 at Ign+79.5s" [21:10:07] but it didn't [21:10:18] since S-IC/S-II staging? [21:10:25] I will check, I didn't test S-II failures [21:10:32] yeah [21:10:53] I guess that should be 79.5 seconds since SII ignition? [21:11:12] staging actually, was like that before [21:11:19] I want to mention I did the randomizer at T-10 seconds [21:11:32] don't know if it was too late [21:12:01] shouldn't matter [21:12:06] likely a bug [21:12:55] could you check in the scenario you closed after it didn't work [21:13:16] FAILURES_BEGIN [21:13:21] anything below it? [21:13:26] FAILURES_BEGIN [21:13:26] MALFUNCTION 0 1 1 0.000000 [21:13:26] MALFUNCTION 7 1 1 0.000000 [21:13:27] MALFUNCTION 24 1 2 79.500000 [21:13:27] FAILURES_END [21:16:02] looks like it scheduled it correctly [21:16:11] maybe the changed code in the S-II systems is the problem [21:16:16] checking [21:17:02] I know I had tested S-IVB failures in a very similar way [21:18:39] oh [21:18:43] if (n < 0 || n > 4) [21:18:46] { [21:18:46] j2engines[n]->SetFailed(); [21:18:47] } [21:18:47] find the issue... [21:19:55] it does the opposite of what it should be doing [21:20:22] fix pushed :D [21:24:22] ah [21:26:48] alright ill test the same failure [21:40:37] hmm so I copy pasted the failures back into the Apollo 11 launch minus 30 scenario, the failure showed up in the PAMFD, but it did not fail [21:40:59] so I tried another launch but manually re-entered the failure at 79.5 seconds [21:41:15] and it did fail this time, but right at SII ignition [21:41:30] ok, will check [21:41:34] the first part I can explain [21:41:36] MALFUNCTION 24 1 2 79.500000 [21:41:42] the 1 there means it already has failed [21:41:52] in which case it doesn't ask the S-II systems again to fail [21:41:54] ah [21:42:39] ok I will take an unmodified launch scenario and enter the failure in the PAMFD [21:42:42] right at S-II ignition is wrong of course. Maybe I only changed it so the S-IC/S-II staging time is used as reference for the failure with the random failures [21:42:56] let me quickly check if I got that wrong [21:44:01] yep it's wrong [21:45:33] fix pushed [21:45:45] now both the random and scheduled S-II failures should hopefully work... [21:49:32] yep works [21:51:39] buggy stage that S-II :D [21:54:59] how do you set an SIVB failure? [21:56:28] only with those scenario entries right now [21:56:30] the line from above [21:56:31] MALFUNCTION 24 1 2 79.500000 [21:56:36] 24 is the type of failure [21:56:51] defined in code, I will add a list in the wiki [21:57:04] 27 for the S-IVB failure [21:57:16] second number needs to be 0 or else the failure is instant [21:57:21] then the time condition [21:57:30] and then the time [21:57:40] 0 = mission time, 1 = simulation time. Other values are vehicle specific, for the CSM implemented right now are 2 = time since S-I/S-II (or S-IVB) staging, 3 = time since S-II/S-IVB staging. 4 = time since EOI, 5 = time since TLI preparations (Timebase 6 start), 6 = time since TLI cutoff [21:57:55] so for example [21:58:13] MALFUNCTION 27 0 3 30.0 [21:58:21] would be a failure 30 seconds after S-II/S-IVB staging [22:00:40] eventually every failure option should be accessible in the PAMFD. But that seemed like its own, not very small project to me. [22:03:58] night! [15:34:26] hey [16:03:20] hey Alex [16:17:34] I guess it's time to do the final checks on S-IVB venting [16:17:48] also worth an update in the release thread on the forum [16:17:52] so I will start writing that [16:31:34] ok [16:31:44] so I guess its good for my approval now? [16:33:36] yeah, I very likely won't make any changes to it [16:33:44] so it will not be dismissed again :D [16:34:10] I will still wait a bit for an Apollo 9 checklist fix, but it wouldn't be terrible if the venting gets merged even without that [16:40:27] morning! [16:47:30] hey Mike [16:52:03] what's up? [16:52:40] being too lazy right now to write something for the forum about the S-IVB venting update. Any you? :D [16:52:46] And* [17:01:03] maybe don't do a write-up and wait into we get a hilarious post on the forums about someone wondering why their SIVB is smoking :D [17:01:40] or why the EMS and P47 seem to suddenly have a bias [17:02:13] finished disassembling bank 4 in Sunspot [17:02:44] but its checksum is 07777 instead of 00004 or 77773 so there are clearly still problems somewhere [17:10:13] hmm annoying [17:11:12] so that's not an error like with the erasable where one bit of every word was wrong? [17:17:54] nah, there's just probably one or two words with a single incorrect bit somewhere [17:23:12] and this is unique code or can we compare with another rope to repair it? [17:23:50] it's probably in unique code [17:24:17] because everything that's in Solarium/Corona now matches them [17:25:56] there is one instruction that I don't understand in the V37 code that is suspicious [17:32:09] 04,6734 30022 1 U04,6734 XCH CYL [17:32:12] 04,6735 20601 1 INDEX PHASDATA [17:32:13] 04,6736 50115 1 TS MPAC [17:32:21] I don't like this indexed TS MPAC [17:32:41] especially since it's indexing a variable that has not been set anywhere here [18:35:28] the other troublesome area is the CADR table for all of the programs [18:35:56] i.e. how do I know that the address I currently have for P23 is definitely correct, when I don't even have a dump of the module it's in? [18:38:35] ouch yeah [18:38:47] a puzzle with pieces missing [18:38:58] but you still want to assemble everything you have :D [18:39:21] oh of course [18:41:46] are they avoiding program numbers with a 0 in the last digit for some reason? [18:41:52] only P00 has it [18:42:03] the list of programs I see, every other program at least starts with a 1 [18:42:06] or, ends with it [18:42:20] no P40, but there are P41-P43 [18:43:19] I wonder how P33 and P43 look like. Maybe they don't even enable guidance and it's a separate program with short burn logic or something. [18:43:33] found anything about those yet? [18:47:04] I think my next step is to capture bit 7 and bit 13 for all four strands here, since there have been isolated instances of both being incorrect [18:47:10] and I may have missed one [18:48:05] oh also my other messages didn't go through [18:48:36] yeah, that's a good question about programs ending in 0 [18:48:47] there definitely aren't any, but I don't see any reason in the code why that should be the case [18:48:51] so I'm not sure [18:49:09] haven't looked at P33 or P43 yet [18:49:20] P43 is in the missing module [18:49:34] just found it interesting to have separate programs for different burn types [18:49:43] maybe P33 has a time input or something [18:50:05] burn time that is [18:50:24] can't quite tell from the list of nouns I am looking at. I'm sure we had procedures for this somewhere [18:50:46] we have the GSOP section with flowcharts [18:51:08] even better [18:51:57] https://www.ibiblio.org/apollo/Documents/R-507-AS204A-GSOP-Section4.pdf [18:53:31] that's fun, in P33 if you enter a TIG it automatically gives you lat/long/altitude [18:53:37] and shows orbital period [18:54:14] and you can enter SPS trims and DT of tailoff [18:54:30] yep [18:54:33] you enter a burn time [18:54:35] fun [18:55:24] there probably are a lot of "nice to have" features [18:55:35] that afterwards got deleted, thanks Tindall :D [18:57:17] damnit Tindall [18:58:44] AS-204 Status [18:58:49] "According to Ed Copps, all fixed memory of the computer is filled; and, in fact, it was necessary to take out about 500 words of the reentry program associated with super-orbital entry in order to make it fit." [18:58:55] what is full is full :D [19:00:02] and then you get to Block II and for about a month you think you have a lot of memory [19:00:37] hahahaha oh man [19:01:02] I was wondering where P65 and P66 were [19:02:33] banished to the great bitbucket in the sky :D [19:02:51] man I really hope we're able to piece together a complete sunspot some day [19:03:18] it seems like super interesting software [19:04:44] no rendezvous capabilities, but I think it would make for a fun Earth orbit mission [19:05:14] well, we'll have Skylark for the rendezvous capabilities [19:05:48] it's nearing time for me to make another phone call about that... [19:06:17] also very capable of fun Earth orbit missions :D [19:08:47] waaaait a moment, P32 has a TIG search for deorbit burns [19:09:03] you enter a threshold time and it outputs a TIG [19:09:48] nice :D [19:15:35] AS-204 GSOP Volume 1 where... [19:24:46] it did exist... one sold in the last rrauction https://www.rrauction.com/auctions/lot-detail/347226606649176-apollo-1-as-204a205-gn-system-operations-plan [19:30:22] hmm, what we have already, did we get that from UHCL? [19:30:32] I do see this [19:30:34] 208488 R-507 10/31/1966 G&N ( GUIDANCE AND NAVIGATION ) system operations plan MISSION AS-204A/205 ( APOLLO SATURN 204A/205 ) GUIDANCE NAVIGATION AND CONTROL APOLLO 084-61 [19:30:50] I know we got a bunch of Block II GSOPs from there [19:31:27] oh interesting [19:32:22] no, I think I scanned the Section IV from Don's collection [19:33:08] and in doubt, restricted NTRS [19:33:18] 20130014498 Apollo Guidance, Navigation and Control. G and N System Operations Plan Mission AS-204A/205. Volume 1. [19:33:26] Revision 507-1 [19:33:33] something tells me this would be harder to get :D [19:33:48] lol yes, definitely [19:34:56] I think Volume 2 came from the archived NTRS [19:35:43] yeah, I can find it there [19:47:45] I will check if the don't have that UHCL document somehow already, that has happened a few times already, where I almost requested something we already have [19:47:51] but if not, I will get it for us [19:47:59] if we* [19:48:16] awesome, thanks! [19:49:27] we definitely don't have it on ibiblio