[17:15:15] NASSP Logging has been started by alexb_88 [17:15:17] yeah could be a good system for that [17:21:14] morning! [17:22:32] hey Mike [17:24:14] what's up? [17:24:46] lamenting terrible Apollo 9 LVDC state vector precision :D [17:25:41] hehehe [17:26:26] "At S-IVB second cutoff, the radius difference (trajectory minus LVDC) was -6.465 kilomoeters" [17:26:50] mine is 5.5km lower than predicted [17:26:59] sadly doesn't say anything about downrange [17:27:28] or rather, the trajectory is good. It's the LVDC state vector that is 5.5km too high. [17:29:55] oh weird [17:30:04] I just need to find some source that gives me confidence that the LVDC can really be that far off in downrange [17:30:13] it seems to be correct behavior with this venting model. [17:52:15] when I simulate trajectories with different venting models, then this error is correct. We get similar behavior to the Apollo 17 LVDC venting model in NASSP, that's what I implemented because the state vector accuracy from that was pretty good on the actual mission. [17:53:57] Downrange -53483.014770 Crossrange 25.323108 Altitude -5515.474314 [17:54:07] difference between Apollo 9 and TLI venting models, at 3h GET [17:54:16] 9 and 17 venting* [17:54:35] in meters [17:55:05] the flight evaluation report shows a graph that confirms the LVDC venting numbers from the LVOT pages [17:55:16] venting model numbers [17:57:07] I like the graphs this makes :D [17:57:09] https://i.imgur.com/wtfkkOh.png [17:57:40] ahh that's very cool [17:58:39] I should set up something like this with postflight trajectory numbers [17:58:46] but that's a lot of numbers to process [18:05:15] oh actually [18:05:32] if I take a state vector from the Apollo 9 postflight trajectory, shortly after insertion [18:06:54] and use the venting model on that [18:07:02] and compare with actual state vectors later [18:07:42] maybe that gives me an idea of actual vs LVDC state vector [18:15:53] oh nice! that is a cool graph :D [13:29:53] good morning [13:42:24] hello hello [13:42:55] I can test your scenarios in a bit [13:43:19] still trying to convince myself about this LVDC state vector issue [15:30:02] hi Alex [15:33:45] hey [15:47:33] hey Alex [15:47:37] more graphs anyone? :D [15:47:38] https://i.imgur.com/8jE5zvN.png [15:48:48] the "actual" is very roughly transcribed from a postflight trajectory graph [15:49:21] overall I see less error on the actual mission than we get. Maybe it's because they had more venting on the actual mission. [15:51:30] I could circumvent this whole issue by using LVDC parameters that agree more with NASSP. But that's like using an actual AGC padload for a while and then moving away from it because it works better that way... [15:58:58] hmm wonder why the LVDC has such a perfect step shape [15:59:34] because that's how it simulates the venting acceleration [15:59:49] just, constant acceleration segments [15:59:59] I know the numbers from the Apollo 9 LVOT [16:00:07] and confirmed by the graph in the postflight trajectory [16:00:20] they kept adding more segments to make it more accurate [16:01:04] 3 values on Apollo 8, 7 values on Apollo17 [16:07:01] ah ok [17:08:53] indy91, im building a mission to Gassendi crater [17:09:16] 17.55°S 39.96°W [17:09:26] a western one, for once [17:09:28] which I think was one of the proposed sites for Apollo 18 [17:09:31] yeah [17:09:37] west and south [17:10:08] an Atlantic launch window give quite good results [17:10:31] LOI at 83.5 hours [17:10:46] PC+2 2149 ft/s [17:10:58] remaining DV 1532 ft/s [17:11:22] that is pretty good [17:11:46] as a bit limited on lunar stay length [17:12:06] landing at 110 hours and liftoff at 146 hours [17:12:31] or else plane change DV climbed too much [17:13:16] MaxQ and Residuals would not approve :D [17:13:18] what's the optimum approach azimuth? [17:13:36] with longer lunar stays that might shift closer to -90° [17:13:37] I used -75 [17:13:49] right [17:13:50] away from -90° is always larger plane changes [17:14:15] we will get better optimization from not burning LOI exactly at pericynthion some day [17:34:52] I'll give the venting branch a few more days of thinking time :D [17:35:11] I don't really expect to make any more changes, but, I just need to feel more comfortable with these LVDC errors [17:53:07] fair enough [19:08:13] n7275, I'm flying your Apollo 11 scenario for systems test, but to be honest, I have no idea what I should be looking for [19:08:18] just any temperature? [19:08:38] just cabin temp [19:08:47] lm cabin temp [19:08:58] I just want to make sure it's stable o. other [19:09:16] it's stable and low at the moment [19:09:20] ...on other computers [19:09:37] I run on 144 Hz, I would hope it's stable haha [19:10:06] I will see how it goes on the surface [19:24:12] n7275, does your update change much about the behavior of the suit temperature control? [20:06:58] it shouldn't change anything other than flow-rates (making them higher) [20:07:05] air-flow that is [20:07:52] right, makes sense [20:09:22] might be difficult to see, but I added the data I collected earlier with actual venting acceleration in NASSP to my graph [20:09:26] https://i.imgur.com/EKlG7bk.png [20:09:35] orange is NASSP behavior in my branch [20:11:55] right in the middle of the other curves there. I thought it would be even lower, but this being Apollo 9 data, the stack is a bit lighter than on later missions, so you get higher acceleration [20:15:46] I've never really questioned that the equation I am using was giving realistic behavior. The tricky thing is really to get S-IVB, RTCC and LVDC into agreement. At least a realistic level of agreement. [20:23:52] how do MCC-1/2 DVs look? [20:27:25] depends on the mission. Overall a bit higher because of a more degraded IU state vector. [20:28:02] this Apollo 9 scenario wouldn't have such a nice MCC-2 DV if there was one [20:28:07] all other missions are basically fine [20:31:20] the IU state vector uplink limits in Earth orbit are basically driven by acceptable MCC-1 DV [20:31:33] so I have been mostly looking at and comparing with these limits [20:34:44] it's not an update that will make things more precise [20:34:55] well, the actual trajectory in Earth orbit I guess [20:35:02] quite noticable for Apollo 9 [20:38:47] your gravity update in Open Orbiter will also not help navigation precision :D [20:39:15] yes :) [20:40:34] we will just have to apply all these biases to the RLS and state vector time tags and such. We will figure it out. [20:41:27] so from the standpoint of this PR, it seems like a lot of things are pointing to this being a realistic update. what are you most concerned about error-wise? [20:42:25] only the Apollo 9 LVDC navigation, nothing else at this point [20:43:32] it seems correct behavior when I simulate the venting with the LVDC venting model for the mission, but I am not actually seeing quite the bad state vector near the time of re-ignition [20:43:54] but I also don't have very good sources for that. Other missions give more numbers. [20:44:27] by the time of the second S-IVB burn the state vector has 100km downrange error [20:45:04] I just wanted to find a source confirming that and what little I have found so war actually doesn't quite agree with that [20:45:09] so far* [20:45:50] just have to check for more data for a few days, doing a few more simulations and stuff. Then, very likely, this PR will be merged as is. [21:52:00] night! [15:32:47] hey [15:33:00] hey Nik [15:34:04] yesterday evening I found some example Apollo 8 MOCR audio files [15:34:37] I wouldn't be surprised if all of the MOCR audio that has already been digitized is already sitting on some web servers... [15:34:43] Apollo 8 and 9 at least [15:34:54] ooooooo [15:35:07] I even tried to reconstruct some links to it, but no success haha [15:35:24] I might have to send some emails to potentially get access [15:35:45] it also doesn't sound quite as processed as the "final" audio files on the Apollo in real time website [15:36:21] how I got there (in my brain) was the need for more information about the Apollo 9 LVDC state vector :D [15:36:27] and what could be better than the FIDO audio [15:47:19] good morning [15:49:31] hey Alex [16:23:12] hi alex [17:02:37] hmm interesting, in terms of downrange error the Apollo 11 LVDC venting model is actually closer to what we get right now than the Apollo 17 model, which I thought was the closest. [17:02:45] I have to launch 11 to check on that [17:45:45] watching the LVDC errors on Apollo 11 feels like therapy compared to Apollo 9 :D [17:47:26] haha [17:48:07] what kind of errors did they got on Apollo 8? [17:53:17] get* [17:54:16] I don't have the perfect data set for that, but from what I am seeing it was quite accurate [17:54:31] we would also be quite close with the Apollo 9 LVDC vent model [18:06:56] morning! [18:11:17] is the Apollo 17 venting model from the AS-512 listing? is it possible that I screwed up the numbers? [18:12:47] hey Mike [18:13:17] no, remember, I had already tried to transcribe those numbers from a graph in the flight evaluation report. And I was proud that I had gotten quite close that way :D [18:13:30] oh right! [18:14:24] pretty sure they are good. the Apollo 17 model has less venting than all the other LVDC models, but then, most actual S-IVBs had less venting than the LVDC predicted. [18:15:42] I thought NASSP behavior was pretty close to that 17 model, but it's a bit more. Still in the ballpark, we don't get too much venting really. [18:16:07] I could make it a bit less... and with that make the Apollo 9 issue even worse :D [18:16:14] hahaha [18:18:59] https://i.imgur.com/0Wpq6Ky.png [18:19:00] you could also add mission-specific venting :P [18:19:06] aha well [18:19:10] oh man [18:19:18] mission specific venting is equal to the amount of sun you have on the vehicle [18:19:20] for the most part [18:20:06] that's why eventually we should replace my solution with our Systems SDK tank [18:20:28] ahhh that makes sense [18:20:59] but it can't really simulate a correct amount of boiloff from heating up [18:21:06] not even with Matt's big update I think [18:30:14] hmm, there actually seems to be a 4th segment in the Apollo 9 model, which we did not get from the LVOT [18:30:24] the other segments agree with the values from the LVOT though [18:30:32] oh weird! [18:30:35] that last segment is too late to really make a difference [18:32:49] all the madness in its beautiful glory [18:32:53] https://i.imgur.com/3eHiXRr.png [18:47:38] haha, it's beautiful [19:07:32] ooo nice graph [19:37:46] enough of that for today. Tomorrow this PR gets merged. If I don't come up with a change until then, so be it. These issues can always be solved later, they aren't issues that are central to the update. [20:11:14] cya! [15:21:05] I think today a few updates are getting merge :) [15:21:08] merged* [15:53:36] hey [16:06:32] hey guys [16:09:44] hello hello [16:10:20] I pulled a Lovell before PDI last night [16:11:07] when checking s-band angles I hit V65 instead of V64 [16:11:40] a very bad thing to do right before PDI :D [16:11:52] unless you know what the remedy is [16:12:27] I didn't find out my error until after landing [16:13:25] V65 "Disable U,V Jets During DPS Burns" [16:18:29] oh oops :D [16:18:50] Verb 75 [16:18:58] yeah [16:19:42] the amazing thing is I didn't notice it until 7-8 minutes into PDI, when you switch to att hold for manual control [16:20:31] which of course didn't work...but I thought that that was the action that somehow broke the ACTA or something [16:20:52] then I switched back to auto and noticed the PGNS was still not using RCS and I was really confused [16:21:30] so I ended up switching to AGS att hold mode for manual control and followed PGNS error needles to landing [16:21:37] haha [16:21:46] good problem solving [16:21:51] ... if you got it to land that way [16:22:01] speaking of DPS trouble [16:22:12] yeah it wasn't too just following the PGNS error needles manually [16:22:26] n7275, I flew your Apollo 11 scenario 2 days ago through DOI, for the systems testing. Your DPS gimbals were at the stop. [16:22:39] RCS had a lot to do during DOI there [16:22:57] I know that isn't what was meant to be tested lol, but that's what I noticed [16:23:37] I had forgotten about it and now checked in the scenario what the gimbal angles were [16:34:54] oh weird [16:35:10] how'd I manage to do that [16:36:47] something during the drive test maybe [16:40:33] finally it pays off that Alex has added an animation [16:40:49] https://i.imgur.com/I6uPTff.png [16:40:56] when I load the scenario :D [16:41:35] n7275, N48 has zeros for the DPS gimbal angles [16:41:51] you have to use 6° to put it on the centerline [16:42:01] there is a DAP PAD with that, too [16:44:28] AlexB_88, was there anything more to test on the failure overhaul PR? I will focus on the venting PR first today, I think that will get merged. But the failure one can follow soon after, right? [16:53:13] yeah I think it was in a pretty good state, I will rebuild it just to test the switch failures etc and then add my review [16:54:25] I'll write something for the wiki before it gets merged [17:57:31] probably the result of me flying a mission over the course of like 3 months [17:59:05] and looking more at temperatures than on the DSKY :D [17:59:42] yeah, that tends to get me too haha [18:04:21] yeah, damn that thing's right in the corner [18:06:55] didn't spin out of control at least [18:07:13] 10% and then 40% thrust gave it a chance to be a little bit more centered [18:07:51] got all the way from 6° off center to 1° in my scenario after DOI [18:08:18] it was probably constantly driving in one direction during the burn :D [18:23:53] I gotta get the crew's metabolic rate up somehow :) [18:24:44] ours don't get excited that easily [18:32:14] indy91, can failures defined only in the .scn also be given a random condition? [18:32:19] are we simulate 3 John Youngs for every mission? :D [18:32:35] AlexB_88, hmm no [18:32:47] ok [18:33:06] Im trying to set up a simple switch failure to test it [18:33:16] I guess Ill use mission time [18:39:19] I have too many other things to do and on my mind than merge a big update now and having to hope there aren't many bugs I have to fix quickly. Maybe I'll merge it tomorrow. [18:39:30] the S-IVB venting one I mean [18:39:58] right [18:40:02] yeah switch failures can't be randomized. I guess technically some of the specific SECS failures we simulate are switch failures [18:40:07] just failed my CMC Cbs [18:40:20] and those can can be randomized if the PAMFD already supports it [18:43:24] btw I was thinking, there is a lot of internal Mission Control chatter on our Apollo 11 launch audio [18:43:35] after launch I mean [18:43:44] I don't think that is very realistic [18:44:03] we should probably cut down to the capcom calls only [18:49:33] yeah that makes sense [18:49:58] hmm [18:50:28] I failed my CMC CBs but it does not seem to save the failure [18:51:53] the failed condition exists in the switch class and that is indeed not saved [18:52:07] ah ok [18:52:16] I didn't really want to add that to every switch [18:52:31] but I guess potentially the failure class should call the switch again to fail it? [18:52:38] on scenario load [18:52:45] but only for switch failures [18:52:54] there are other failures like "disconnect FCs from Main Buses" [18:53:02] that should only happen once, at a specific time [18:53:08] not every time you reload a scenario [18:53:12] but switches... maybe [18:54:42] right [18:55:30] I was thinking if one wants to fail the CMC for the rest of the mission, by failing the CBs [18:55:38] but maybe thats not the point of that [18:56:12] I'm not sure actually [18:56:23] I was more thinking about setting up these scenarios you try once [18:56:27] like challenges [18:56:31] and not mission long failures [18:56:47] right makes sense [18:56:56] MALFUNCTION 0 0 0 100.0 [18:56:58] but maybe at least switch failures should persist [18:57:03] is there a list of those [18:57:23] not yet other than in code, I will add it to the wiki. [18:57:51] https://github.com/orbiternassp/NASSP/blob/2eb39b2897b78b710f61c68daf9b05ee88358729/Orbitersdk/samples/ProjectApollo/src_csm/CSMMalfunctionSimulation.h#L31 [18:58:55] thanks [18:59:05] Ill test one of these and then approve the PR [19:01:04] there is a lot more we can do with this. I didn't really want to make a huge project though. [19:01:44] just kind of transfer our old system with bad code to something new that can be expanded on in the future [19:02:21] I might do something about saving switch failures [19:02:25] so don't approve yet :D [19:02:42] ok [19:05:31] MALFUNCTION CSMFailures_Fuel_Cell_1_Disconnect 0 0 360.0 [19:05:42] Is that the right order? [19:06:14] it doesn't work by name [19:06:22] you put the number in there [19:06:28] ahh ok [19:06:48] although, again a feature for the future, the malfunction class has names [19:06:57] could be changed to allow that [19:09:18] all these things we talk about indicate to me that this PR should be a lot bigger maybe :D [19:09:34] I can do that, but it will then be a while before it gets merged [19:09:48] does it use the Orbiter failures flag? [19:09:59] nope [19:10:19] I'm not really sure how that should be utilized [19:10:37] as we have to actively set failures in the PAMFD or scenario anyway [19:11:08] I think it could just lock-out any failures from actually happening [19:11:58] yeah [20:38:36] indy91, does the SFP have any information about when the LOPC is? Wouldn't that be taken into account in the TLMCC calculations? [20:39:47] it's not on the SFP actually, but these two parameters (N and M) on the constraints page [20:40:02] SFP has an initial guess for time from LOI to lunar landing [20:40:12] also an initial guess for total time in lunar orbit [20:40:25] but from lunar landing it goes M revs to LOPC [20:40:36] and lunar ascent is N revs after LOPC [20:40:45] so it's definitely related, but not on the SFP itself [20:40:54] ah ok [20:40:54] we have it in the init file I think [20:40:59] more of a mission constant [20:41:20] and I guess it should be put in the init file then [20:41:31] because the mission planning page has the exact same inputs [20:41:43] maybe something that can be output to the init file by the ATDP based on the selection? [20:41:45] yeah [20:41:57] I can quickly add that I think [20:43:18] oh and I guess REVS1 and REVS2? [20:43:35] yeah [20:43:45] both always being integers for now [20:43:47] but still [20:43:53] and the asscociated LDPPDwellOrbits [20:44:05] which I guess is the same as REVS2? [20:45:33] I'm confused why not all our RTCC init files have them... [20:46:11] some use default I guess? [20:46:33] M and N I mean [20:46:45] ah right [20:46:51] I put some for Apollo 8 [20:47:03] the default is Apollo 11 probably [20:48:52] I guess the LOPC data be wrong on the TLMCC calculations for most missions after 11 [20:49:03] yeah I am starting to believe that as well [20:49:19] they can be loaded in the init file, so it should be added [20:49:28] I guess the lack of a LOPC TIG display has hidden it [20:49:41] because like I said, total time in lunar orbit is on the SFP [20:49:48] and we have that correct [20:49:54] right [20:50:17] is LOPC/Lunar ascent TIG available internally in the TLMCC? [20:50:25] yeah [20:50:39] and I even know that there was some sort of second TLMCC display [20:50:43] with additional numbers [20:51:11] maybe it would be on there [20:57:21] my ATDP still assumes the mission profile is LOI-1, LOI-2 and a separate DOI [20:57:30] so LDPPDwellOrbits will not be loaded yet [20:57:35] that should be 0 [20:58:10] ah right [20:58:24] REVS1 and 2 would not be used yet if that profile is flown (TLMCC options 3 or 5) but I can of course already load it [21:00:54] REVS1 2.00 [21:00:54] REVS2 11 [21:00:55] LOPC_M 3 [21:00:55] LOPC_N 8 [21:01:01] looks right [21:01:23] anything else... [21:02:00] AZ_min and max for the TLMCC? [21:02:12] should that be set to the right approach azimuth... [21:02:28] yeah [21:03:11] hmm [21:03:28] earth landing spot as a PTP site? [21:04:01] yeah, could be done [21:04:51] hmm [21:04:55] but which one [21:05:22] EOM? [21:05:22] should the logic just assume that the first case you ran on the mission planning page is the nominal mission? [21:05:31] oh right [21:05:39] yeah I guess [21:05:45] ah but the data sets are sorted somewhere [21:05:52] it could use the first launch azimuth [21:05:58] makes sense [21:06:58] ah no, only the LV targeting objectives are sorted actually [21:07:17] probably gives an unhealthy SFP at the moment if you don't do it in order [21:08:14] but which order... [21:09:25] ah the RTCC loading function takes care of the SFP [21:09:44] just the launch azimuths have to be in order I think [21:10:03] but you can do all the azimuths first on the mission planning page and then go to the second opportunity [21:10:06] or back and forth [21:10:08] doesn't matter [21:10:41] I'll definitely add something soon to sort the SFP data though [21:10:45] looks cleaner [21:19:28] PTPSite 0 EOM 10.380 -170.009 [21:20:25] update pushed [21:20:32] I'll take a look at the RTCC files some time [21:20:50] don't think we really get midcourse correction errors from it right now [21:21:00] but the displayed DV won't be wrong [21:21:04] won't be accurate* [21:21:19] right [21:21:33] I guess the only errors would be in the parts after LOI [21:22:34] it does run some sort of DV optimization on the full mission [21:38:24] night!