[12:42:09] NASSP Logging has been started by n7275 [12:42:11] hey [12:47:49] good morning [13:03:13] I need your opinions. best way to sync the spsdk tank quantities, with the SIVb phmain propellant handle (or whatever it points to inside Orbiter). [13:06:38] I'll probably just remove a block of liquid mass based on propellant flow rate and mixture ratio [13:08:06] I'd rather not subvert Orbiter's propellant/thruster system too much, so I don't think making the tank quantities be the driving factor is the right way to go about it [13:46:06] hey [13:46:22] yeah this is tricky [13:46:36] I was thinking about it a few years ago when I implemented the APS and DPS propellant stuff [13:46:50] I wanted to use the SPSDK for that, too, but ended up not doing it [13:51:39] helium should be way better at not flash freezing things now [13:52:20] haha [13:52:59] I also wondered then, how easy it would be to implement bipropellants [13:54:35] kind of important for the S-IVB, too, with H2, O2, different settings of mixture ration etc [13:54:40] ratio* [13:57:36] impliment bipropellants in what sense? [13:58:44] that you have two propellant tanks in Orbiter itself, which are required for a thruster [13:58:54] for one thruster [13:59:47] hey Niklas [13:59:49] so that you dont need a much of special code to try and simulate mixture rations [13:59:53] ratio [13:59:56] got the k factor working nicely [14:00:02] why do I always say ration [14:00:04] hey Alex :D [14:01:40] ooooh probably not hard [14:03:25] PROPELLANT_HANDLEs point to the tank_spec class internally. it would be cool if you could point their mass at an external double [14:07:17] I might try making a bipropellant thruster class. needs two propellant handles and a way to calculate thrust wrt mixture ratio. [14:12:53] hmm, I am quite unhappy with my Apollo 7 orbit [14:13:05] argument of periapsis is off [14:13:07] like, 60° [14:13:32] well, at least 40 [14:13:48] SPS-7 should only need to rotate my orbit by 30° [14:13:57] but because of this it's nearly 90° [14:14:00] 700 ft/s [14:14:27] and like usual I am 20 minutes behind the flight plan [14:14:36] probably the missing drag [14:15:33] I feel like the start of this problem goes back to SPS-3 [14:15:43] don't want to go back that far :D [14:16:53] whats missing to bring the drag to realistic levels? [14:17:02] trust [14:17:08] trust that the RTCC holds up [14:17:15] haha [14:17:22] in most places drag is not taken into account yet [14:17:32] the question is, how much does that matter [14:18:10] also, if I change it, it affects two missions immediately, 7 and 9 [14:21:56] on this Apollo 7 flight I definitely put in more code that can now handle drag though [14:23:04] I should still have 1600 ft/s of DV [14:23:21] rotating the orbit will make deorbit smaller [14:23:29] so I would need maybe 1000 ft/s in total [14:23:45] bet I would be violating some mission rule [14:26:03] right [14:26:16] haven't touched 7 myself in ages [14:27:23] I'm probably just targeting some SPS maneuvers wrong [14:27:45] for these Earth orbit maneuvers I have a hard time finding exact requirements from the burn or how they were calculated [14:27:57] usually I am placing them at the same longitude as the actual mission [14:28:39] Apollo 9 mission rule I need to have 3.6% of SPS propellant left for deorbit [14:29:23] so I would not violate that with this large SPS-7, I think [14:29:39] btw I just have a few TEI fixes to push on my Apollo 12 MCC branch in the next few minutes. Do you think we can merge it afterwards? [14:29:59] yes [14:36:40] until SPS-3 my argument of periapsis was ok [14:37:09] I probably need to make changes to the targeting of that [15:00:13] got a question about the AST [15:00:42] is the abort GET treated as a threshold time? [15:01:32] I find if the abort GET is 45 minutes before the desired GET, it goes to the previous REV [15:05:52] for TEI? [15:05:58] yeah [15:06:09] not a threshold [15:06:19] it's wrong though [15:06:51] I need to change it [15:07:01] the real thing took a min and max GET as input [15:07:13] and it would find the optimum solution in between [15:09:38] ah ok [15:30:10] and now SPS-7 is so large that due to non-spherical gravity the apogee and perigee are different... [15:30:28] I don't want to loose the last 150 hours of the mission and have to go back :D [15:32:47] I should have taken more care that the orbit after SPS-3 is actually what I want it to be [15:35:00] do what I did for MCC testing a while back: burn SPS-3 and use the MPT ephemeris to calculate the state vector 150 hours later :D [15:37:11] I am also updating the mission scenarios [15:37:24] and now they are all somewhat bad [15:37:28] all since SPS-3 [15:37:34] right [15:38:46] btw I think I can use MoonRev and MoonRevTime to get the TEI abort time initial guesses [15:39:30] that should make it work with any type of orbit/GET dispersions [15:39:43] yep [15:40:14] what I am doing is defining what the MoonRev/MoonRevTime should be for every TEI [15:40:49] then subtracting the actual MoonRev/MoonRev Time from them for each case [15:41:33] and then adding that to the current GET at the time the TEI is calculated to find the initial guess [15:43:41] it would be easier if you could just tell the MCC the rev/time and it automatically finds the right GET, but I don't think it can do that yet [15:49:25] you mean, get the GET when the rev starts for any future rev? [15:52:19] I mean say you are calculating a TEI in the future, you could have a function like REVtoGET(rev, revtime) [15:52:28] and then the GET is used as the TEI guess [15:54:34] it could be used for other things too like landmark PADs etc [15:56:24] ugh, are TEIs almost always at the REV start time? [15:57:01] maybe I just need to define which REV for each TEI, not really the rev time, if its always near the beginning [16:11:59] hmm not quite, I think TEIs are always close to 180° longitude, but it can vary, I'm pretty sure it can be 20° or more [16:12:40] a trajectory update is also creating a rev crossing table, a table of times when you cross that longitude [16:12:58] so in a way the MCC is having like half a MPT feature there [16:14:20] morning! [16:15:08] hey Mike [16:20:12] I like the 1-bit rope :D [16:21:57] haha thanks :P [16:22:24] can I get a .bin for it [16:24:13] modern computers are too powerful [16:42:54] alright I think I have this TEI guesses working how I want it [17:32:18] indy91, pushed my update and its ready for merging [17:33:31] looks good [17:33:49] are you going to write a forum post or so? [17:34:00] I can [17:34:19] ok I'll merge it [17:34:40] don't worry ill tell everybody to come see me for issues :D [17:34:51] haha [17:34:52] merged [17:35:11] awesome [17:35:13] thanks [17:36:41] thank you, that was a big effort [17:37:02] it was fun to do [17:37:23] I have a hard time imagining that [17:37:30] you had to work with my RTCC code :D [17:40:54] haha, well it helped that I had studied the MCC/RTCC code while playing with Apollo 8/11 MCC late launches [18:19:37] btw the NASSPVER variable is still 80000 in the WIP folder scenarios (except Apollo 12, which I set myself to 80001) [18:19:53] but we probably should set the others to 80001 as well [18:19:58] n7275 [18:20:24] yep [18:43:19] oh yes. agreed [19:12:13] I think I'll go with the 700 ft/s SPS-7 for now. The calculation for that is right, what happens before is the problem [19:12:35] actual mission had 200 ft/s [19:13:01] which is extremely close to what was planned [19:13:53] I think it comes down to the fact again that the orbit is a bit high before SPS-3. That's why that maneuver is quite different than the actual mission [19:26:08] due to drag? [19:28:02] probably [19:28:22] well the orbit is also lower because of the unscheduled S-IVB NPV vent [19:28:31] that was a bit more propulsive than desired :D [19:42:30] cya! [12:26:35] good morning [12:27:37] hey Matt [12:28:07] Apollo 7 mission report has a nice graph that shows the effects of drag on the orbit: https://i.imgur.com/6cfxmB8.png [12:28:43] and I have decided on a new SPS-3 calculation that should help with the orbit rotation. Now I am just thinking if I really want to go back to SPS-3 and fly everything from there again... [12:33:05] oh wow, apogee altitude drops quickly. [12:33:16] right? [12:33:22] it's that 90 NM perigee [12:33:32] it's like a small burn at perigee every time [12:35:26] at the end of the mission the CSM is also pretty light [12:35:49] 90nm is quite low. basically an airplane haha [12:36:50] yeah [12:37:01] entry interface is at 65.8 [12:37:32] and 80 NM is already the absolute minimum [12:38:06] if the perigee drops below 80 somehow you would do an extra burn to correct it, following Apollo mission rules [13:04:13] does the RTCC drag code just need testing or do we need more documentation? [13:05:59] it's implemented according to spec, with CD = 0.1 instead of 2.0 [13:06:25] the problem is mostly old code, using a propagator without the drag taken into account [13:06:35] and that old propagator is still used in many places [13:07:00] there is also the complication of the newer propagators needing area and mass as inputs [13:07:14] where in the old one it simply was a state vector [13:07:31] so all function that would use the new propagator will need more inputs than before etc. [13:07:40] bit of a snowball effect how much code needs changing [13:08:38] I think I just need to systematically go through every bit of code the MCC for Apollo 7 uses [13:08:48] and then make it use the newer functions, one by one [13:10:10] the analytic ephemeris generator also has no drag capability yet. That is the function that gets used in the RTCC instead of numerical integration in several places, like some rendezvous calculations and the general purpose maneuvers [13:11:04] but I think as long as the durations without drag taken into account are short, that is not such a problem [13:12:25] that sounds like a lot of work [13:13:52] it will happen, just not today or tomorrow yet [13:14:53] at least we have no random amount of drag anymore, like we used to [13:15:07] there was a huge difference depending on attitude [13:15:50] even at its peak it was less than realistic [13:15:59] but at its lowest it was nothing really [13:17:46] yeah that's a huge improvement. [13:20:48] yep, it's going to be as simple as removing one line of code and it's a very realistic model then [13:32:26] I need to resume flying Apollo 12, so we can merge the radiative function updates. I definitely want those in before trying to achieve good SIVb tank pressures in orbit. [13:35:31] yeah makes sense. I think there is a bunch of prep work to do for that [13:35:35] then tank pressures [13:35:37] then venting [13:51:47] I tried a "pumping" the H2 and O2 in proportion to "propellant" flow rate. pressure drops to near vacuum in the tanks almost instantly, so I need to do some work on maintaining pressures [13:52:30] TLI no-go I guess :D [13:56:25] I don't think the turbopumps would even make it up to speed on ascent [14:03:03] Mode II it is [14:09:37] it's kind of interesting, at work im usually making a FMEA matrix so that we can *avoid* failures, but with NASSP it's the other way around [14:12:36] tries to not get distracted by pump cavitation [14:17:21] after being excited about finding one at all, I have already discarded my SPS-3 solution for a new one... [14:17:48] and I think I will go through the mission again, using lots of 50x and skipping everything I can [14:43:37] makes sense [15:23:23] morning! [15:23:56] hey Mike [15:26:31] what's up? [15:27:11] still tinkering around with Apollo 7. I'll probably go back by about 150 hours to fix my trajectory... [15:27:14] and you? [15:28:41] https://i.imgur.com/gC6oNDz.png [15:28:53] getting the rope reader drivers tuned :) [15:35:39] you sure that isn't my new concept for simulating RCS firing? :D [15:36:39] hehehe pretty sure :P [15:37:19] bye bye progress of the last two weeks. At least I can go faster through the mission now that I have already tested checklists etc. [15:38:30] but first I'll make double, triple, quadruple sure that this is how I want SPS-3 now. Don't want to redo it again lol [15:39:53] oof, yeah that is a lot of progress to lose [15:49:18] am I allowed to question numbers in the mission report? [15:51:49] of course [17:28:22] n7275, I'll update the launch scenarios where we forgot to change the scenario version to 80001 [17:32:43] done [18:11:30] alright, rope reader is officially fully tuned and meets all of the procurement specifications for the corresponding AGC modules [18:12:35] !!! [18:13:09] so now the Draper Lab can buy it ;) [18:13:31] hahaha [18:14:22] so now you can step up from 1 bit ropes? [18:15:15] I still want to do some final tests, and I need to finish soldering the malco/samtec pins on the backplane assembly [18:15:27] but yeah it's just about ready [18:15:31] ah yeah, the nice pins [20:54:43] night! [12:59:58] hey Nik how's 7 going? [13:13:46] hey [13:13:53] got a block data hung thread... [13:14:13] but I believe I found what caused it and it's a very, very rare bug [13:14:31] basically converged on a solution and ran into a limit at the same iteration [13:14:45] and then reset the iteration continually [13:15:07] block data was always super reliable for me, hate to see that not working :D [13:15:44] but yeah, I decided on a solution for SPS-3 and now am 50x-ing through the mission [13:15:48] skipping as many things as I can [13:16:50] I'll also make changes to SPS-5 [13:17:02] also a relevant maneuver for perigee positioning [13:17:07] there are a lot of things.... last time I did 7 I think it took me 6 months [13:17:46] I'll skip everything that doesn't affect my power consumption [13:18:09] and everything I don't need for mission scenario creation [13:19:10] none of the special tests, skipping P51s and P52 on days where I don't need them [13:24:53] I got a message on the forums this morning about the "MCC" scenarios. looks like the version checker is doing its job. [15:44:30] Ryan! hi. [16:22:02] morning! [16:36:08] hey Mike [16:36:10] and Ryan! [16:37:44] today is the day where we learn if this thing works haha [16:38:11] oh boy [16:39:28] oh boy indeed [16:39:34] I had a bit of a hard time sleeping last night [16:40:56] even if something doesn't work, as long as it doesn't fry itself or anything connected to it then I call it a success! [16:44:15] hahaha well it's almost certain to be a success in that case [16:45:27] so what were you going to try first? I forgot. Is it already the Comanche 72 module? [17:04:06] I don't know actually. I just know that multiple modules are being brought today [17:22:45] well, time to head out [17:22:51] will report back shortly :) [17:23:08] until later [18:14:23] question is, should I ever make Apollo 13 use Comanche 67 or wait until we have 72. Getting to 72 could take days, or weeks, or months... [18:16:16] I'll definitely keep Apollo 14 with out modified Artemis solution [18:16:24] maybe even if we have 72 [18:41:38] probably best to wait [18:46:21] ugh, I keep making changes, going a bit too agressive, and then undoing too much. 20 GOTO 10 [19:48:01] you didn't have to undo 150 hours of Apollo 7 mission progress. So you have that going for you :D [19:55:37] haha, good point [19:57:55] hVolume is getting a new function: void removeLiquidMass(double grams) so that I don't have to do that manually in the code ever again [20:13:52] hey [20:16:06] hey Alex [20:34:27] hey [20:38:19] I added the same basic abort functionality to Apollo 12 MCC as was in 8 MCC [20:45:09] ah nice [20:53:45] can you fly an Apollo 13 style flyby with MCC support now? [20:59:25] yeah I guess [20:59:37] if you abort right after getting the flyby PAD [21:00:19] ah yeah [21:01:00] before the first TEI PAD? [21:03:02] well I think the TEI PAD will overwrite some parameters [21:04:08] splash target and TEI/EI times [21:04:23] which is saved at very abort calculation [21:05:34] its literally a copy/paste of the Apollo 8 MCC abort logic [21:06:14] yeah. Kind of difficult to handle it more flexible without adding a bunch more saved parameters and some decision tree in the CAPCOM menu [21:07:17] one challenge is the P37 block data, you get many solutions in the same PAD, but only the last one's parameters are saved [21:07:54] so I guess as long as the philosophy is burn the last one received, then you are good [21:08:05] ah, Apollo 8 got a full Maneuver PAD for all aborts [21:09:09] yeah, also, the P37 PADs are really for the no-comm case [21:09:27] of course it could happen that you somehow regain communications again after burning a P37 PAD [21:09:56] but if you had to abort directly and had comm then you wouldn't use P37 [21:10:29] right, you'd get a full PAD [21:10:34] and that's where you disable the MCC :D [21:11:47] I mean, it could be set up so that if you are TLC, within earth SOI then pressing abort just gives you an immediate abort PAD [21:13:16] with a TIG in an hour or so [21:13:23] that could be interesting [21:13:24] yeah [21:14:14] theres already the code for the "generic MCC" 5 hours after the abort time [21:14:34] that could be used for the abort itself too I guess [21:15:47] there would need to be one initial ATP solution [21:15:59] the generic MCC is probably fuel critical, right? [21:16:22] so one maneuver targeting a longitude and then fuel critical [21:16:32] I think it just uses the same logic as the regular TEC MCC's [21:16:56] ah right, it assumes you have done the TLC abort maneuver [21:17:00] so if less then 24 hours to go, fuel critical [21:17:08] which in the Apollo 8 MCC was always a full Maneuver PAD already [21:18:49] are you thinking of ever adding abort support to Apollo 11 MCC? [21:18:50] time to call it a day. Wish Mike good luck from me. Good night! [21:18:53] yes, sure [21:18:58] sounds good! [21:19:07] night! [21:19:12] when I stop being stuck on Apollo 7... [21:19:18] yeah haha [13:48:28] hey guys [13:49:37] good morning [13:51:55] hey [14:12:29] our H2 and O2 work pretty well for fuel cell cryo tanks, but rocket propellant tanks are definitely pretty far outside of their original scope [14:13:41] are they changing states properly? (cryos) [14:15:31] The problem appears to be the density. [14:15:38] I have a graph [14:15:58] https://imgur.com/UvRZkyS [14:19:22] around 80K our model has a fairly realistic value, but as you get to higher temperatures things get weird [14:19:46] haha yea I see that [14:28:53] I have a feeling the rope reader is working [14:39:20] it appears to be :) [15:04:51] anyone know the main operational differences from Comanche 55 -> 67? [15:05:18] like, was 67 using V79 for G&N PTC? [15:06:37] I believe V79 was a big one from a user standpoint. [15:07:09] might be wrong, but I don't think we have a G&C checklist for it [15:07:55] I wonder when we get C67, if we can use the Apollo 13 G&C checklist without too much trouble [15:08:44] ah, we have the delco manual [15:11:36] oh yeah, 67 and 72 are very similar [15:11:53] 72 puts the TIG into V90 automatically [15:11:58] for plane change [15:12:44] might be the only difference really operationally [15:12:55] ah, interesting [15:13:57] 55 to 67 is also not a super large amount of features [15:14:10] as Matt said, V79 is the big one [15:17:16] most of the GSOP section 5 page about 67 is just small fixes and improvement [15:53:39] morning! [15:53:51] hey Mike [15:54:05] resounding success? [15:54:11] indeed! [15:54:28] when I saw 72 Rev 3 reconstruction talk I already knew it haha [15:55:56] I had one minor bug initially that only got me every other group of 256 words [15:56:12] I was calculating the parity inhibit over the bottom 7 bits of the address instead of the bottom 8 [15:56:32] but that was the only thing. after I fixed that the whole module read perfectly [15:57:38] awesome [15:58:04] this opens some doors... and we haven't even found most of those doors yet [15:59:04] you mentioned something about coasting integration appearing rewritten [15:59:25] there is PCR 776.1 and 776.2 [15:59:38] maybe it's just part of that [16:00:35] yeah could be [16:01:58] and about the 72 rev 3 reconstruction, you already partially solved that? [16:02:12] for this module [16:02:34] nope, I haven't figured anything out yet haha [16:02:42] oh ok lol [16:03:06] I have pieced together source code that assembles such that banks 6-13 exactly match the Comanche 72 module dump [16:03:27] so in theory we can do the reconstruction work on this before we have the full Comanche 72 [16:03:33] but, all of my attempts so far have been wrong [16:04:15] there are no straight forward, last minute AGC bug fixes it seems [16:04:35] Luminary 99 rev 1 was very straightforward [16:04:47] we had the opposite problem with that. super easy fix, but what was the bug? :P [16:05:02] a rather difficult to reproduce bug :D [16:05:33] at least in NASSP [16:06:14] did you all of the modules from the collector to check if it's all working? [16:06:19] read* [16:06:55] he only brought two yesterday [16:07:10] Luminary 69 module B4, and Comanche 72 module B2 [16:07:23] ah ok [16:07:32] we did Luminary 69 first since the Comanche 72 one is more special [16:07:41] makes sense [16:08:14] Aurora 88 is the most likely next rope; Comanche 67 will happen this year but may not be until December depending on how schedules work out [16:08:45] now I need to finish the Block I reader, because I want to have that before I fly to read LM131 [16:09:50] you deserve to have my username for this next phase, flying all over the world to find the hidden treasures :D [16:10:37] hahaha [16:52:11] I was really really hoping that it would be a long while before I needed to break everything again...maybe I'll save this branch and make a pull request next year... [16:56:06] indy91 https://imgur.com/wJbzmiH [16:58:04] noo, don't break everything again [16:58:24] "Legacy SPSDK" is that old or current behavior [16:59:22] That's current [16:59:50] I'm working on some "middle ground" solutions [17:00:46] do we really need that? If this is all for the propulsive LH2 vent we can try a simpler solution without the systems SDK [17:01:04] also, why is current behavior so far off... liquids being weird? [17:01:53] I think that correction was intended to only be used over an very small temperature range [17:02:27] so as the cryo liquids warm up, density goes back down, which causes some really strange problems [17:02:55] hmm, right [17:03:29] would a fix really break things though? Usually they will be in the temperature window where it's not that far off [17:05:45] you have this, right? [17:05:46] https://commons.erau.edu/cgi/viewcontent.cgi?article=2883&context=space-congress-proceedings [17:05:59] I'm testing it out now. It looks like the only thing it actually effects are the CSM cryo tank pressures. They end up very low for a few hours, because they're too cold for the pressure's they're at in later scenerios https://imgur.com/uoqxPnB [17:06:30] I do. [17:07:25] If I can't get a realistic SPSDK version working, I may just simulate it in a branch, and them mimic the behavoir without systems. [17:08:06] hmm would PC+2 on Apollo 12 have forced a specific return inclination? [17:08:58] just let it run into the inclination constraint [17:09:17] yeah thats what I do I think [17:09:23] MCC come up with DVY of 1978.6 ft/s [17:09:35] but the real PAD had 1561.9 [17:09:45] ouch [17:09:50] DVX and Z are close [17:10:04] that large of a DVY is definitely a case of fixing the inclination [17:10:13] its a contrast of the flyby PAD, which MCC gets almost exactly as the real one [17:11:25] n7275, those curves being so far off is a bit annoying though. Even for the expected temperature range they are off [17:12:26] the very high temperatures, how relevant is the liquid simulation there. Isn't it simulated differently for gases? [17:15:00] AlexB_88, I wonder if it's a timing issue [17:15:33] is it the impulsive TIG at exactly PC+2 for both NASSP and actual? [17:16:00] maybe a few minutes different TIG would already make a difference there [17:17:45] hmm NASSP seems to be PC+1h57 [17:17:58] seems to be nearly exactly 2 hours between actual LOI-1 TIG and actual PC+2 TIG [17:18:06] but they also are similar in size [17:23:10] indy91 so the problem appears to be the interaction with liquid volume and gas volume. lower quantity/pressure tanks end up with a boiling point in a bad place with respect to those density curves [17:25:01] AlexB_88, that's the small tricky things with the MCC. The exact timing of maneuvers can be quite arbitrary [17:25:11] depending on the mood of the FIDO or RETRO basically [17:26:10] n7275, how relevant is that for e.g. the cryo tanks near the end of a mission. [17:26:26] that would be an important update, much more than anything with the S-IVB [17:26:42] hmm I don't completely understand what you mean by timing, you mean changing the TIG by a few minutes can have that big an effect on DVY? [17:27:04] My hope is that this change would give us more realistic cryo tank behavoir too [17:27:06] potentially, with running into constraints [17:27:30] with timing I mean, when exactly is e.g. a MCC-2 [17:27:43] flight plan time? Impulsive or actual? Rounded to the next hour? [17:27:48] I have seen all of those already [17:28:03] so what defines PC+2 [17:28:22] could also mean LOI-1 TIG plus 2 hours [17:29:20] its defined as calcParams.LOI + 2.0*3600.0; by MCC [17:29:44] right, but calcParams.LOI is sometimes the pericynthion time [17:29:49] sometimes actual LOI-1 TIG [17:29:56] ah right [17:31:02] I think the last thing thats sets it before is GET_LOI in the MCC-2 calculation [17:31:18]