[13:41:52] NASSP Logging has been started by n7275 [13:41:54] finding complete thermophysical data on NTO/hydrazine has been a bit of a challenge. guess I'm just gonna have to buy some and experiment with vapor pressures.... [13:49:18] haha [13:49:44] I bet they are in one of my books from college (which are packed away somewhere) :( [13:56:15] good news though, I do have some very good Antione Equation coefficients for ethylene glycol [13:58:58] I think I had those when I was computing the mixture originally [13:59:19] They are on a spreadsheet somewhere haha [14:03:11] what I'm seeing as the primary issue, is this massive pressure spike during phase transitions [14:07:40] for all substances? [14:07:59] for oxygen and hydrogen at least [14:08:33] hmmm [14:08:53] I think they are handled differently in code kind of cheaty [14:09:20] there is a correction factor in the code for liquid density [14:09:55] which isnt exactly the wrong way to do it. but I think it's only accurate over a very small range of temperatures [14:12:37] right [14:13:23] like, really inaccurate (negative density) [14:51:14] hey [14:51:46] good morning [14:52:25] I found a bug that was actually responsible for making your CSM MPT state vector [14:52:52] it's a bit complicated, but it basically did LOI twice haha [14:54:53] haha good find! [14:55:57] ok so I am in the process of adding the AGC clock time increment and liftoff time updates to the RTCC MFD [14:56:14] hey Nik [14:56:18] hey [14:56:33] clock time works like this. There is a button to compare the current AGC clock time and the actual [14:56:49] requires the accurate liftoff time to be in the RTCC MFD of course [14:57:06] and then it shows you the necessary clock update [14:57:27] and then there is a separate button where you can actually calculate the uplink [14:57:41] but you always manually input the clock increment there [14:57:50] so it's either the one you just calculated or any other value [14:58:11] I managed to get all the eloads into my AGC. I had to redo the ephemerides because I put an extra 0 in my MJD by mistake [14:58:12] whatever reason there would be to make the clock worse and not better haha [14:58:39] ah nice [14:58:43] I noticed AGCEpoch doesn't get saved though, it gets reloaded from the constants each time. So you have to remember to change it when you load teh scenario. [14:59:05] right, it will get back to the default one [14:59:20] I guess for a custom mission it could make sense to add a new RTCC mission file [15:00:28] Custom missions are always zero. Maybe an idea to put it in the scenario and load from there if the mission number is 0 [15:01:02] hmm right [15:01:22] for the general mission file there is already some code in place so that you don't need a number as the mission [15:01:30] so it could be e.g. "SL-2" for Skylab or so [15:01:38] but I don't think that is completely implemented yet [15:01:55] but the RTCC needs some similar code for custom missions [15:03:38] I'm quite satisfied with how well you can initialize the RTCC from the MFD. I found a MED to update MCGZSA which was still off. So far I've had to do 0 edits to the scenario. [15:04:20] good to hear [15:04:24] Only blocking issue I have is that once I undock the CSM gets embedded inside the SIVB. [15:04:26] yeah MCGZSA is the equivalent to TEPHEM [15:05:03] indy91, I'f you ever wanted to simulate our tanks outside of NASSP: https://gist.github.com/n7275/f85a3eb06981715fc9171ab3fce7805d [15:05:40] oh nice [15:06:28] Thymo, note though that most calculations in GET use the actual ground elapsed time variable and not MCGZSA. That is mainly used for uplink [15:06:36] causing that bug in the old scenarios if you remember... [15:07:18] the RTCC stores separate values for liftoff time, CMC zero time and LGC zero time. They are normally all set to the actual CMC liftoff time (TEPHEM) just after launch [15:07:22] but they are separate variables [15:08:02] Those are all set. Actual GET can be set through the liftoff time under the config page. The CMC zero time can only be done through a MED [15:08:41] P15 [15:09:57] ah right [15:10:14] there is an option to downlink the TEPHEM from the CMC or LGC [15:10:25] and that then saves the liftoff time in all three variables [15:10:42] but yeah, not directly a method to only set the CMC clock zero time [15:10:47] only through MED P15 [15:11:13] it gets worse, there is also a CMC Guidance Reference Release time [15:11:15] MED P12 [15:11:23] but that is only used to calculate the launch REFSMMAT [15:11:26] so not very important [15:11:43] Yeah, I didn't set that. I'm using a LVLH REFSMMAT [15:12:04] and later on they downlinked the actual launch REFSMMAT from the CMC anyway [15:12:14] so that initial, RTCC one gets onverwritten [15:12:22] overwritten* [15:12:37] I had some trouble understanding G00 though. There are a bunch of different codes to specify the matrix but I don't know what they mean. [15:12:51] I know you can just disable the MPT and it will transfer it for me but its nice to know [15:13:18] well you have several storage places for REFSMMATs [15:13:32] and G00 just moves them around [15:13:51] Say I calculate an LVLH REFSMMAT under the utility page. Would that go in the MED slot? [15:13:54] in lots of places our RTCC stores them in the current (CUR) REFSMMAT slot directly [15:14:06] all a bit a work in progress [15:14:45] I'm pretty sure that gets saved in CUR already, but there is a specific code for LVLH REFSMMAT, I think it's LCV [15:14:49] local vertical [15:15:19] there is a MED to store a REFSMMAT in the MED slot [15:15:27] basically a predetermined, not calculated REFSMMAT [15:15:34] I think they did the PTC REFSMMATs that way [15:15:51] I haven't added that MED for the MED REFSMMAT yet I think [15:16:09] but they also used it as a temporary storage place [15:16:36] the CSM REFSMMAT storage doesn't even have a place for a landing site REFSMMAT, so they either put it in MED or LCV or so [15:24:00] ok pushed my updates [15:24:22] new RTCC numerical integration control module used in many, but not all places yet [15:24:27] MPT fixes [15:24:42] and adding the AGC clock update and liftoff time update uplinks to the RTCC MFD [15:24:49] I quite like how that turned out [15:25:07] on the liftoff time updates, V70 does the same sometimes as it did on Apollo 14 [15:25:24] TEPHEM (triple precision value) ends up being mixed positive and negative number [15:25:53] so I probably will add a TEPHEM display on the uplink page to manually load that as all positive numbers [15:27:20] That update would've been useful when I was setting my CMC clock yesterday :P [15:27:44] The only reference I had was the time from orbiter in the top right of my screen. [15:28:45] Eventually I did a clock update from the ProjectApollo MFD and then did a V55 from whatever it was to my actual time from TEPHEM [15:29:10] That was the only reliable way to get it right on the second [15:29:51] what is actually the difference between V55 and V73... [15:30:01] V55 is decimal and V73 is octal? [15:30:33] Correct [15:31:13] And V70 is the same as V73 but it also updates the state vector time tags. Used for liftoff time increments and somewhere during the skylab missions [15:31:37] Skylab had to change TEPHEM during the mission for some reason [15:31:54] GET would have overflowed [15:33:35] I think? [15:34:47] I think the limit is 2^28 centiseconds [15:35:07] That would be a good reason to shift TEPHEM so probably right [15:35:20] yeah, RTCC uses the correct MED input limit for V70 and V73 [15:35:30] 745:39:14.55 [15:35:41] 31 days [15:43:30] In ARCore::UplinkDataV70V73 that you added did you forget to close the socket or is that handled elsewhere by setting those flags in g_Data? [15:46:37] ARCore::MinorCycle is doing the actual uplink [15:46:42] I think it's closed there [17:14:54] morning! [17:21:04] hey Mike [17:25:55] what's up? [17:27:11] implemented V70 and V73 uplinks in the RTCC MFD [17:27:50] we seem have a slight clock drift over time actually [17:28:05] Apollo 11 entry preparations scenario has 0.58s error [17:30:05] oh weird [17:30:09] that's pretty significant [17:31:38] not sure if it's saving/loading, some general floating point rounding error [17:31:54] have to check a few more scenarios [17:32:04] in Earth orbit before TLI it is 0.02 seconds [17:32:50] which is nothing, that's one timestep long, can't really measure it more accurately than that [17:33:49] 0.48 seconds before TLI [17:33:56] TEI* [17:34:26] it's not as significant as we used to have in the LGC :D [17:34:40] 0.17 seconds before LOI-1 [17:34:45] so definitely a trend over time [17:38:05] it's within the mission rules [17:38:20] Descent, Ascent and Rendezvous have a 0.5 second CMC timing limit [17:38:31] all other mission phases it is 2.0 seconds [17:41:13] oh wow, that's a much bigger acceptable error than I would have expected [17:41:51] I think they were doing clock updates with smaller errors already though [17:42:34] looking at Apollo 15 uplinks [17:42:50] -0.02s correction early in lunar orbit [17:43:04] another -0.06 and -0.05 [17:43:16] -0.04 on the way home [17:43:31] and another one where it doesn't give the number before entry [17:45:18] in all newer scenarios the trend seems to be the same [17:46:33] about 0.35 seconds per 100 hours [17:50:47] difficult to say what causes. And not sure I want to invest much time figuring it out haha [17:50:51] causes it* [17:51:58] hah yeah if it's within the nominal range then no point [17:52:27] plus sounds like there was somewhat similar-ish drift in real life, so you could claim it's an accuracy thing :D [17:53:26] at least we have a better method now to correct the error [17:53:55] Apollo 11 LGC before PDI has a 0.3 second error. I wonder if that method we use with pressing ENTR on both CSM and LM DSKY at the same time isn't super accurate [17:54:23] it probably depends on DSKY timing [17:55:01] LGC after docking has 0.46 seconds error [17:55:10] so that seems to be the same kind of trend as the CMC [17:55:55] would be interesting to check if it depends on the number of saving/loading at all [18:02:33] hmm -- there is going to be a small amount of error because the AGC hardware only scans for DSKY inputs at a fixed frequency [18:02:42] yeah [18:02:45] although I don't think yaAGC actually simulates that? [18:02:50] I don't remember if that got added or not [18:02:54] does it interrupt immediately? [18:07:46] it's definitely not very random [18:08:14] when there was a e.g. 0.3s error, you correct the clock, and then repeat the procedure then the DSKYs always show 0.00 seconds [18:08:41] I'm having a hard time finding it haha [18:09:31] oh yeah yaAGC very much doesn't simulate it [18:09:39] this would be NASSP code [18:09:51] so yes, probably immediate [18:10:09] I'm not even seeing the yaAGC code looking at InterruptRequests[5] or InterruptRequests[6] [18:10:20] it's in SocketAPI.c for standalone virtualagc [18:10:33] ah [18:12:33] older scenarios are a different story for some reason, but in newer scenarios the trend is quite predicated [18:12:59] an Apollo 15 scenario from rcflyinghokie has a 0.64 seconds error at about 224h [18:13:14] I wonder if this is something dseagrav once talked about [18:13:25] now would me being on my laptop with lower frames have an impact [18:13:40] the length of a frame that we use for timing is only an estimate by Orbiter [18:13:52] maybe it's actually a tiny bit longer on average [18:14:12] unstable framerate could have an impact [18:14:27] but I'm seeing the same in Apollo 11 scenarios that I probably created [18:16:07] might be something we need to look at for more precise timing [18:16:36] the "simdt" that the Orbiter functions provide is probably not right to use [18:16:52] we need to use the actual time since the last timestep or so [18:17:23] but then there is also this confusing difference between clbkPreStep and clbkPostStep that changed from Orbiter 2010 to 2016 [18:17:53] clbkPostStep not actually happening at the very end of a timestep [18:22:03] rcflyinghokie, Apollo 16 lunar liftoff scenario, LGC has 0.12s error, CMC has 0.46s [18:22:22] 175h [18:22:25] interesting [18:22:40] 16 was done all on the desktop [18:22:42] so CMC roughly the same trend [18:22:49] LGC gets fully powered down, right? [18:24:03] so that might be mostly the error from the clock init [18:28:18] oh [18:28:22] I think I know [18:28:59] a while back I noticed that the MissionTime parameter in the Saturn class was off a bit after a long mission [18:29:10] I think that gets used to update the AGC time [18:33:27] in 16 yes the breaker was pulled to conserve power [18:59:40] at least we have a good method for correcting clock errors now [19:00:04] once or twice during a mission for that ultra precision [19:04:44] I am going to leave the ATCA breakers pulled for Orion as they likely did on the actual jettison, leaving the LM uncontrollable :P [19:26:54] oh [19:27:02] didn't know that they couldn't do the deorbit [19:27:19] do they know for sure it has crashed? :D [19:28:30] oh I didn't know that either [20:06:55] based on the orbit it was assumed to have crashed [20:07:28] likely due to mascons etc in that orbit I assume [20:08:08] either the ATCA breaker failed or the crew left it open [20:08:25] thats according to the anomaly report at least [20:10:48] projected orbital lifetime of 1 year [20:11:14] additionally, the shaping burn was scrubbed because of the SPS issues [20:14:26] huh, looks like they also did a clock update so the times correlated with the flight plan once again? [20:18:56] around TEI? [20:19:09] I think it was even a 24h update [20:20:07] about 21h50m yeah [20:20:20] so how do I do this with RTCC haha [20:22:01] oh no, first real test of the new uplink [20:22:31] all on the new uplink page [20:22:37] CMC liftoff time update [20:23:11] I guess first you have to determine the DT [20:24:03] when did they do the update actually [20:24:44] the one at 191:20? [20:26:57] no I am around 197 [20:27:29] did they do it just after TEI? [20:27:38] on the actual mission [20:28:10] 202 05 41 Peterson: Okay, I'll do that. If you'll go Accept, we've got the clock sync ready to go, and it'll be a 24 hour 34 minute and 12 second total change in the clocks. And what we would like you to do is pick up the Flight Plan at the old - at the old point of 226:30, actually pick up those events, although your clock may not come out exactly on that time. And what we're saying is we may cut a little bit into your rest period. [20:28:36] so yes just after TEI [20:29:11] let me rebuild with the changes [20:29:20] I wonder what they really synced the time with [20:29:29] maybe flight plan entry interface time? [20:31:24] That sounds reasonable [20:32:31] hmm, nah, they didn't actually do that [20:32:47] actual EI time is a lot different from flight plan [20:33:11] or wait [20:33:20] AFJ doesn't use the updated GETs... [20:33:34] nope [20:33:44] FP EI was 290:22:45 [20:34:02] that's close to the entry PAD they got [20:34:08] so I think they did sync it to EI [20:34:15] so I guess what you will have to do is [20:34:23] FP EI minus RTCC EI time [20:34:52] or actually, the other way around [20:35:08] liftoff time update will be negative [20:35:46] the small calculation you can do on the uplink page doesn't really help in this case [20:36:04] it's more for the case where you want to return to the nominal launch time reference [20:36:11] which is what Apollo 14 and 17 did, I think [20:36:42] maybe I'll change the calculation on the page again, not sure yet [20:39:46] ok I will run through a TEI on MPT and see what EI should be? [20:41:38] AST and RTED displays also have the number [20:41:53] no need for the MPT [20:41:58] ah true [20:46:00] I have to check if the current logic allows negative launch GMT [20:46:05] pretty sure you will get that [20:46:53] uh oh [20:46:57] I really need to internalize this AST computation, ok so am using lunar search, TIG, Tsplash, and in this case 61.8A? [20:47:48] nah, inclination = 0 [20:47:53] gives you the optimal solution [20:48:39] I wonder if they could even use the End-of-Mission target [20:48:44] and to change the IP coordinates? [20:48:47] if they return earlier [20:49:40] I think they did [20:50:05] so you can use EOM and I guess you were right about the inclination, if you use the actual one then you get a similar trajectory [20:50:26] I always forget "EOM" [20:51:24] so I think you will potentially run into trouble when syncing the RTCC to the new GET reference [20:51:48] as it currently doesn't fully allow a negative GMT [20:52:01] pad IP was -00.72 -156.04, RTCC is 00:22S 158:42W [20:52:23] oh [20:52:41] I guess they didn't land at the planned location then [20:52:48] not premission planned one anyway [20:52:58] ah I am going from the TEI pad [20:53:17] so what needs to change [20:56:22] hmm, I think you can still not add custom splashdown coordinates, sadly [20:57:03] flight plan is even more useless, has EOM target at 169°W [21:00:12] "Due to the day early return, the latitude of landing moved from 5°N to 43 minutes S, thus the nominal longitude of landing became unacceptable due to land in the foot print. The RFO ran several TEI's and subsequent ground tracks, and with recovery picked up 156°W as the target longitude" [21:04:51] so that will have to be close enough [21:06:16] I will very soon add an option to add custom target points [21:07:12] but yeah, I think right now you can't do much [21:07:16] well you can edit the RTCC file [21:07:22] which has the EOM loaded [21:07:26] that might be good to do [21:07:41] Config\ProjectApollo\RTCC [21:07:56] 1972-04-16 Init.txt [21:08:16] last line of it [21:08:23] ah cool [21:08:28] "5.0" is the latitude, "-158.7" is the longitude [21:08:34] that change that to whatever you want [21:08:44] I guess about 0.0 and -156.0 [21:08:58] or even better [21:09:11] I think it already supports adding a second PTP [21:09:24] so just add another line in the same format [21:09:40] oh ok [21:09:43] the 0 in that line is where it's stored [21:09:50] so the new line has to have 1 [21:10:02] and you have to come up with a 3 letter name [21:10:55] ACT for actual? [21:11:32] sure [21:11:44] I think I already add all the logic for handling this [21:11:47] added* [21:12:08] it would also appear in the target table, on the RTE constraints page [21:12:37] should I use 0 or 0.7 for the lat [21:12:59] -0.7° I guess [21:13:12] but it can't target that yet anyway. Just as a reference [21:13:40] lets see what it does [21:14:18] ah it doesnt save inputs [21:15:40] 00:25S 156:00W [21:18:17] good to hear that it works [21:18:24] hadn't tried adding another target [21:19:08] Mind if I just merge that with my other changes when I complete this mission? [21:19:49] yeah, that's good to have in there [21:21:50] ok so here is something I always seem to mess up, the P30 REFSMMAT, being heads up or down [21:22:44] This TEI for example has a pad att of 180 000 000 [21:23:02] but I can compute that with P30 heads up and choosing heads down or P30 heads down and choosing heads up [21:23:12] oh no haha, this is something that can't be calculated yet, Alex has been complaining for ages [21:23:24] so its a guess for now? [21:23:47] I usually figure out that ist wrong by my HGA antenna angles being incorrect, then quickly fix it lol [21:24:13] so I think you can get close to those angles [21:24:30] Well how do I know which of the two REFSMMATs to use is the question [21:24:36] by choosing heads up for the maneuver and heads down for the REFSMMAT [21:24:43] or the other way around [21:24:48] hmm [21:24:51] Well one is wrong lol [21:25:27] or rather, not the one they used [21:25:45] you see what I mean right? [21:26:58] in any case, you can't exactly calculate that yet. It will be off by the gimbal trim angles [21:27:11] or gimbal electronic null angles rather [21:27:26] right but they get close [21:27:35] problem is 1 is 180 degrees from the other [21:27:53] yep [21:28:09] On 15 I used the incorrect choice, and could tell by the way my HGA was pointing using FP angles [21:28:28] uplinked and option 1'd the reciprocal and voila [21:29:36] doesn't it have to be heads down as the actual burn attitude? [21:29:43] so that the sextant star check can be done? [21:29:51] yes [21:29:57] so heads down on the RTED [21:30:05] heads up for the REFSMMAT [21:30:36] thats what I was thinking but I had no confirmation since either work technically [21:30:37] and I will add this REFSMMAT type to the REFSMMATs calculated by the RTE [21:30:51] because I'm pretty sure that's where it would come from [21:31:12] it already calculates REFSMMATs that get you: 0/0/0, 0/180/0 and 180/180/0 [21:31:35] that's what the IBM RTCC documents had, but surely they added this 180/0/0 one [21:32:00] makes sense [21:32:26] so the non zero P and Y is because of the gimbals? [21:34:58] yeah, because the REFSMMAT was calculated so that the attitude is 0/0/0 when you were 180° rolled [21:35:29] and because of the gimbal angles the way you are pointing is not the same as the thrust vector [21:36:02] I think that gets you twice the gimbal angles [21:36:12] is it off by 4° in pitch and 2° in yaw? [21:36:27] is that a result of us having no trim angles for CSM alone? [21:36:36] yep [21:36:55] yes. Trim gimbal angle is 0°, but electronic null position is 2.05° [21:37:13] 2.15* [21:37:18] in pitch [21:37:21] interesting [21:37:37] that's closer to the average center of gravity than the centerline would be [21:37:43] I never knew about that, I mean I assumed it was related but didnt know the reason [21:38:44] the range of actually required pitch angles is about -2.5 to -3.7 [21:39:03] so the 2.15° offset gets that closer to 0 [21:39:35] of course different with the CSM [21:39:38] with the LM I mean [21:39:44] docked [21:40:15] we can get very close to the actual behavior of that, as it mostly depends on SPS propellant locations and mass [21:40:36] I already have a function for that [21:42:37] actually my next update will be removing the SPS position offset that gives us zero trim angles for the SPS with the CSM all the time [21:42:46] excellent [21:43:06] I would assume we need to add mission specific masses to go with that? [21:43:07] And I'll add the function for the CoG with that, but unused until I'm sure nothing gets broken [21:43:21] hmm [21:43:55] well for the SPS it will simply use the total propellant mass to determine which tanks are filled etc. [21:44:21] but what might have be taken into account is e.g. the empty CM and SM masses being different between missions [21:44:43] maybe in a second step though [21:44:53] I would have to make the RTCC CG tables mission specific then [21:45:13] I think at first it will just be a function of SPS propellants left [21:45:32] and rest of the CM and SM is static, for the CG calculation [21:45:46] Might be wise to do RCS as well [21:46:20] the real RTCC also had different CG tales for CSM propellant "on bottom of tanks" and "on top of tanks" [21:46:34] that will be, if you have half filled propellant tanks [21:46:37] and thrust with the SPS [21:46:41] vs. the DPS [21:47:04] the propellant will go on one side or the other of the tanks [21:47:16] it's not a huge difference, but a bit [21:47:39] makes sense [21:48:23] what I'd like to do to our sps tanks: https://youtu.be/PPvHZAAGuW4 [21:48:34] Ahh yes! [21:48:43] make ullage important [21:49:00] and effect cg [21:49:04] affect [21:49:07] one of those haha [21:49:11] oh no [21:50:09] one thing affecting the CG location at a time haha [21:50:55] haha fair [21:52:57] first I have to measure our CSM mesh [21:53:11] so that I know the right offset between the actusl CSM coordinate system and the one of the mesh [21:53:15] actual* [21:59:28] to be clear: I have no intention of try this any time soon [22:00:34] haha [22:00:48] but it would be fun to make the SPS do weird things without ullage [22:05:06] yes [22:10:33] night! [22:10:36] night! [22:10:44] I just found the LM again haha [14:44:04] hey [14:46:42] hey [14:47:46] morning [14:50:17] SPS is on the centerline [14:50:24] and RTCC can deal with it [14:50:29] now, what else do I need to change... [14:50:36] padloads and checklists probably [14:56:41] wrt the CG changes? [14:57:09] without CG changes right now. Although I already put the function for it in code [14:57:37] just SPS on centerline, 0° pitch and 0° gimbal angles, meaning -2.15° pitch trim angle and 0.95° yaw angle [15:05:36] I've also tested the CG shift already [15:05:48] gives a pretty realistic behavior [15:06:21] but more work is required to get that working I think. Have to check animations, something has to be shifted at CM/SM sep etc. [15:08:55] so would this give us non zero DAP trim angles for CSM alone pads? [15:10:26] got the signs wrong earlier [15:10:42] without the shifting CG it gives +2.15° pitch trim angle and -0.95° yaw trim angle at all times [15:10:51] CSM alone and CSM/LM [15:16:19] the SPS will point exactly along the centerline [15:16:29] it's just the null position of the gimbals that is offset [15:20:03] what also seems to have been quite wrong is the position of the thruster [15:20:25] way too far to the back [15:20:35] the point where the thrust is applied [15:20:49] about 1.5 meters [15:21:05] we had it well into the nozzle, while it should be at the top [15:21:31] that's where the SPS gimbal plane is and the RTCC also uses that location in its calculations for the trim angles [15:21:59] but I let the exhaust position as it is [15:22:04] so it won't change visually [15:23:40] it will make a difference for TVC [15:23:47] but I think for the better [15:38:06] center of thrust was at the nozzle throat? that bell isnt just there for looks haha [15:38:45] I'm not really sure [15:39:04] but in calculations for the gimbal angles the SPS gimbal plane is used [15:39:34] so to get accurate angles we have to use that position I think [15:41:26] huh okay [15:42:53] https://i.imgur.com/JRfWJHk.png [15:43:00] it uses X_A = 833.2 [15:43:33] the function has three constants. SPS gimbal position in CSM coordinates, that's the 833.2 inches [15:43:41] then the same for the DPS, X_E = 154 [15:43:50] and also the distance between SPS and DPS [15:44:24] then you just need to have the CG of CSM and LM in their own coordinate system [15:44:33] and you can calculate SPS and DPS gimbal angles [15:44:54] that's how the IBM RTCC document does it [15:45:18] makes sense [15:45:51] I'm doing a comparison to what the AGC assumes [15:48:12] I would love to have the DPS gimbal angles simulated for each LM [15:48:20] instead of using 6/6 [15:48:42] can be implemented soon [15:53:47] very cool [15:54:48] https://i.imgur.com/GUrKqqi.png [15:55:19] that's basically how much power the gimballing has [15:55:32] smaller value is stronger [15:56:02] previous we had the SPS located 5 meters behind the CG [15:56:05] previously* [15:56:16] updated distance is 3.37472 [15:56:42] the orange line is definitely closer to the blue and yellows lines [15:57:03] yellow would be close to the actual, AGC just tries to model that with two linear segments [16:09:22] that looks pretty close indeed [16:15:44] awesome [16:18:00] Ryan what sort of issues did you run into with the DPS tanks? [16:22:25] When I tried throwing He into them? [16:26:27] morning! [16:26:34] Good morning [16:26:43] what's up? [16:26:56] Work work is trumping NASSP work :P [16:27:01] boooooooo [16:27:27] But Nik has some pretty good data on the SPS changes I am excited to test [16:30:32] :D [16:30:38] it comes in two steps [16:31:11] first one is just fixing bad NASSP development decisions of the past :D [16:31:17] hahaha [16:36:57] rcflyinghokie, yeah the Helium pressurization. [16:37:26] I have truly so many projects that I want to work on right now [16:37:53] n7275 it was a few years ago, but I remember the tank pressure dropping to something crazy low when they were "mixed" [16:41:18] thewonderidiot, just think about it for a while which project you prefer and then decide for Luminary 131 [16:41:42] indy91: I can argue that two of the projects help with that, and only one of them is reconstruction ;) [16:42:48] since we've lost access to Jimmie's AGC, I'm thinking about building a little portable core rope reader so I don't need to lug around an entire AGC to do that.... and I know a guy who knows a guy that has a LM131 rev 1 module [16:43:36] right [16:43:43] yeah a standalone rope reader would be awesome [16:44:52] rcflyinghokie, okay that definitely sounds like a phase-change enthalpy of vaporization problem that I can fix [16:45:42] thats what I thought as well, but had no clue how to code it! [16:46:06] It just didnt know how to handle two phases in one tank [16:50:43] seems to have no issue with multiple substances as long as their phases are the same [16:55:31] I think it may have "boiled" when it should really be supercritical [16:56:01] well this case was gaseous helium in the hydrazine tank [16:56:08] hydrazing of course being liquid [16:56:12] hydrazine* [17:21:51] I'll edit the old scenarios, but it seems that the wrong trim angles aren't causing bad things like spinning out of control or so [17:22:12] so older scenarios are fine [17:34:29] transient at TEI ignition is pretty large, beyond 1°/s, but it still easily recovers [17:35:07] thats good to know [17:53:40] surprisingly difficult to figure out the padload [17:53:49] normally angles are just value/360 [17:53:58] but it's converted to CDU pulses [17:56:32] thewonderidiot, how does that actually work, I never thought much about it. When you enter a value in degrees in Noun 48 in the CMC, how does the AGC determine the scaling factor [17:58:55] it's a kind of complicated setup in PINBALL NOUN TABLES [17:59:02] https://github.com/virtualagc/virtualagc/blob/master/Comanche055/PINBALL_NOUN_TABLES.agc#L442 [17:59:15] that tells pinball that N48 is two TRIM DEGREES components [17:59:28] the actual scale factor is then found here https://github.com/virtualagc/virtualagc/blob/master/Comanche055/PINBALL_NOUN_TABLES.agc#L556 [17:59:54] ah, so that 22245 [18:00:08] https://github.com/virtualagc/virtualagc/blob/master/Comanche055/PINBALL_NOUN_TABLES.agc#L816 [18:00:20] and this encodes what routine to use with that scale factor [18:01:08] so in this case, https://github.com/virtualagc/virtualagc/blob/master/Comanche055/PINBALL_GAME__BUTTONS_AND_LIGHTS.agc#L2081 [18:01:48] the 00002 22245 as a double precision thing [18:03:11] and in the end it's 1 bit = 0.023725 degrees [18:03:35] that's the scaling factor we use in the TVC electronics code [18:05:48] which is the CDU scaling factor [18:06:01] ideally yeah lol [18:06:49] not super precise, 2.15° it appears as 2.16°. But one bit less is 2.13° haha [18:08:16] but you have that often in the AGC [18:08:34] you enter something in a noun and due to scaling and rounding the value you entered has slightly changed [18:09:09] hahaha yeah [18:09:10] I see that very often [18:09:23] https://i.imgur.com/vZwyUCc.png that's what Norton has to say about N48's scale factor [18:10:49] 85.41/3600 = 0.023725 [18:11:02] arc seconds to degrees [18:18:45] nice to confirm the value haha [18:18:52] :D [18:34:12] good afternoon [18:39:04] hey ALex [18:47:03] hey! [18:51:38] Good afternoon :) [18:52:39] I think I will not edit all mission scenarios with the new trim angles. I would have to do it again when the shifting CG is implemented [18:52:46] and I want to work on that immediately anyway [18:58:46] I've made it a pull request, for once [19:07:30] What kind of differences should I be looking for in a non edited scn [19:08:56] there will be a transient at SPS ignition [19:09:23] where it moves the gimbals from wherever it was, 0° trim for example, to +2.15° [19:10:02] after the burn it stores the last angles in N48, so no problem with the next burn [19:10:11] what effect will this have with entering new N48 angles [19:10:22] like from a maneuver pad [19:11:31] Will the pads give the correct N48 angles or will it still enter zero [19:12:46] old PADs have 0, but if you regenerate them they will be correct [19:12:59] old MCC PADs I mean [19:13:14] ah gotcha [19:13:18] the RTCC is fully prepared for any future change now [19:13:21] I am coming up on TEI I would like to try it [19:13:29] quite happy with that, all gimbal angle calculations go through the same function [19:13:51] and it uses CG tables for CSM, LM and LM ascent stage [19:14:39] what is the best way to merge these changes into my current branch to see how they perform [19:14:45] hmm [19:15:06] ok, I think the PR can just be merged, I'm writing a post for the forum right now [19:15:31] and the version with the shifting CG is already there, too, just commented out [19:16:32] I was just going to test it before adding a review :) [19:16:43] ah [19:16:54] not sure, I put it in a branch [19:17:18] get the branch from Github and merge it into your own branch I guess [19:18:13] SPSLocationUpdate? [19:19:00] yep [19:19:05] in my own repo [19:22:24] got it [19:22:45] lets see what TEI does :) [19:23:00] I missed being able to build fast haha [19:23:49] I guess there is now a slightly different TVC behavior due to the shorter moment arm of the SPS [19:24:00] but the TVC DAP should like it, it's closer to what it expects [19:24:40] So I have 0 0 in my N48 [19:25:11] recalculated the pad and your +2.15 and -0.95 are there :) [19:26:16] if I use 0 0 will I get the transient? [19:27:41] yes [19:28:19] and if I use the new pad angles I will not [19:28:42] correct. Then it will behave just like before when the trims were set as needed [19:29:37] oh she jumped haha [19:30:01] fixed quickly [19:30:05] yep [19:30:13] but it induced a roll [19:30:22] almost at db [19:30:35] bet RCS will have to fire to correct [19:30:56] yeah, there is a separate TVC Roll DAP [19:31:01] whoever had to write that had it easy [19:31:14] yep RCS fired at db [19:31:36] the actual behavior of roll angle during TEI is wild [19:31:45] they usually bounced back and forth in the deadband [19:31:48] really [19:33:00] not to self, "x" closes the IRC client :P [19:33:23] TEI residuals -.8 +.1 0 [19:33:31] now lets burn with the new trim [19:33:40] probably due to the quickly changing CG with the tanks becoming near empty. [19:33:59] yaw trim angle changes from +1 to -1 during TEI :D [19:34:00] ah true, light vehicle all around [19:34:23] haven't tried a TEI yet though with the shifting CG [19:35:18] I don't think we will get that induced roll though [19:35:59] Orbiter doesn't simulate the products of inertia, the off-diagonal elements in the inertia tensor [19:36:25] I think it does for docked vessels, but not single vessels [19:37:25] interesting that it doesnt for single vessels, but I guess less of an impact than docked (as we saw with Apollo 9) [19:39:01] yeah [19:39:13] allrighty, TEI with the new trim angles [19:39:30] it needs to simulate it for docked vessels or else it has no chance to get the inertia properties right [19:39:44] most spacecraft are fairly symmetrical and have small products of inertia [19:41:45] as expected no transients during TEI ignition with trimmed SPS [19:42:03] but I do have a roll again [19:43:03] that shouldn't really be new behavior caused by this change I would think [19:43:10] I've had it on rare occasions [19:43:33] Maybe I never noticed before [19:43:35] that it got to the deadband [19:44:33] almost hit the other db before ECO [19:44:59] -1.9 +.1 -.1 on residuals that time [19:45:55] likes to overburn [19:45:57] Hey [19:46:15] hey Thymo [19:46:20] rcflyinghokie: If you want to test the changes you can checkout the branch Niklas wants to merge from. No need to do merges into your own branch. [19:47:18] As long as you have the remote, just do a fetch and do a git checkout / and that will detach your HEAD to the HEAD of that branch. This doens't do any local merges or creation of a new branch. [19:47:19] Well I needed to merge into mine as I have other modifications [19:47:31] otherwise this scn would misbehave [19:48:43] It's best to only check out the changes Niklas made so you actually test just those things. Only one variable at a time. [19:51:10] which is what I did [19:51:42] I just wanted to see how they performed with TEI [19:52:00] nothing else I have remotely impacts the SPS stuff [19:52:34] And I can say even the TEI transient isnt bad at all [19:57:23] bigger than I would like [19:57:27] but not too bad [19:57:58] Are you also updating the values in the padload worksheets, Nik? [19:58:19] I've changed it in the Colossus 237 padload worksheet so far yeah [19:58:23] Also what value did you change? Initial trim value? [19:58:28] yes [19:58:50] there is a gimbal drive check in the prelaunch procedures though [19:59:04] does that call V48... [19:59:27] Ah gotcha. So I don't think there's any other things affecting the scenarios. MCC will calculate the proper value so in flight missions should be fine. [19:59:28] yeah its a kick in the pants but it is quickly corrected, and as you can see the residuals were nominal [20:00:44] yeah, with short burns it might be different, but during longer burns it quickly compensates at the beginning of a burn [20:01:33] Does UpdateMassAndCoG() still need work? [20:02:06] it's mostly done I think. Maybe slight tweaks, eventually processing SM RCS proplellant separately [20:02:10] The only call to that function is commented out as TBD [20:02:13] yes [20:02:26] right now I am leaving the CG static, just like it was before [20:02:38] just the position of SPS thrust application has changed [20:03:02] back on the centerline of the CSM where it belongs [20:03:47] the two things that have to be implemented for a shifting CG in the CSM is handling CM/SM separation [20:03:51] and touchdown points [20:04:14] Orbiter provides a function that shifts everything in the vessel together with the CG [20:04:25] like animations, thrusters etc. [20:04:33] as they are all defined relative to the CG [20:04:43] but there are some exceptions [20:04:53] touchdown points, some lights [20:05:16] don't think we any lights like that in the CSM though, only in the LM [20:05:44] I don't think the CSM has any lights yet. [20:06:09] yeah no BEACONLIGHTSPEC at least [20:06:50] would be great if it was as simple as shifting the CG back to where we currently have it, during CM/SM sep [20:06:57] and then let the old code handle the rest [20:07:12] I hope that will work [20:07:30] and the VC clickspots not breaking... [20:10:53] rcflyinghokie, if you want you can also try a TEI with the shift CG [20:10:54] shifting* [20:11:13] just need to uncomment the UpdateMassAndCoG call [20:11:23] in Saturn::StageSix [20:12:40] Left some very minor comments [20:12:46] yeah, looking at it [20:13:12] about the brackets, I copy and pasted some old code by dsagrav that had it like "if ((LastFuelWeight - CurrentFuelWeight) > 100.0) {" [20:13:28] but I usually do the { and } on separate lines [20:14:20] I like consistency there, but I'd rather fix that in UpdateMassAndCoG than where you suggested haha [20:15:24] I think most stuff uses if () { all on one line. At least the code I frequent. [20:15:57] yeah, I think that's good for readability [20:16:01] I'll keep [20:16:02] if (ph_sps != NULL) { CurrentFuelWeight += GetPropellantMass(ph_sps); } [20:16:23] but if there is more than one line in the brackets I'll put the brackets in a separate line [20:18:05] isn't that how Visual Studio suggests it? [20:19:04] oh you didn't mean if () {Stuff} in one line [20:19:14] No I didn't :P [20:19:16] but just "if () {" [20:19:17] I usually try following the linux kernel coding guidelines as that is generally what most people use naturally. [20:19:22] Yeah.. haha [20:19:43] indy91 sure I will see what it does [20:20:12] break a lot of things, so just uncomment it for a TEI test haha [20:20:22] not for the rest of your TEC [20:20:47] sure thing [20:21:17] Thymo, well in this case I really only left the "if ((LastFuelWeight - CurrentFuelWeight) > 100.0) {" by accident as I do it 99% differently [20:24:31] indy91 should I do it with the N48 angles zero? [20:24:51] you could also uncomment the RTCC CG table for the CSM [20:24:57] already added it [20:25:17] zero angles would work ok though [20:25:41] I'll try those first [20:25:55] it will be roughly +0.5 for pitch and -0.5 for yaw [20:26:06] at TEI igntion [20:26:08] ignition* [20:27:53] the CG doesn't get updated every timestep, only every 100kg in mass change [20:28:00] might have to make that smaller [20:28:01] For now just leave it the way it is, when I get back to the contributing we can decide on what to use [20:28:27] But I will say :P https://preview.redd.it/p56sdw2umy2z.png?width=640&crop=smart&auto=webp&s=7b2cb6188929b1ad2c046e02a38169b3e7c4c130 [20:28:28] it's noticable when it shifts every few seconds or so [20:28:44] haha [20:28:54] I'll change it to the way that is consistent to my style [20:29:53] very little transient [20:29:57] using zeros [20:30:23] gimbal angles are about -1 and -.4 [20:31:22] now -1 and -1 [20:31:26] I should stop looking at the Apollo 15 G&C Checklist for that [20:31:49] I'll give you my final N48 after [20:31:53] our behavior is a bit of a mixture of MIT simulator and operational data book numbers [20:32:12] closer to the chart in the Apollo 13 G&C Checklist [20:32:35] it should end up at -1 and 1.3 or so [20:32:43] PR Approved. Thanks for making a PR! :) [20:33:21] "indy91 dismissed rcflyinghokie’s stale review via 3c2274e 2 minutes ago" [20:33:25] I did no such thing! [20:33:55] probably automatic by pushing another commit despite approval from Ryan? [20:34:20] -1.0 +0.7 +0 [20:34:32] N48 -1.00 -1.48 [20:34:43] Yes because you made a new commit it invalidates his approval because he has new code to look at. [20:34:57] I feel invalidated [20:35:16] but the update CG had no ill effects [20:35:17] Otherwise it's easy to bypass the merge checks. 1. Make a simple change. 2. Someone approves. 3. Add bad code 4. Merge without review [20:35:31] makes sense [20:35:34] weird seeing both SPS P and Y in the negative though [20:36:02] https://history.nasa.gov/afj/ap15fj/csmgc/5-12.gif [20:36:28] it's not exactly like this close to empty tanks [20:36:43] I expected pitch being -1.0° and not -0.8° [20:37:17] the constant CG update will definitely keep the TVC busy [20:37:23] even if it's small changes [20:37:28] it looked good though [20:38:02] Do those N48 numbers sound right for ECO though? [20:38:05] yes [20:38:15] good to hear [20:38:17] for our CG [20:38:40] it depends a lot on CM and SM empty masses and CG locations of those [20:38:52] and I think that is a bit more mission specific [20:39:47] Ok, merged the PR and posted an update in the forum [20:40:02] and hopefully I can quickly in the next few days resolve the remaining issues with the CG shifting [20:40:44] AlexB_88 has probably already fixed most of the issues when he had to make the VC work after S-IC/S-II and S-II/S-IVB staging [20:40:52] that does work, right? [20:41:06] no broken clickspots? [20:41:27] hmm I think there are still a few issues with staging [20:41:42] for the VC clickspots [20:42:51] oh ok [20:43:10] you have to quickly cycle to a different "seat" and back after staging to refresh the clickspot locations [20:43:20] thats the workaround for now [20:43:34] because it's using the old CG shift function of Orbiter [20:43:35] but I have to dig deeper to see what is causing that [20:43:41] yeah [20:43:45] ShiftCentreOfMass [20:43:54] instead of ShiftCG [20:44:14] hopefully for CM/SM sep I can just ShiftCG it back to the normal zero position of the mesh [20:44:53] I think that's how we handle LM staging [20:44:58] yeah [20:57:04] night! [20:59:34] Hey AlexB_88, can you register your name with NickServ? We recently got cloaks for our hostnames so instead of your IP it shows NASSP/developer/. If you want I can set you up the same but you need to be registered for it. [21:00:42] Thymo, my registration worked didnt it? I know I was having issues on the laptop, but I am back on the desktop now [21:01:40] You're not logged in Ryan [21:02:05] Thymo, sure thing. Pardon my ignorance but how does one register with NickServ? [21:02:20] Hmm how am I not logged in? [21:02:48] * You are now logged in as rcflyinghokie [21:02:49] * SASL authentication successful [21:02:57] AlexB_88: do /msg NickServ help register [21:03:56] Hmm I don't think yours is applied then [21:04:01] I'll ask them to check [21:04:51] Thanks, just let me know if I need to do anything [21:05:50] Yep, I'll wait till Alex is registered so I only bother them once [21:06:39] haha ok [21:07:49] Thymo, I think its done? [21:09:15] Looks like it [21:17:17] Done and done [21:17:47] AlexB_88: You were a special case because cloaks can't contain underscors. I hope a dash is fine haha [21:18:50] Haha Alex is a special case :) [21:21:42] haha [21:22:32] Alex I see why you did all those J mission flights, they are a lot of fun! [21:23:26] I have been running them in order (started with 11 now on 16) just to make observations and learn the RTCC, and apparently I have dethroned you in finding RTCC bugs ;) [21:49:22] nice [21:49:30] yeah they are just really long lol [21:50:47] haha yeah [21:51:16] Learning so much both about NASSP and the actual flights thats for sure...makes me want J mission LM panels [21:58:31] working on how to properly update the mission time, trying to figure out how they actually did it [21:58:41] now that we have liftoff time update and all [22:03:44] You need to update TEPHEM, CMC clock and do a MED P10 and P15 in the RTCC MFD [22:05:36] First two can probably be done by a V70. It should update TEPHEM, CMC clock zero and SV timetags. [22:08:13] Right but what do I update them with [22:08:59] Am I just subtracting the 24h from the liftoff time? [22:11:20] trying to determine the proper way to actually get that time and utilize it [22:14:23] If you download one of the padload worksheets you can input an MJD and it will give you the proper AGC values [22:15:11] Hmm actually. That's if you do a manual change of TEPHEM [22:15:21] Don't know about V70 is that octal? [22:15:56] Well the liftoff time update works in the RTCC [22:16:25] I just need to know how to compute the delta, I could just use the actual delta but I want to know how they computed that to line the timeline back up [22:16:42] and then I need to know do I just subtract that from the liftoff time in RTCC [22:17:59] You also need to do a P15 as manual MED otherwise your state vectors will be off. [22:20:32] Why would I do a P15 [22:20:52] Okay V70 is an onctal time increment,The input is added to TEPHEM, subtracted from TIME2 and TIME1 (AGC time) and subtracted from both state vectors. [22:21:04] P15 updates the liftoff time for a specific vehicle. [22:21:15] It updates MCGZSA [22:21:16] Doesnt the RTCC liftoff time update do that [22:21:19] Nope [22:21:24] There's two separate ones [22:21:43] Pretty sure they didnt have to do a P15 for 16 [22:22:07] they only did an uplink [22:22:21] I didn't go off what they did, I went off what made it work. [22:23:53] I am trying to replicate their procedure [22:24:09] https://history.nasa.gov/afj/ap16fj/25_Day9_Pt2.html#200_44 [22:24:17] go to 202:04:52 [22:26:09] so I need to determine 1) what all was uplinked 2) how the delta was computed and 3) what they were using the G&N p 9-4 numbers for [22:26:34] Right. I'm not familair with it, I can read up tomorrow. I need to head off though, work tomorrow. [22:27:13] night [22:33:34] haha no worries, night! [13:43:47] good morning [13:45:14] morning! [13:47:56] windows decided it wanted to restart [14:40:50] hey [14:44:12] morning [14:44:39] rcflyinghokie, mine decided that running the audio service today is too hard [14:46:28] hey Niklas [14:49:56] working on the shifting CSM CG [14:50:14] that also causes the docked DPS burn to have DPS trim angles [14:50:45] every time I merge any commits that have anything to do with MCC/RTCC/RTCCmfd into my telemetry branch git finds a way for there to be a merge conflict.... [14:52:55] fun [14:55:12] there must be a different sign convention for the DPS roll gimbal angle [14:55:25] I'm getting the wrong one [14:59:29] or is it pitch that is wrong... I will see soon :D [15:13:05] hmm [15:13:21] something about the RTCC calculation for this must be wrong [15:17:45] uh oh [15:18:22] just for the docked vehicles it seems [15:18:45] indy91, sounds exciting [15:18:54] finally those trim charts can be put to use [15:19:28] yep [15:26:42] Oh yes I am very excited as well :) [15:26:58] Will also be nice to actually have to put the DPS angles in for a change [15:34:17] or see how much transient angles we get for not updating the DAP angles [15:41:24] haha, I don't think SPS pitch gimal angles of +5.96° is correct [15:44:49] yeah seems like I forgot a minus, so the sign was wrong [15:45:03] how has that not caused issues before... [15:46:08] for CSM alone it wouldn't have caused a problem [15:46:15] the function would always have returned 0 [15:50:02] is this the RTCC computation? [15:50:07] yes [15:50:38] maybe my hacky solution for the offset SPS location we had previously prevented an issue [15:51:02] and the version commited right now always returns 0 for pitch and yaw, which then gets biased with the electronic SPS offset angles [15:53:51] so there should only be a problem in my local copy right now, which I have just fixed [15:57:50] I probably put that old SPS offset in the wrong direction for the RTCC calculation [15:58:04] so that it cancels out the missing minus sign [15:58:07] something like that :D [15:58:15] it's giving the expected numbers, that is what counts [15:58:23] now* [15:59:43] excellent [16:00:03] Oh, did you by chance give any more thought to the Apollo 16 clock update procedure? [16:00:12] DPS doesn't like if the trim angle is off by more than 2° [16:00:13] Was it as simple as changing the liftoff time? [16:00:26] Haha yeah that would make an interesting ignition on the DPS [16:00:48] yes, V70, maybe loading the TEPHEM manually so that it doesn't have a negative component [16:01:02] and then also syncing the RTCC to the new liftoff time [16:01:17] that's why I added the same update button on the uplink page as on the RTCC MFD config page [16:01:38] syncs the RTCC liftoff time, CMC clock zero time and LGC clock zero time to a downlinked TEPHEM [16:01:52] the only problem I am seeing is that the liftoff time is now negative [16:01:56] probably [16:02:05] so the time reference is before midnight of the launch day [16:02:17] So they did an uplink, and they asked them to read the TEPHEM and then load register 2 and 3 with values from a table in the G&C book [16:02:48] 202 13 03 Peterson: Okay, 16. On those numbers you've got on the DSKY there, if you'll go to the G&N Checklist, Page 9-4, you can load Register 2 and 3 in column Bravo, Lines 4 and 5. [16:03:32] what exactly are they changing there' [16:03:34] backup padload [16:03:40] is page 9-4 [16:03:52] surely they previously received the octals for the change liftoff time [16:04:55] or wait [16:05:01] are they doing DSKY -> checklist [16:05:04] or checklist -> DSKY [16:05:33] 202 11 19 Peterson: Okay. And, also, we'd like you to read out Tephem for us. That's Verb 5 Noun 1 1706 Enter. [16:05:35] https://history.nasa.gov/afj/ap16fj/25_Day9_Pt2.html#198_53 [16:05:38] ah you have it [16:05:52] yeah they called the TEPHEM up then had them change R2 and R3 in it? [16:05:55] I think they are copying down their TEPHEM into their checklist [16:06:00] am I reading that correctly? [16:06:02] and not changing them in the computer [16:06:11] 202 11 54 Peterson: Stand by one; we'll take a look at it. [16:06:12] 202 12 01 Peterson: Okay, 16. That looks good. [16:06:32] he says load register 2 and 3 [16:06:49] 202 13 30 Peterson: Load Register 2 and 3 in column Bravo, line 4 and 5. [16:06:53] interesting phrasology haha [16:06:58] saying load is weird [16:07:11] but I don't think they are changing it on the DSKY [16:07:22] yeah thats why i was confused, but in context I see he is taking R2 and R3 and "loading" into the checklist lol [16:07:43] at least I think so [16:07:54] it would only make sense if they previously had written down the new TEPHEM for the liftoff time update [16:08:07] and then they could copy it to the DSKY [16:08:18] but Peterson says it looks good on the DSKY [16:08:49] right [16:08:59] on Apollo 14 the liftoff time update caused one of the three words that make up TEPHEM to become negative [16:09:06] R1 and R3 positive, R2 negative [16:09:19] they weren't sure if that causes any problems [16:09:35] so they manually loaded the full number with all positive values [16:09:44] that is what they are checking here [16:09:49] ahh I see [16:09:58] but it seems it didn't happen this time [16:10:28] so which uplinks were performed here, I am just trying to better grasp the procedure [16:10:33] V70 [16:10:37] that's irt [16:10:38] it [16:10:43] which is liftoff time update [16:10:46] yes [16:11:00] and that also updates the time tags on SVs and the clock itself? [16:12:42] yep [16:12:56] you can do a clock check afterwards to confirm that [16:13:03] on the clock update page [16:13:27] "CMC time increment" [16:19:07] So determining the delta [16:19:20] that was the other question [16:20:05] your expected EI time from RTCC minus the flight plan EI time [16:20:38] RTED page? [16:21:27] AST has it, too [16:21:36] rcflyinghokie, there is some notes about liftoff time update in the RTCC input reference guide but it might need some updating with the new function in the RTCC MFD [16:21:40] RTED might be more precise though and you need it anyway [16:22:16] right I have read that guide through and through, it does need a lot of updates :P [16:22:35] Do I need to compute a maneuver for RTED to display? [16:22:38] I am post TEI [16:22:45] hmm, then [16:23:04] either compute your first course correction or use the space digitals [16:23:07] works without MPT now [16:23:14] I think I have a more rcent version of it on my hard drive that I forgot to commit, mostly the newer RTE stuff [16:23:22] recent* [16:23:38] AlexB_88 either way its been my bible along with real time support from Niklas haha [16:23:55] haha that works too [16:25:32] indy91 for the space digitals display, what inputs am I using here [16:26:20] first button is the init button, only works with the MPT [16:26:36] you want column 3, which has the EI and perigee numbers [16:26:55] you need to input a time, which is just the time when it starts searching for EI [16:27:00] ah got it [16:27:07] so it can be anything between now and EI really [16:27:14] GETEI [16:27:18] yeah [16:27:26] 265:35:33 [16:27:33] got a good EI angle already? [16:27:35] GEI or so [16:27:40] for gamma EI [16:28:50] flight plan EI time is 290:22:45 [16:29:41] hmm -5.10 [16:29:51] pretty good I would say [16:30:13] isnt that shallow? [16:30:15] yes [16:30:22] but this is just after TEI, right? [16:30:24] yes [16:30:27] no course correction yet [16:30:29] correct [16:31:00] actual Apollo 16 mission had -7.44° after TEI [16:31:10] interesting difference [16:31:27] it's very sensitive to any small TEI error [16:32:17] I didnt realize it was that different [16:32:24] I'm sure that's a small MCC-5 still [16:32:30] maybe a few ft/s, but not that much [16:32:47] lets get this clock updated first :P [16:33:15] by my calculation you need an update of -24:47:12 [16:34:10] and the RTCC won't like it [16:34:58] haha yep thats what I have [16:35:38] so i subtract that from liftoff time [16:36:00] you input that number on the uplink page [16:36:13] on the right side [16:36:24] left side is a small calculation tool that doesn't help you in this case [16:37:37] so I have the dT in the increment [16:37:49] that doesnt change the liftoff time though does it [16:38:13] yes, you uplink a time difference [16:38:20] not thw actual new TEPHEM or so [16:38:30] this alone does not change the liftoff time in the RTCC [16:38:42] but it will change it in my CMC? [16:38:58] well what is the name of the uplink type :P [16:39:19] ah true I keep thinking its just clock increment :P [16:39:26] that's V73 [16:39:31] I also added the uplink for that [16:39:46] TEPHEM is 00011 12312 13670 [16:39:58] after or before the uplink? [16:40:00] after [16:40:15] new clock looks good [16:41:08] I'm pretty sure you will get errors on the online monitor if you now try to sync the RTCC to the new liftoff time [16:41:29] I will need to make a bunch of changes to allow a negative liftoff time [16:41:42] because the reference time is now on the day before actual launch [16:42:10] but I think you do a workaround [16:42:16] you can do* [16:42:31] you will have to change your day of launch to one day before actual [16:45:20] ok I will try that [16:46:01] then how shall I adjust the time [16:46:31] the config page should allow you to change it [16:46:51] change it to the day before. And then the UPD button should work to get the new liftoff time from the CMC [16:47:09] there is one problem with this, the RTCC launch day specific files aren't loaded [16:47:23] but TLI and skeleton flight plan don't matter anymore [16:47:40] it won't load the custom RTE target points [16:47:53] the EOM and ACT or whatever you called it [16:48:14] Well hopefully I just need corridor control now [16:48:29] then the launch day change should be ok [16:48:31] new time is now 17:06:48 so looks like it worked [16:48:43] will only be a 47 minute change [16:48:47] yes [16:48:48] instead of 24 hours and 47 minutes [16:48:56] great, it works haha [16:49:13] I think by the time of Apollo 16 they had changed it so that you could load negative liftoff times [16:49:17] but they had one issue [16:49:34] "The RTCC GMT of IU GRR cannot be input as a negative value. [16:49:35] This parameter is used to reference the RTCC expendable table, and as [16:49:36] such, should be flexible enough to accommodate all GET updates." [16:50:00] so they probably removed the constraint on liftoff time, CMC clock zero time etc. [16:50:08] but didn't do IU GRR time [16:50:46] when would that come into play [16:50:51] other than launch [16:52:13] not sure what you mean [16:53:11] what impact would being unable to change IU GRR time have? [16:54:10] " parameter is used to reference the RTCC expendable table" [16:54:36] I don't use it yet, but the expendable table is basically mass losses that are not caused by maneuvers [16:54:59] for the MPT [16:55:37] so I guess after they made their liftoff time negative they couldn't use this table anymore [16:56:11] ah I see [16:56:37] RTCC time keeping is GMT since midnight of launch day and you set the reference times like IU GRR in that GMT format [16:56:40] Just computed MCC5 as FCUA, 1.71 fps 00:24S 155:53W [16:56:55] looks like the times are happy [16:56:59] great [16:57:20] lets see what 6 and 7 look like [16:57:44] seems like this is definitely easier than what AlexB_88 had to deal with when he first tried Apollo 14 and 17 delayed launches [16:57:50] lol [16:57:57] of course the PAMFD clock isn't updated [16:58:02] and Checklist MFD [16:58:10] right [16:58:17] but I am using neither [16:58:47] those are basically following the AFJ timing haha [16:58:54] time since actual launch [16:59:15] hmm am I missing something? I dont see a MCC6 slot on the FP [16:59:33] only 5 and 7 [16:59:42] missing pages or wrong order? [17:00:03] CSM burn schedule has one [17:00:07] 268:23 [17:00:25] oh [17:00:30] there is a small note only at that time [17:00:31] on the right [17:00:39] ahh yep I see it [17:00:45] so I guess they didn't really want to do it [17:00:50] only MCC-5 and MCC-7 [17:01:05] like MCC-1 and MCC-3 are not the preferred points for course corrections [17:01:50] interesting, doing an FCUA at MCC7 time without MCC5 results in 11.2fps 00:20S 155:54W [17:02:03] makes sense, MCC-7 is quite close to Earth [17:02:06] DV increase quickly [17:02:09] oh, what EI time is predicted for MCC-5? [17:02:21] 290:21:57 [17:02:33] close enough [17:02:39] MCC-5 will change that time a bit [17:03:03] compared to what the space digitals predicted without MCC-5 [17:03:12] looks like they burned both MCCs [17:03:45] yeah [17:04:11] wonder if they were both corridor control [17:04:51] I'm sure they were [17:05:35] I'm not sure that there were any longitude controlling burns at all during the Apollo program [17:05:43] not counting Apollo 13 PC+2 [17:06:29] the mission rules just say that MCC-5 can be used to control the landing area if it's too close to land [17:06:38] or if the reentry trajectory comes too close to land [17:06:48] makes sense [17:27:44] morning! [17:28:34] morning [17:30:34] hey Mike [17:34:20] V70 works now thanks to Niklas :) [17:43:09] :D [17:45:01] was late enough that I added those uplink types [18:01:56] indy91, so the GET in the RTCC MFD can be adjusted now? [18:02:23] yes [18:02:38] it already could sync the launch time to the AGC by downlinking the TEPHEM [18:02:44] better then just being able to match it to the CMC one like before [18:02:54] and now you can uplink the V70 liftoff time update [18:02:57] which changes TEPHEM [18:03:29] ah ok [18:03:49] so you just need to the V70 uplink and then the TEPHEM update in the RTCC afterwards [18:04:27] Ryan had the problem that he was doing a liftoff time update of about 24 hours [18:04:46] that makes the liftoff time negative as it's now before midnight GMT of actual launch day [18:05:05] and the MEDs for the RTCC time updates don't allow that right now [18:05:11] need to change that [18:05:25] he just changed the liftoff day by one as a workaround [18:05:40] don't think you could do that in the real RTCC once you had launched [18:06:17] I'm not quite sure yet what the because procedure is to determine the liftoff time update during TLC [18:06:21] th ebest* [18:06:23] the best* [18:06:48] initially I thought you would just make it the nominal liftoff time [18:06:58] I'm thinking about Apollo 14 or 17 there [18:07:20] but maybe you want to adjust it differently, so that it is close to the flight plan [18:08:22] like the flight plan says for Apollo 14, update when "start of rev 2 differs from 84:35:12 by more than 1 minute" [18:08:47] so you probably rather want to calculate your actual time when that happens [18:09:05] and make the difference your time increment [18:14:35] hmm, FIDO report indicates that they made their GET update to get back to the planned liftoff time [18:14:54] and targeted MCC-2 such that it would get that rev crossing GMT(!) as planned. [18:15:53] Is there a certain part of the D3D9client NASSP has a hard dependency on? I always thought it did but now that I'm talking to some of the D3D9 people I'm starting to question myself. [18:16:21] Something regarding the terrain? [18:17:20] I know that certain particle effects look terrible in the default client [18:17:28] and make the frame rate terrible [18:17:43] at CSM sep I think [18:17:54] but hard dependency... [18:44:39] AlexB_89, do you know if the CSM VC has the clickspots problem at CM/SM separation? [18:50:54] I think it does [18:51:40] ah, then I didn't just add it with the offset CG lol [19:04:39] are you using ShiftCG? [19:16:02] yes [19:16:14] I've basically copied the code that we are using in the LM [19:25:12] ok [19:25:42] I guess that might fix the clickspot issue like it did for the LM? [19:27:14] you would think so [19:27:19] if I remember correclty ShiftCG does a lot more stuff as well like move the docking ports, clickspots etc [19:27:20] but it doesn't seem to do that [19:27:35] yeah I actually checked the Orbiter code for ShiftCG [19:27:40] hmm weird [19:27:42] it does shift the clickspots [19:28:04] and I guess it also calls ShiftCentreOfMass? [19:28:08] yes [19:28:23] in our CM/SM sep code ShiftCentreOfMass is also called though [19:28:29] that might screw it up? [19:29:09] at CM/SM sep I am creating the SM at the offset position and then shifting the CG back to the the center of the mesh [19:29:13] and then CM/SM sep happens [19:29:24] visually it looks fine if I do neither of these things [19:29:44] but I think what it would do then is create the SM and shift the CM at the wrong location [19:29:50] just relative to each other it looks right [19:30:37] if the CG were e.g. shifted to the right 1 meter [19:31:01] then it would create the SM that 1 meter to the right [19:31:22] have to check CM/SM with LM docked actually [19:33:17] I don't know why ShiftCentreOfMass screws up the clickspots though [19:33:24] I thought that would just shift the whole vessel [19:35:02] I haven't shifted the camera position yet though [19:35:47] how are you handling the VC mesh in the CSM right now [19:36:03] does it get deleted and created from scratch on staging? [19:36:17] I guess if ShiftCG is called, ShiftScentreOfMass called as well would be bad since it would be called twice? [19:36:44] no [19:37:00] its created once at session start and is just shifted around I think [19:37:11] I am just using ShiftCG to get back to the center of the mesh, basically to have everything just like it would be without CG shifting [19:37:14] its loaded as mesh 0 [19:37:25] at CM/SM sep I mean [19:37:42] and of course ShiftCG for the normal CG shifting during burns [19:37:51] whenever the CSM has become lighter [19:38:42] how is the VC shifted during Saturn staging? [19:39:14] we have a custom ClearMeshes() which only deletes mesh 1 and up, never the VC [19:39:39] let me look at the code again [19:39:48] indy91 are RTED and AST maneuvers not saved between saves? [19:40:02] UpdateVC [19:40:13] thats the function which shifts the VC [19:40:49] including Saturn staging [19:41:12] its at the bottom of saturnmesh.cpp [19:46:16] hmm [19:48:16] rcflyinghokie, they are not. [19:49:01] I think the only way to fix the clickspot issue may be to move away from the ShiftCentreOfMass call entirely [19:49:04] ok making sure it wasnt an issue on my end [19:49:10] but Im not entirely sure [19:55:14] ShiftMesh doesn't seem to update the VC clickspots [19:56:01] I guess that's the issue [19:56:55] so yeah, ShiftCG is the way to go [19:57:02] we have ShiftCentreOfMass in a lot of places [19:57:12] because there are so many staging options [20:00:09] right [20:01:33] although it's slightly confusing [20:01:49] oh no it's not [20:01:53] "centre of active area in the local vessel frame" [20:02:02] clickspots are vessel relative [20:03:03] so they have to be shifted separately from the mesh [20:04:36] which only ShiftCG can do right? [20:04:46] yes [20:05:00] don't think we could implement a function like Orbiter uses internally to do that [20:05:10] we could reload the whole VC on every CG shift [20:05:19] so any time ShiftCentreOfMass is called, the clickspots are doomed [20:05:28] hmm [20:05:38] ShiftCentreOfMass really only shifts the whole vessel I think [20:05:46] don't think that is what is breaking it [20:08:32] at staging UpdateVC is called to shift the mesh [20:08:40] it does shift the mesh, but not the clickspots [20:08:59] that is what breaks it [20:09:32] and when the VC is reloaded when you switch positions or so it reloads the clickspots at the right location [20:12:39] hmm [20:13:25] if you are using ShiftCG now with your CM/SM sep tests, maybe try it without the ShiftMeshe in the UpdateVC function? [20:13:55] since ShiftCG already does a ShiftMeshes [20:14:02] I'm not doing that yet [20:14:39] I'm just using ShiftCG to get back to the center of the mesh [20:14:44] the order is this [20:14:47] ah right [20:15:01] ShiftCG to revert the offset CG, at the start of SetReentryStage [20:15:14] then all the CM loading stuff is done, including VC shift in UpdateVC [20:15:21] and after all that is done it does [20:15:28] ShiftCentreOfMass(_V(0, 0, 2.1)); [20:15:43] that is to shift the whole CM forward so that it's at the right location [20:16:53] I don't want to get too deep into it in this CSM CG update, but I think I'll try if I could use ShiftCG for this whole operation [20:19:04] it might need a whole new concept for the order of operations [20:21:25] ShiftCG first, no UpdateVC and no ShiftCentreOfMass maybe... [20:22:55] that looked right from the outside at least [20:23:41] but most things that ShiftCG shifts get deleted and recreated right now anyway [20:24:29] that worked [20:24:34] VC clickspots not broken [20:24:40] camera shifted to a different position [20:24:57] that probably shouldn't happen [20:25:19] so maybe this isn't so complicated to implement [20:28:42] internal camera? [20:28:54] yeah [20:29:13] but I think the problem was rather that the camera position in the CSM with shifted CG wasn't right [20:29:21] thats in SetView() I think [20:29:25] SetReentryStage calls SetView yeah [20:31:31] hmm, compensating for the CG like I did in the LM VC put me right into the MDC [20:36:03] hmm [20:36:11] it seems to already compensate for that [20:36:17] // VC Offset [20:36:18] VECTOR3 ofs_vc = _V(0.0, 0.0, offset); [20:36:19] if (vcidx != -1) { [20:36:19] GetMeshOffset(vcidx, ofs_vc); [20:36:20] ofs_vc.z = ofs_vc.z - 0.15; [20:36:21] } [20:36:47] I guess that will already take the CG offset into account because the mesh is shifted [20:37:40] hmm [20:37:49] but not in all axes [20:38:23] ah, right [20:38:47] I didnt add x and y [20:38:59] no I was wrong, it's fine [20:39:32] it just puts that 0.15 into ofs_vc.z [20:39:41] but uses all of ofs_vc later on [20:41:08] the call to SetView just puts the viewpoint in the default position I think [20:41:43] if I don't call SetView then you would miss CM/SM sep if it wasn't for the master alarm :D [20:41:50] and clickspots still work [20:43:01] I think that's just normal behavior, like we have right now at CM/SM sep [20:48:53] there is also another issue where if you load a scenario that has a LM present, and the initial view is inside the CSM VC the cliskspots dont work [20:49:06] and its the same fix (shift view and back) [20:52:00] just LM present? Not even docked? [20:56:40] just present I think [20:57:33] weird [20:57:57] when I make the PR for this update I'll include the change to using ShiftCG, just for all configurations changes to the CM stage [20:58:05] will need a bunch of testing [20:58:25] other than I think I have most things taken care of [20:58:31] lots of scenario changes [20:58:33] still to do [20:58:51] for the SPS gimbal trim angles in the padload [21:06:29] makes sense [21:08:15] but it looks good, no visual problems like the VC mesh sticking out [21:08:23] and clickspots always keep working [21:10:07] will start editing the scenarios tomorrow, a bit more testing and I should have a PR of this update very soon [21:11:02] night! [21:32:51] Heh [21:32:54] https://www.orbiterwiki.org/wiki/File:Apollo-eyeballs-out.jpg [21:33:22] I just looked at this image from 2006 and even that has the Telecom bind failed issue. That was a long running bug lol. [21:49:28] yeah that message was there since forever [22:32:38] oh wow haha [23:25:35] night! [14:40:19] hey [15:37:39] hmm [15:38:13] "While there are optional simplified implementations of the CMC/LGC" thats from the description of NASSP on the main GitHub page [15:38:38] should probably be removed as we took that out ages ago [15:39:41] ah well I guess NASSP 7.0.1 is also among the projects on that GitHub page [15:54:24] Yeah, it can be taken out. Even at NASSP 7 release we didn't really support them anymroe [15:54:56] right [16:49:39] hey [17:16:02] hey Niklas [17:19:56] I was thinking about the system I implemented for the CSM CG [17:20:08] it's basically ignoring the actual empty CM and SM masses and CG [17:20:15] and uses the fixed values from the MIT simulator [17:20:25] morning! [17:20:30] hey Mike [17:20:51] but the J-type missions, probably because of the SIM bay, has a very different CG of the empty SM than the earlier missions [17:21:00] and a bit heavier [17:21:24] so where the trim angles we will get now are quite close to actual for the earlier missions, it's a bit off for the later ones [17:21:47] I wanted to just start using the trim angles of the flown padload [17:22:23] but for Apollo 17 for example that is not as close as I would like [17:22:58] flown padload: -0.578° in pitch, 1.892° in yaw [17:23:22] for a fully loaded CSM we would right now get: -1.66° pitch and +1.22° yaw [17:23:59] so I'm thinking about making the SM CG mission specific. And take the actual CM and empty SM masses into account [17:24:11] but then I also need to make the RTCC CG tables mission specific.... [17:25:01] CG of the fully loaded CM only varies by less than half an inch between missions [17:25:19] but the J-type mission SM is very different [17:26:23] so before I start editing missions scenarios I first need to make a decision there [17:26:40] right [17:26:51] quite a difference with the J missions [17:28:22] yeah [17:29:18] CSM-109: 10531.7 lbs, CG is at 918.8, -5.9, 10.9 inches [17:29:50] CSM-113: 13537.8 lbs, CG is at 917.3, 1.5, 1.0 inches [17:29:55] that is the empty SM [17:31:37] once I have implemented loading that from the RTCC file generating the CG tables shouldn't be too difficult [17:31:48] so I think I'll do that [17:34:36] makes sense [17:35:00] I don't have separate CG data for the empty SM for the earlier missions [17:35:06] but they should all be quite similar [17:35:26] did you have any more luck with the clickspots at staging? [17:35:41] I've had no problems with that really [17:35:44] well [17:35:50] I only tried CM/SM sep so far [17:36:01] with your changes? [17:36:06] yes [17:36:08] ShiftCG [17:36:15] but I would expect it's quite possible to implement the same logic for the other stagings [17:36:40] I guess that would be good yes [17:37:24] right now the clickspots get screwed at each staging and also through all the states of the CM [17:37:54] so at apex cover jett, etc [17:37:57] yeah [17:37:58] I won't include that in this update [17:38:11] but we can work on fixing all that afterwards [17:38:44] sounds good [17:38:56] but yeah it definitely should be a priority [17:39:40] Ill have to also figure out what causes the issue with the LM present [18:38:28] very close with the right SM mass and CG [18:50:21] for the J missions too? [18:52:26] yeah [18:52:43] I've only tried the MIT simulator values (based on Apollo 8 or 9) and Apollo 16 so far [19:21:19] don't we have an IsJmission() function? [19:24:01] hmm, actually mission specific probably makes more sense. better for future expansion. indy91 I can help edit mission scenarios if you don't want to do them all. [19:33:34] in other news I think I figured out why our helium acts weird https://photos.app.goo.gl/H1Ft25gGwx2YaJvq7 [19:35:29] my blue and red lines for the CG (actual vs. simulated) overlap more than that :D [19:36:33] for the mission specific values, I am adding it as a parameter in the mission class. Defaults to the SM CG we used previously and then you can, but don't have to override it in the mission file [19:37:24] the tricky thing with the mission scenarios will be that the correct numbers are a function of weight, so they won't even be the same for each mission [19:37:47] but thanks for the offer, if I can figure out a good system to calculate the right numbers for each scenario then I'll share that so you can help [19:49:11] could make a simple spreadsheet calculator [19:58:41] yeah I'll generate the RTCC CG tables and then I'll try to come up with something for the scenarios [20:29:43] fun, finding issues unrelated to my update... [20:29:51] our Apollo 8 SM is way too heavy [20:30:01] its empty mass includes the SM RCS propellant [20:35:51] total mass isn't off though, weird [20:36:28] that sounds suspicious haha [20:36:48] it's the same for the CM [20:36:58] I think both values were taken from the GSOP section 6 [20:37:18] Ryan has worked on spacecraft masses, but I believe he only updated Apollo 9-11 [20:38:56] or maybe I just loaded an Apollo 11 scenario by accident, which of course has a correct mass [20:39:30] Apollo 8 is indeed too heavy [20:40:01] all the RCS (CM and SM) is counted twice [21:07:06] whoops that's not good. [21:11:37] yeah, I'll correct that with this update [21:11:41] night! [23:55:22] I'm afraid I had to do one edit to my wet workshop scenario. I manually blew a pyro in the SIVb to indicate CSM sep occured and it stops creating a docking port that glitches the CSM as soon as I undock from the ASTP docking port [11:39:13] Thymo, what's your plan for the wet workshop SIVb? [11:40:24] Ooh, I just wanted to see how well that old scenario worked. Gives me an idea how well the default states are defined if they aren't present in the scenario but its mostly for fun. [11:41:31] The wet workshop has been in NASSP for a long time, it's just not actively used. Right now it's a regular SIVb with the ASTP docking port and the docking target from Apollo 7 attached to it. There's no actual mesh for it. [11:51:53] would be cool to do the Bellcomm Venus flyby at some point [11:55:19] Yep, we would need to come up with a Block 3 CSM though [12:51:42] wasn't there a plan to use two dps engines in place of the SPS? [13:37:41] good afternoon [13:41:07] Thymo, interesting glitch. The docking port there is for the nosecap on Apollo 5, and at some point for a CSM "docked" to the SLA. I kind of wonder if this should be prevented from happening. [13:41:47] On the other hand, all S-IVBs will have something docked to them there. And only on an old scenario would the pyro for it not be fired. [14:01:16] .tell rcflyinghokie got the new vapor pressure code in. minor pressure transient on older sceneriaos but nothing breaks as far as I can tell. will need a lot more testing [14:28:51] still tinkering around with the right numbers to use for the CG [14:29:17] I got a lot closer by increasing the total mass that can fit in the sump tanks [14:29:35] MIT simulator has a too small value for that [14:41:01] I was looking at plumbing diagrams for those last night. they're fairly complex. [14:43:01] yeah. But for the mass properties they seem to assume the same SPS propellant masses for most misisons [14:43:26] which is 23068.1 lbs in the sump tanks [14:43:34] MIT simulator had 22300 lbs [14:47:15] huh, that's not insignificant. [14:50:46] yep. In the graphs I am generating there is a sudden turn at the mass when the storage temp are becoming empty [14:50:54] and the location of that was wrong before [14:51:09] storage tanks* [14:58:35] ahh okay. yeah that would have a profound effect I would imagine. [15:03:07] enough to change the number for sure [15:03:57] right now I'm turning every number on its head, but over all I'm happy. Just have to generate all the RTCC CG tables again, which I already had done. [15:05:08] don't want to have to change every number again, if I find something later on that affects CG [15:05:15] hey [15:06:13] hey Alex [15:18:24] I discovered that not only Apollo 8, but also Apollo 10 had wrong empty masses [15:18:51] as with Apollo 8 it included the CM and SM RCS in the empty masses for CM and SM respectively [15:19:53] should we even fix that in the mission scenarios? Because then you kind of have to load the new number in V48 too [15:20:03] this is why I don't enjoy supporting mission scenarios... [15:22:37] ok, I think I have arrived at final numbers [15:24:08] btw, the RTCC had a different set of CSM CG tables for CSM propellant at the bottom of the tanks (CSM thrusting) and on top of the tanks (LM thrusting) [15:24:34] not loaded at the same time, but they could load the right one when it was required [15:24:44] I've based all calculations on bottom of tank numbers [15:25:02] that gives us SPS trim angles closer to actual [15:25:14] but I guess for e.g. docked DPS burn it will be slightly off [15:25:46] for a half empty CSM the difference between the two is of course big [15:25:58] up to 8 inches [15:26:01] in CG [15:43:14] https://imgur.com/a/BCBQdrU [15:51:17] pretty close [15:52:44] nice! [16:27:14] RTCC values seem to mostly agree with actual Maneuver PADs [16:27:42] but the actual CG calculations still are buggy [16:27:54] don't think the CG should be inside the SPS nozzle... [16:33:39] morning! [16:36:15] hey Mike [16:38:55] I saw Marc's first video about the Apollo S-Band equipment [16:41:33] :D [16:47:36] I'm glad it's finally out haha [16:47:50] Marc's been having a hard time between the lost audio and trying to figure out how to explain it all [16:51:05] right [16:51:09] he did a good voiceover [16:51:17] I remembered some of the numbers I saw in the video [16:51:42] from the IBM RTCC documents, we have the routines for calculating doppler shift stuff and light speed delay [16:52:29] yeah [16:52:37] BLMDFQ, Doppler Frequency Subroutine [16:52:53] BLMLPR, Generalized Speed of Light Delay Subroutine [16:53:55] oh neat! [16:54:00] I had no reason to implement them yet, but they are there [17:32:58] https://github.com/indy91/NASSP/tree/CSMShiftingCG [17:33:10] I think I am mostly done, except testing and scenario editing [17:35:05] woooo! awesome [17:54:56] hmm [17:55:28] I also implement new moments of inertia [17:55:31] implemented* [17:55:40] but I think I didn't change the axes to Orbiter... [17:55:55] so right now it's the pitch axis that is as "light" as the roll axis should be :D [17:58:11] indy91, great to hear ill give the branch a test [17:58:48] fix pushed [17:58:50] sounds good [17:58:58] the scenario changes are just for the MCC right? Like if I calculate my own burn with the RTCC MFD it will be ok? [17:59:12] the scenario changes are for the erasable memory [17:59:24] because the wrong trim gimbal angles are loaded in V48 [17:59:32] ah, right [17:59:58] in MCC scenario where it has saved an old Maneuver PAD that PAD would also have wrong angles [18:00:14] so should maybe be fixed as well [18:01:12] but any new calculation by the RTCC MFD and the MCC will calculate the correct angles [18:01:22] I guess a "repeat uplink" should re-run the calculation with the new angles [18:01:32] yes, that will fix it [18:19:15] one thing I might still tweak is the frequency at which the CG update is done [18:19:28] the number right now is every 100kg [18:19:42] so it checks if the mass has changed by more than 100kg since the last CG shift [18:19:55] that is about every 3.3 seconds with SPS burning [18:20:10] and that's slightly noticable, a small transient every 3.3 seconds [18:34:48] building the test branch [18:35:06] any particular burn that is best to test? [18:35:17] I guess a long one like LOI [18:37:36] sure [18:37:40] different missions, too [18:38:05] and because the ShiftCG for CM sep update is also part of this, any vehicle change that leads to the CM configuration [18:38:14] if it looks right visually from the outside and the VC [18:38:26] that includes pad aborts, also CM configuration after the abort [18:38:43] hmm [18:38:45] and if the clickspots work [18:38:52] the VC vies are changed [18:38:55] views* [18:39:03] oh [18:39:12] well then it does need an offset applied to them [18:39:14] I wasn't sure [18:39:40] when I separate the SM it snaps back to the correct position [18:40:04] what if you change between places in the VC? [18:40:08] does that fix it [18:40:21] nope [18:40:31] yeah needs the offset then [18:40:46] but I was trying that actually [18:40:56] it lead to me being inside the MDC [18:41:21] the CG is shifted backwards a lot compared to before for heavy CSMs [18:42:14] I see the clikspots work after SM sep though :D [18:43:01] oh I was wondering [18:43:02] VCCameraOffset [18:43:06] what is that variable [18:43:11] doesn't seem to be used for anything [18:44:16] I was wondering if I have to apply the offset to that, too, before I realized it doesn't do anything [18:45:47] yeah, doesnt seem to be used [18:46:01] if I handle SetCameraOffset the same way as I did in the LM then I end up inside the MDC [18:46:55] so what I did for the CM VC is use GetMeshOffset in ofs_vc [18:47:02] right [18:47:28] but only in the z axis [18:48:11] that's what I initially thought, but I don't think that's the case [18:48:27] GetMeshOffset loads ofs_vc directly [18:48:33] ofs_vc.z = ofs_vc.z - 0.15; [18:48:42] that just makes an offset to what it just loaded [18:49:02] but in the viewpos switch its only added to the z [18:49:12] case SATVIEW_LEFTSEAT: [18:49:13] v = _V(-0.6, 0.85, ofs_vc.z + 0.1); [18:49:13] break; [18:49:19] oh, I see [18:49:49] so in what way is the position wrong now, with the shifted CG? [18:50:08] shifted down and right I think [18:50:29] ah, so not wrong forwards/backwards [18:50:36] dont think so [18:50:46] then I think I need to do the same as in the LM, but leave z-axis zero [18:52:59] and I think I'll delete VCCameraOffset [18:53:04] right [18:53:16] this whole view function is already messy enough without unused variables [18:53:48] maybe it was originally designed as the variable to use for the updated VC view offset? [18:54:09] I had tried to use it for applying VC view offsets before but I think I could never get it to work [18:54:39] so thats why I ended up using GetMeshOffset [18:56:20] I'll search in old NASSP versions for that being used [18:56:24] there is also VCMeshOffset [18:56:42] VCMeshOffset only gets used for VCCameraOffset [18:56:43] which is updated by the mesh_dir in each stage [18:58:07] VCMeshOffset can probably go as well [18:58:47] those have been there since a very long time, probably when the VC was 1st added [18:58:56] yep [18:58:57] maybe GetMeshOffset didnt exist back then [19:01:18] hmm I wonder if saving/loading moves the CSM right now [19:01:32] the CG shift is only applied on the first timestep [19:01:37] not when Orbiter is loading [19:01:58] the position Orbiter stores in the scenario will be with the shifted CG [19:02:06] but then it builds the unshifted CSM at that same position [19:02:08] and then shifts [19:02:11] have to test that [19:02:15] with CSM/LV sep [19:04:26] SetCameraOffset(v - _V(currentCoG.x, currentCoG.y, 0.0)); [19:04:31] that seems to work correctly [19:04:48] apply currentCoG in all but the z-axis [19:05:20] great [19:05:54] so LOI-1 Apollo 10: PTRIM: +0.89 YTRIM -0.2 [19:06:41] Pitch and yaw trim (Noun 48): +0.95° and -0.17°. [19:06:47] from the actual PAD [19:06:52] close enough [19:07:40] yep [19:14:16] annoyingly the CSM is indeed moving [19:14:24] did CSM/LV sep [19:14:34] no thrusting, so perfect stationkeeping [19:14:45] and with each reload the CSM gets closer to the S-IVB [19:15:34] so each loading moves the CSM by the amount that the CG is shifted relative to the mesh [19:15:41] up to a 1 meter [19:16:11] I guess what I need to do is save the current CG and apply that [19:18:42] hmm [19:19:32] LM will already have the same issue [19:23:20] this is potentially really bad [19:24:22] in the worst case the CG offset needs to be saved and applied to every single thruster, docking port etc. [19:24:32] ouch [19:24:35] applied to during initial scenario loading [19:24:51] or [19:25:12] a ShiftCentreOfMass in the other direction :D [19:25:20] only at scenario loading [19:25:47] that sounds so cheaty it might even work [19:29:20] if I had a nickel every time I heard that line in NASSP work :D [19:29:37] our code likes like it haha [19:29:53] looks* [19:30:57] the last thing ShiftCG does is [19:31:04] ShiftCentreOfMass (shift); [19:31:08] be basically do a [19:31:10] ShiftCentreOfMass (-shift); [19:31:14] to cancel it out [19:31:54] it seems to work [19:32:03] but I want to test it some more [19:32:08] and then also check if the LM needs the same [19:32:45] LOI-1 went well [19:33:48] but for fun I did an TEI calculation following it, it gives me an 11600 Ft/s TEI [19:33:58] that doesn't sound so fun [19:34:17] what did you enter for TZ? [19:34:50] 180:00:00 [19:35:02] before it 150:00:00 [19:35:14] both gave similar DV [19:35:29] this is Apollo 10 post-LOI [19:35:42] ughh [19:36:00] ok I am dumb [19:36:12] I was using "specific site" [19:36:16] ah, fixed TIG [19:36:28] Lunar Search is the one [19:36:34] yeah [19:36:44] 2549 ft/s, much better [19:37:20] the 24h quicker return will have an acceptable DV then, too [19:37:46] 150:0:0 [19:38:18] 3037 ft/s [19:39:09] 104 [19:39:59] lol disregard that 104, I am trying to type in the RTCC MFD, not the chat :D [19:40:41] haha [19:41:59] ok, I can confirm that the LM has the same issue [19:42:14] where the initial CG shift actually changes the position of the LM [19:42:31] my test setup is CSM and LM exactly at the same position in space :D [19:43:52] maybe if I implement the fix for the LM as well the problem is gone [19:44:12] I wonder how SSU handles this... [19:45:01] hahahaha [19:45:06] Atlantis::clbkSaveState [19:45:12] / save default vessel parameters [19:45:13] // set CoG to center of mesh before saving scenario; otherwise, shuttle position will change slightly when saved scenario is loaded [19:45:14] ShiftCG(-currentCoG); [19:45:15] VESSEL3::clbkSaveState(scn); [19:45:16] ShiftCG(currentCoG); // reset CoG to correct position [19:46:17] they shift it to the center of mesh at scenario saving, but only for the Orbiter internal scenario data in VESSEL3::clbkSaveState [19:46:25] I like it [19:46:44] but I wonder if that does anything weird when docked [19:49:23] not any weirder than what we are doing right now [19:58:33] yeah I think I'll use the SSU version, I like it slightly better [19:58:57] "You can has PAD" lol our CAPCOM is needs to go back to grammar school once and for all [20:00:43] I think that was just a fun placeholder that dseagrav implemented [20:00:53] and I just never bothered to change it [20:01:51] sounds like a meme [20:03:36] what would you change it to? [20:07:35] hmm "I have a PAD for you" or "PAD" but its not that important really haha just found it funny that it hasnt ever been changed [20:12:32] back in a bit [20:58:30] night! [21:53:18] AlexB_88, any big projects on the horizon? [21:54:25] for now nothing big, probably just continue VC work [21:55:05] there are a few bugs that need fixing and things left to add in the LM VC such as the overhead window markings and COAS [21:56:15] I think the clickspots breaking at staging will be fixed soon [21:57:48] with indy91's testing branch for the CSM variable CG, the CM/SM separation is now done with ShiftCG so for that case (CM/SM sep) it is already fixed [21:59:05] but all the other staging's are done with ShiftCentreOfMass and that does not take care of shifting the clickspots...ShiftCG does so eventually they should all be changed to the ShiftCG function I think [22:59:27] going to checkout his branch now and do some testing [23:32:43] night! [03:25:10] .tell indy91 flew a few LOI-1s with your branch. Everything looks good, the only thing I noticed is that if I go to external view and then back in, I'm a bit low in the seat, but all the clickspots still work. [14:08:09] morning [14:16:25] hey [14:16:36] yeah, that's fixed now [14:23:48] and doing the ShiftCG at scenario saving seems to have no ill effects [14:24:08] not even for docked vessels [14:24:10] or landed ones [14:50:00] awesome. good news. [15:13:42] indeed [15:13:48] I was sure it would cause some problems [15:14:00] when loading a scenario with docked vehicles [15:14:27] I guess the ShiftCG forwards and then backwards doesn't give the Orbiter physics to update, so for a landed LM it makes no difference [15:14:41] time to update* [15:43:03] huh. good to know. [15:44:45] I feel like better CG-shifting api support can go on NASSP's "official list of new features we would like in Orbiter" [15:46:35] before we do that we should probably actually make use of the current API features haha [15:46:49] moving from ShiftCenterOfMass to ShiftCG [15:47:26] if anything I question the wisdom of the whole system of having the center of mass be the origin of the vessel coordinate system [15:47:40] center of mass is just for physics calculations [15:48:19] it might make those more complicated, but if it was separate from the center of the coordinate system then the API and addons would have an easier time [15:58:51] ok so for scenarios [15:59:04] I'll take care of the launch scenarios and the padload worksheets [15:59:19] not really sure what we do with the mission scenarios [15:59:32] you could call the RTCC MFD, DAP PAD [15:59:39] put the numbers in V48 [15:59:52] and save? [16:00:04] or convert them to octal and edit the scenario [16:45:41] yeah you could have a center of mesh and a center of mass [16:47:33] converting to octal and editing might be easier [16:48:46] can be easily done with the worksheet [16:49:08] although I am not sure that PACTOFF and YACTOFF are already in there [16:49:15] because they were zero before [16:50:59] but I'll add it [17:42:29] ok, got padload worksheets updated [17:42:34] all launch scenarios [17:42:49] and Apollo 8 and 10 CM and SM empty masses in mission scenarios [18:00:11] Evening [18:03:15] morning! [18:04:20] Hey Mike. What's up? [18:05:42] doing some research for my yet another new project lol [18:06:56] what are you up to? [18:08:32] Just sat down after an afternoon of dispatching first aid around at this dirt bike event for the red cross. Looking at Nik's padload changes now. [18:08:44] Probably gonna continue flying 8 in a bit [18:09:16] nice :) [18:18:42] indy91: Is "Allow edits from maintainers" checked in your PR? [18:42:20] Thymo, it says so, yeah [18:43:33] Hmm, I couldn't push to it. In either case I created a PR to your branch to fix a typo "Sescription" to "Description [18:43:46] If you merge that I'll approve the PR [18:44:39] ah ok [18:45:30] Merged [18:46:32] thanks [18:51:38] I stepped away for a few hours. was in the process of reviewing, haha [18:52:43] okay I can edit now. what missions should I do? [18:54:13] Apollo 7-11 whichever you want [18:54:30] I've already done a few Apollo 8 scenarios just to see how the process is [18:54:39] and because I had to edit the masses anyway [18:58:02] there will also be lots of scenarios where you don't have to recalculate the trim angles, because no major maneuvers was done in between [18:58:24] so you can use the same numbers as in the previous scenario [19:07:53] I think I'll start with 9 [19:08:54] sure [19:09:11] when it's all done I'll do another pass on Apollo 9, because I also need to give it DPS gimbal angles [19:09:16] for the docked DPS burn [19:09:25] which is probably what they had loaded on launch [19:26:03] Where can I find a description of scaling factors? I've got some stuff scaled as B-29 but I'm not sure how to interpret it [19:31:47] Norton manual is pretty good for that [22:11:07] well. I finished the Apollo 9 scenarios [22:24:04] n7275: What platform toolset is your VS install at? [22:26:44] oh my. I have no idea. [22:26:45] I'll will look. [22:28:50] Whenever I open the NASSP solution it starts complaining that it wants to upgrade to v142, it's currently on v140. I'd like to update it to the latest version. [22:31:43] v141 [22:35:21] Oh, are you using VS2017, or VS2019? [22:36:29] VS2019 [22:37:19] v141 is the VS2017 compiler. v142 is the VS2019 one. So you/NASSP are using the VS2017 compiler in the VS2019 editor basically. [22:37:58] That's not an issue per se, it just means you need to check it as v141 is not installed by default. [22:49:45] I'm actually still using 2017 for NASSP, had't upgraded yet. I have 2019 though. [23:11:22] ugh lightning knocked out the internet again... [02:52:04] Well that took a bit. Lightning took out the internet again. [10:55:09] morning [10:59:44] hey Matt [11:00:06] I merged your PR, and I am taking care of Apollo 8 and the DPS for the docked burn on Apollo 9 [11:00:20] if you want to continue you can do Apollo 10 and 11, if you want [11:34:44] I will start on 10, and see how far I get. [11:38:11] great [11:38:14] I'll do 7 then [11:41:55] are you using the spreadsheet to convert the angles to octal? [11:44:26] yeah [11:49:38] I got the sign wrong on the actual DPS gimbal angles at first [11:49:48] it liked that even less than the zero gimbal angles :D [11:50:48] the process to derive those angles to put in into V48 is weird, I wonder if the RTCC was even doing it [11:51:09] or if it just calculated and displayed the angles relative to the centerline [12:03:26] that doesnt sound good [12:28:37] it's not spinning out of control, but there is a large attitude excursion [12:29:26] the burn was done with the pitch and roll thrusters disabled (V65), but if you get weird behavior from the DPS then you could enable it again quickly (V75) [12:39:49] out of curiosity I disabled the gimbal motors on the apollo 10 LOI-1 until it built up a good attitude rate and then reenabled them. [12:41:45] did a full flip and barely missed gimbal lock. but eventually settled back on a stable attitude and concluded with less than 0.5 ft/sec residuals [12:42:10] haha [12:43:55] one thing I want to check is how the SCS is now coping with a LOI-1 burn [12:45:35] in theory it is holding an inertial thrust vector [12:45:42] in SCS Auto TVC [12:46:24] and it should cut off correct with the EMS [12:46:28] correctly* [12:46:46] which assumes that the RTCC is simulating the burn correctly with changing gimbal angles during the burn [13:00:05] how much extra dV do we use due to steering? [13:06:31] RCS or SPS? During an SPS burn? [13:11:31] LOI-1 with SCS Auto TVC only gives 10 ft/s residuals [13:11:59] basically all of it out of plane [13:43:03] sps [13:50:29] I think it's basically nothing [13:50:42] the gimbal angles vary such a small amount during a burn [13:51:07] if anything the lack of steering is causing the burn to be longer [13:51:32] LOI-1, like all others done by the CSM and LM, is done as a constant attitude burn [13:51:41] and that is not optimal [13:52:20] I think it's up to 10 ft/s that LOI-1 is spending more than a fully optimized burn with steering [13:52:37] they did a lot of analysis in the RTCC for that, doing LOI-1 with P31 lambert aimpoint guidance [13:52:55] in the end they decided the easier procedure for a constant attitude burn is more important than saving 10 ft/s [14:26:22] yeah that makes sense. [15:31:34] trying to make it back to my desk to finish the editing today... [15:49:42] morning! [16:06:13] hey [16:06:33] rcflyinghokie, do we not have the full Apollo 9 LM Systems Evaluation Checklist? [16:06:38] I thought we did... [16:06:47] but I can't find it in my documents [16:06:59] let me take a look [16:07:34] I only have a few pages of it [16:07:39] yeah, same [16:07:45] then I misremembered [16:07:56] we have the full EVA and rendezvous activation checklists [16:08:19] Yeah [16:09:02] n7275 thats great to hear, I will set up a test LM this week to try it out [16:12:45] thewonderidiot, you have new projects... again? :D [16:14:22] just doing some real work on this core rope reader haha [16:14:36] ah yes [16:15:06] sadly it's not going to convince museums to give us rope modules any more than the full AGC did [16:17:58] rcflyinghokie, https://github.com/n7275/NASSP/tree/VapPressAndHvap [16:18:27] awesome I will set that up on my LMECS branch and make some test tanks [16:18:34] still need to make some minor adjustments to helium, glycol, and NTO [16:19:24] yeah I am sure [16:19:44] Another thing I was thinking wrt the phase changes is how the evaporators are going to handle it [16:20:38] indy91, no, but it will let us at least get Aurora 88 and Comanche 67 sooner [16:20:44] yep [16:22:54] as long as the pressure is in the 1-5 bar range it should be close to the linear approximations [16:24:01] if there are major adjustments needed it would be better to wait until the enthalpy of vaporization update is done too. [16:26:42] ok, Apollo 7 scenarios edited [16:26:49] so we have Apollo 7-9 complete [16:29:39] docked DPS burn behaves fine, but I think I want to create a graph to see how the DPS moment arm works there compared to what the LGC predicts [16:30:16] I'm about half way through 10. [16:30:38] I can do 11 later on [16:36:10] indy91 also want to look at the Apollo 13 DPS behavior as well since thats a full SM attached [16:36:25] right [16:36:41] I probably have a scn if you need it [16:36:49] I'm sure it's fine, the graph will already tell us if it's going to be good [16:36:54] it should be better than before really [16:36:57] haha ok [16:41:08] but good thinking with Apollo 13, I didn't really think about potentially testing that [16:47:54] The last Apollo 10 Scenerio is before the TEI pad right? [16:53:17] yeah, I got lazy and didn't actually create all the scenarios [16:53:28] I was dreading the landmark tracking day haha [16:53:45] uh wait [16:54:05] Apollo 10 - 15 - After Docking T+106h20min [16:54:11] this is the last Apollo 10 scenario [16:54:15] not before TEI [16:57:25] well technically before TEI, just 2 days before [16:59:54] okay good. will commit and push in a few minutes. out picking up lunch. [17:21:48] ok so the LM calculations for the DPS are a fairly simple polynomial, with two variables, CSM mass and LM mass [17:22:39] https://i.imgur.com/nI7t34R.png [17:23:09] the yellow line behaves like I expected, at some specific mass the old, static CSM CG is correct [17:23:29] I was hoping that the LGC and our new behavior would agree more [17:23:33] but this is for a full LM [17:24:35] https://i.imgur.com/dzEyExi.png [17:24:41] this is for DPS propellant 50% burned [17:24:47] a lot closer [17:25:02] so the coefficients of the polynomial are probably optimized for a mid range LM mass [17:25:17] there it is the most correct, while for 0% and 100% DPS propellant it's a bit off [17:26:22] For completion, 0% DPS propellant left: https://i.imgur.com/TI5IDcx.png [17:27:53] in all cases it's a good improvement for the case of a heavy CSM [17:31:29] certainly better, any way to further optimize? Also the dip in the middle? [17:33:52] I think our new behavior is actually closer to the correct CG than this model that the LGC uses [17:34:26] the dig is the point where the SPS storage tanks are becoming empty and the sump tanks are start getting used [17:34:40] that is also why in the graphs for the SPS trim gimbal angles there is a change of direction [17:34:50] dip* [17:35:13] oh even better then [17:35:43] compared to the old CG, the actual one is about a meter more towards the SPS nozzle for a heavy CSM [17:35:50] it's about right for 1/3 SPS propellant [17:35:59] and then of course shifts further and further forward [17:36:15] also, maybe a QOL change, but would it be prudent in the entry RTCC to set the unspecified area to start on FCUA instead of TCUA since it will be used more frequently? I know its simple to just type FCUA but just a thought :P [17:36:21] I bet that is no accident [17:36:31] probably done with Apollo 7 in mind a long time ago [17:36:56] Ahh that makes sense [17:36:58] yes, that can be easily changed haha [17:38:44] the MED doesn't default to TCUA either, it gives an error if neither FCUA or TCUA is entered [17:38:53] so I can't even say it should be TCUA because that's the default :P [17:44:14] committed, pushed, PR sent [17:46:35] and merged [17:47:36] nice [17:49:21] so just Apollo 11 left, and some creative testing [17:49:56] I'll probably check again if the ShiftCG upon saving/loading is really not doing anything weird. [17:50:46] I've already tested that, but if I am doing it a few more times then I feel better about the update not causing issues that we only find some time later... [18:45:32] probably a good idea. [18:58:09] one thing that is not taken into account yet is SM RCS usage [18:58:27] the the RTCC CG tables are based on total mass [18:58:50] so if a lot of RCS has been used then the table would be off a little bit from the behavior we get in NASSP now [19:04:09] I didn't really want to introduce a second variables. Right now it's only based on SPS propellant, the other number used (e.g. CM empty mass) are all mission constants [19:06:35] if I would include the SM RCS in the CG calculation I could use an assumption like, the quads are going to be used equally. And 50% of the RCS is used during a mission, or so [19:11:01] but I don't expect the SM RCS to do much with the CG, the CG location of the SM RCS tanks is very close to the CG of the full CSM for near empty SPS propellant [19:12:20] ok, scenarios are all done :D [19:32:26] nice [19:42:11] yeah, I imagine that a in most cases the diference would be rounded off any way [19:45:59] *"in most cases" [19:47:07] at least not significant enough to update all mission scenarios again :D [20:33:57] haha yeah. [20:35:51] how are we going to keep these updated when we have 7-17 + skylab [20:38:35] we just don't, we only update them for major release [20:51:19] night! [14:07:45] good morning [14:08:41] my branch now has the fixes to glycol, helium and N2O4, if you want to try it [14:08:50] hey Niklas [14:09:13] hey [14:10:48] found one more issue with the shifting CG. Vessels that are created from the CSM have to have the CG offset applied to them [14:11:12] that is the optics cover, SIM bay panel, docking probe, if they are jettisoned from the CSM [14:11:26] ahh yeah that could be a problem [14:11:42] I imagine the fix isnt too bad though? [14:12:22] yeah it's easy, the CSM keeps track of its offset to the mesh [14:12:28] just have to apply that [14:12:52] in addition to the normal offset where the new vessels of optics cover etc. are created [14:13:23] I guess in theory I also have to use it for some more rare cases [14:13:27] like the LET on the CSM [14:15:16] yeah, I should add that [14:28:08] interesting [14:28:47] it didn't seem to do the CG shift when I did CSM/LV sep with the LET still on the CSM [14:30:06] but LET still got created in the wrong location then [14:30:53] n7275 thats great would it be best to try it from a fresh scn? [14:35:10] CSM looks really weird with the LET [14:35:20] the LET is almost as tall as the CSM itself [14:38:45] rcflyinghokie, I've had luck in mid mission scenarios as well as fresh ones [14:39:08] sounds good [14:39:12] in the csm theres a brief suit compressor alarm then an O2 high flow [14:39:21] and then things settle down [14:39:30] make sense as things equalize [14:40:16] I think it's just the "puddles" of previous-version, room temperature lox boiling off, lol [14:41:39] indy91 speeking of the LET, i discovered yesterday that we still have a Little-Joe mesh. [14:42:06] yeah we have a bunch of unused meshes [14:42:16] milkstool for LC-39, too, I believe [14:42:53] so we can simulate the entire Apollo-Saturn program then haha [14:43:37] the first flight for that was SA-1 thought in 1961 [14:44:13] though* [14:44:55] n7275 I will say we need to watch the CSM side as its pretty hacky with respect to the plumbing of everything/heat exchangers etc [14:45:27] yeah it's easy to bring the CSM ECS out of balance [14:45:41] the few small changes I made to it already were tricky [14:47:04] my hope is: 1) these changes dont break anything that wasn't already broken. 2) they allow us to impliment better systems simulation down the road. [14:48:45] makes sense [14:49:07] thats why i am going to be testing a lof of these with the LM [14:49:09] oh interesting, when you do LET jettison with the CSM (or any stage really) then it loads all meshes agan [14:49:27] but the offset CG isn't applied to it again [14:49:29] simpler plumbing and, since I plumbed it, I have an idea of where things should go and the behaviors haha [14:50:19] but I can do the same as in the LM [14:50:39] make sure that the CG gets updated when SetCSMStage is called [14:51:32] hopefully we can eventually get rid of reloading all the meshes [14:51:40] with ShiftCG that should be unnecessary [15:08:35] hmm [15:08:42] not so easy to solve actually [15:15:49] morning! [15:16:55] hey Mike [15:19:13] hey Mike [15:20:56] I hope calling ShiftCG with a zero vector is no problem [15:27:20] hmm [15:27:29] tower is still not created in the right position [15:28:02] is someone in a branch without the shifting CSM CG and can test a launch? [15:34:14] is the shifting cg merged into the orbiter 2016 branch? [15:34:20] no [15:34:53] well now I am already building the Orbiter2016 branch myself, so I can test it myself haha [15:35:04] ah ok I was going to say I am in a branch without it [15:35:27] I feel like the LET vessel is already not created in the right position even without the CSM CG update [15:35:33] when you have CSM+LET that is [15:37:09] its created on tower jettison, correct? [15:37:46] yeah [15:38:18] when I do tower jettison with CSM+LET the LET appears inside the CSM [15:38:33] and I feel like I have fixed the issues that come from the shifting CSM CG [15:38:39] but it's still wrong [15:38:45] so I think it might have already been wrong before [15:39:17] of course a rare configuration [15:40:37] ah yeah I see the problem [15:40:52] it's created with the same offset for both CSM and CM [15:41:39] confirmed [15:41:44] already was wrong before [15:48:51] one thing I am noticing in all this is that we have way too many empirically derived numbers in all the offsets used for loading meshes, the RCS etc. [15:49:41] no idea where the numbers come from, if they actually correct etc. [15:49:50] and difficult to change anything without breaking stuff [15:52:56] I made that a little bit better in the LM when I implemented the shifting CG there [15:53:01] but the Saturn class needs work [16:01:24] ok, that bug is fixed. The LET just needed to be created 2.1 meters further forwards, which is distance between the center of our CSM and CM meshes [16:06:20] jettison behave normally still? [16:06:42] Of course I have no idea how it actually was, but it still seems to be awfully close when the stack flies past it again [16:06:52] right [16:07:03] it actually used to be even closer before I made some adjustments [16:07:38] I can take a look at that again. The main simplification I am doing there is that it's constant thrust [16:07:57] while the real jettison motor being a solid motor wasn't very constant [16:08:28] but I thought in terms of total impulse it should be quite right already [16:08:38] and the changes I did shouldn't affect normal LET jettison [16:08:52] only with the CSM stage [16:09:19] but I'll do a pad abort and a nominal tower jettison to make sure [16:11:49] oh no [16:12:52] the drogue chutes were completely wrong [16:13:02] like 30 meters lower than they should be [16:14:03] doesn't happen with pad abort [16:14:07] but Mode 1A [16:14:18] I hope it's not random [16:15:57] not random [16:15:59] but very weird [16:17:55] https://i.imgur.com/3DMs7fx.png [16:19:08] it doesn't even go through the CSM stage during a Mode 1A abort, so I have no idea how this could be caused by the CG update [16:19:19] ... [16:20:29] I of course also implemented ShiftCG to be used by any configuration change to the CM stage [16:20:37] that is what must cause this [16:22:37] well that certainly looks odd lol [16:23:07] must be an attachment problem [16:23:17] the chutes are connected via attachments [16:24:08] oh yeah. attachments are weird [16:24:49] I fear bad things for TD&E [16:24:57] almost looks like they're attached to the center of the saturn 5 mesh + the offset for the cm [16:25:30] we have the attachments in the Saturn5.cfg [16:26:14] previously they probably were always in the same position, no matter the current configuration [16:26:17] full Saturn V or CM [16:26:30] but now that I am using ShiftCG instead of ShiftCenterOfMass [16:26:34] they get shifted [16:27:36] vessel->ShiftAttachments (vs); [16:27:46] ShiftCG does indeed shift attachments [16:27:53] that's a problem... [16:29:17] the variable CG csm is too good of a feature not to fix this though. [16:29:23] yeah [16:29:47] maybe I can put the attachment point where it was before in SetReentryStage or so [16:43:59] the attachment points are always at the center of the CM [16:44:24] what we should probably do is choose an actual spot where they attach and allow any ShiftCG to shift it around [16:45:09] and maybe not define them in the config file [16:52:50] yeah [16:53:27] we should probably add some comments to anything dimensional saying where we got the measurement [16:55:14] always a good idea [17:24:25] resetting the attachment points of course fixed it [17:24:48] but this seems like a duplicate because the same numbers are already in the config... [19:46:52] rcflyinghokie, I've re-checked the tower jettison motor performance, all numbers check out [19:47:16] the only difference I could see is that the motor is pulling the LET more to the side than we are currently getting [19:47:20] well thats good to hear [19:48:27] more sideways than forwards [19:48:39] maybe another moments of inertia thing [19:49:37] a bit more clearance wouldn't hurt. getting hit by the saturn would be bad [19:50:08] I think the thrust vector we use is correct [19:50:33] there are two nozzles, one is at a 30° angle, the one on the other side at 22° [19:50:53] so you get an effective 4° thrust vector to the side [19:52:00] so it can only really be the thrust application point relative to the CG or moments of inertia [19:56:21] I only have numbers for the full LEV for that though [19:56:55] we use [19:56:56] SetPMI (_V(20, 20, 10)); [19:57:00] for the LET [19:57:19] if it was the CM+LET then it should be more like (15, 15, 1.0) [19:58:08] I wish we had a better idea of the actual clearance, maybe it just looks close to me? [19:58:38] yeah, the separation & recontact documents don't seem to talk about the LET at all [19:58:45] but we might have some document that talks about it [20:14:27] "The lateral-separation maneuver ensured a minimum [20:14:28] miss distance of 150 feet" [20:15:59] hmm that doesnt seem like much does it [20:16:13] it's a minimum [20:16:45] oh and also, I think our tower jettison motor starts up immediately when the tower is jettisoned [20:16:54] and burns at 100% the whole time and immediately [20:17:08] that's making it burn out a bit earlier than the real one [20:17:20] which is making it not pull as much to the side [20:20:27] but the whole thing is over quite quickly, it only burns for 1 second [20:20:51] real one reaches max thrust at 0.2 seconds and then burns constantly until 1.2 seconds [20:22:14] I'll make it burn a little longer and change the inertia from 20 to 15 [20:22:29] yeah I am curious as to the result [20:29:03] well it's a bit more [20:29:33] I think it did stay above the minimum distance [20:30:34] but it was probably quite close before [20:57:29] night! [22:52:50] so coming up on 284 hours, CMRCS indicating 5C: 3.2 5D: 4.1 6A: 4.3 6B: 3.1 6C: 4.9 6D: 4.8 with actual from this phase in the mission being CMRCS indicating 5C, 4.5; 5D, 4.6; 6A, 4.1; 6B, 4.4; 6C, 4.9; 6D, 4.4 [22:54:45] Maybe just a tad low but looks pretty good [22:55:27] yeah just a tad [22:55:50] the only two that are below the 3.9V threshold are the 2 pitch jets so I am wondering if I need to tweak their position [22:57:01] I will be testing the heaters next and if they look good I think its safe to commit with the expectation of small tweaks going forward [23:04:05] Yeah, sounds good to me. [07:41:22] .ask I'm curious as to what Visual Studio version you're using. With Orbiter development work based on VS2019 I'd like to upgrade NASSP to use the VS2019 tooling versions so we only have to keep one install. [07:45:47] .ask indy91 I'm curious as to what Visual Studio version you're using. With Orbiter development work based on VS2019 I'd like to upgrade NASSP to use the VS2019 tooling versions so we only have to keep one install. [13:45:17] hey [13:45:27] I use 17 [13:45:35] I'm fine with upgrading to 19 [13:46:01] I have all versions from 2010 to 2017 installed right now :D [14:07:48] Okay then everyone will need to go into their VS installer and upgrade to the v142 platform tools if using 2019 or upgrade to 2019 if using 2017 [14:08:20] I already have the upgraded project here https://github.com/orbiternassp/NASSP/tree/vs2019 [14:10:09] ah great [14:10:15] installing 2019 right now [14:11:38] and I think I am done with the CG update. I can always convert a draft PR to a full PR, right? Just want to look at it at first [14:13:40] Yeah, you can change from the one to the other as often as you like [14:14:13] ok, done [14:14:26] I just tested a TD&E and I can report it behaves a little bit different [14:15:01] at first I thought it was more difficult, because of a different CG and slightly smaller mass normalized moments of inertia for a heavy CSM [14:15:15] but actually I think it's more intuitive for a heavy CSM now [14:15:42] the CG is behind the RCS quads now. Which means if you need to translate up you now induce a pitch up moment, too [14:16:06] before it was a bit counter intuitive. Thrusting upwards gave you a bit of pitch down moment. [14:16:33] so you had to wait a moment for the att hold to kick in before judging in which direction you are actually going relative to the LM [14:17:15] previously the CG was slightly forward of the RCS quads [14:48:22] Awesome. I'll try to get your PR reviewed before dinner, if not later this evening. [14:50:16] .ask thewonderidiot Did the DSKY have a "color code" or other form of specification other than "green"? From video material I can tell the mission timers are also a cyan color but I'm not sure if its the same cyan or not. Might need to change the colors in NASSP for those too. [14:58:41] indy91: That kid we fixed the RTCC time for had an TEC MCC6 of ~5000 ft/s while MCC5 was scrubbed. Some kind of overflow? [14:58:43] https://cdn.discordapp.com/attachments/809545464331370506/889880775196049458/A8_Before_MCC6_11_hours.scn [14:59:14] Haven't gotten a chance to check his trajectory yet but if 5 was scrubbed there's no way I'd expect MCC6 to be this large. [15:00:05] I'll check [15:01:50] not a good trajectory [15:01:59] surely a TEI problem already [15:02:17] Yeah... it wasn't perfect. [15:02:26] if I recalculate MCC-5 it doesn't get scrubbed [15:02:32] 2200 ft/s [15:03:30] any potential problem solving has to start before TEI then [15:05:25] alignment is bad [15:05:34] I watched it. At some point during TEI he had TVC oscillations due to heavy lag and he had some pending uplink (SV probably). [15:05:40] I'm not surprised. [15:06:28] Any idea why MCC5 got scrubbed in his case? Couldn't find a solution in time? [15:06:32] state vectors are bad, too [15:06:51] hmm, don't think that would cause a scrubbed message [15:07:00] maybe some missing error handling [15:07:19] MCC5 calculation returned no DV at all, so it thought it was 0 ft/s [15:07:21] maybe [15:07:57] could the scenario be affected by the time acceleration/threading bug? [15:08:19] but I guess terrible framerate will also cause TVC oscillations [15:09:19] ok one thing the Apollo 8 MCC does is uplink the REFSMMAT directly [15:09:20] No, not since I applied that fix. I'm not sure what scenario this is originating from (he keeps switching) but it's either a fixed one or a mission scenario. [15:09:33] they did that one Apollo 8 [15:09:44] there is a lunar entry REFSMMAT uplink shortly after TEI [15:10:17] and assuming that the trajectory doesn't change much, they uplinked a entry REFSMMAT directly [15:10:33] which means you don't have to do P52 option 1 [15:10:43] and you will get larger torquing angles with a P52 option 3 [15:10:53] that might all break down if the trajectory is bad [15:10:58] but that's only one problem in this scenario [15:12:26] clearly the problems start with TEI, or else you wouldn't get this trajectory [15:12:57] totally possible that it's a MCC or RTCC bug [15:13:02] there was one last time as well [15:14:40] Nah, apart from that MCC5 oddity I don't think there's anything going on. I'm confident this guy has shit for brains at this point. He never listens to the advice we've given him so far. [15:17:04] you can ask him for a scenario just before TEI if you want [15:17:21] or just tell him to check everything and redo TEI [15:21:45] he is pretty young, but yeat its a bit frustrating to have to explain the same things over and over again....he treats it like a video game sadly which is fine...if he isnt asking us what he did wrong all the time [15:26:12] hey Ryan, what's your strategy during TD&E when it comes to attitude rates caused by translational RCS firing? [15:30:11] Assuming CMC control on the attitude? [15:31:27] yep [15:31:42] there is a deadband [15:36:17] Does EmptySMCG every change? [15:36:35] Does it need to be writable or can it be marked constant? [15:36:51] it's loaded from mission files [15:36:52] optionally [15:37:14] if (oapiReadItem_vec(hFile, "EmptySMCG", vtemp)) [15:37:15] { [15:37:15] EmptySMCG = vtemp; [15:37:16] } [15:37:31] Okay! [15:37:36] it's different for the J-type mission only right now [15:37:44] SIM bay equipment making that quite different [15:38:19] missions* [15:44:15] Thymo, thewonderidiot, would be interesting to film the dsky we have with a 16mm filmstock that's close to that of the era. [15:49:50] Sorry got dragged into a meeting indy91, using CMC control I usually thrust one direction at a time and wait for the attitude to null before firing again [15:50:00] aha! [15:50:16] yes, that's because thrust up causes pitch down [15:50:21] yes [15:50:22] but not any more [15:50:34] the fixed CG we had is forward of the RCS quads [15:50:40] ohh [15:50:45] but for a heavy CSM it is not behind it [15:50:47] now its more centered on the quads? [15:51:12] not centered for a heavy CSM, even further away from the quads I think [15:51:23] and a heavy CSM now also has slightly smaller moments of inertia [15:51:38] so I just did a TD&E test and it felt quite weird haha [15:51:57] it's the opposite effect and stronger than before [15:52:00] Interesting [15:52:13] well then my technique should still work :P [15:52:33] we will have to get used to it, but it's maybe more intuitive as translational thrusting causes the CSM nose to go to the right direction [15:53:07] yeah the opposite direction was a little weird but I guess, like the rate needles, I adapted [15:53:38] but I did the same before. A bit of translation and then wait until it settles to see in which direction it moves [15:54:53] yep, I also try keeping track of how many pulses I use to make a change so I can better null it [15:54:58] even for Apollo 7, which only launched with 1/3 of SPS propellant the CG is slightly behind the RCS quads [15:55:36] I hope the mission report can confirm that [15:56:00] Ohh that reminds me, the position vectors for items in the config files, are they based on the current whole vehicle? For example, the cm rcs thrusters where is that position 0 0 0 located? [15:56:31] And does it change when say the CM separates [15:57:00] which config files [15:57:15] \Config\ProjectApollo ? [15:57:21] for vessels? [15:57:23] or the mission files [15:59:12] ah sorry, saturnsystems.cfg in this case [15:59:34] uh oh [15:59:59] hmm [16:01:20] Could pose an issue for the CM and LM when adding these [16:01:21] ok for a moment I thought the shifting CG could do bad things [16:01:31] but the logic doesn't really care I think [16:02:17] I just want to know where that 0 0 0 position is located for the vehicles and if it changes when you stage (LM staging or SM jettison) [16:02:19] it just cares about the direction of the sun etc. [16:02:32] there is a dot product [16:02:39] e.g. there is a sun unit vector [16:02:56] it does a dot product with the vector you use for the system in the config [16:03:01] But where is the zero point on the vehicle [16:08:44] I don't think it really matters [16:08:58] your vector in the config file is two things [16:09:09] a direction and a magnitude how much heat it lets in/out [16:09:25] direction in the vessel coordinates [16:11:59] it's not very intuitive as it's not an actual position in the CM or CSM [16:12:07] it's really just a direction [16:15:20] for the CG, RCS quads are at 958.9 inches [16:15:42] Apollo 7 CSM CG was 950.4 at SPS-1 [16:15:55] and doesn't move forward of the RCS quads until SPS-5 [16:17:28] I wonder how the sdk actually treats something at (0,0,0) because it's a direction, that should be a singularity [16:19:06] all of those directions should be normalized to length =1. I cant remember if the dot product with the sun vector does this [16:19:57] ideally, I would think it would take the special case of a zero vector as omnidirectional [16:20:18] rather than just giving NaNs [16:20:55] morning! [16:21:31] Thymo, the specifications for the panels give a wavelength but not a spectrum [16:22:01] what I really want to do is get Ben over with his optical spectrometer [16:24:22] hey Mike [16:24:33] n7275, it doesn't normalize the position vector of the thermal system [16:24:46] so the length of that vector actually matters [16:24:54] a zero vector just completely isolates it [16:24:58] no Q going in and out [16:25:10] ahh [16:25:25] not for Sun, radiation, albedo and that stuff at least [16:25:57] that's the opposite of how I'd do it considering theres a seperate isolation factor. [16:27:29] yeah the isolation is then applied to the whole Q [16:29:45] I'm glad I normalized the new eps radiators then [16:31:46] well all of my rcs jets look good other than the 2 pitch jets which are a touch cool [16:45:49] what are their vectors? [16:46:16] maybe the size of the vectors is smaller? [16:47:35] <0.0 0.2 0.2> [16:48:02] https://github.com/rcflyinghokie/NASSP/blob/JMissionCSM/Config/ProjectApollo/SaturnSystems.cfg [16:48:09] line 610 [16:48:53] CMRCSPITCHJET23 <0.0 0. 0.0> 273.15 [16:48:56] is that intentional? [16:49:13] no that is fixed in my local copy [16:49:41] all these vectors are between 0.22 and 0.3 in lengthy [16:49:43] length* [16:49:47] but those arent measured anyways [16:50:30] So the voltages are jet 24: 3.2 25: 4.1 12: 4.3 14: 3.1 16: 4.9 21: 4.8 [16:51:07] so 14 and 24 are low [16:51:16] yeah which are the 2 pitch jets [16:51:41] both have 0.0 0.2 0.2 [16:51:48] yes they are right next to one another [16:52:03] the direction where the sun shines on them the most on them will be different from the others of course [16:52:12] yep [16:52:15] but in terms of size they aren't that different [16:52:25] there are some with 0.3 [16:52:50] Yeah I set all of these initially pretty arbitrarily as a starting test point [16:53:36] open to tweak suggestions based on the temps [16:54:45] if I understand it correct then those vector basically mean, the most heat goes in/out of them when you point the main windows of the CSM at the sun [16:54:54] between Y and Z axis [16:56:10] Orbiter axes [16:57:39] going to bump them up a touch [16:59:14] so this is just with normal radiator class and thermal class heating and cooling [16:59:16] but all in all not a bad starting point [16:59:17] no heaters? [16:59:19] correct [16:59:36] I mean, I would just say you didn't point them at the Sun enough [16:59:42] but maybe they just need to be more isolated [17:00:03] well I flew all the maneuvers during this mission [17:00:10] all the flight plan attitudes [17:00:19] other than some in lunar orbit [17:00:44] do we have numbers from actual missions? [17:00:55] yes [17:01:09] CMRCS indicating 5C: 3.2 5D: 4.1 6A: 4.3 6B: 3.1 6C: 4.9 6D: 4.8 with actual from this phase in the mission being CMRCS indicating 5C, 4.5; 5D, 4.6; 6A, 4.1; 6B, 4.4; 6C, 4.9; 6D, 4.4 [17:01:19] mine compared to actual at the same checkpoint [17:02:26] not terribly far off [17:07:12] I can grab them from all missions as a comparison [17:07:23] but I got those actuals from the transcript [17:11:48] I guess PTC should make it nice and even [17:12:03] well I flew every PTC [17:13:06] in reality [17:13:19] not with our weird thermal and radiator classes :D [17:15:08] fair point! [17:15:32] I think I am going to bump up a vector 0.05 on those and let it ride for my next full flythrough [17:15:57] My concern right now is the heaters being too powerful which I am going to test today [17:20:13] could be [17:20:20] I guess it's Apollo 17 next? [17:20:29] with the CG update then [17:27:02] hey [17:28:13] indy91, Ill give your branch one last quick test and Ill review the PR [17:29:02] sounds good [17:29:05] Yep 17 next! [17:29:15] you can try a TD&E next, that feels different now [17:36:46] ah interesting, because of the modified PMI? [17:38:20] that too [17:38:37] but the CG is now aft of the RCS quads and not in front of it [17:38:58] translation up/down left/right causes a small rotation, too [17:39:15] but the polarity of that is now the opposite of before [17:39:53] before e.g. translation up caused pitch down [17:53:10] ah yeah I see that [17:53:17] good docking [17:54:30] I guess now you do a translation and you think you are already centered but the translation caused a fairly large rotation in the same direction [17:55:06] I already tested a GNC controlled burn docked and undocked a few days ago also SCS burns [17:55:16] so I think its good to go from my end! [17:56:37] the last bug I found was ShiftCG shifting the attachment points for float bags and the chutes [17:57:03] so during a Mode 1A abort the chutes attached at a very wrong point [17:57:23] I will fix the VC for the CM during entry next and will need to revisit that [17:57:31] the attachment points are simply at 0,0,0 [17:57:45] and defined in the vessel config file right now [17:57:46] ah right [17:57:53] I think I'll move that to code [17:57:59] and not create them until they are needed [18:11:14] I've been working on a secret project. A major visual enhancement. First picture here: https://i.imgur.com/9Ls5ixo.png [18:11:55] man my gpu had to work to render that [18:11:59] nah I just found NASSP 3 for Orbiter 2002 and got it working without problems. [18:13:14] oh wow haha [18:13:40] there already was an Orbiter Sound for it apparently [18:13:55] would be fun to put together a "history of NASSP" video [18:14:15] yeah Orbitersound 1 released in February of 2002 [18:14:21] iirc [18:14:42] nice! I think I did the same a while back [18:15:12] thats the 1st version of NASSP that I had used [18:16:03] hmm what is EMP509 [18:17:31] "Inhibit Gimbal Lock Monitor Downmoding" [18:17:57] inhibits coarse alignment of the IMU when the yaw angle gets greater than 85° [18:18:10] Ah [18:20:00] Yeah they had erroneous gimbal lock indications [18:22:21] To prevent caging the plat form if the erroneous gimbal lock indication recurred, the crew used an eras able program whenever the thrust vector enable relay was used. This program inhibited the computer from changing the coarse align relay. [20:28:47] rcflyinghokie, I found a H_vap equation I like. it's from 1972, not 1772 so that's good [20:29:00] haha! [20:29:07] 200 years of improvement [20:31:12] Carruth-Kobayashi [20:32:50] all it needs is a acentric factor and critical temperature [20:43:24] thats one I dont think I dug into in college [11:27:51] Hey Nik [11:28:36] hey [11:28:40] just commenting on your comments [11:29:08] Yeah, I noticed the emails coming in :) [11:29:20] haha, one for each, ouch [11:32:53] did find one more bug, too. I thought I had by accident fixed the issue where VC clickspots don't work when the chutes open in the CM. [11:32:59] But he whole VC was just shifted wrong [11:33:14] suddenly a tunnel and docking port appeart inside the cockpit... [11:33:19] appeared* [11:34:01] so now clickspots don't work again after chute opening, but that is like before. I want to work on that next anyway [11:36:04] Ah, yeah I haven't your stuff to that depth since Matt and Alex also tested. I did make sure that infiinity thing works and nothing else crazy happens [11:36:28] ah ok, then I can implement that for CSM and LM I guess [11:37:21] What are your thoughts on having a NASSP_VESSEL both the CSM and LM can subclass from? [11:38:14] we kind of already have that [11:38:21] ProjectApolloConnectorVessel [11:38:31] but that is just for common connector class stuff [11:38:43] it could be renamed and some features be added [11:39:58] Sounds good. I'll take a look at that soon. [11:43:40] latest commit is up [11:44:41] Do you still want to add stuff later since you have it marked as draft still? [11:45:45] Approved [11:46:10] just made it into a proper PR [11:46:18] I think it's ready now [11:47:34] Yep. I created an issue for expanding the connectorvessel so it won't be forgotten [11:53:46] Looks like Ron overhauled the document library http://www.ibiblio.org/apollo/links2.html [11:55:18] yeah [11:55:29] the flood of documents from Mike pushed him over the edge :D [12:01:22] good morning [12:03:34] hey Matt [12:04:54] ok my update post is ready [12:05:09] update merged [12:05:18] and posted on the forum [12:15:28] I made a bit more progress with upgrading the substances [12:15:32] https://media.discordapp.net/attachments/809545464331370506/890065289969029140/unknown.png [12:18:15] C2H6O2/H2O is glycol? [12:21:18] C2H6O2 (aq). Glycol mixed with water [12:23:21] right [13:03:31] yes [13:19:39] we could in theory work towards a mixture of water and glycol, but that seems like more trouble than its worth [13:21:07] yeah [13:21:21] there should never be another substance in the glycol loop [14:23:32] good morning [14:25:40] morning [14:39:13] hey guys [14:39:18] PR is merged [14:41:44] awesome [14:43:22] AlexB_88, started to test stuff with the CM on chutes. It seems to be as simple as replacing ShiftCenterOfMass with ShiftCG for that [14:43:30] although that keeps a lot of messy code intact [14:45:56] ShiftCG before StageEight and then UpdateVC is still called but doesn't have to do a mesh shift anymore [14:46:24] RIGHT [14:46:34] oops sorry caps lol [14:48:36] but then on scenario load the ShiftMesh is done in UpdateVC, but the clickspots aren't loaded until afterwards haha [14:48:47] that works but a bit of a mess [14:49:51] I see, yeah [14:50:41] there is just one CG shift [14:50:47] when the apex cover is jettisoned [14:50:53] shifted up 1.2 meters [14:51:05] which is the right place for the CG of CM + chutes I guess [14:52:31] so won't the UpdateVC() call be useless once ShiftCG is done anyway? [14:53:46] only if the ShiftCG is also done on scenario load [14:53:52] or if that is handled differently [14:54:14] but right now how it works is, ShiftCG takes care of the mesh shift, UpdateVC is called but the shift is 0,0,0 [14:54:16] right [14:54:26] but on scenario load UpdateVC does 0,0,-1.2 [14:54:28] ah right [14:54:36] makes sense [14:55:30] the same could work for Saturn stages I think [14:57:45] indy91 I know you and I computed the CMRCS heater power separately and got the same results, where did you get your numbers from again? [14:58:01] CSM Data Book I think [14:58:33] there is a master electrical equipment list for each mission [14:59:30] thanks [15:00:06] If the heat is too much too fast I might consider increasing the mass in those radiators to account for heat sink [15:08:13] indy91, in the CM there is the DeltaV CG switch, LM/CSM or CSM [15:08:24] yes [15:08:34] is that going to be more important now with the changes? [15:08:52] I can't recall what exactly that does [15:10:32] different set of filters and gains for SCS TVC [15:10:40] filters we don't simulate yet [15:10:50] gains... I'm not sure if there is a difference in our code right now [15:10:59] but I don't think it would make a difference [15:11:18] the trim position changes during a burn now but very slowly [15:11:34] so dynamic behavior isn't really different to before [15:12:18] need to look into those filters some time again [15:13:57] I have transfer functions for that [15:14:08] but that tends to be difficult to implement in a real-time simulation [15:20:30] I see [15:34:28] the CG does change a lot during TEI [15:34:39] I should probably test a TEI with the SCS [15:34:55] I tested a LOI-1 with good results [15:38:15] I kind of wonder if you need to adjust the trim thumbwheels during a SCS controlled TEI [15:38:25] so that the burn stays inertially fixed [15:38:42] I think no [15:39:51] but the initial trim should be set very accurately [15:40:00] that seems like something we need to have [15:40:16] you can already move the thumbwheel in 0.1° increments with right click [15:40:22] but there is no visual feedback [15:40:27] because we don't have the bitmap for it [15:40:30] not sure about the VC [15:43:10] the VC works like the 2D panel [15:43:25] but it should be possible to change that in code easily for the VC [15:43:46] so that the thumbwheel moves smoothly [15:44:39] or at least shows each 0.1 increment [15:45:03] yeah [15:59:47] hmm, I did not like that SCS TEI [16:00:09] have to try that again, I screwed something up and got a delayed SPS start [16:29:17] yeah getting pretty large residuals and transients with the SCS [16:29:30] and ullage is causing a weirdly large rotation [16:31:14] ah [16:31:31] Rate switch to High only after ignition [16:31:36] for SCS SPS thrusting [16:31:44] that will help [16:38:57] Direct Ullage switch causes pitch and yaw Auto RCS disable [16:39:15] 15 seconds ullage before TEI causes a quite large attitude rate [16:39:22] are out thrusters pointing wrong... [16:40:26] and what seems to not work is compensating for shifting CG in the SCS Auto TVC electronics [16:40:36] seems like I have some things to check :D [17:04:44] anyone try the Felis 747-200 for x-plane? what a gem... [17:05:17] been waiting for a study sim one of the Boeing classics [17:05:23] I have not [17:05:36] Hell I have FS2020 and have yet to be able to try it since it came out of beta [17:08:14] I used to play FSX but don't have any recent civilian flight sims. I know from my experience with DCS how much of a money drain those can be haha [17:09:38] Haha oh yes I love DCS [17:09:51] I just got my new VR headset cable so I am going to try to get back into it [17:11:00] back to NASSP, I am trying to figure out why my FC3 voltage is low [17:11:09] I have been purging [17:12:02] its sitting around 26V [17:14:49] rcs heaters triggered an undervolt [17:15:57] n7275 any ideas? [17:22:37] seem the power load is really high [17:23:58] gimbal motors running? [17:24:17] hmm. send me a scenario and I will check later [17:26:34] how much do the rcs heaters draw? [17:26:56] a lot lol [17:27:19] I found the issue though I had my suit compressor on AC2 instead of AC1 and that pulled the voltage down [17:27:39] back to 28 [17:28:17] indy91 the rcs heaters arent that bad actually, they dont skyrocket the temps [17:28:40] I am happy with the results [17:29:33] okay good. [17:29:58] I imagine that's like 80 amps on the cell? [17:30:21] less if it hadn't warmed up yet. [17:30:26] good to hear [17:31:37] the suit compressors were my go-to for load testing haha [17:31:51] Yeah I guess I didnt realize I popped one to AC2 [17:34:16] want to fly 17 with my new substance updates :) [17:34:57] *appropriate disclaimers in advance* [17:35:03] Yes :) [17:35:12] I will PR the CM RCS first after splashdown here [17:35:24] Then I will update my test branch with your changes [17:39:14] actually, I'll fly 17 with the rcs just to be safe [17:42:39] yeah, more testing never hurts. [17:43:05] especially since things tend to be interrelated to a high degree [17:45:23] yeah I would like one more whole mission to see what the RCS looks like [17:45:38] But the initial results were promising [17:46:10] n7275 did you want a test mission first or some test tanks for mixing first [17:48:11] quite possible that our SM RCS thruster directions need an update, they look a bit too simple [17:52:10] rcflyinghokie hmm, hard to say. if the aerozine/nto tanks work but it breaks all the other systems that doesnt really help us [17:52:57] but on the other hand, if more work needs to be done and I have to change everything down the road then that invalidates the testing that's already done... [17:54:26] the only thing that I'm somewhat unsure about is whether or not the fuel cells are actually oxygen when the tanks are full [17:54:50] I need to look at their code again [18:00:03] yeah, I think our SM RCS thruster directions aren't quite right, I think I know what to do [18:00:20] n7275 ok I will run with the changes as they are and give you any requested data [18:00:37] indy91 how so? the slight angle? [18:00:53] yes, the engines are all canted outwards by 10° [18:01:09] and we dont sim that [18:01:10] and then all quads are rotated around the X-axis by 7.25° [18:01:30] all our thrusters have variation of this as the direction [18:01:36] [0.1 1.0 0.0] [18:01:45] and then just different signs and directions [18:02:17] do I have a good example... [18:02:42] D4 [18:02:47] right now: _V(0.1,0,-1) [18:02:55] should be: _V(0.172260, 0.021914, -0.984808) [18:03:49] similar for all thrusters [18:03:54] Orbiter normalizes the vector [18:04:05] but that makes the error for this thruster even worse [18:04:43] I'm not sure we should be a rotation from +X thrusting at all [18:04:47] be getting* [18:04:58] it's too strong right now, got stronger with the CG shift [18:06:49] ok seems like there is a small moment from that at least [18:07:08] I have checked my calculations against the CSM Data Book [18:07:17] I'll implement the new numbers and then I will see what it does [18:09:52] morning! [18:11:48] hey [18:12:08] sounds good [18:13:06] EI here we come [18:15:58] ah of course, there is still a rotation from +X thrust because of the offset CG [18:16:04] and it's still there, but weaker [18:16:12] but that agrees with the Data Book [18:17:08] I quite like this update, the 10° cant angle of the RCS is a lot more noticable [18:17:23] I'll give it a bit more testing but that will get pushed soon [18:18:09] excellentr [18:19:50] thruster[nthruster]->dir = MakeVECTOR3(dir.unit()); [18:19:58] and Orbiter does make a unit vector out of the direction [18:20:09] I'll use a unit vector anyway, but good to know that [18:20:35] love checking these little things in the Orbiter code [18:21:56] man, 0.05G time horizon check and everything all right on the money wrt the pad [18:22:37] too bad entry heating doesnt do anything to the RCS thrusters :P [18:23:11] what should it do? [18:23:37] warm up :P [18:23:50] nah it doesnt matter in this case I just had a debug script still up [18:24:55] start in a rolling reentry, wait for entry heating, CM RCS warms up, start steering [18:25:09] who needs heaters :D [18:25:50] haha, its funny there are a few contingency heating methods for them all to prevent that oxidizer from freezing [18:27:55] EVA and rub the thrusters? [18:32:36] oh wait. so our SM rcs jets were pointing in the wrong direction? [18:34:08] slightly yes [18:34:37] some new thruster directions also look just a little bit off because the meshes of the thrusters aren't quite right [18:34:59] CSM needs a re-measurement and maybe new meshes like AlexB_88 did with the LM [18:36:00] I'm not changing the thruster positions right now, only the direction. I bet the proper positions of them would look weird with the mesh [18:39:36] although a first look at the mesh seems ok [18:39:55] so maybe I should fix the thruster positions, too, and see if it looks weird [18:40:14] MCC: "Ok John, we are going to have you send Ken out and massage the CM RCS jets....the purpose being generating friction to warm the injectors and prevent oxidizer freezing" [18:40:29] Young: "WTF?" [18:41:01] yeah no way MCC would want the job of telling that to Ken directly [18:41:27] yep, let the commander deal the blow [18:44:37] here is a more advanced git question, I was running the RCS changes in my J mission text branch, how do I pick and choose the changes to merge into the main repo? [18:44:43] test* [18:49:08] For example I only want to merge my rcs changes and not the J mission edits [18:49:34] are you in a branch? Is everything of those changes commited? [18:50:05] maybe Thymo knows that better than me, I think you can cherry pick changes [18:50:49] Sounds like you are looking for an interactive rebase :) [18:51:20] I am in a branch, and wish to move only certain changes to another branch [18:52:01] Fist checkout to a new branch then, do a `git log` and copy the long commit id from the commit /before/ the first one you want to keep. [18:52:23] Call up `git rebase -i ` that wil give you a file to edit [18:54:21] I see 3 commits here but all are from today [18:54:47] because I just created this new branch [18:55:19] If you do a git log does it show all the commits including the ones you intend to drop? [18:55:49] no it only has 3 from today [18:56:07] How did you create the new branch? [18:56:32] in github [18:56:34] You should have them if you swotch to the branch with all the commits and then do `git checkout -b ` [18:56:38] Oh no [18:56:43] You need to do this locally [18:56:51] ahh [18:56:52] ok [18:57:11] From the command line. Maybe the GUI can do it, but I have no clue how as I never use it. [18:57:55] I might just migrate them manually [18:58:40] Once you do what I show you you'll find it easy [18:58:59] heading into a meeting then I can jump on and we can go through it [18:59:04] Sure! [19:17:12] I think I might have too many branches... [19:17:39] nah :P [19:17:52] I have 23 [19:31:04] Can't be bothered to delete them or too many unfinished side projects? :p [19:44:26] oh man that is a lot of branches [19:58:06] some of those can definitely be deleted [19:58:33] but there are some unfinished projects that I'm slowly mining features out of [20:43:36] but getting anything out of that data from Francois would be very impressive :D [20:44:17] hah yeah it would certainly be some work [20:55:00] night! [21:18:11] n7275 I am ready to pull your changes for 17 if you are [21:25:41] go for it! [21:28:32] which branch [21:34:34] night! [21:36:44] https://github.com/n7275/NASSP/tree/VapPressAndHvap [00:55:25] I take it no issues so far? [14:01:47] hey Ryan [14:03:03] morning [14:03:12] just building with your branch now [14:03:53] nice [14:04:08] I'm flying 10 now [14:04:20] or rather I was last night [14:04:43] do you have a bunch of errors and a warning when you compile? [14:04:48] made from prelaunch to insertion without any major issues [14:04:54] uh nope [14:05:12] what errors are you getting? [14:06:00] https://www.dropbox.com/sh/mg1agh24bzmie5x/AACZCBfeOveZbyBUYAv_YqJBa?dl=0 [14:06:06] hey [14:06:09] morning [14:07:40] hey [14:08:13] just rewriting half the SCS because of Orbiter vs. actual coordinate system differences... [14:08:21] ouch [14:09:49] in the past most things used the Orbiter coordinate system [14:10:01] well the warning is something we all probably get because that = should be a cast to a float, the errors on the other hand... [14:10:03] right now it's a mixture, so it's very difficult to tell [14:10:36] VS likes to throw fake errors [14:13:13] can we make a: "VECTOR3 nasspCSM2orbiter(VECTOR3 coordinates)" function or macro? [14:13:59] yep, that's what I did [14:14:06] just added it to nasspdefs.h [14:14:18] in both directions [14:14:37] right now only used for BMAG rates [14:14:49] which were the main cause of the inconsistency in the SCS [14:14:54] n7275 I mean it builds successfully [14:15:15] so it could just be VS being silly [14:15:33] probably fine then [14:16:00] those aren't even classes my update touches [14:16:05] sounds good, time to prep 17 [14:16:09] despite git integration I don't think VS really likes switching branches [14:16:15] haha true [14:16:21] that's usually the cause of fake build errors [14:23:57] I did not know that, good to know [14:24:55] sometimes closing and reopening VS makes them go away [14:27:50] sometimes [14:29:14] how warm does the ecs glycol typically get launch? [14:32:22] I think it gets a little too warm right now, I will look at some numbers [14:34:57] okay. I had no issues with cabin or suit temps but the glycol was over 110F before I closed the bypass [14:35:37] primary inlet/outlet temps that is [14:36:41] which temp did you read? [14:36:46] ah [14:37:02] rad outlet should not exceed 90 [14:37:56] I am trying to find launch numbers [14:38:17] but the radiators are bypassed during launch [14:41:24] so the glycol only circulates within the CM when bypassed, and the coolant and structure are prechilled by GSE [14:41:50] that should provide heat sinking until the evaporators start working [14:42:15] oh I think I fixed the SCS Auto TVC issue during TEI [14:42:30] I knew that fixing the coordinate system stuff first was a good idea :D [14:42:32] what was the issue? [14:43:07] so during TEI the CG shifts a lot, especially in for the SPS yaw gimbal [14:43:20] so what the Auto TVC needs to do is not hold an inertial attitude [14:43:27] but an inertial thrust vector [14:43:57] so it needs to compensate the attitude error it has [14:44:10] because it wants an attitude error for the thrust vector to be inertial [14:44:17] there was basically just a sign wrong in the calculation for that [14:44:22] ah I see [14:44:43] but I couldn't figure it out before with the coordinate systems [14:45:06] there is a SCS training manual which shows that nicely [14:45:37] https://history.nasa.gov/afj/pdf/apollo-scs-block-ii-training-program-196905.pdf [14:45:43] PDF page 300 [14:46:30] really good manual all around [14:47:26] still made my brain melt a little bit visualizing what the code needs to do :D [14:48:37] haha [14:49:21] speaking of a little brain melting, I am about to fire up a 17 scn...so whats all this with the launch time and azimuth changes I am trying to wrap my head around what all happened and what they did [14:49:39] our launch scenario is on time [14:50:01] but if you want to launch like the actual mission you can adjust the mission time in the launch scenario [14:51:05] RTCC MFD has a utility to get the predicted launch azimuth from the LVDC [14:51:12] you will then need to do a V78 to change the launch azimuth in the CMC [14:51:32] Yeah I want to follow the actual in this case and see how it all works out [14:52:36] MISSNTIME -14400 [14:52:40] that is T-4 hours [14:54:04] so what am I changing this to [14:54:42] I know it was a 2h40m delay so am I adding that? [14:54:56] yeah, was looking for that number [14:55:08] so -24000? [14:55:12] yep [14:56:00] in terms of procedures, not really sure when you should do what [14:56:30] there are some automated things happening at specific mission times [14:56:51] so you might have to wait for a while and then pick up the procedures a the normal T minus times [14:56:56] also i see the TLC time was shortened to keep them on time [14:57:08] will the IU compensate? [14:57:14] I'd be interested to see if you have the same heat issue launching at night. maybe 10 is just too sunny for our chillers. I was about 20 minutes late closing the bypass too. [14:57:17] yeah. While we don't have the LVOT for Apollo 17 I seem to have given the LVDC parameters that should accomplish that [14:58:02] I think we had TLI numbers for the nominal and actual launch time [14:58:05] n7275 we dont really chill the structure like we should I think, theres no heat sink [14:58:10] so I extrapolated those two sets of numbers [14:58:30] Sounds good I will see what happens [14:58:57] and for the RTCC, after insertion, do liftoff time update as usual and then also on the LVDC state vector update page there is a button to update GRR time and IU launch azimuth [14:59:16] then the RTCC should be in sync with your actual launch [15:01:31] Ok will do [15:04:15] rcflyinghokie, I've been thinking about how best to do that. theres telemetry values for structure temperature so it would be nice. the systems SDK has some placeholder structure for conductive heat transfer [15:05:34] My kneejerk reaction is to create a structure "radiator" and have that chilled and heat exchanging with the CM glycol [15:05:47] The CM glycol plumbing is very simplified though [15:06:50] that would do for now [15:06:55] RTCC azimuth agrees with actual [15:07:39] also I dont know where the heat loads are applied to the glycol [15:08:11] I am hesitant making too many changes without actually replumbing it properly [15:10:51] you've an awesome job with the lem ecs. it might be time to tackle the csm. [15:13:18] Trick is one system at a time lol, LM was a bit easier because it was from scratch....the CSM we need to figure out how to undo things but I can at the very least start replumbing based on the handbooks in the cfg file [15:13:58] After my 17 mission I would be happy to look into that with the new substances [15:20:45] other than some warm glycol on launch I'm not predicting that you'll run into any issues that would prevent you from completing the mission. [15:21:22] sounds good to me! [15:22:07] So upon brief reflection, I think I want to try adding actual helium and propellant tanks to the LM before revamping the CSM [15:22:21] That way we have a clean test case for it and it can be laterally transferred with relative ease [15:22:55] After 17 I will get back into a non J mission branch and start adding those [15:23:11] Curious to see what they do now [15:23:16] awesome [15:24:15] I think the issue may have been the helium vapor pressure [15:24:19] hopefully we can remove the cheaty pressures in code and read from actual tanks lol [15:24:50] that's the goal :) [15:24:52] the SHe tank might pose problems I was having all sorts of issues trying to get that to properly exist [15:25:14] helium was super broken [15:25:36] On that note I want to have tanks interact with the structure heating and cooling...our oxygen and water for example is a "set" temperature [15:26:49] my fuel cells have a fixed structure temperature that acts as a heat sink [15:32:15] what I would like to do is go through list of all the telemetry values, test meter values, and gauge values, and evaluate how realistically each one is calculated. [15:41:44] the part of the config file really only needs to describe the connections between different thermal objects. [15:42:14] yeah that would establish a good baseline for where we are [15:44:46] that would also keep us out of O(n!) territory [15:51:19] each line would be something like: objectA objectB connectivity(watts/degree) [16:01:45] Thymo, I'm very smart, I think all padload worksheets already had PACTOFF and YACTOFF and I added new ones for the new angles... [16:02:25] I only checked Colossus237. The values were blank, about 3/4 down the page [16:35:15] indy91 for launch all I need to do is update the azimuth and then update everything else after boost? [16:39:39] ASCP maybe, too, for the GDC [16:41:42] morning! [16:44:59] Yeah I did the ASCP, and did you know it takes 11 right clicks to move 1 degree? [16:45:04] shouldnt that be 10 [16:54:25] another thing I noticed, Apollo 15 and later they left their CMRCS propellant valve tb's grey, wonder why they changed that [16:54:31] after insertion [16:59:09] hey Mike [16:59:53] propellant valves were open for the whole flight? [17:00:44] yeah [17:00:58] even down to the entry checklist is has tb gray (verify) [17:03:17] maybe they were afraid they wouldn't open again [17:03:41] and omits the "on" step [17:03:56] could be, maybe something to do with the extended mission time? [17:04:11] or unnecessary since they werent pressurized [17:08:20] is there a good resource on procedural changes like that? [17:20:16] not that I know of [17:29:00] a nice 92.5x93.8 orbit at 91.50 azimuth [17:31:15] I hope for a good IU state vector accuracy at TLI, but we don't have the full presettings for TLI itself, so if that is a bit off it will be difficult to say what the cause it [17:31:16] is* [17:32:05] well, it's based on the numbers from the actual mission [17:32:14] with that azimuth [17:32:17] I'm sure it will be good [17:32:19] so hopefully after updating everything it should be good [17:32:47] so my CMC should be good I just need to now tell RTCC and the IU about the new time? [17:32:54] yeah [17:33:11] well IU already knows when you launched [17:33:25] RTCC needs to know when the CMC and IU launched :D [17:34:02] oh one thing I am unsure about [17:34:06] there is a CMC GRR time [17:34:12] thats in the configuration menu? [17:34:14] yes [17:34:23] CMC GRR time is only used to calculate the launch REFSMMAT [17:34:35] I'm not sure it gets updated with that button in the config menu... [17:34:54] ok I hit update liftoff time [17:35:31] anything else? [17:35:41] yeah, IU state vector uplink page [17:35:52] that's where you can update IU GRR time and launch azimuth [17:35:58] or the RTCC's knowledge of those [17:35:59] PAMFD or RTCC [17:36:21] RTCC [17:36:30] uplinks 49? [17:36:35] I guess [17:36:42] IU nav update or whatever it is called [17:36:48] on the left side it should have a button [17:36:50] ah got it I havent been in this one yet [17:36:58] GRR? [17:37:01] yeah [17:37:09] it should update GRR time and azimuth on that page [17:37:16] 5:32:47 [17:37:22] do I need to set the target [17:37:24] 43* [17:37:27] ah maybe [17:37:38] yep [17:37:47] now GRR/S is 5:32:42.95 [17:37:52] AZI 91.503 [17:38:00] sounds perfect [17:38:04] uplink? [17:38:05] so now the RTCC knows about those [17:38:10] or just for RTCC [17:38:16] just to update the RTCC [17:38:28] do I need to CLC or are just setting those enough [17:38:44] if the numbers on the page updated then they are in [17:38:49] ok cool [17:38:51] CLC will be for the state vector [17:39:00] this was just a convenient place for this [17:39:04] makes sense [17:39:09] basically the IU equivalent of the button on the config page [17:39:31] I think it would be good to now downlink the REFSMMAT [17:39:38] TLI pad looks good [17:39:40] ok [17:39:44] oh it does [17:39:49] even the angles? [17:40:09] I havent compared the angles yet but the time changed [17:40:43] compared to what [17:40:59] the time change I mean [17:41:11] oh I computed the pad before updating RTCC liftoff time etc [17:41:17] ah interesting [17:41:27] kind of surprised that worked :D [17:41:28] was like 5h something [17:41:46] yeah, it doesn't even have a correct state vector time tag without the update times [17:42:21] https://www.dropbox.com/s/prq9zazoxid3zi7/Screenshot%202021-09-23%20114210.jpg?dl=0 [17:42:30] 002:27:40 Schmitt: Okay, Houston. Here's your TLI PAD. 3:02:57; 180, 312, 000; 5:51; 10359.6, 35582; 000, 345, 040; 300, 165, 320; 312.0, 306.0, 57:10, 000; ejection time, 4 plus 39 plus 00. [17:43:00] yeah, as I thought, the TB6 IMU angles are off [17:43:14] yeah they are [17:43:17] because of a launch REFSMMAT calculated in the RTCC for the nominal launch time [17:43:24] either use the MED to update the CMC GRR time [17:43:33] or just DWN button on the REFSMMAT page to update it [17:43:41] it is updated though [17:43:49] oh I didnt hit clc again lol [17:44:16] https://www.dropbox.com/s/rf6iks0eq5yedlv/Screenshot%202021-09-23%20114401.jpg?dl=0 [17:44:35] awesome :D [17:44:56] TLI PAD still uses old TLI calculations sadly [17:45:01] so DVC is off [17:45:13] only MPT can use the full TLI simulation right now [17:45:22] with better values for DVC and VI [17:45:24] I can try that this time [17:46:20] TLI is up on it now [17:48:36] Alex' RTCC cheat sheet has procedures for this I think [17:51:08] pushed the TCUA -> FCUA default value for AST unspecified area [17:51:25] I'll do a PR again with my RCS and SCS changes as that has become a bigger update [17:54:35] Awesome thanks for that little QOL item :) [17:55:45] MSK 54 DVC 10372.7 [17:56:17] that is definitely closer to the actual TLI PAD than the TLI PAD page said [17:56:48] BT 5:50 [17:56:59] DVM 10384.6 [17:57:19] that's the total DV [17:57:36] comparing to DVC [17:58:49] difference is tailoff [17:58:55] right [17:59:06] trim gimbal angles for the J-2 are fixed 0 [17:59:10] at least for us [17:59:20] the RTCC could load some angles [18:00:20] VI 35603 [18:00:41] sounds reasonable [18:00:54] after cutoff the velocity very quickly starts dropping [18:01:16] so even a small difference in performance, like 1 second difference in burn time, is probably a larger difference in VI already [18:01:55] I know that they called the checkout monitor for the VI value [18:02:05] but what our DMT doesn't have yet is some custom TLI displays [18:02:13] which I believe the real one had [18:02:23] depending on the type of maneuver, display different numbers [18:02:30] ah interesting [18:02:32] like TB6 time and also actual ignition time [18:02:45] instead of pulling them from multiple [18:02:48] yeah [18:03:04] the lower half has maneuver type specific stuff, even in the RTACF version [18:03:10] I am trying to compute the sep attitude using mpt but I cannot seem to add a 0dv maneuver to it [18:03:12] but the RTCC display was more dynamic [18:03:39] in the viode footage of the Apollo 14 MOCR there is a brief glimpse of a empty DMT and it is actually completely empty in the lower half [18:03:46] video* [18:03:54] hmm [18:04:12] there is probably an error on the online monitor [18:04:55] did you make it an RCS zero DV maneuver? [18:05:00] sps [18:05:02] I think it might have problems if it's SPS [18:05:04] ah [18:05:09] not sure if the real thing had that [18:05:25] because SPS maneuver sims has several maneuver phase [18:05:32] thrust rise, tail off etc. [18:05:37] which is new for the SPS [18:05:46] so maybe that worked before, 0 DV maneuvers with the SPS [18:06:10] with the RCS it should still work [18:07:51] unless you already terminally broke the RTCC by trying SPS :D [18:08:38] nah it worked [18:08:46] using RCS [18:09:04] Now where are my sep RPY on the MSK54 [18:10:07] I see 3 sets of angles [18:10:10] right [18:10:19] IMU, FDAI (different for LM) and LVLH [18:10:32] Ah ok thats what I thought [18:10:46] So RPY B should be my sep attitude? [18:10:55] I think so [18:11:14] it should be the same as the TLI PAD [18:12:05] I think I mentioned this with 13, but I think the FDAI angles are incorrect [18:12:14] Y and R are transposed [18:12:21] ah I remember [18:12:29] I thought I had changed something, but maybe not everything [18:12:37] I'll take a look soon [18:12:38] This would be correct for the LM [18:12:46] Middle angle being R instead of Y [18:13:17] For the FDAI at least, the gimbals are correct wrt outer middle inner [18:13:24] for the CSM [18:13:55] is the order right for the IMU? [18:14:25] OR IP MY you mean? [18:14:49] that too, but also the numbers itself [18:14:54] yes [18:15:06] based ont he TLI pad at least [18:15:09] on the [18:15:26] so the FDAI angles have a different order than the IMU angles [18:15:53] https://www.dropbox.com/s/3swgekyloqvqne5/Screenshot%202021-09-23%20121545.jpg?dl=0 [18:16:05] Y and R are transposed [18:16:30] the labels only [18:16:56] or the numbers, you can choose either transposition lol [18:17:18] I do have a source on this, but it will be slightly incorrect [18:17:48] curious the differences in the CSM and LM displays of this as well [18:18:00] For IMU: [18:18:01] "outer, inner, and middle gimbal angles at ignition (0° - 360°). These labels will be dynamic and displayed as follows: for the CSM, roll, pitch, yaw: for the LM, yaw, pitch, roll: for the S-IVB maneuver these will be CSM gimbal angles, deg" [18:18:30] "FDA1 angles. These are the same as the gimbal angles yaw, pitch, roll for CSM maneuvers, but correspond to pilot yaw, pitch, roll for LM maneuvers , deg" [18:18:35] FDAI* [18:18:51] that confused me I guess [18:19:01] but it makes no sense to have yaw, pitch, roll for the CSM in that order [18:19:02] ever [18:19:47] no the middle gimbal should always be last [18:20:36] well IMU middle gimbal already is always last [18:20:51] the logic has different labels for IMU only right now [18:20:57] CSM: OR, IP, MY [18:21:00] LM: OY, IP, MR [18:21:07] but it should als be for the FDAI [18:21:13] CSM: RB, PB, YB [18:21:27] LM: YB, PB, RB [18:21:30] right? [18:21:32] LM display got so many people confused during 13 [18:21:40] yes [18:22:00] hmm, but in the LGC is it always roll in R3... [18:22:56] so you enter the ICDU angles as YPR [18:23:15] but a 50 18 display shows FDAI angles as RPY [18:23:36] yeah [18:23:43] so the N22 is YPR and N18 is RPY lol [18:24:22] so the DMT is double wrong [18:24:40] at least the definition of symbols I have [18:25:36] "LM display got so many people confused during 13" you mean in the MOCR audio? [18:28:22] yes [18:28:44] especially with respect to V16N20 or any V49 entries [18:29:14] I'm sure looking at the DMT didn't help them lol [18:29:37] for now I'll make it as I wrote above [18:29:47] although I am not sure that it 100% makes sense for the LM yet [18:30:17] at least it's not 100% wrong for the CSM FDAI [18:30:20] we can use it a few times to see [18:30:43] I think the liftoff time update confused the map update pad [18:31:04] unless its using MPT? [18:31:16] ah yeah [18:33:52] SBD signal doesnt take into account LEO AOS and LOS between stations yet does it? [18:34:08] nope [18:34:17] ok [18:34:36] maybe that is one of n7275's 23 branches lol, he mentioned that some time ago [18:34:55] hahaha [18:35:52] I am trying the uplink in LOS inhibit but I cant use the signal strength for LEO haha [18:36:25] haha. [18:37:37] oh I haven't worked on the LOS inhibit feature in the RTCC MFD in many years [18:37:55] well it works [18:38:09] hmm [18:38:14] no it only inhibits :P [18:38:43] so it half works? [18:38:49] I had started on something in my telemetry branch [18:40:26] but I still dont have a clear understanding of what determines what the "active" transmitting station is. [18:41:51] I believe uplinks are routed to specific stations by the network controler [18:42:34] rtcc->ccats->gsfc->nascom->station [18:48:08] plausibly it's the station in aos with the los time farthest into the future. [18:54:46] I should listen to the network controler audio and see if I can learn anything from that. [18:55:27] rcflyinghokie, when it comes to targeting your MCCs, to get it to the desired LOI GET, you will need to subtract your launch delay from the flight plan time [18:56:16] ah good point [18:56:38] the SFP is all GMT times, so that shouldn't be a problem for targeting before or after a time update [18:57:46] oh in the mission report sequence of events, at 65h, it says MCC time update (+2:40:00), is this just at MCC or does this impact the spacecraft as well [19:00:33] they both have to do it [19:00:56] I'm sure it's close in time to the CMC uplink [19:01:06] oh wait, 65h [19:02:13] when was the CMC update [19:03:39] ah, same time, ok [19:03:58] for you the procedure is like you already did [19:04:04] so am I bringing it back 2h40m? [19:04:21] yep [19:04:29] ok then simple enough [19:46:22] For P15, is VC/O the same as VI? [19:47:28] hmm good question [19:47:57] I mean the way it's phrased it makes sense [19:48:32] yeah I guess they don't consider tailoff there [19:48:37] so VI should be fine [19:48:43] its what I have been using at least for 15 and 16 [19:48:53] I just never checked for sure [19:49:24] the N95 numbers look odd though [19:49:53] R2/R3 +09961/+25642 [19:51:02] VG should be my DVM correct? [19:51:05] (R2) [19:52:00] yeah [19:52:02] 9961 ft/s [19:52:12] close enough, I think there is a program note that it isn't exact [19:52:22] and R3 has to be the current velocity? [19:53:40] yeah R3 is the current velocity [19:53:42] I think R2 is really just your VI minus current velocity. So not a good indicator for actual velocity-to-be-gained [19:53:53] VI at TLI cutoff [19:53:57] Thats what i was thinking [19:54:57] lets see how the trajectory looks post TLI, about to hit tb6 [19:55:58] IU state vector accuracy good? [19:56:21] good question [19:56:45] SV Accuracy: -7600.856127 -3.071452 104.030007 [19:57:11] I'd say that means the orbital navigation is fixed [19:57:28] Apollo 17 TLI is later than usual [19:57:32] https://www.dropbox.com/s/4o1m3b8k8ibgcps/lvlog.txt?dl=0 [19:57:39] just started tb6 [19:57:54] and I was getting about 7000 meters error max at TB6 with Apollo 11 [19:58:14] previously it was more like 12k meters [20:00:44] certainly an improvement [20:03:09] yeah, that's all error from boost and at least half of it is normal [20:03:50] thewonderidiot, would you believe it that the CSM functional schematics document has just been quite helpful and better than the CSM Systems Handbook? [20:04:19] yes I definitely believe that haha [20:04:33] it's more detailed in a lot of places [20:04:40] true [20:04:54] I guess you just had to deal with a section with errors [20:05:12] S-Band [20:05:15] I have beefs with pin accuracy in the comms section... but it was right in almost all cases about what pins existed, just not which was which [20:05:26] good enough [20:06:36] for SCS TVC, the Systems Handbook summed attitude error, rate and integrator (so basically a PID controller) together and only then went to specific paths for CSM or CSM/LM [20:06:59] but that made no sense as those three inputs have different gains for CSM and CSM/LM [20:07:35] in the functional schematics they get summed together separate for each path [20:07:53] so it can have separate rate, error, integrator gains for CSM and CSM/LM then [20:09:02] just a bit simplified in the Systems Handbook [20:10:16] I didn't implement the separate logic for CSM or CSM/LM docked before as that always confused me [20:10:36] so now that CG switch is doing more than setting an unused CMC input bit haha [20:11:33] "LEM Attached" is the input bit [20:12:27] -8.4 on the EMS [20:13:34] however the ordeal jumped from zero to 355 a few seconds before ECO I dont remember that kind of behavior [20:15:13] hmm [20:15:49] more like 30 seconds or 3 seconds? [20:15:55] 30 [20:16:05] probably closer to 30 [20:16:21] that's the time when terminal guidance is frozen [20:16:38] the equivalent for boost to orbit is when it drops the altitude constraint [20:16:46] and only tries to achieve velocity and such [20:16:55] there is always a small transient at that time [20:16:58] 5° is a lot [20:17:01] lvlog might be useful [20:17:07] ah I guess that isnt on the TLI burn table [20:17:53] but also could be the delayed launch [20:18:58] don't think it's the delayed launch [20:19:03] maybe some wrong presetting [20:29:57] oh nice, yeah that is a confusing simplification on the system handbook's part [20:34:08] already one of the most cramped parts of that Systems Handbook page [20:34:17] would be difficult to make it correct there [20:34:48] but an annoying error anyway [20:36:21] indy91 https://www.dropbox.com/s/4o1m3b8k8ibgcps/lvlog.txt?dl=0 [20:58:16] hmm [20:59:38] at the very least some default values are wrong [21:00:22] two variables that are both 30 seconds for most missions [21:00:27] are 15 and 3.59 seconds by default [21:00:42] so that transition to terminal guidance was probably at 15 seconds for you [21:00:48] not 30 [21:01:02] that should be changed, that might be the reason for a fairly large transient [21:01:20] it will be the same for most missions though [21:01:37] 15 and 16 at least use the default values, too [21:03:28] I'm not seeing a jump in commanded pich attitude by the LVDC [21:03:45] so not sure what happened. But at least I found this thing with the default values [21:05:25] I have a pre TLI scn if it would help [21:05:59] sure, I'll try that tomorrow if I see the same thing [21:06:26] and I can test the updated switch time to terminal guidance with the scenario [21:08:00] its TIG-10m or so [21:08:23] https://www.dropbox.com/s/b4jd8ho3vh6ta26/Apollo%2017%20-%20TLI.scn?dl=0 [21:08:44] thanks [21:08:48] good night! [21:58:27] n7275 through TLI no issues noted thus far, any data that would be useful to you? [22:24:44] well, first and foremost I want to make sure that nothing is broken. I also want to make sure nothing weird happens with the csm cryo tanks. they're very close to supercritical so I'd like to see how vapor_mass increases over time [22:36:54] I didn't notice any degredation in stability with time aceleration, but I did just introduce two very nonlinear factors into the mix, so that's something to look out for. [22:38:14] will do