[14:53:39] NASSP Logging has been started by n7275 [14:53:41] good morning [15:02:29] hey [15:22:09] have our Saturn IB and V a better drag model during first stage flight [15:22:11] gave* [15:22:17] still very simple [15:22:21] but a bit better [15:22:31] finally depends on Mach number :D [15:25:16] oh awesome [15:26:22] I know exactly which documents would have good numbers, but exactly those documents are not available [15:26:45] instead we have the same type of document for the aborted Saturn V [15:26:46] that's sadly usually the case [15:26:53] so S-IC + S-II and S-IVB but no CSM [15:27:16] but I think I've collected enough information for this simple model at least [15:27:41] I really want to add moment coefficients, too, as the vehicle are slightly instable in certain Mach regions [15:27:52] https://i.stack.imgur.com/d2eSh.png [15:27:55] slightly scared it will be bad at low frame rates haha [15:28:01] yeah [15:36:26] https://cdn.discordapp.com/attachments/780878788216881173/821574218654679060/p.png [15:40:25] Saturn V winning Olympic Gold against the ML in Wrestling [15:45:00] yep haha [15:45:37] on the other hand, right now we get an angle of attack during launch that is a bit too large, because there are no stabilizing moments [15:45:54] also leads to a bit more drag with my current model [16:08:21] morning! [16:17:46] hey Mike [16:21:56] what's up? [16:38:26] I may or may not have just accidentally deleted the container containing the new wiki's database... [16:38:53] Guess it's time to import everything all over again [16:45:02] oh no. [16:49:12] that doesn't sound good [16:52:12] Meh, I just need to run the maintenance scripts again to reimport all the pages and images, then recreate my account and tweak all settings. Mean I get to wait while that;s running again [17:15:33] thewonderidiot, you scanned too many things, I had to spend like 1 minute to find a specific document that Ron hadn't put up yet haha [17:19:56] the "Preliminary" Apollo 7 Flight Crew Abbreviated Checklist [17:20:06] it isn't as preliminary as the title page suggests [17:20:11] because it has updated page [17:20:16] that go up to September 1968 [17:20:23] so just before launch basically [17:20:44] I kind of want to change our Apollo 7 checklists based on that [17:20:48] but that's a lot of work :D [17:31:54] oh hahaha [17:32:18] I'm not sorry for scanning too much :D [17:34:39] yeah seems like the first part of that document is quite like the CSM Launch Checklist of the later missions [17:35:30] and it's the final document of this, so very good to have [17:35:43] the title page suggested it was from 1967 [17:36:31] it also has the SM RCS test firing on the pad [17:36:41] don't think we have safely do that in NASSP yet [17:36:43] the rocket would move [17:37:56] oh awesome [17:39:13] can safely* [17:43:21] yeah I've been having a lot of fun finding unexpectedly good things in the scans lol [17:43:33] I really did not look at most of these things too closely [17:45:55] yeah will be a while until we have properly digested it all [17:46:40] hmm, I gave the Saturn IB a moment coefficient that is way too strong and has the wrong sign [17:46:58] in other words, auto aborts due to large attitude rate is still working [17:53:59] haha, that must be fun to see [17:58:58] well it wasn't on purpose [17:59:02] but still fun to see [18:02:40] hehehehe [19:54:11] well, past the 200hr mark now [20:07:47] :D [20:42:34] How am I supposed to interprete NARAs reproduction fees? I found a document listed as 2 linear feet stored in 5 boxes, I see two different rates, one listed as "paper-to-paper" at $0.80 per copy and another as "Oversized and per linear foot" at $3.50 per linear foot. Which one applies? [20:42:35] https://www.archives.gov/research/order/fees [20:43:05] This is the document https://catalog.archives.gov/id/990772 [20:44:08] If it's $0.80 per page its gonna cost a small fortune to have scanned and I'm not sure how many pages it even has. [20:46:49] that's not a document, that's 5 boxes full of documents that are roughly categorized as checkout procedures [20:47:31] you're certainly looking at thousands of pages there [20:48:02] and that $0.80 per page is a fixed rate, you're reading that right [20:49:16] the "per linear foot" is talking about oversize materials -- things that are multiple feet long or tall [20:49:26] like a poster [20:50:07] Oh, I see it now. "Series". I thought I had found a nice document specifying a lot of before T-4H stuff. [20:51:47] Know anyone in Washington with nothing to do that knows how to operate a scanner? :P [21:02:42] NARA-SW might actually have the same documents if not a more recent version [21:06:07] Both actually. One listed as 2 ft. Same as in Washington. There is another entry for CSM checkout procedures listed at a whopping 24 feet! [21:09:08] yeah [21:09:14] there is a *lot* at NARA [21:15:54] I think I could sit there for days surrounded by towers of boxes [21:16:26] Maybe it's in my own best interest the archives are on a different continent [21:21:08] lol [21:47:21] thewonderidiot, what's volunteer program like? [21:47:27] ^NARA's [21:50:34] n7275: you mean like the kind of volunteer that Ron is? [21:54:18] it'd be better to ask Ron directly about it, but it's a bit more involved than the "volunteer" title suggests [21:54:54] there's a lot of paperwork to fill out, and you need to get recommendations from people who can attest to your archival history... or something like that [21:55:09] Ron said it was kind of like a job application [21:55:54] Yeah, I imagine it's fairly involved. [21:55:58] I will ask Ron [21:56:18] Are you interested in becoming a volunteer? [21:57:37] also from Ron: "The truth is that there are no enhanced privileges as a volunteer.  The rules for volunteers explicitly guarantee there aren't any extra privileges.  The sole reason I'm able to get these aperture cards for free (even though it's against the rules for volunteers) is that it was agreed-upon in advance and therefore has become a sanctioned activity. " [21:58:24] not really, since I'm nowhere near any of the archives and there isn't that much to be gained [21:59:33] oh I mean I'm not, I can't speak for Matt haha [21:59:44] We'll I'm in Maine, so that's about as far from anything as you can be. [21:59:53] heh [22:01:52] Sounds like there wouldn't be much point to it then. [13:58:35] hey [13:59:57] good morning [14:23:27] about the LVDC navigation update, I think in the end it still is definitely an improvement [14:23:34] not by as much as I thought but still good [14:24:12] getting very consistent results and orbital navigation isn't contributing any additional error as far as I can see [14:24:37] so any idea where the remaining error is coming from? [14:24:40] yes [14:24:42] all boost [14:24:55] Hey guys [14:25:00] Yeah that makes sense then [14:25:15] Is the large IMU torque after insertion a result of that error as well? [14:25:32] Morning Thymo [14:25:56] hey [14:26:00] hmm good question [14:26:16] I think the alignment is actually correct [14:26:28] it's the REFSMMAT that gets calculated at liftoff that is slightly off [14:27:01] because of non-spherical Earth assumption in the AGC [14:27:15] state vector is also quite off after launch in the CMC because of that [14:28:17] And we have a sphere in Orbiter [14:28:30] yes [14:28:49] some errors are expected and I think they make up at least a decent part of the error [14:29:02] the integration scheme [14:29:09] that would be interesting to be able to fix in Orbiter now [14:29:16] not taking into account the third and fourth harmonics in the boost navigation [14:30:27] those cause an error that just makes the state vector worse over time [14:30:58] in all scenarios I get a quite consistent error [14:31:09] 11,000 ft downrange at 1:45h GET [14:31:35] and that error is already predicted to happen after insertion, so not a contribution of orbital navigation [14:32:17] and that's well within even the strict Apollo 17 mission rule for a IU nav update [14:32:58] so if it really cuts the error we previously got in half in every scenario then we should really not need any IU uplink [14:33:10] and that is better than all actual missions I think [14:33:33] but to be fair, the main error source for orbital navigation is propulsive venting which is somewhat random [14:33:40] and we don't have that yet [14:36:03] one error source that the actual missions didn't have of course is staging [14:36:16] at staging the center of gravity of our Saturn is shifted [14:38:57] wonder if any timestep issues occur then as well [14:39:36] yeah maybe [14:39:57] those of course happen a few times during boost and can lend to error propagation [14:40:12] in any case, I think I am done with LVDC navigation for now, it should be better than before at least [14:42:14] any improvement is a good thing [14:44:21] there was a never ending confusion about the J3 harmonic, or "H" as the LVDC code calls it [14:44:32] we did in fact use the wrong sign for it [14:45:13] the LVOTs don't agree on the sign and our two source for orbital navigation didn't either [14:46:06] but I check the gravity vector against what the AGC calculates and I know which sign gives the correct result haha [14:46:09] checked* [14:58:35] good morning [15:03:12] hey Matt [15:18:48] I'm in the home stretch of Apollo 7 now. one more sps burn, then deorbit [15:19:29] the O2 and H2 stratification tests are making me want to work on systems again [15:24:41] I might need to let the LM lose more heat during TLC than it gains [15:24:56] I mean nothing is off scale high but it just seems higher than I'd like [15:25:09] hmm, Apollo 7... [15:25:44] the Earth Entry PAD has a tailoff DV [15:25:58] basically what the EMS will show at the end of the burn, so not at cutoff [15:26:10] I think that might not be implemented yet [15:26:18] probably hardcoded to 0 [15:27:51] yeah [15:27:55] need to fix that [15:37:49] got deleted from the Apollo 9 version of that PAD though [15:37:54] but we use the Apollo 7 one [15:39:36] oh I found something useful on the archived NTRS earlier [15:39:52] rare these days, we have almost gotten everything good from it by now... [15:40:02] Operational Data Book for Skylab [15:40:10] quite like the one for CSM and LM [15:40:15] 1200 pages [15:42:07] I was looking for drag coefficients for Skylab. Found the title of a document, looked at the restricted NTRS list and it was there. I was 99.9% sure it would be one of the not available documents, but I was wrong. [15:43:14] morning! [15:43:16] oh man [15:44:15] I found 3 volumes of it [15:44:21] 2 others are about experiments and stuff [15:44:39] the CSM Data Book would be another volume of it, but it's not available. [15:44:49] Something interesting, in the 16 LM activation checklist, the initial cb positions have the ASA cb open [15:44:51] I knew that about the CSM one [15:45:44] I also found the "Skylab Operational Command Listing" [15:45:59] basically all commands you could send to Skylab, CMC, IU [15:46:15] damn that's some good stuff [15:46:37] 16 and 17 both have the ASA open... [15:47:44] that seems odd [15:49:12] Well confirmed in the apollo 17 closeout pics ASA is indeed open [15:50:05] does that affect the heater? [15:51:45] Pretty sure [15:51:50] At least in earlier LMs [15:52:03] Apollo 15 has the breaker in [15:59:54] But in the LM 11 volume 2, it looks like it's open for prelaunch yet closed on the initial entry [16:01:31] but thats not in the activation checklist [16:03:05] so not closed until activation power up CB chart [16:04:59] in the LM activation checklists yes [16:05:10] however the AOH vol 2 has it closed during initial entry status checks [16:09:18] I trust the activation checklist over the AOH for what actually was done [16:11:13] yep same here...and the closeout photo of panel 16 for 17 confirms that being out [16:12:13] https://history.nasa.gov/alsj/a17/LM12-co8.jpg [16:12:20] https://history.nasa.gov/alsj/a17/LM12-co22.jpg [16:14:05] huh 15's seems out as well [16:14:06] https://history.nasa.gov/alsj/a15/lm10-co13.jpg [16:14:30] hmm maybe not [16:15:09] iiiinteresting [16:15:14] https://history.nasa.gov/alsj/a15/lm10-co14.jpg this one it looks in but it could just be the angle [16:15:18] I think its out [16:15:25] the flight copy of the Apollo 15 LM Activation Checklist has a comment about it being open [16:15:39] oh? [16:16:07] have a link? [16:16:10] https://readux.ecds.emory.edu/books/readux:sc5zx/pages/readux:sc688/ [16:16:52] don't think that means they should open it, they also changed the number of open CBs on the right [16:17:03] I think that means it should have been open [16:17:11] as shown in the closeout photos [16:17:23] yeah, so just like 16 and 17 [16:17:45] Wonder if there was any demonstration about the ASA being able to warm up later and be accurate [16:18:04] Or if it was due to additional heaters (MESA) being necessary [16:19:07] I guess 13 demonstrated the ASA could cool down and warm up and be accurate [16:24:32] right [16:28:10] interesting info for the J mission LMs [18:18:21] indy91 can you explain the differences in the LS and LS during TLC REFSMMATS? [18:19:13] so, the LS REFSMMAT as the AGC also calculates it in P52 option 4 you need a CSM state vector, as that defines the orbital plane of the CSM [18:19:33] how do you get that CSM state vector in TLC [18:19:44] you have to do all the effort like the LOI-2 REFSMMAT for Apollo 8 [18:20:07] which I think is the only way the real mission could do it, of course with the help of the MPT [18:20:23] the "LS during TLC" method defines the CSM orbital plane with the approach azimuth [18:20:43] and the landing site coordinates [18:21:01] so that works without a CSM state vector in lunar orbit at the landing time [18:21:13] I don't think the real RTCC had a method like that though [18:21:23] but it's much easier and nearly as accurate [18:23:06] it uses the approach azimuth from the LOI processor inputs [18:23:45] but once you are past LOI-2/DOI the LS REFSMMAT should be calculated using the CSM orbit [18:24:22] there is always a REFSMMAT update in lunar orbit before landing and it's always been very small compared to "LS during TLC" [18:27:22] makes perfect sense [18:32:01] hmm did I miss something? Was Apollo 16's flight pushed back for some reason? [18:32:12] Their prelim LOI was 4 hours after mine [18:32:19] and the flight plan [18:33:40] Oh wow [18:33:49] Disregard I had 15's open [18:35:19] oh speaking about 16, do you have a pre TLI scenario for me? I wanted to see how it does in terms of overburning/underburning [18:35:52] without implementing the post TLI LH2 venting, maybe it could improve accuracy a little bit if I bias the cutoff by the same amount that the LH2 vent was supposed to be [18:36:08] I think it was 0.26 m/s [18:36:50] so I am curious where the pericynthion altitude is in your Apollo 16 scenario [18:36:57] I should yes one moment [18:37:03] with IU nav update, so I need pre TLI [18:37:27] Take the caveat that the launch was done on my laptop, so timestep/frames could have had an impact [18:37:36] right [18:38:01] with a fresh SV the IU should be happy [18:42:05] 10m before tb6 ok? [18:42:08] yep [18:42:21] https://www.dropbox.com/s/udk47h4usinvggc/Apollo%2016%20-%20TLI.scn?dl=0 [18:42:43] in terms of IU state vector accuracy, there used to be a bug at liftoff that made the accuracy worse if you had a bad framerate [18:42:46] thanks! [18:43:30] so not sure how much that is still a factor [19:17:32] rcflyinghokie1, with a IU nav update I get a 3 ft/s MCC-2 at 30h GET [19:17:36] unconstrained [19:17:42] 5 ft/s with time constraint [19:18:00] thats really good [19:18:19] I would only make that worse when I mess around with the cutoff bias again, so I think I'll leave it alone :D [19:18:36] pericynthion altitude after TLI cutoff is 120NM or so [19:18:37] considering 16 burned 12.5fps [19:18:55] it means the presettings are good at least [19:19:11] The mission report shows 146.7 after TLI [19:19:14] and the cutoff bias agrees with the actual tailoff thrust [19:19:45] so hopefully with the now better orbital navigation TLI should be less of a problem [19:20:03] very nice [19:20:55] :D [19:22:01] well I really wanted to do this test to see if we now get a slight underburn because of missing LH2 venting [19:22:09] but we don't soo, test failed? :D [19:23:29] well the PC is still a little low [19:24:19] not compared to the planned number [19:24:25] that is 71.4NM [19:25:00] but the sensitivity is very high for that [19:25:15] 279 NM difference in PC altitude per 1 ft/s TLI cutoff difference [19:25:40] so basically nearly perfect [19:32:51] Fair enough! [19:36:04] you just have to look at the THC and your pericynthion has already changed by 10NM [19:39:36] Haha [19:55:22] LOI looks like its going to be a good one based on the pad and calcs [19:55:36] less dvz than actual [19:56:55] actual: -2781.6 -219.6 -256.2 RTCC: -2793 -233.3 -161.5 [20:01:15] yeah looks similar, actual mission rotating the orbit a bit more with the DVZ [20:19:45] very good burn [20:19:53] 0.6 on the EMS [20:20:23] -.2 -.2 0 on the N85 [20:20:56] 170x59.3 on N44 [20:26:37] I hope that's a -0.6 on the EMS [20:27:14] and even that should be even more negative I would think [20:27:31] unless you put in the total DV and not the DVC [20:30:41] with DVC the EMS should have -6.0 [20:40:56] sorry it was a +0.6 [20:42:03] Ahh [20:42:10] yep I used VT [20:43:17] Rookie mistake haha [20:54:02] previously the values were nearly the same [20:54:11] but not exactly, especially not for LOI [20:54:26] EMS accelerometer is along the X-axis of the CSM [20:54:38] but the thrust vector isn't exactly the same [20:55:04] so even before we got a 1-2 ft/s or so difference of DVT and DVC [20:55:37] the Detailed Maneuver Table shows the tailoff DV separately [20:55:53] so if you wanted the EMS to end exactly at 0 after a burn you could add DVC and DV TO [20:56:03] not sure if they ever did that for a maneuver [21:03:44] the RTCC maneuver simulation even has separate values for total DV of tailoff and tailoff DV along the x-axis like for the EMS [21:03:53] now that is not a very significant difference :D [21:05:15] Quickly cutting in here. Has any of you ever seen a panel 201 with a food warmer switch/cb? I'm listening to the baseline CSM configuration from the Apollo 13 tapes and I don't recall every seeing that. [21:09:04] there is a ACA utilitiy switch on a panel 201 [21:09:06] AC* [21:09:12] not sure if we have that [21:09:43] AC utility* [21:10:19] Same thing but relabeled maybe? [21:11:39] maybe [21:11:47] AOH mentions the food warmer switch [21:11:54] Volume 1 [21:11:56] We don't have CSM-109s system handbook. [21:12:00] OH. What page? [21:12:01] page 2.12-80 [21:15:19] I'm gonna check the CSM112-114 system handbook but I don't think we have this. [21:15:33] 104 systems handbook doesn't have the panel at all [21:15:57] It probably would go into AC utility as it is a stowed device. Probably relabeled [21:16:46] it's not even in the Apollo 14 Launch Checklist [21:16:57] the checklist starts with a list of initial switch states [21:17:06] or at liftoff rather [21:18:59] The system handbook still shows the switch as "AC Util" [21:20:18] seems like the other way around, food warmer until at least Apollo 13 and then later it's AC Util [21:20:38] That would make more sense [21:28:05] night! [22:02:15] .ask indy91 So about that Skylab document. you have a link or a hint of where I should look? I'm interested in it. [22:07:37] I can probably dig it up [22:07:40] actually [22:26:18] Awesome [22:26:21] thank you [22:27:08] it took us a bit to work that out lol [22:27:44] it's also possible, but a bit more difficult, to map a document number of the form Nyy-xxxxx (where yy is a year) to an NTRS ID [22:30:07] ahh [22:34:15] :) [22:41:02] I have a fairly large collection of offline documents now. [22:42:49] I used to have a bunch of shuttle docs circa 2007. at some point, I just figured I'd always be able to access them and stopped maintaining the archive [22:43:05] which was dumb [22:45:49] hah yeah having offline backups is always good [22:46:15] speaking of, I've been meaning to buy a big drive and back up all of the listings and engineering drawings and things we've added to archive.org..... I should do that this week [23:10:46] brb [10:29:55] .tell indy91 nevermind, Mike hooked me up with it and and showed me how to find stuff like this [11:00:16] Hey Matt [11:35:27] hey Thymo [11:41:10] what's up? [11:42:27] Listening to Apollo 13 again while working. They just read up the LM to CM power procedure. Also taking a glance at the ECA on the side to figure out how they made it work without disconnecting the batteries. [11:43:45] Also got the FLIGHT loop in one ear where they are discussing if the PLSS LCG water is safe to drink and optionally feeding it into a ASC water tank to use with the sublimator. [11:55:26] oh cool [11:56:59] They opted not to fill the tank because the tank would need to be empty (which took 30 hours) so that the delta pressure could push the water from the PLSS to the ascent tank and they're afraid the water in the DES tank would've frozen by then so they rather use that first. [11:57:58] Fred Haise also suggested this independantly but with the urine bags. That also wasn't done due to the 30 hours it takes to use that tank. [12:01:01] They also appeared to have done of the descent batteries short out causing a thump and venting from the descent stage. It was believed this was the relief valve on the ambient helium tank but post-flight they determined this was a small hydrogen explosion causing electrolyte to leak. [12:01:24] This was also shown in the telemetry [12:01:25] https://history.nasa.gov/afj/ap13fj/pics/battery-transients.png [12:01:38] Bus voltage dips and BAT 2 amps are off scale high [12:02:03] woah [12:02:13] They are going to get a battery fault light later but I haven't gotten there yet. [12:02:33] https://history.nasa.gov/afj/ap13fj/pics/battery-terminal.png [12:02:47] It's assumed the battery leaked and then caused the terminals to short [12:09:28] n7275: Also have you ever read something about what the X LUNAR BUS breaker was for? The X LUNAR BUS is also connected by a relay when CSM power is applied, the breaker only bypasses this breaker. I'm wondering if it's just there for contigency purposes if that relay fails to latch or if there's more to it. [12:12:25] huh, I have no idea [12:15:55] Hmm, I think I know. [12:16:33] The relays are operated by the DES ECAs so if for some reason you needed CSM power after staging or in case of DES ECA failure you would need to use the breaker to tie in the X LUNAR BUS [12:16:52] So I don't think it was used in normal situations [12:17:10] .ask rcflyinghokie Do you know if the X LUNAR BUS was closed as part of any normal non-contingency checklist? [12:41:21] I still have a bunch of systems work to do for proper Apollo 13 fuel cell deaths [12:41:43] Like the electrolyte solidifying and stuff? [12:47:52] eventually, but salt-water phase simulation is fairly complex. first I want more stable pressures to the cells, so I can make voltage proportional to the reactant pressures [12:48:10] I guess you also want PH stuff at some point [12:48:32] then "clogging" can be done by partial pressure and "contaminating" the O2 tank with n2 [12:49:35] There was also some stuff about KOH contamination in the fuell cells in the mission rules. Don't know where that would be coming from though [12:50:00] Isn't the electrolyte made out of that stuff? [12:51:33] yeah' KOH and water [12:52:11] there are teflon seals that keep the electrolite, H2 and O2 seperate [12:52:30] those can break down over 550F or so [13:03:22] then the steam+KOH mix leaks out and activates the pH sensor [13:26:52] Hey Ryan [13:28:44] morning [13:29:03] It was closed whenever the LM went under internal power [13:30:20] It was necessary to tie the negative returns since some LM systems were "grounded" via the xlunar bus and others vis the CDR/LMP negative busses [13:34:38] Hmm. I can see that. There is no such thing as CDR or LMP negative bus. Equipment usually used frame ground in the LM. I don't know of any equipment grounded to the x lunar bus though. AFAIK that bus only exists to bring the LM and CSM to the same reference as the CM did use a negative return bus instead of frame ground. [13:36:47] It looks like the systems that were used on CSM power indeed use the x lunar bus as their ground reference, so in that case it makes sense for that breaker to be in when those systems are used on lm power [13:36:54] Actually there are a few systems grounded through the xlunar bus, and there are CDR/LMP negative busses [13:37:21] The systems on the xlunar bus were those that were intended to be powered via CM (Nik and I went though a few weeks of this research haha) [13:40:03] I can find only one mention of a negative bus in the systems handbook and that is on the AC power drawing. It says the DC input and AC output of the inverters are tied to two separate negative buses which are both tied to structure ground. So would it really qualify as a bus if it's permanently bonded to structure ground? [13:40:17] That also doesn't matter for the x lunar bus tie breakers [13:40:44] the negative busses in this case are floating grounds, and they are grounded to the frame [13:40:51] but they are denoted as negative busses [13:41:14] In what situation are they not grounded to the frame? [13:41:40] If they are always grounded it's not floating [13:42:17] the xlunar negative busses are floating grounds [13:42:36] the CDR/LMP negative busses are frame grounded [13:43:00] the xlunar bus tie ties those floating grounds to the CDR/LMP negative busses which are grounded to the frame [13:44:33] Where are the CDR LMP neg. buses described? They are not on the drawing I'm looking at. [13:45:55] Which are you using? And they are all in the AOH for example [13:46:16] I'm looking at the LM10 AOH Vol.1 and the LM-3 systems handbook [13:47:00] The only two negative buses in the AOH are the x lunar bus and the ED negative bus [13:48:08] Haha I have the LM 10 AOH up looking at many -bus examples :P [13:48:25] page [13:49:47] for example look at pdf 356 [13:49:53] the CSM/LM power transfer logic [13:51:10] Those buses don't exist in the systems handbook [13:51:37] And I trust that more than this simplified diagram [13:52:24] Haha we went through all of this recently [13:52:36] I've sent a screenshot of how that is drawn in the systems handbook. No bus to be seen [13:52:40] On Discord [13:53:10] Yes I have that open [13:53:50] the frame ground is denoting the negative bus [13:54:19] So you agree that "CDR negative bus" is just a convenience term used in the AOH and not an actual bus [13:54:21] and the floating grounds are the xlunar negative busses [13:54:37] As in the drawing they are tied together but there is no actual bus to speak of [13:54:54] Are you asking if there is a physical bus bar versus just being frame grounded [13:55:13] I'm not asking I'm stating how I see it. [14:00:14] well in the functional schematics there is what looks like a physical negative bus [14:04:56] "DN2" appear to be physical bus bars [14:06:29] on the other topic of the apollo 8 scns starting P37 when you load them he is correct [14:09:21] Okay so -DN2 are actual bus bars. I assume there is also -DN1 then. I just find the name "CDR/LMP - BUS" confusing as in the CSM the negative bus is the reference point where in the LM that is just a convenience bus bar to bond it to chassis ground. I also don't think there is any other place than that one AOH drawing that refers to it by that name. [14:10:11] In my mind it implies that there is a separate ground reference point other than frame ground and the x lunarbus in the LM. [14:10:44] Ahh ok I see where you thought that [14:12:54] I thought what you were saying was that the CDR/LMP - bus are there own entities rather than. "LM systems are grounded to frame ground through -DN2" as that does add up with my knowledge of the LM not having its own negative bus like the CSM. [14:13:10] But it looks like we're on the same page now :) [14:13:24] Yeah I think it was just a verbiage confusion :) [14:16:14] So how fucked are the mission scenarios? Is it just a quick fix or should I terminate next best PTP on my current run and start over and recreate them? [14:17:27] so it looks like the checklist is off step [14:18:00] Its calling the P37 call group then going back in line [14:18:37] I think I can fix them relatively easily [14:23:43] Is it just in the P37 checklist or is the computer in P37? [14:25:28] its weird, it loads calling "V37E37E" then returns to the proper place [14:27:00] But easy to fix [14:29:48] So it only starts P37 if you have auto execution on? It's not in P37 when you start it is it? [14:31:11] correct [14:36:06] Hmm a number of these Apollo 8 scns are screwy [14:36:14] The pre TEI one has the mission timer off [14:38:00] Is it in stop, are the numerics off or is the timer breaker pulled? [14:38:22] Don't think the timers have been touched since I worked on them in 2017. Unless its a power thing [14:39:33] its just all balls [14:39:47] so off is the incorrect wording [14:39:59] everything is on and powered, its just all balls not counting [14:41:40] That is weird. The switch shouldn't have been in stop [14:42:09] Switch was in start [14:42:13] Thats the odd thing [14:42:19] I can't imagine a code change would flip that switch. [14:42:29] So switch in start but the clock is stopped? [14:42:32] yes [14:42:45] Which scenario are you using? [14:43:04] Before TEI TIG-15min? [14:43:47] yeah [14:45:59] There is no mission timer state in that scenario [14:47:19] Can you try loading that scenario, exit and then start (Current State) [14:47:46] It should start counting then. I'm not on my desktop [14:48:04] Actually it won't. It needs to read that switch first [14:48:29] Yeah, it [14:48:39] It doesn't poll the switch. The switch sets that variable. [14:50:46] It's weird that there is no state for the timers. That's been there forever. [14:51:06] There are other panel config issues as well like EDS breakers in and the suit demand reg in 2 instead of both [14:53:43] I'm starting to get curious about calculating my own maneuvers back to earth and targeting a recovery area. Thinking about going back to earth and restarting 8 to get mission scenarios [14:54:11] I'm not gonna just stop. I want to fly this one to splashdown. Question is just if I complete the mission or head back now. [14:54:51] I didn't really make intermittent saves this run [14:57:50] As far as the premade ones, I can fix them pretty easily I have half done [14:58:26] And you can use the RTE processor to compute an early return if you like [14:59:35] This is the second issue in like a week and a halfs time. They need to be remade anyway before the next release. We just need to make sure we don't willy nilly messing around and making breaking changes for the scenarios [15:00:50] I think the checklist issue in these was me, I added missing groups so it likly "stepped" the location [15:01:06] What about the switches [15:01:11] But that TEI scn and beyond, the panel config is wrong [15:01:51] EDS, suit demand, mission timer. Those are 3 systems that don't have anything to do with each other. Makes me lose confidence in the consistency of the scenarios. [15:02:33] This is also CSM only. I wonder what the state of the later missions is like. [15:03:18] The panel config was just oversight on whoever saved it to begin with [15:03:49] Everything TEI and later has the same configuration and the mission timer not working [15:04:10] all the ones before TEI are fine other than the checklist step which I caused and only effects 8 [15:04:31] I can pretty easily fix these [15:25:26] found the problem with the EDS breakers [15:25:36] this scns origin predates correcting the names [15:26:07] EDS 1 2 3 used to correlate with A B C incorrectly [15:26:21] Now 1=A 2=C 3=B which is correct [15:39:41] all fixed [15:54:32] rcflyinghokie, I think (perhaps naïvely) that I might have a very simple way to move from ideal gas to Van der Waals for our hsystems [15:55:07] Oh really? [16:08:50] yeah, I just ran a quick test in matlab(octave) and things look right [16:10:33] the magic here is that we just let the fluid boil/condense so that we have the right "gas volume" so no need to do any newton rapherson, Maxwell construction stuff [16:13:25] things we'd need to add: [16:13:42] A and B coefficients [16:14:18] new equation of state in thermalcomps [16:14:40] make h_vap a function of temperature [16:15:05] ^better than it is now [16:20:52] hey Niklas [16:21:02] hey [16:21:10] n7275 that sounds like a great experiment to test [16:21:43] it might require tweaking of other systems of course [16:22:31] I'm sure it would [16:22:48] old Apollo 8 scenarios were broken? In what way? [16:24:06] well first of all a checklist change stepped the starting location/call group so that was my doing [16:24:38] For example, many of the TIG-15 scns for some reason were starting the P37 call group [16:25:03] the other thing I noticed was the mission timer was all balls for TEI and later, even though the switch was on [16:25:22] yeah that's still the original NASSP 7 scenarios [16:25:25] Apollo 7 has the same [16:25:48] And the panel state for TEI and beyond had the incorrect EDS breaker names [16:26:19] I only completly replaced the earlier scenarios as the LVDC wouldn't do TLI and the MCC wouldn't properly calculate midcourses [16:26:24] I havent looked at the 7 scns [16:26:40] but stuff like the mission timer being 0 is not something that breaks the scenarios completely [16:26:42] just annoying [16:26:45] checklist is a bit worse [16:27:30] the Checklist MFD is the reason why we can't properly maintain mission scenarios throughout development [16:27:45] one small change to it can completely throw off the checklist state [16:28:03] and it's barely possible to edit the checklist state in the scenario [16:30:07] Thymo, "It's weird that there is no state for the timers. That's been there forever." Yeah, but not in the NASSP 7 release yet which is where those Apollo 8 scenarios after LOI after still coming from :D [16:31:45] well the problems I mentioned in those are all fixed [16:33:08] great [16:34:52] all will be fixed with the great re-fly of all scenarios. [16:35:19] and then they will get broken again haha [16:35:31] well...yes lol [16:58:10] morning! [17:05:54] hey Mike [17:07:42] Hmm why would the lunar surface flag be set before the first P20 of 16? [17:09:37] 75h20m [17:10:54] I don't see a V45 this time [17:11:02] But I am getting SV updates with V66 [17:20:17] Ah they keep it set until LM activation...wonder why [17:30:54] all that really does is inhibit LM state vector integration [17:31:16] I know [17:31:22] I am trying to figure out the purpose here [17:31:37] especially with V66s and the DOI all while its set [17:32:07] reduce processing time maybe [17:32:28] ah could be especially with the P20 almost constantly running [17:33:08] something like that yeah [17:40:13] n7275, did you get all the Skylab Data Book stuff that you wanted to look at? [18:34:58] Hmm do I fly 16 per the flight plan or delay the PDI [19:28:53] indy91 yes [19:31:47] ah good [19:45:46] https://www.dropbox.com/s/km3bjrbgaibj67l/Screenshot%202021-09-07%20134535.jpg?dl=0 [20:09:42] I think that's at a specific longitude [20:09:44] 0° or so [20:11:22] interesting [20:11:48] ah yes, the moon spikes. very pointy [20:15:36] Surprised there's not a P24 pad for them ;) [20:53:44] night! [14:06:46] hey [14:41:04] hey [14:41:31] I made it to splashdown on 7 last night ... almost [14:41:56] something weird happens when the cm hits the water [14:43:03] framerate drops to like 0.1 and then gets worse from there [14:43:27] huh [14:43:32] haven't seen that before [14:44:40] https://drive.google.com/file/d/1gvWF_DOdrwGldTL36nTjLYtJvYw_LHtQ/view?usp=drivesdk [14:45:34] it happens reliably for me with this scenario [14:49:28] trying it right now [14:49:38] I think I have rarely loaded a scenario on chutes [14:49:44] maybe it's related to that [14:50:27] no problems here [14:50:36] no framerate drop or so [14:51:12] well that's very strange then [14:51:35] I can reload earlier scenarios and have the same issue [14:51:51] or post-splashdown and same [14:52:32] maybe we have some different setting for terrain resolution or something like that [14:53:46] I will look at those tonight [14:54:01] i even tried rebuilding [14:55:48] does releasing the chutes change anything? [15:16:55] I'll have to try that again, it'll have to be before I hit the water. after, orbiter becomes unusable [15:53:44] morning! [15:56:03] hey Mike [15:59:15] what's up? [16:00:06] oh I started my 5th attempt or so to implement a specific RTCC function [16:00:27] and you? [16:00:58] hahahaha [16:01:20] taking a closer look at my CDU simulation now that we have documents giving numbers for how it performs given bad inputs [16:01:58] and trying to track down if/when the coarse system changed from an 8.4 degree threshold to a 7 degree on [16:02:26] also, the majority of your requested Apollo 17 checklist/procedure/etc. documents should hit the website tomorrow [16:02:42] ah great [16:03:04] I'm sure Ryan will find them very useful [16:03:13] he will probably fly 17 next I guess [16:04:30] so that is a CDU modification that got done at some point? [16:04:47] Early on or when they were already flying missions [16:05:39] absolutely no idea! [16:05:42] that is the mystery :D [16:05:45] J mission CSM Systems Handbook still says 8.4°, but that doesn't mean much [16:06:12] ND-1021043 says 7 degrees, but then specifies a voltage that corresponds to 8.4 degrees [16:06:22] not helpful lol [16:06:25] what if they changed it from 7 to 8.4 [16:06:31] early on [16:06:38] mmmm I don't think that is the case [16:06:49] because the early specs only mention 8.4, and then some later ones bring in 7 [16:07:12] Apollo 16 had CDU trouble [16:07:17] did they make a changed after that? [16:08:08] do you have the anomaly report for that? [16:08:10] hmmmm, I don't think it would be that late [16:08:30] I'm pretty sure we don't [16:08:47] well I do [16:08:52] it's not super useful [16:09:18] hah [16:09:22] https://web.archive.org/web/20100525144108/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19730018171_1973018171.pdf [16:09:48] ah, they really only had a false failure indication it seems [16:09:55] I thought they had a real problem [16:10:35] ah interesting [16:10:50] it's really not easy to search for 7 and 8.4 haha [16:11:23] well anyways [16:11:44] thanks to one of our new documents describing how things work, I know which resistor they would have had to change to change the threshold [16:12:18] so I'm hoping that would lead to a different dash number for those modules, and so our configuration drawings will specify which vehicles got the change when [16:17:06] Apollo 16 had both actually [16:17:16] a false CDU error causing a master alarm [16:17:45] and a "false gimbal lock indication in the computer caused by an erroneous 90° middle gimble angle bit in the electronic coupling display unit" [16:18:52] CMC then coarse aligned the IMU because of that [16:18:55] so actual problem haha [16:18:57] happened in TLC [16:19:28] I think that's why they ran some EMP to monitor or prevent that [16:19:39] oh random read counter bit change [16:20:09] I have another memo relevant to that, that vastly predated 16 :) [16:20:10] http://www.ibiblio.org/apollo/Documents/edg_memo_216.pdf [16:20:46] actually it goes into detail about the Apollo 12 lightning event, which is interesting [16:22:14] okay, R73 is the resistor in the coarse module that sets the threshold angle for the coarse system [16:22:25] now, did that ever change... [16:23:25] oh no [16:23:35] https://i.imgur.com/EXHSl5l.png [16:23:40] yeah I'd say it probably changed lol [16:24:24] a bunch of times haha [16:25:16] can you attach those part numbers with revisions of the CDU and the timeframe of the change? [16:25:21] "Select item 71 (R73) per applicable PS from appropriate chart. (Selective electrical component.)" [16:25:22] great [16:25:41] those are options -- the different part numbers are just for the resistors themselves [16:25:46] ah right [16:26:01] very scientific method [16:29:14] right? what even is the applicable PS here haha [16:30:19] uhm [16:30:26] the flown Apollo 15 CSM Systems Data [16:30:29] has 5° [16:31:31] so does the CSM 112-114 Systems Handbook from March 12, 1971 [16:31:50] but CSM 114 Systems Handbook from August 23, 1972 has 8.4° [16:34:32] ??? [16:36:08] LM Systems Handbook tends to have 8° [16:37:02] and I zoomed in again to make sure it's actually 5 and not a 8 [16:54:59] my contribution is more confusion by questionable sources. Thank me later. [16:55:30] hahahaha [16:55:32] thanks a lot [17:33:38] I don't see 5 anywhere in these procurement specs [17:33:50] and the most recent revision for the CDU procurement spec is not helpful [17:34:31] it gives two different specifications... one for "IMU (Type I)" which is 8.4 degrees and one for "IMU (Type II)" which is 7 degrees [17:34:43] but doesn't actually bother to specify when you would use Type I or Type II [17:42:51] different kinds of CDUs? [17:42:55] ICDU, OCDU, RR CDU... [17:43:44] hmm [17:43:55] do OCDUs and RR CDUs even have this haha [17:44:42] optics and RR are specified explicitly elsewhere in this spec [17:44:48] right [17:44:58] so I doubt they'd say IMU (Type II) when referring to them [17:45:14] ah yes haha, didn't properly read that [17:47:40] "The operation of the Block II ECDU, in a system configuration, disclosed two problems that required design changes. The coarse-fine crossover for the ECDU was originally designed to take place at a maximum coarse error of 9 degrees. System tests showed that, under certain conditions, an oscillatory limit-cycle condition developed between the coarse and fine systems. A design change made to reduce the crossover point to 7.5 degrees [17:47:40] ull corrected the problem." [17:47:51] well, neither of those are exactly the numbers I was expecting to see [17:48:22] maybe the tolerance is fairly large [17:48:32] so 9° is the max, 8.4° nominal [17:48:40] and then 7.5° max, 7° nominal [17:49:11] oh yeah [17:49:13] from the PS [17:49:59] "Coarse Ternary (IMU) Type I. The Coarse Ternary Schmitt Trigger shall have an 800 pps output when the 1X resolver is set to 8.40 degrees +/- 1.40 degrees..." [17:50:16] "Coarse Ternary (IMU) Type II. The Coarse Ternary Schmitt Trigger shall have an 800 pps output when the 1X resolver is set to 7 degrees +/- 0.5 degrees..." [17:51:08] so far I'm thinking that I should be using 7 degrees, as what most likely flew [17:51:41] oh, so already type II on Apollo 11 [17:52:33] maybe? [17:52:50] that's what I'm really trying to figure out lol [17:52:57] what the threshold was on 11 [17:53:45] because except for very specific conditions, in a nominal simulation it does not matter at all. but for replicating bad behavior it matters a lot [17:55:14] the ASTP Delco book still has 8.4 degrees [17:55:58] so they probably never updated it... but I'll check the books for 11 and 14 to make sure [17:56:23] I check 15 earlier, it has 8.4 [17:56:26] checked* [17:56:58] 11 doesn't actually specify [17:59:41] nor does 12 [17:59:47] that page was first added in the 13 version of the book [17:59:50] which is even more annoying lol [18:05:07] although the resistor in question is the same value through all books [18:05:09] 6.2k [18:05:18] which was the original value that corresponds to 8.4 degrees [18:10:13] I really was not expecting this to be this hard haha [18:10:46] yeah, especially with all the schematics scanned [18:14:25] whatever happened it has to have been early [18:14:37] because we have effectively both the first and last revs of ND-1021043 [18:14:46] and both of them say 7 but give a voltage for 8.4 [18:15:18] and that first rev is March '66 [18:26:10] but somehow nobody got the memo that it isn't 8.4... ever? [18:28:46] yeah no clue [19:41:37] Evening [19:47:56] yo [19:52:38] hey [19:56:20] Listening to A13 audio while flying up to LOI-2 on 8 [20:00:26] flight directors loop? [20:04:36] Flight directors and the downlink [20:04:57] Listened to the TELMU loop for a bit when the battery fault came up [20:05:30] EECOM is great, too [20:06:51] Yes, it's pretty quiet right now though at T+100h [20:07:24] lol yeah I bet, with the CSM powered down [20:07:52] at the accident and the hours after it it's really great to listen to EECOM and the support team [20:19:06] Just had a crash after I pressed the P99 button on the EMP page [20:22:21] P99 on a mission without a LM eh? [20:22:27] I could see how that could lead to a crash lol [20:23:11] it's missing a check if the vehicle is a LM [20:23:14] It shouldn't crash the whole sim, it should handle the error. [20:23:17] but why that crashes... [20:23:31] it will try to connect to the LM socket for uplink [20:24:39] of course if you were doing the P99 uplink to a CMC then you would have to reload anyway, so little difference :D [20:24:42] but I'll add a check [20:26:13] Might be worth adding some error handling to the socket stuff. There was an edge case in the CSM where that socket sometimes doesn't get started, same can probably happen in the LM. [20:28:01] yeah, there is some error handling, but maybe not enough [20:31:44] didn't crash for me [20:31:59] but there is that delay when it unsuccessfully tries to connect to the LM socket [20:32:11] might cause the crash [20:50:56] indy91: Does the RTCC MFD have displays that can help me get my orbital period? [20:51:29] FIDO Orbit Digitals would have that. Basically the low Earth/lunar orbit version of the Space Digitals [20:51:48] but I haven't made that "non-MPT mode" ready yet [20:54:53] Just go MPT -> INI, VEH, AUT, M55 right? [20:55:09] Or do I also need to get a vector to initialize it? [20:55:18] also needs an initial state vector [20:55:36] and masses, so both buttons on the right of the MPT init page [20:55:40] M50 or whatever it is [20:56:09] Is just DC enough or do I need to transfer it [20:56:15] Make it my anchor? [20:56:40] yeah, DC is the finish product of long-term tracking of the spacecraft. Or in the RTCC MFD, one button press [20:56:50] still neds to be the initial state vector of the CSM ephemeris [20:56:55] so the TUP button and then choose DC [20:57:18] needs to be made* [20:57:45] I got data now [20:58:04] period is somewhere on the right [20:59:08] "TO" [20:59:20] Oh nice, so I don't even have to calculate it myself [20:59:43] right, seems to be one of the automated processes [21:00:08] display gets calculated on a 12 second timer whenever there is a valid CSM ephemeris [21:00:25] and when you have the display shown of course [21:00:48] and a bunch of other data at the current time [21:09:34] So what I wanna do is now that I have this number is calculate what my orbital rate would be. Of course I could just fly to keep the ORDEAL at a certain pitch angle but as I wanna learn more of this stuff it's a good exercise. [21:10:19] Is it just To in seconds / 360° for orbital rate? [21:10:39] other way around, 360° / period [21:10:46] gives you degrees per second [21:10:56] Ah yes, that's right [21:12:02] So about 0.046° per second [21:12:11] yeah, it's prett slow [21:12:33] Earth orbit is a bit quicker with the 90 minute orbital period [21:12:37] instead of 120 minutes [21:16:34] It's less than one pulse in MIN IMP [21:19:05] get yourself a LM for more inertia [21:20:04] but I think you should still be able to get the correct rate going, roughly at least [21:20:14] will need adjustments over time [21:20:22] Yeah, I just need to trim it every once in a while. [21:21:02] Does the side hatch dump valve induce any rates? :P [21:21:42] you could try a quick uncoupled firing [21:21:52] so with just one thruster instead of two [21:23:13] good idea [21:29:32] night! [13:40:28] Hey Ryan [13:49:51] hi Ryan, Thymo [14:25:13] .tell indy91, is this you? https://photos.app.goo.gl/2nufXdUvAhgF4rRaA [14:26:18] Morning [14:27:17] 15 minutes away from LOI2 [14:29:52] Awesome [14:29:59] I am going to fire up after my 9am meeting [14:30:32] Do MCCs P30 pads not calculate trim at all? [14:30:55] Mission rules state that if the last burn was CMC controlled the stored values should be used, but this isn't listed on the PAD. [14:31:46] It's only .02° in pitch but still, I think it would be on the PAD [14:32:16] ptrim and ytrim should be on there [14:33:30] They are on there but 0 [14:33:53] yes because our CSM has a perfect CG without a LM [14:34:28] any time the LM is attached you will see MCC compute nonzero trim [14:34:36] CSM alone will be zero right now [14:36:07] Well, the CMC came up with a different number. I'm not 100% sure how it calculates it. Probably whatever trim it held at the end of the burn [14:44:03] Yeah that sounds correct [14:45:00] I set it to zero again [14:45:27] any good documents on sps tank slosh modes? that would be fun to impliment. [14:48:24] Afternoon Nik [14:48:39] hey [14:49:10] well I wished it was [14:50:00] Question about the vector compare display. Is V2 supposed to display the differences from V1 or is it supposed to display the actual values? [14:50:11] differences [14:50:18] and in some cases it's not even the same unit [14:50:30] where V1 has nautical miles V2 in some cases has the difference in feet [14:50:33] Like velocity? [14:50:44] That was the only difference, rest wal near 0 [14:50:49] I think in velocity it should be the same [14:50:52] same unit [14:50:52] s/wal/was [14:51:21] the total velocity or in the weird UVW system at the bottom? [14:51:31] The latter, UVW [14:52:03] Ah I see velocity is higer up. What's UVW? [14:52:13] V is about +285 [14:52:17] it's basically LVLH [14:52:27] oh, there is UVW and UVW dotted [14:52:37] V is downrange distance [14:52:42] so not velocity [14:52:51] or at least some distance, let me check [14:53:48] but you can barely see the dot above the lower three values [14:54:29] U is radial [14:54:36] W is out-of-plane [14:54:40] V is downrange [14:55:00] and then you have the same in velocity below that [14:55:22] so I think +285 in V2 for V means 285 feet in downrange error [14:55:51] which is pretty small [14:57:00] oh and about the SPS trim [14:57:53] the SPS in its electrical null trim position is already angled at an offset [14:58:01] about 2° in pitch, 1° in yaw [14:58:32] so to point it through the centerline, with a perfectly centered CG, you would actually need -2° and +1° in trim [14:58:49] a long time ago someone decided that is annoying in NASSP [14:59:12] so the SPS in NASSP does not only have this offset of the null trim position [14:59:21] but is also offset in its position [14:59:28] in such a way that it points through the CG [14:59:36] that leads to always 0° trim angles for the CSM [14:59:45] The stored angles were +0.02° and -0.00°, so that's in the other direction. [14:59:50] but then the combined CG of CSM and LM is further away to the LM [15:00:07] so with CSM+LM we do get trim angles that are not 0 [15:00:18] Whenever did we choose convenience over realism? If the position is not where it should be it should be corrected IMO [15:00:23] my preferred way is to remove that offset [15:00:26] I agree [15:00:38] what we get then is always the -2.15° and +0.95° trim [15:00:43] I mean, that's what the trim is for isn't it? Now it's pretty much unused [15:01:10] I think that's fine. It's listed on the PAD anyway so there's no issue in people not knowing to set the trim. [15:01:11] yeah, it just wasn't changed yet out of more convenience :D [15:01:29] and the DAP will have the last values stored, at cutoff of the previous burn [15:01:41] so if you got 0.02° there it might have done a bit of steering at the end [15:01:54] it does often end up at exactly 0°, but it can be slightly off [15:02:42] the RTCC is mostly ready to change that, I have some extra lines of code in the function that calculates the CG and trim angles [15:02:52] .02 degree is practically nothing. Last burn was LOI1 and the trim always oscillates every so slightly around 0 degrees [15:02:54] I basically just need to remove that [15:04:12] in my mind I wanted to wait unti the CSM gets a variable CG [15:04:37] because we will have the same trim values with that change for all CSM and CSM/LM burns [15:04:53] just a bit boring, but not really a reason to keep it the way it is [15:05:36] and I'm not 100% sure we got all issues solved with the shifting CG. A while ago Alex mentioned some animation bugs of the LM RR or steerable antenna [15:05:44] rcflyinghokie, did you see any of that? [15:06:16] but I agree, that really needs to be changed. I'll look at it very soon [15:06:53] I recently had some VC clickspot issues during CM SM seperation, chute deployment, etc [15:07:46] right, that is also shifting the CG, might be missing some code handling animations [15:09:01] CG affects clickspots and animations? How? [15:09:30] the CG is the center of origin for the vessel coordinate system [15:09:49] so if the CG is in a different location all the coordinates of clickspots need to be shifted, too [15:10:18] Orbiter and NASSP have good code handling this, but something might be missing for CM/SM sep and the chute stages [15:10:29] Genius [15:11:41] I remember that there were some issues at staging during launch early in the CSM VC development [15:12:18] Something with clickspots shifting over time IIRC [15:12:27] that, too [15:12:40] but something to do with the CG shift at staging was a problem, too [15:12:47] It would be nice if you could define CG as an offset from the vessel origin [15:12:58] indeed [15:25:26] if we were to implement shifting CG then it wouldn't be too hard, I already looked into it [15:25:41] just assume the four SPS propellant tanks as point masses [15:25:49] rest of the CSM as another point mass [15:26:05] and you already get trim gimbal angles extremely close to actual [15:57:31] indy91 the only animation bug I have seen with the RR was it being appearing down almost parallel to the hatch [16:01:43] hmm ok [16:09:02] and clipping through the bulkhead a bit [16:23:56] morning! [16:24:33] after spending much time with the drawings I have an extremely unsatisfying initial answer for the CDU angle thing [16:26:35] it appears that the 8.4 -> 7 thing did fully happen, but only briefly, for CDU configurations -131 through -161. But after that for higher dash numbers, with only a few exceptions, they relaxed the requirement and 7 degree and 8.4 degree modules are listed as interchangeable [16:26:51] including the config that 11 flew with [16:27:05] so it could be either for Apollo 11 [16:27:25] so I don't know if there is even a way to know without seeing the part numbers for the coarse system modules inside its CDU [16:27:55] yeah [16:28:11] did that never come up in the investigation of the program alarms? [16:28:38] seemingly not [16:29:15] maybe they didn't think it mattered? it will change the precise behavior but overall results will be pretty much the same either way [16:51:07] the stuff I am working on also leads to mass loss because of LH2 venting being taken into account by the RTCC [16:51:17] not propulsive yet, but the loss of mass [16:51:45] comparing it to the actual behavior, we maybe have a tiny bit too much venting at the time of TLI [16:52:12] the venting thrust goes down over time in the real S-IVB [16:52:18] as does the mass loss [16:52:24] we don't have that right now [16:53:06] so at the time of the 2nd TLI opportunity we have too much venting [16:53:19] seems like it was adjusted to be about right for the normal TLI [16:54:04] I am giving the RTCC a realistic venting table as it's not too different from what we actually get in NASSP [17:02:02] Just realized Orion is missing the NODAP light [17:03:15] oh wow [17:03:20] Apollo 15: LMDSKYVersion=3 [17:03:24] Apollo 16: LMDSKYVersion=2 [17:03:28] that's wrong [17:04:02] just needs a fix in the config file for Apollo 16 [17:04:17] Missions/ProjectApollo/Apollo16.cfg [17:04:58] needs to be LMDSKYVersion=3 [17:05:46] must be a bad copy and paste [17:05:53] and nobody noticed for a long time :D [17:07:09] haha [17:09:53] PR sent [17:10:25] and merged [17:14:31] And I cannot spell "LGC" [17:14:56] guess the liquid cooling garments have a DSKY now :P [17:14:57] liquid cooling garment DSKY [17:15:46] aha, changing the title after the fact [18:06:23] sent* [18:07:46] thanks! [18:12:55] maybe those documents need some more processing before uploading them somewhere [18:13:08] I got two IBM RTCC documents with about 1000 pages [18:13:20] but even thought it's 1000 pages, they don't need to be 500 and 600MB [18:13:23] though* [18:13:35] feel free to send them to me, I'd be happy to process them [18:13:41] and they aren't even OCRed [18:13:46] I've certainly been doing enough of it recently lol [18:13:47] can't search in them [18:13:49] haha [18:14:06] I already have a folder of IBM RTCC documents in my Google Drive, I put the rest up, too [20:43:00] night! [13:22:08] hey Ryan [13:25:20] good morning [13:32:41] couldnt find a pdf Apollo 16 LS checklist so I just made one with all the page jpg scans haha [14:30:23] hey [14:37:45] good morning [14:42:15] hey [14:42:47] I fixed my splashdown issue [14:43:36] I forgot I messed with time propagation settings a month or so ago... [14:44:26] oh, interesting [14:47:27] RK8 and 10000 subsample, and contact with the ground do not mix [14:53:09] also doesn't sound great for performance in general [15:05:22] no, not at all [15:55:10] morning! [15:56:16] did you guys see Ron's update this morning? [15:56:38] in addition to all of the checklist stuff I scanned, he also added the Apollo 9 LM G&N Dictionary [15:56:40] http://www.ibiblio.org/apollo/Documents/apollo_9_final_dictionary.pdf [16:06:03] hey [16:07:00] Alex! [16:07:34] thewonderidiot, haven't looked at it yet, but I'll be sure to check it out. [16:07:58] hey Alex! [16:11:02] Oh thats certainly a good G&N to have :) [16:11:26] Now if only that elusive AGS documentation would turn up [17:13:52] ah nice, I only had a few pages from auctions of that Apollo 9 G&N Dictionary [17:14:53] Same here [17:35:22] ok I think I have a new version of the general RTCC numerical integrator that fixes all the shortcomings of the current version [17:35:54] I'll use it for only one thing initially, will take a bit of time to properly roll it out and use it everywhere it gets used [17:36:14] but I think it's an important step for the RTCC that such a fundamental function is now working right [17:44:41] forgive my ignorance, but what impacts would that be making [17:47:17] mostly for the MPT, but not only. Drag and venting mass loss will be considered for the ephemeris. [17:47:56] Stuff like the vector compare display call this function to propagate a state vector to some desired tme [17:47:58] time [17:48:06] and maneuvers can be considered for that [17:48:26] that's basically what this function does, it's the interface to the maneuver and coasting integrators [17:49:18] the current function can only take 1 maneuver into account [17:49:30] so there are some bugs that can currently not be prevented [17:49:39] like if you did you last trajectory update before TLI [17:49:43] your* [17:50:00] and then save a scenario after the separation maneuver, if you had that on the MPT [17:50:20] then if you load that scenario the last state vector, pre TLI, would be taken to current time [17:50:43] which is now two maneuvers later (TLI and separation or ejection) [17:51:54] but I think it's really the handling of masses that is the more important improvement [17:52:08] you need to handle mass and areas for drag calculations [17:52:13] and mass also for venting [17:56:28] it's also better at handling coordinate systems [17:57:05] sounds nice [17:57:15] the old method uses a state vector like this: time, position vector, velocity vector, reference body indicator (Earth or Moon) [17:57:30] and then saves large tables of these state vectors [17:57:41] but that's wrong, it doesn't save the body indicator [17:57:59] the ephemeris table has a header and that's where that indicator exists once [17:58:16] the ephemeris is often being interpolated [17:58:18] lots of enhancement to experiment with [17:58:37] and when the next state vector is suddenly in lunar reference instead of Earth [17:58:45] that doesn't give a very good interpolation :D [17:58:48] Haha [17:59:08] there is some bad code right now dealing with that [17:59:13] And I will say RTCC performed very well in computing the delayed PDI and circ for Apollo 16 [17:59:24] ah great [17:59:54] including those delay times, all times have been within about 2 minutes of actual this mission [17:59:55] did you get an updated LS REFSMMAT? [17:59:58] yep [18:00:28] the real mission did that I think. REFSMMAT would have been 3° off because of Moon rotating [18:00:31] which I believe is still fine [18:00:47] but an update is better [18:01:00] One thing I noticed at least on the PDI pad is my crossrange seemed small [18:01:21] the actual PDI pad had a crossrange of 3.6 [18:01:28] I had 0.3 [18:01:33] interesting [18:01:53] maybe the different lunar gravity field [18:02:12] is that the final PDI PAD? [18:02:17] yes [18:02:46] attitude was a little different as well but not by much [18:03:17] probably because of the crossrange (R 002 actual vs R 000 NASSP) [18:03:51] ah yeah, I think that is normal [18:04:04] will try to compensate for the crossrange at ignition [18:04:12] taking out the out-of-plane [18:04:26] we used to get non-zero roll angles on Apollo 12 I believe [18:04:49] when we didn't have a good LOI method resulting in small crossranges [18:05:57] right [18:06:09] just interesting to see the differences in orbits in that case [18:06:16] wrt the crossrange error at least [18:06:59] oh actually [18:07:09] they already had a plane error before the nominal PDI [18:07:41] "LM activation for descent began at 91:50 GET. During this phase 3the Flight Dynamics Officer reported that PDI would be initiated 10,000 [18:07:42] ft higher than nominal and 17,000 ft out of plane" [18:08:11] 17k feet in 2.8NM [18:08:22] is* [18:08:31] did I see that the mystery EMEM corruptions may be a thing of the past now? [18:08:34] Ah yeah the original PDI pad had 2.6 [18:08:45] ah [18:08:53] AlexB_88, Thymo likely found the cause [18:09:01] I think so Alex...I suffered some pretty bad ones on 15 haha [18:09:03] something with time acceleration and multi threading [18:09:09] right [18:10:05] well good job Thymo, that was quite an elusive one for a while [18:11:19] They are! Corruption due to time acceleration is a thing of the past now [18:25:30] https://www.orbiter-forum.com/threads/nassp-8-installation-guide.36801/page-3#post-586369 [18:25:50] I guess that is a good idea [18:32:36] but I find OHM frustrating to use... its slow, some of the links are broken [18:36:47] but if its a direct link to the file, that doesn't matter I guess... Ill add it to the installation guide [18:37:20] sure its an option [18:51:52] done [20:02:31] So just a quick CMRCS temp check at 147h: 3.5v, 2.2V, 2.4V, 3.4V, 2.9V, 3.1V [20:02:53] Seems pretty normal [20:04:53] they were warmer during TLC/PTC so I am expecting a little higher at warmup time but still looking good for an initial guess [20:09:12] is that what it's supposed to be? I thought they were quite cold and then the pre heating is warming them up. Or was that the idea and it wasn't really necessary on the real flights? [20:23:09] rcflyinghokie, first part of the Van der Waals substances is done. no adverse effects [21:00:44] night! [21:07:25] night [01:36:26] n7275 awesome! [01:36:57] I assume the first round was a substance by itself not in a mixture [01:42:33] rcflyinghokie just treating mixtures like ideal gas partial pressures right now [01:48:39] I am curious how liquid and gas mixtures will behave like helium and hypergolics [01:49:30] you tried systemsSDK SPS tanks before right? [01:51:38] I havent messed with the SPS tanks [01:51:51] I tried the mixing within the DPS though with poor results lol [01:52:22] oooh okay [01:58:56] Same idea though, both DPS and SPS I believe use direct helium pressurization [01:59:41] Also, our vapor pressure is linear, while actual vapor pressure is exponental [01:59:55] for water we have: https://www.wolframalpha.com/input/?i=plot+39441.0+-+%28273.0+-+T%29+*+680.0%2C+T+%3D+0+to+647 [02:00:09] vs https://en.wikipedia.org/wiki/Vapour_pressure_of_water#Graphical_pressure_dependency_on_temperature [02:07:51] yeah ours are oversimplified haha [02:24:35] Weird this has had almost no noticible change on pressures [02:24:53] Hmm not sure if thats good or bad [02:25:15] same here [14:43:21] Any idea what causes this on the textures? I noticed it after extended stay on 15 as well https://www.dropbox.com/s/km3bjrbgaibj67l/Screenshot%202021-09-07%20134535.jpg?dl=0 [15:42:17] rcflyinghokie, my guess would be it's an error caused in the creation process of the textures [15:42:55] yeah I only get it during long stays on the moon [15:43:08] oh really [15:43:27] as in, they're not there when you first load the scenario [15:43:50] ? [15:45:48] I've definitely seen them before too though [15:49:05] I always assumed they were a discontinuity cause by Martin's matlab script. I know because of memory constraints it is done in multiple section so smoothing may not have worked. [15:49:44] could also be an issue with d3d9 clients interpolation algorithm [15:51:41] oh, i found my pressure issue after a bit more thinking/actually reading the code. [15:51:51] was only setting partial pressures [15:55:33] They arent there for the first part of the lunar stay, I think its a function of the sun angle [16:03:24] maybe somebody implemented a simulation of moon madness? [16:03:35] stay on the moon too long and you start seeing things... [16:11:33] is there any way to generate a liftoff table using RTCC? [16:42:31] not after the moon madness sets in... [16:43:10] I feel like there is a way. but I certainly don't know it [16:48:21] yeah its only the LM that the sun is hitting [17:00:57] hey [17:05:16] hey Nik [17:11:28] rcflyinghokie, what liftoff table do you want to get? [17:11:48] Basically the T times [17:12:49] A T time for each rev [17:13:15] which uses the coelliptic rendezvous profile [17:13:42] I think mainly you need to calculate a TPI time for each rev [17:14:11] for most other inputs the default value works fine [17:14:28] Not sure IO am following [17:14:30] *I [17:14:44] calculate TPI time, input that on the LLWP page [17:14:52] and calculate solution [17:14:59] Well I know how to do that part but I didnt want to manually do it for each rev [17:15:43] Thats why I was curious if it could generate a table haha [17:15:49] it can't [17:16:04] it only generates a table with launch window opening and closing for one rev [17:16:10] 10, 15 and 20NM DH [17:16:26] ah ok fair enough [17:16:28] with MPT mode you can generate a sunrise/sunset table [17:16:43] yeah thats what I use to compute TPI [17:16:56] and you can then quickly get a whole list of TPI times [17:17:19] in the real RTCC they had a "tape" prepared for this with the TPI time left open [17:17:30] best way to make it as automated as possible [17:17:38] but TPI time always needs to be supplied [17:19:08] oh and vector time maybe [17:19:39] yeah, the Apollo 11 FIDO called it the "T3 Tape" [17:19:56] and then he did instructions to the RTCC like [17:19:57] 104:00:00: Make LLWP T4 tape out of T3 tape. Changes 106:20:00 vector time, 109:10:00 TPI time, CSI 50 minutes after insertion [17:20:02] so kind of "plug and chug" [17:20:08] 104:04:20: T3 tape, vector time 108:20:00, TPI time 111:08:30 (Dynamics read back :00) [17:20:19] 104:05:40: T6, 110:20:00 vector, 113:07:00 TPI [17:20:20] 104:06:50: T7, 112:20:00 vector, 115:05:30 TPI [17:20:29] so this was his mass generation of T-times haha [17:20:40] the first time is when it was done, from my notes [17:21:21] RETRO gave him a sheet with TPI times, rounded to the next 30 seconds [17:22:44] and a few hours before they made the tapes where the FIDO gave all the inputs [17:23:39] were all of those made based on a coeliptic rendezvous even in J missions? [17:23:53] probably [17:24:01] this could be used in the case of loss-of-comm [17:24:17] and surely they would revert to coelliptic for that [17:24:26] no-comm means no tweak maneuver [17:24:30] but those same T times were also used for direct? [17:24:45] there would be a difference in time [17:25:01] don't they get both coelliptic and direct Ascent PADs for the actual ascent? [17:25:03] So the T time for my liftoff rev is different than LO time? [17:25:23] we can check that [17:25:50] 173:55:19 Irwin: Okay, Charlie, I'll give you the direct pad first and I'm reading: 175:43:35.18 [17:25:58] 173:58:14 Irwin: Okay, on the coelliptic: 175:46:09.37 [17:26:08] ah thats right they get both [17:27:34] hmm [17:27:37] T51, 173:47:29, 176:38:00. [17:27:40] second number is TPI [17:27:44] but that is one rev earlier [17:28:04] this was before EVA 3 on Apollo 16 [17:28:38] not sure they separately got a T52 [17:29:16] with the direct ascent PAD they got this [17:29:17] Tig (time-of-ignition), one rev late, 177:42:06 [17:32:44] Remember the timeline is different than the flight plan [17:35:28] EVA 3 ended at about 171h [17:36:29] "If there is no communication, the CSI/CDH rendezvous will be used. The no-communication contingency lift-off times sent to the crew while on the lunar surface will always assume a CSI/CDH profile" [17:36:39] makes sense [17:36:48] APOLLO MISSION TECHNIQUES [17:36:49] MISSION J·2 AND MISSION J·3 [17:36:50] UPDATE [17:58:49] Well time to jettison some gear and get ready for powerup [18:00:44] indy91 have you seen the textures do this? [18:00:51] https://www.dropbox.com/s/8kemvu5ye9sq1pr/Screenshot%202021-09-11%20120036.jpg?dl=0 [18:01:33] hmm [18:01:39] something like it when I have F9 active [18:01:47] to see the navigation stars [18:03:17] I usually have nav stars enabled the whole time [18:03:31] only happens on the lunar surface to the LM [18:03:55] And I only noticed it on J missions, so maybe something to do with the sun angle being higher? [18:03:59] yeah it might go away if you have that disabled [18:04:04] could be yeah [18:04:40] no change [18:04:54] hmm, then it's the self shadow setting [18:05:17] under advanced video settings [18:05:27] Self Shadows, Terrain mapping. What do you have there? [18:06:02] interesting I switched to the LRV and back and its gone? [18:06:35] projected [18:06:52] maybe try Stencil [18:06:58] but no guarantee that it goes away haha [18:07:15] I switched to the LRV moved it away from the LM and back to the LM and its gone [18:07:51] go figure [18:07:52] so some shadow projection weirdness [18:09:15] when I was looking at the RTCC venting model I remembered a fun Apollo 13 screw-up [18:09:48] the vent model is active from a specific time after liftoff until the end of the vent model, probably a few hours after launch [18:10:03] but if there is a TLI maneuver on the MPT the venting ends a short time after TLI cutoff [18:10:22] not long after TLI they managed to screw up their MPT on Apollo 13 a bit [18:10:33] so they deleted all maneuvers and started over with the latest IU state vector [18:10:46] but by getting rid of the TLI maneuver they now had venting thrust and mass loss [18:11:09] which confused everyone and made the reference trajectory for ground tracking bad, too [18:11:28] Oh interesting [18:11:39] it really didn't help with targeting the lunar impact burns haha [18:12:50] but hey at least the SIVB impact was a successful objective [18:13:11] yeah [18:13:32] there was also an actual vent at 13h GET that they couldn't really explain [18:13:40] still hit the Moon [18:16:50] hmm what am I doing wrong here...trying to use checkout monitor to find insertion time [18:17:39] ERR 2 [18:18:05] "2. The Mission Plan Table is in an update state." [18:18:21] don't think that can really happen unless there is a bug [18:20:01] Oh odd, pressing "MPT" didnt put my ascent on the table the first time [18:20:08] it worked that time [18:20:58] some process didn't finish probably [18:21:25] pressing MPT the first time stopped that process [18:21:36] but all that also sounds buggy [18:25:56] I also had some random nans on the LLT and ASC pages [18:26:10] reinitializing the MPT fixed those [18:26:55] Does the DC vector continuosly update? [18:27:05] Gonna verify the results of my P22 [18:27:32] Because I think I forgot to transfer my state vector to CSM slot before making my marks [18:27:47] no, it only saves the DC vector when you request it [18:28:22] Okay [18:28:37] is the liftoff time update display not implemented yet in the RTCC uplinks? [18:28:51] Pressing TLM gets both slots from the downlink right? [18:28:53] if you can't go to the page it's not implemented [18:29:14] Thymo, it gets everything there is from the current vehicle you are in [18:29:17] ok [18:29:47] so in the CSM that is only CMC CSM and CMC LM [18:30:00] in the LM it is LGC CSM, LGC LM, AGS CSM, AGS LM [18:30:12] and if there is a IU then it also gets that SV [18:30:26] no separate CSM and LM vector in the LVDC of course, it just saves it in both slots [18:32:48] rcflyinghokie, but I think I'll implement that quickly tomorrow, shouldn't be too difficult. All the remaining AGC time updates [18:33:31] Are HA and HP in V2 in feet? [18:33:37] or in nm [18:34:08] https://puu.sh/IaD4E/7e50b11cf6.png [18:34:09] NM [18:34:41] sounds good, my liftoff time is slightly different .24 sec ;) [18:35:04] I'll just go through the C-type MEDs and look what is missing [18:35:06] I got a SV update in the LM slot but forgot to move it to the CSM slot. So my vector is off, I'm just assuming my P22 improved it but more marks are required it looks like. [18:36:04] that is quite off [18:38:06] That SV was from before I did my LOI2 [18:38:26] So I've used it during a maneuver and then one or two revs [18:41:21] Also I'm not sure the coords are 100% correct in the flight plan. The idea was to do a P22 with manual optics and there is a spot in the FP to enter updated coords. So I'm not sure if that should've been incorporated in my SC [18:41:22] SV [18:52:47] oh rcflyinghokie, isnt the shadow issue related to the LRV bounding box size being huge [18:55:52] you know that would explain it [19:00:32] https://www.orbiter-forum.com/threads/d3d9client-development.16787/post-263021 [19:01:46] we could probably manually kill them in the mesh file [20:15:18] indy91: Can you check CSMcomputer.cpp:874 [20:15:50] I just put my trunnion switch to the 25° position and it slewed it to 12.5° [20:16:30] The panel graphic and the case both say 25 but the comment on that line says 12.5. Any idea what the story is on that? [20:18:20] hmm [20:20:33] maybe before the updated reticle the field-of-view didn't allow us to use 25°... [20:20:38] and we forgot to change that [20:20:46] I wish the old forum was more easily accessible [20:22:53] https://cdn.discordapp.com/attachments/780878788216881173/886346042482769970/unknown.png [20:23:11] Second paragraph mentions 12,5 so that's probably where it came from [20:25:04] hmm insertion residuals were very small, yet RTCC computed a tweak burn of -6.1 +0.3 -29.8 ? [20:25:09] Seems a bit high [20:30:03] Thymo, yeah I think that needs to be doubled. Not sure how ggalfi and I overlooked that. [20:31:25] It does say that the motor drive amplifier should be at 12.5 degrees/ [20:31:39] Maybe that needs to multiply it? [20:31:57] rcflyinghokie, maybe one of the inputs was wrong, either for the launch targeting or now for the tweak [20:32:08] maybe a sign on the target offset or something [20:32:13] 30 ft/s is definitely too high [20:34:08] tweak parameters are right from the RTCC manual [20:34:53] both fixed, casper, 175:35:42, 176:20:05, 1.7, 15, 26.6, 130 [20:35:29] and 176:20:05 is the TPI time from the launch targeting [20:35:39] yes [20:36:23] launch was TTH:175:00:00, VTI: 174:30:00, DT: 47, RDO: 32 [20:36:55] aha [20:36:56] DT = 47 [20:37:15] ah wait, tweak is after insertion of course [20:37:19] yes [20:37:33] DT is insertion to TPI [20:37:37] 47m [20:37:43] and then you did the procedure with calculating the ascent and then the launch targeting again? [20:37:48] yep [20:38:33] https://www.dropbox.com/s/a2c315spuzsm00f/Screenshot%202021-09-11%20143807.jpg?dl=0 [20:38:38] https://www.dropbox.com/s/c9mg1y0qdzgyviq/Screenshot%202021-09-11%20143823.jpg?dl=0 [20:39:05] uh oh [20:39:10] powered flight arc of 5° [20:39:20] powered flight time of 840 seconds [20:39:26] that doesn't sound right for the ascent [20:39:37] well thats not a value I can change haha [20:39:49] no, that's the result of the ascent processor calculation [20:39:55] is the CSM ephemeris current? [20:40:00] those were nan values for a few triesd [20:40:02] tries [20:40:29] was updated before doing the calculation [20:40:34] sounds like it used a bad CSM state vector [20:40:52] ok, I'll have to look at the scenario [20:41:14] I can give you before and after insertion/tweak [20:41:22] but that simulated ascent was very bad [20:41:30] you can delete your power insertion scenarios haha [20:41:32] post* [20:41:54] I'm surprised it is only 30 ft/s with these ascent parameters [20:42:18] so yeah, I need before ascent [20:42:52] 840 seconds is probably the total LM ascent stage mass [20:43:12] and it didn't have a check on depleting the propellant [20:43:21] and the CSM state vector targeted really can't be good [20:43:50] sure one sec, how far before liftoff do you want [20:44:04] long enough that you can target a new ascent and then fly it [20:44:12] with different liftoff time [20:44:39] I should add a few more display parameters to this ascent processor page, the RTACF version has wedge angle, so basically cross range. [20:44:48] I'm sure that was very large [20:46:14] Hmm I cannot load any scns... [20:46:19] of course... [20:46:28] must be MPT again with the ascent maneuver [20:47:22] as you will have noticed lunar stay phase and MPT is rather buggy :D [20:47:29] haha indeed [20:47:49] will get better with the new numerical integrator, too [20:48:20] all you can do is clean out the MPT section of the scenario [20:48:56] it either has a problem with the anchor vector being before PDI and then present time is on the lunar surface [20:49:06] This is one I believe you can check it out [20:49:07] https://www.dropbox.com/s/v8c17r426euyn2r/Apollo%2016%20-%20Lunar%20Liftoff.scn?dl=0 [20:49:08] or it just can't properly handle lunar surface anchor vectorsin general [20:50:35] I think the problems always happen when you have the MPT active, maneuvers on the MPT, and you are on the lunar surface. And then saving/reloading [20:51:21] uhh [20:51:36] am I seeing the CSM anchor vector having a lunar surface indicator... [20:52:25] umm how would that happen [20:52:40] it can't [20:55:00] I don't think I even need to try much in your scenario [20:55:13] it just needs to have the MPT completely cleaned out and initalized from scratch [20:55:16] then it should all work [20:55:31] but I'll try anyway [21:00:01] question is how did it get that way in the first place [21:00:16] got it to work, but had to first get new powered flight arc and time [21:00:29] and the currently loaded ones prevent the LLTP from working [21:00:32] as* [21:01:08] it's just bugs that have to do with the lunar surface phase [21:01:40] completely breaks the MPT. And when it loads from scenario it creates new CSM and LM ephemerides [21:01:56] and if that fails really bad the scenario doesn't even finish loading [21:02:25] right now you should just avoid having a ascent maneuver saved in scenarios [21:02:32] while on the surface [21:03:24] but I am super confused how it is possible to get a CSM vector on the surface... [21:05:00] I can only imagine something being uninitialized [21:06:05] oh I have an idea haha [21:06:12] DC button [21:06:16] left side for CSM [21:06:18] right side for LM [21:06:41] you must have used the left button for CSM but then typed Orion [21:07:05] that would get you this [21:07:06] RTCC_MPTCM_ANCHOR 9 APIC007 -1 -1 0.000000000000 0.000000000000 0.000000000000 0.000000000000 0.000000000000 0.000000000000 0.000000000000 1 [21:07:17] empty but with the last entry being the 1 for lunar surface [21:07:56] I think this is the only way this could happen. I need to add some logic to prevent the CSM ephemeris from being able to be initialized with a lunar surface vector like this [21:08:16] hmm [21:08:18] but then [21:08:19] RTCC_BZUSEVEC 5 APIC007 7 1 674028.082511597313 1620400.292694091797 866611.061553955078 -195427.849589787424 732.752940142202 -1430.451865136802 -265.504451450222 0 [21:08:24] this is the actual DC vector [21:08:34] the one above was the anchor vector [21:08:47] and this one looks like a normal state vector, but same ID [21:14:58] indy91: In TelescopeServoDrive you mention a transfer function from the A15 Delco manual. I'm having trouble locating where exactly in that document you got it from. [21:17:10] page HW-55 and 56 [21:17:15] the ideal version [21:23:53] rcflyinghokie, do you have earlier scenarios with the ascent maneuver on MPT? The more broken the better [21:31:16] So the 12.5 degrees would be fed into the motor drive amplifier, but since you used the ideal version I don't think that's simulated. I suppose that would somehow multiply it by 2. [21:31:42] yeah some 2.0x factor [21:32:02] I think we just need to change the number for the offset directly [21:51:36] night! [00:11:04] .tell indy91 I will take a look tomorrow, remind me :) [14:32:39] Morning [14:44:47] good morning [14:52:18] working on a matlab NASSP-tank simulator [14:52:35] so I can understand our current equations of state better [14:52:47] Press = (-(mass - vapor_mass) / density + sqrt((Volume - (mass - vapor_mass) / density)^2 - (4.0 * vapor_mass / MMASS * (mass - vapor_mass) / density / BULK_MOD))) / (2.0 * (mass - vapor_mass) / density / BULK_MOD)); [14:53:07] that's what you get if you expand the pressure equation out... [15:21:52] for any substance, correct? [15:25:34] yes [15:31:26] matlab is being a pain about global arrays... [15:34:54] Hey [15:39:42] morning [15:41:31] I didn't know we had a model for the SIVb wet workshop [15:44:23] https://puu.sh/IaOTw/9b5e7ac72d.jpg [15:46:56] interesting [15:47:22] It's under those broken scenarios, venus flyby [15:48:19] It still sort of works, after a minute or two of button pressing you can get the EPS and ECS going again [15:49:41] CMC is no bueno. The scenario still used the SimpleAGC so it just runs a default rope without any padloads so its pretty useless without DAP, ephemeris, star tables and SPS stuff. [15:50:29] You could do an emergency erasable update if you want to spent time in figuring out what you need :p [15:53:51] haha [15:55:58] Ryan, if you have a moment could you take a look at that checklist change I did? [15:56:25] sure [16:09:03] looks right to me as far as I can tell comparing it to the procedure [16:11:59] Thanks [16:36:54] hey [16:37:19] good morning, that reminded me [16:37:44] haha [16:37:49] I think I found before and after scns of those values changing though I have no idea why [16:38:01] sounds good to me for debugging [16:42:56] going to change the names for ease in determining order [16:43:47] https://www.dropbox.com/sh/gkwy1gbjd76m85o/AACX6-W5gtjfWW6k78ZHyC5aa?dl=0 [16:44:17] See if that works they are in order...I found files that has the normal flight path angle and pulled all the saves after to where it looked screwy and wouldnt load [16:49:08] ok, I'm taking a look [16:50:43] hmm in terms of DC and anchor vectors scenario 3 is good [16:50:49] has APIC005 [16:51:28] although [16:51:44] it's weird that CSM and LM anchor vectors are completely identical [16:52:12] I wonder if it's a really dumb bug and the scenario loads the LM anchor vector into the CSM one or so :D [16:52:23] I was thinking back on that and, while I dont have a way to check, its *possible* I could have typed the wrong vessel name into one of them [16:52:54] But I know for a fact before I computed the ascent I went back and updated them correctly [16:53:39] scenario 3 is called LOPC [16:54:04] yeah, that is CSM in orbit [16:54:07] and LM on the surface [16:54:12] yet the anchor vectors are identical [16:54:43] they are a vector on the surface judging by the velocity [16:54:52] but are marked as not being a landing site vector [16:55:32] hmm [16:55:44] I see a potential for a saving/loading bug [16:57:31] back in a sec [16:58:57] morning! [17:15:18] Hey Mike [17:26:40] updates required a slew of reboots haha [17:27:53] so is there a saving/loading issue? [17:36:14] was away for dinner, looking now [17:36:33] but in basically all scenarios the CSM and LM anchor vectors are identical [17:36:37] that can't be right haha [17:38:20] yeah thats really odd [17:39:25] the DC vectors are not identical [17:41:13] can't generally replicate that, not even with saving/loading. At least not with CSM and LM in orbit [17:41:38] one further thing that could be, I also see a state vector on the surface without the surface indicator [17:41:55] maybe the LM hasn't settled after scenario loading and isn't indicated as landed by Orbiter? [17:42:17] that could be possible, the textures seem to be all over the place after loading [17:42:23] then it settles out [17:42:55] a landed state vector needs to be indicated as such in some way [17:43:13] right now you don't really know if that could have happened unless you look at the scenario [17:46:57] hmm [17:47:10] not even the configuration code makes much sense in this scenario [17:48:34] I feel like there might be one step that isn't done correctly [17:48:44] This is the full process [17:48:50] MPT Initialization page [17:48:57] Table CSM, Vehicle Casper [17:49:05] then I press the Auto button on the right [17:49:12] gets me weights and configuration C [17:49:19] then I press M55 and M50 buttons [17:49:37] then the same with LM and Orion [17:49:53] after that I go to VPS page [17:50:05] DC button on the left with Casper [17:50:09] TUP button on the left with DC [17:50:30] DC button on the right with Orion, TUP button on the right with DC [17:50:38] are you doing all these things? [17:51:09] Wait you have to initialize both tables even when only using one of them? [17:51:30] not if you fly e.g. Apollo 8 or so, no [17:51:50] but you have the CSM in orbit [17:51:52] I mean both were initialized, but I didnt reinitialize both before computing the ascent [17:52:07] launch targeting needs CSM ephemeris [17:52:10] I only updated the DC vectors [17:52:29] and if you want to plan ascent with MPT active then LM MPT needs to be initialized of course [17:52:36] Which I did [17:53:01] And the last CSM table initialization was before LOPC [17:53:08] I'm seeing config code 13 in the CSM MPT [17:53:12] that is CSM + LM [17:53:23] which is wrong of course, although shouldn't really hurt [17:53:43] auto pulled the wrong config then? [17:53:45] so you probably didn't use the M55 button in awhile [17:53:50] hmm [17:53:54] probably not, let me check [17:54:09] It was initialized before circ and before LOPC [17:54:20] actually, wait, no I didnt use MPT for those [17:54:35] So that could very well be initialized when in the stack [17:55:01] right [17:55:24] in reality they had the sep maneuver on the MPT, manually added maneuver [17:55:29] but I didnt know that both tables needed to be reinitialized when just using the LM table [17:55:34] and there you can specify that as being an undocking maneuver [17:55:55] ascent targeting neds to access the CSM ephemeris [17:55:58] needs* [17:56:17] so a previous initialization wont work for it? [17:56:25] it should [17:56:33] but I guess didnt in this case [17:56:38] if you didn't use the TUP button in a while then the state vector could be old [17:56:41] or pre LOPC or so [17:56:48] both vectors were current [17:57:22] except for some reason I only see LM state vectors as the CSM anchor vector, really weird [17:58:13] not one of the scenarios you just gave me has a good CSM anchor vector [17:58:29] it's either a landed LM state vector, but without landing site indicator [17:58:38] or an empty state vector, with landing site indicator [17:58:40] haha, so strange [17:59:24] that is weird indeed [17:59:34] the DC vectors look right [17:59:40] you can see in the VPS when they were last updated though [18:00:08] mostly. Loading a scenario takes the anchor vector to current time [18:00:18] which then is saved as the anchor vector [18:04:16] can I look at even earlier scenarios? [18:04:21] EVA3 0001 [18:04:28] and EVA3 I guess [18:04:29] Absolutely [18:04:46] EVA3 001 got overwritten but I have those and earlier [18:04:50] 0001 [18:05:02] RTCC_MPTCM_ANCHOR 9 APIC005 -1 1 618598.656201688573 1640863.626875036862 -487055.062695532804 -302241.938229863939 3.401666544774 3.043943604894 -0.209870763125 0 [18:05:09] this is really the weirdest case [18:05:16] CM anchor vector [18:05:26] last three double precision numbers are the velocity [18:05:39] which looks like a landed state to me [18:05:47] small velocity because Moon rotating [18:05:53] but then the last digit is 0 [18:05:56] so not landed [18:05:57] haha [18:06:19] I can't even come up with a user error case where this would be possible [18:06:24] has to be some bugs [18:06:36] I copied a whole bunch to that dropbox folder [18:06:41] thanks! [18:06:52] I can go back further if need be [18:06:54] although, I think what might have happened in the later scenarios is you using Orion for the CSM ephemeris [18:07:12] but with all these weird anchor vectors I am not sure of that at all [18:13:35] So I think at this point I should clear the MPT and reburn the LOPC? [18:13:39] do you remember when you used the CSM MPT for the last time [18:13:56] DOI I believe [18:14:06] actually, no [18:14:07] don't think you need to reburn LOPC, you can continue shortly before ascent [18:14:20] The MPT I am not sure [18:14:30] just delete the lines with the anchor vectors [18:14:38] and make any ManeuverNum 0 [18:14:47] then it will load [18:15:10] but would that ascent time be incorrect? That was used for the LOPC [18:15:33] maybe slightly, but the Moon rotates very slowly [18:15:43] so not enough error to cause a problem [18:16:03] if you can land a few revs later than planned with just a small cross range error then the same applies to ascent [18:16:18] and a few revs is a bunch of hours [18:16:27] your ascent time error was maybe a minute or two [18:16:56] yeah, not causing a problem [18:18:26] great [18:18:44] I want more scenarios haha. I need to find the place where RTCC_MPTCM_ANCHOR and RTCC_MPTLM_ANCHOR started being identical, landed, yet somehow not landed state vectors [18:19:11] I will put all of mine in the folder! [18:19:21] awesome [18:20:01] I got lazy with naming [18:20:13] But you should be able to sort by "date modified" [18:20:47] right [18:21:08] 144 saves :) [18:21:14] uploading now to that folder [18:22:25] should be up [18:22:34] ah, I had already downloaded, was wondering why some were missing haha [18:22:54] Apollo 16 - 53h 0001 0007 looks fine [18:23:00] but that's pre LOI I guess [18:23:30] PDI Day, already bad [18:23:43] LOI2 is good [18:24:08] already a landed LM vector [18:24:14] oooh [18:24:16] that's the S-IVB [18:24:19] impacted S-IVB [18:24:52] I guess that's why it has no landing site indicator [18:25:26] the ephemeris stops being generated at the lunar surface [18:25:41] yeah I was trying to see when it would hit [18:25:53] maybe the MPT has some trouble with that [18:27:24] "LOI 2" is good, "LOI2 0001" is bad [18:27:27] I cleared the vectors and maneuvers and now my LLTP wont compute [18:27:37] ah right [18:27:49] you still had the bad powered flight time and arc [18:28:03] just use current time and input it on ascent processor page [18:28:18] and calculate an ascent to update those parameters to something reasonable [18:28:39] ah [18:28:46] I had the same problem with your scenario [18:29:21] much better [18:30:14] perfect, loading the "LOI 2" scenario I can reproduce the issue [18:31:09] that scenario has MCC and LOI on the MPT [18:31:48] anchor time after LOI though [18:31:52] so in theory LOI wouldn't matter [18:32:01] LastExecutedManeuver 2 [18:32:14] and it knows that MCC (maneuver 1) and LOI (maneuver 2) were already done [18:33:49] so should be some interesting bugginess happening [18:35:19] LOI maneuver data on the MPT doesn't look very healthy [18:41:02] nah, the state vector in this scenario has impacted, too [18:46:17] curious which user errors caused some of these [18:50:16] Working the ascent and updates, with the ascent on the MPT, giving the CSM a time tagged LM SV at insertion time should work properly? [18:53:56] insertion plus X minutes, isn't it? [18:54:23] yes +5 [18:54:31] if you use exactly insertion time there is a slight chance that you get a SV just within the ascent maneuver [18:54:52] which should generate an error... but might not yet in our RTCC haha [18:55:52] just tested it, no error that I could see [18:57:01] how do I pull the post insertion LM weight? [18:57:14] checkout monitor with MVE should have it [18:58:24] ah perfect [18:58:30] something is happening between the "LOI" and "LOI 0001" scenarios [18:58:45] I wonder if it's taking a pre LOI scenario to post LOI or so [18:59:44] something made the CSM state vector impact at least [19:00:03] and then it sits there on the lunar surface, but without PDI maneuver it doesn't properly get considered landed [19:00:15] and then for a long time no TUP was done for the CSM [19:00:33] in fact you probably didn't use the MPT for a long time [19:00:51] yeah I didnt need it [19:15:26] so far everything looks good this time around :) [19:15:42] ascent and vectors/weights all look good [19:15:50] tweak preload all set [19:21:00] CSM and LM anchor vectors became the same because regardless where the impact happens it is switched to the landing site coordinates afterwards [19:21:38] but no landing site indicator has saved [19:21:40] was* [19:21:50] because it wasn't a PDI that lead to impact it seems [19:22:27] but I don't know yet why the CSM ephemeris even impacted [19:22:41] it should just have a post LOI state [19:25:10] I wish I had a better idea of what i did between those two [19:33:04] oh [19:33:06] I think I have asked this before but it didnt stick....what is the "zeroes pos/neg cells" uplink again? [19:33:13] no idea lol [19:33:27] maybe one of the new AGC memos has something about that [19:33:33] probably why it didnt stick :P [19:33:45] oh I think I know what went wrong [19:33:59] did you do MCC-2 to LOI all in one go? [19:34:05] without saving/loading? [19:34:46] I dont think so [19:35:04] looking at the save times at least [19:35:34] Did MCC2 on 1 SEP and LOI on 6 SEP [19:36:01] oh, this isn't MCC-2 on the MPT [19:36:14] it's MCC-4 [19:36:35] let me find a quote of myself haha [19:37:04] "the current function can only take 1 maneuver into account" about the general numerical integrator [19:37:17] in the LOI scenario the anchor vector is from before MCC-4 [19:37:39] and the scenario is saved after LOI [19:37:44] so that is two maneuvers in between [19:37:54] and when you load the scenario, problems [19:38:02] ahh [19:38:41] so leaving them on there was the issue? [19:38:52] yeah basically [19:39:11] haha ok, I guess I just inactivated it and forgot about it [19:39:19] and then you didn't touch the CSM MPT until the scenario LOPC [19:39:56] and that's where the CSM ephemeris switches to a proper landed state [19:40:21] I can only explain it by using Orion for the CSM MPT by accident [19:40:34] yeah as I said I might have done that [19:40:41] hmm although [19:40:48] I wonder if deleting the maneuvers on the MPT somehow did it [19:40:59] hmm, that happened earlier [19:41:22] I don't really know, but I already added some code that prevent anything landed going near the CSM MPT [19:42:02] the new numerical integration control module will fix the two maneuver on MPT issue [19:42:29] I probably still need to look at handling state vectors that impact [19:43:02] and you now know that you need a fully initialized CSM MPT for the MPT ascent maneuver stuff [19:43:48] but I think the focus should be using that new RTCC function everywhere [19:43:55] will fix a lot of stuff, and break other stuff :D [19:46:07] haha naturally [19:46:16] and I have learned to modify my procedures as well [19:46:28] Nik, what's the UNIT W padload? Is that W-matric related? [19:46:53] It's not in the padload worksheet but it is in the erasable load [19:47:39] it's in the padload worksheet under a different name [19:47:43] -AYO and AXO [19:48:02] it's basically a small vector correcting for Earth nutation and precession [19:48:22] the z-component of it is always loaded as 1 [19:48:42] and AXO and -AYO is launch day dependent [19:49:22] The erasable load has two extra locations to fill. 1715 and 1716 both as 37777 [19:49:34] yep [19:49:40] that's the z-component [19:50:01] basically 1 in double precision [19:50:03] Right [19:50:44] RTCC MFD has a calculation method for it under utilities [19:50:57] I was gonna ask about that haha [19:51:16] previously I only had some MATLAB scripts for it [19:51:30] I opened one of the broken scenarios that has no E load at all and I'm trying to do the emergency memory update [19:52:24] yeah the loading of 1715 and 1716 is probably the most important part [19:52:33] or else it is a zero vector instead of a unit vector [19:52:51] planetary inertial orientation subroutine wouldn't like that [19:53:16] oh actually, a long while ago the 37777, 37777 was loaded into the computer at startup, in CSMComputer.cpp code [19:53:34] but I moved that to the CMPAD values [19:53:36] Meaning the LVLH REFSMMATs the AGC generates are wrong if that isn't loaded correctly? [19:53:55] but what I didn't do is add 1715, 1716 to the padload worksheets [19:54:02] Also, can I pick my own TEPHEM as long as the CMC and RTCC use the same? [19:54:10] uh, could be [19:54:16] yes [19:54:44] RTCC MFD config page has a button to downlink the TEPHEM [19:54:50] to sync them [19:55:01] will get used as the reference for GET [19:55:12] actually working on that today [19:55:28] adding liftoff time update (V70) and clock time increment (V73) to the RTCC MFD [19:55:43] Cool [19:55:56] will be easier then to do a Apollo 14 or 17 liftoff time update [19:56:14] Btw, if you ever find yourself in need of doing a P27. Don't use the built in feature in the telemetry client, it doesn't work. [19:57:03] What is "Epoch of BRCS"? [19:57:13] Basic Reference Coordinate System [19:57:23] it's a time near January 1st of each year [19:57:32] basically the reference time of the coordinate system [19:58:15] there is also a "TEphem0" [19:58:25] that is the reference time of AGC time keeping [19:58:32] always July 1st, midnight [19:58:45] TEPHEM is the number of centiseconds since that time [19:58:59] It's february 1971, so I guess july 1st 1970 [19:59:14] yeah [19:59:18] Apollo 14? [20:00:49] Not quite. The Broken scenarios\Fictional missions\Manned Venus Flyby\Test flight approaching orbit-raising burn.scn :P [20:00:53] oh haha [20:00:59] hmm [20:01:00] It still used SimpleAGC [20:01:05] which we don't have [20:01:06] So it defaulted to Artemis [20:01:10] oh ok [20:01:20] But with no erasable load [20:01:29] the Epoch times depend on the AGC version [20:02:35] so for that timeframe our modified Artemis might be better [20:03:12] Will the original one absolutely not work? [20:03:44] you mean just Artemis? [20:03:56] I kind of challenged my self to getting the CSM splashed down into the ocean without making any scenario changes. [20:04:08] Yeah without the modifications [20:04:12] ok [20:04:25] then you need a negative TEPHEM [20:04:37] because reference time of Artemis is July 1st 1971, midnight [20:04:56] hmm [20:05:03] how much does that matter though... [20:05:12] Can it handle a negative TEPHEM? The padload worksheet was able to come up with one [20:07:14] not sure [20:07:38] One way to find out [20:07:56] What about RTCC? [20:08:58] I think it should be doable, just need to input a few things manually on the config page [20:09:09] liftoff day, time etc. [20:09:20] what TEPHEM would you like to use? [20:10:08] at some point the clock would also overflow, so you can't just use 0 for it [20:10:18] thewonderidiot, what was it, 31 days or so? [20:11:33] It's currently 8pm feb 13, 1971 so I picket 7pm as my TEPHEM [20:11:35] RTCC has a limit of "745:39:14.55" for GET [20:11:45] 745 hours [20:12:44] Now I need to calculate what the Besselian epoch is [20:13:06] RTCC config files have that [20:13:09] AGCEpoch 40952.009432 [20:13:11] for Apollo 14 [20:14:01] hmm, RTCC might have trouble with uplink addresses [20:14:08] if you don't have a config file for your mission [20:14:36] I was going to use this equation https://en.wikipedia.org/wiki/Epoch_(astronomy)#Besselian_years [20:15:15] I also have a MSC memo about this topic [20:17:26] RTCC defaults to Apollo 11 uplink addresses [20:17:40] I got 1971.119871235. That looks correct but I don't think that is what the RTCC wants [20:18:08] it wants Modified Julian Date (MJD) [20:19:22] not sure your number is correct [20:19:34] is that Julian Epoch? [20:20:05] oh I see [20:20:10] you used the daily epoch [20:20:17] AGC uses a yearly coordinate system [20:20:46] I plugged the MJD into that wikipedia calculation [20:22:12] doesn't the calculation take a JD instead of a MJD? [20:23:18] https://ntrs.nasa.gov/citations/19700026563 [20:24:45] Yes. So I too the current JD, used that calculation to get the Besselian epoch and now I think that needs to be turned back into MJD for the RTCC MFD [20:25:12] the number is a constant for each year [20:25:20] so no need to calculate it from scratch :D [20:25:30] or use the calculations in that NTRS memo [20:27:53] Right so I see it in that document but I stll need it converted to MJD for the RTCC MFD right? [20:28:38] yes [20:29:03] Did someone say hour angle? sounds like ya need https://drive.google.com/file/d/1RTgwvtrgbAqHWXUxhgQVakQECyKqOqh4/view?usp=sharing [20:29:17] hahaha [20:31:53] Thymo, Orbiter has a nice date conversion tool if you haven't seen it [20:32:01] I have it open now [20:32:06] ah good [20:32:17] It doesn't do besselian years though [20:40:54] wouldn't help you calculating a yearly epoch anyway [20:41:19] The one from Apollo 14 you gave me is what I should use anyway [20:42:25] I don't need MJD of mid-mission do I? [20:42:45] TIMEM0 [20:42:46] you need all numbers [20:42:57] that's the time used for the lunar ephemeris [20:43:00] and solar [20:43:12] makes it the most accurate in the middle of the mission [20:43:25] usually that's about 7 days after launch [20:43:42] and it's then valid for 14 days [20:44:04] I'm not going to the moon, nor will I stay in orbit for 7 days. So same as TEPHEM would work? [20:44:16] I guess [20:44:23] you want the solar ephemeris [20:44:33] but I think it's not very sensitive to the number you use [20:44:35] for TIMEM0 [20:45:13] is the scenario near Venus? [20:45:28] It had 6.75. I put in 40995.791670 [20:45:31] It's in LEO [20:45:34] ah ok [20:45:57] Supposedly a test mission like Apollo 9 but wet workshop [20:46:02] I guess mini-skylab? [20:48:30] How do I change the rope RTCC generates the ephemeris for? [20:49:34] hmm, annoyingly I was using the mission parameter for that [20:49:59] config page and make it Apollo 15 [20:50:17] at least so that it does the calculation for Artemis [20:51:28] testing my new RTCC MFD page for clock updates [20:51:51] at the end of the mission the Apollo 11 CMC has a clock error of 0.58 seconds it seems [20:52:17] It still says Apollo 8 in the file after I changed it [20:52:59] oh sorry [20:53:08] there is a separate "AGCEphemMission" variable [20:53:22] which is not the same as the mission number [20:53:39] Which I bet I can't change without changing my scenario [20:53:40] damn [20:53:42] you can't change it [20:53:58] need to add a button on that page for that [20:54:05] so that you can choose the rope [20:54:25] how about [20:54:32] you just load the Apollo 15 launch scenario :D [20:54:38] and then use this tool [20:56:32] wait a minute [20:56:37] you can set that mission variable [20:56:50] MIS button [20:57:25] on the page for the "AGC Ephemeris Generator" [20:57:42] past me wasn't as stupid as I thought [20:58:52] Only that that button only works for the correction vectors :P [21:00:51] hmm [21:00:58] I don't think it matters at all for the ephemerides [21:01:11] where did it say Apollo 8 [21:01:13] "(Mission Specific value. 40214.5=Apollo8)" [21:01:15] here? [21:01:17] Yes [21:01:24] 40214.5 is the value for Apollo 8 [21:01:28] but you input something else [21:01:34] Also does on the Apollo 15 launch scenario [21:01:42] this is just an example number [21:01:46] Right [21:01:58] it doesn't say what you generated is for Apollo 8 [21:02:00] I'm mostly concerned that the addresses don't line up [21:02:39] oh [21:02:46] int mem = 02033; [21:02:54] uses that as the starting address [21:03:01] is that not the same for Artemis... [21:03:14] I hope I accounted for that in our actual padloads :D [21:03:31] no, that is still right [21:03:49] what doesn't line up? [21:05:33] I think it does looking at it. I got mislead by that header [21:09:31] for once something doesn't change to a different address multiple times haha [21:13:46] Yes [21:17:55] indy91, can FP8 take RR marks in NASSP? [21:24:27] Precession data is different though [21:24:42] But I can just plug the values into the worksheet no biggue [21:24:50] s/gue/gie [21:27:01] rcflyinghokie, not via downlink from the PGNS [21:27:11] that is what doesn't work for some reason [21:29:19] Can I use Apollo 15s EMSALT of 290000ft since I'm in earth orbit and not lunar return? [21:29:32] Not sure what it's used for [21:30:53] ah ok [21:30:54] I think that's just used to calculate the noun that has the numbers to initialize the EMS [21:31:04] in P61 or so [21:31:58] we use 284843 ft for Apollo 7 and 9 I think [21:32:12] Colossus mentioned that value in a comment [21:34:38] Found it [21:34:39] https://puu.sh/IaSUU/09b5831e43.png [21:38:12] night!