[16:50:26] NASSP Logging has been started by thewonderidiot [16:50:30] Guenter! [17:54:02] always fun when you try to debug something that doesn't need debugging [17:54:47] This Artemis distant retrograde orbit got me curious, there is a procedure doing LOI with the DPS, but because the DPS doesn't have enough DV you don't target 170 NM apolune, but about 700 [17:55:13] so somewhat similar [17:55:29] But the MPT told me I had 200 ft/s too little for even a 1000 NM apolune [17:55:51] turns out this alternate mission plan assumed a 2500 ft/s SPS burn that was already done because TLI was bad [17:55:58] the reason to do LOI with the DPS in the first place [17:56:04] so CSM weight is way down [17:56:23] and so you do have enough DV. I was already checking if the RTCC values for the DPS were bad :D [17:58:58] hahaha nice [17:59:57] there probably isn't any reason to do a DPS LOI if the SPS has enough DV for LOI-1, 2 and TEI [18:01:31] plenty of failure modes where you would do a DPS TEI though [18:02:59] in what case would you do LOI with DPS though? [18:04:40] TLI goes really bad, SPS does a 2500 ft/s MCC-1 [18:04:43] if TLI was bad, would they have continued a non-landing mission? [18:05:06] yeah depends on the mission, but, for 10-12 at least that's what they would have done [18:06:30] maybe after 13 they rather would have kept the LM as a lifeboat [18:06:43] I am only seeing DPS TEI in e.g. the Apollo 15 alternate plans [18:39:36] besides a bad state vector, is there anything that would cause LLOS to point in the wrong direction during P23s? [18:44:13] alignment maybe? [18:50:16] auto optics finds the stars though. [18:51:09] is it neither pointing at the horizon or the star? [18:54:57] it points the optics at the star, but the spacecraft seems to be 15 deg or so off from the horizon [18:55:42] might just uplink a new state vector and see if it fixes things [18:57:50] i recall having fairly good results last time I did this, apparently not that good [20:09:57] thewonderidiot, question on Aurora 88 [20:10:30] or, I guess a question on system test stuff in general [20:13:39] were test ropes swapped into the spacecraft computers to test as a production/quality test, or were they more design validation? [20:14:16] my understanding is that they lived in the spacecraft throughout production and launch site testing [20:14:21] and flight ropes were only swapped in at the very end [20:14:31] which is part of the reason why they made like 20 sets of each [20:15:16] the Aurora 88 modules I dumped were originally assigned to LM-8 [20:17:30] ahh [21:25:24] oh whoops, my message didn't go through [21:31:48] hmm? [21:35:32] connection issues on my end haha [21:36:09] what message? it may have still not gone through haha [21:36:31] I was just going to say, it might be interesting if we could swap ropes in a running NASSP session [21:37:31] oh boy [21:38:05] that would be fun lol [14:06:35] hey Suzuran [15:48:17] hey [16:19:23] hey Nik [16:24:29] I see a vector compare display [16:26:09] am i using/interpreting that correctly? [16:28:33] you are using reference M for Moon, which might not be the most useful comparison [16:28:47] not at 30h GET anyway [16:29:19] but otherwise, I see a downlinked CMC state vector in the second column with very small differences to the "ground tracking" SV in the first column [16:32:44] oh whoops [16:32:51] should've been earth [16:33:18] I checked both. screenshoted wrong one [16:34:00] this was just before the uplink prior to MCC-2 [16:34:33] so my state vector has had P23 updates to it [16:35:34] right... so, there is still a bit of confusion on my part about which state vector exactly to downlink from the CMC [16:35:47] so I am not 100% sure this actually has P23 changes [16:36:28] ooooh [16:36:41] so this might be the LM one? [16:36:55] *other vessel [16:37:20] it's not that, it's that the AGC keeps more than one state vector around for each vessel [16:37:29] ahh [16:38:26] this might be the last one that was output by the coasting integration or something [16:38:54] have to figure it out some time, I remember there being some difficulty with getting the downlinked one [16:40:25] I could see not wanting the one with P23 data. and if the spacecraft is relying heavily on P23s then there might not be a lot of uplinking/downlinking going on [16:41:23] I did have some pretty good marks though. [16:41:42] great [16:41:54] my LLOS problem proved to be 100% user error [16:42:12] ...of the DAP config variety... [16:42:43] morning! [16:43:32] hey Mike [16:43:58] 5° deadband? [16:44:00] hey [16:46:28] yeah I don't know why I am getting the integration SV from the AGC and not the one specifically for downlink, I need to fix that [16:48:56] oooh now I remember [16:49:22] I believe the addresses of the downlink state vectors changed very often [16:50:01] while the other, more internal one, stayed constant for all CMC and all LGC versions [16:50:27] So was kind of laziness, didn't want to add a lot of extra code or RTCC system parameters for the downlink [16:52:23] Luminary is the offender [16:53:03] hah yeah I remember that [16:53:16] EMEM1220 in Luminary 69 and 99, 1217 in 116, back to 1220 in 131 [16:53:33] back to 1217 in 178 [16:53:44] ideally we would just read the out of the intermediate data array, that the telemetry processor should be handling [16:53:48] yep [16:55:31] I think the state vector is in pretty much the same place in all downlink lists [17:14:34] I had started on a table of IDA adddresses [17:17:44] quite a while ago [18:05:12] thewonderidiot, someone on the mailing list wrote they have a rope module, have you been in contact? Any idea what module it is? [18:05:29] no idea yet. I sent them an email asking about its part number and they haven't replied yet [18:07:23] my money is on another Sundial :D [18:07:47] I would have said it's going to be erasable memory, but it says that so clearly printed onto the module that it is hard to confuse :D [18:12:25] hahaha yeah [18:12:37] I think you meant Sunrise, and if so I agree [18:13:17] I did mean Sundial. I thought they were as common as Sunrise [18:14:00] they kind of have the same purpose? [18:14:20] ahhh yeah okay [18:14:46] there's less individual Block II modules in private hands than Block I modules, which is why I'm leaning towards Sunrise [18:15:00] but you're right that there were just as many [18:15:51] I guess even at the time the Sunrise modules were suddenly not needed anymore [18:16:06] while Sundial could still be useful through 75 [18:21:42] yeah [18:25:45] don't think about Skylark, don't think about Skylark, don't think about Skylark [18:26:12] not that one module would help us too much :D [18:26:40] hah well, Sundance started off as a single module at Eldon's place [18:26:44] and now look where we are :) [16:08:01] hey [16:16:21] hey [16:26:55] seems like we have some slightly broken Apollo 10 mission scenarios [16:27:03] easy fix though [16:41:20] i had some weird issue when I flew 10, I believe due to an accidental p52 option 1 [15:13:37] hey Nik [15:14:36] hey hey [15:22:01] how is Apollo 12 going? [15:24:16] I'm in-between MCC-2 and 3 right now [15:25:19] MCC-3 looks like 1.6 ft/sec. if I don't do it, and just press on to 4, then 4 should be 9ft/sec. [15:25:52] LOI-1 is looking like 2889ft/sec [15:26:32] pretty big MCC-3 [15:26:55] I guess you have Alex' MCC for 12 disabled? [15:30:00] yes [15:30:39] and that MCC-3 is calculated with the updated table? [15:31:11] mode 1? [15:31:22] oh wait [15:31:30] I had mode 5 [15:31:38] a, re-optimized [15:31:41] ah* [15:31:58] that would explain it. It will shift a little of DV from LOI to the MCC [15:32:21] optimal in the sum, but not as desirable to not get as many and large MCCs [17:28:26] I will recompute those and see where I end up [18:03:56] it's not going to be a big difference of course, but 1.6 ft/s for MCC-3 did sound more than normal [18:04:09] that's more what I would expect for MCC-4 [21:06:59] night! [14:37:15] hey [14:45:46] so is there a way to "revert" SFP-2 if I have MCC3 or 4 data in it? [14:48:32] hey Matt [14:48:54] not sure why you would want to do that, but, yes [14:49:31] you can just do calculations using SFP-1 though [14:50:16] the SFPs don't really have MCC-3 or 4 data in it, they contain initial guess and targets for it [14:51:13] hmm direct reverting might not be possible actually [14:52:00] at worst you need to manually edit it either in the scenario or on the SFP display [15:03:38] would I need to do that for an accurate LOI calculation? [15:07:55] option 1 has me at 1.5 (vs 1.6 with 5) for MCC-3 [15:13:02] LOI calculation doesn't use the SFP [15:13:43] oh good [15:13:55] And after your MCC-2 calculation you stored the SFP for that MCC in table 2? [15:14:08] yes [15:14:28] you said you had calculated MCC-3 using option 5 [15:14:37] had you done the transfer there already? [15:14:47] yes [15:15:27] that explains it [15:15:33] ah [15:15:50] what you would have liked to do is to return to your SFP-2 you had after MCC-2 [15:16:01] now I get it [15:16:27] don't think that is really possible [15:16:37] that SFP-2 is gone [15:16:44] SFP-1 doesn't help you with its preflight data [15:17:07] I'd say burn that MCC-3 and skip MCC-4 [15:17:54] okay, I will do that [15:18:08] should be the smallest DV over all [15:18:30] doing a SPS MCC-4 isn't a problem either [15:18:34] there were some [15:19:27] I think mcc4 was a 1 sec SPS burn [15:21:15] what's your pericynthion like? [15:21:42] you can use the space digitals display for that [15:22:55] you only get these larger DVs because of the reoptimization, but maybe you need neither MCC-3 or 4 [15:41:08] 60.01 iirc [15:41:19] not in front of my computer right now [15:42:55] I have a hard time believing that :D [15:43:39] that might be your predicted pericynthion including doing another MCC, but if that is the pericynthion of your current trajectory that would be very impressive [15:44:16] and you likely wouldn't need another MCC then as long as LOI computes correct and happens close to pericynthion [15:44:29] I could be remembering what it was when I had MCC-3 and LOI-1 in the MPT [15:44:46] 78 could be what it is now [15:44:56] that's also a number I remember [15:46:16] yeah, I guess just do your RCS MCC-3 or SPS MCC-4 as you had them calculated [17:26:28] my goal for tomorrow is to actually be home during the day [17:31:40] how early on should I get the LM MPT going? [17:34:28] I mean in reality they got it going about 2 minutes after Earth orbit insertion :D [17:34:38] to use it for planning the 2nd TLI opportunity [17:36:04] for me it has first been useful when planning DOI, so in the rest period before PDI day [15:05:30] hey [15:10:07] hey Matt [15:38:52] working on calculating LOI-2 at the moment [15:41:22] did you end up doing MCC-3 or 4? [15:41:41] MCC-4 [15:48:13] it looks like the LDP wants to put me in a 60x60 orbit; flightplan has 64.9x53 [15:54:52] you know why, you have been working on this for month :D [15:55:37] ooooooooooooooh [15:55:46] you want 60 x 60 [15:55:55] haha [15:56:03] they ended up targeting Apollo 11 (and probably 12) with the SPQ [15:56:16] doing a CDH maneuver with a circular orbit at DOI or PDI time [15:56:25] a bit crazy [15:56:38] to get it to propagate backwards from a circular to this elliptical orbit [15:57:31] from Apollo 13 on they had a "integrated DOI" option [15:57:40] which I have not implemented really [15:57:49] I can do it at some point using parts of the LOI targeting [15:58:29] even now it would make LOI-2 or DOI in place of LOI-2 a bit more accurate [16:00:01] I just know the "integrated DOI" as a running gag from the Apollo 13 FIDO audio [16:00:10] must have been poorly optimized and really slow to run [16:00:29] FIDO always said to Dynamics to get a coffee when he instructed him to run that calculation [16:01:20] I guess doing any iteration on numerically integrated trajectories is quite slow [16:01:34] they go to great lengths to avoid doing that with the TLMCC processor [16:21:43] our RTCC is quite fast. never gives me time to get coffee haha [16:23:48] that wasn't always the case lol [16:24:31] previously the old coasting integrator got some Moon and Sun ephemerides on every integration step [16:24:39] from the Orbiter API [16:25:01] using the same method as Orbiter itself, which is very lengthy calculations [16:25:08] that made it noticably slow [16:27:21] I think even Orbiter has a "fast ephemerides" function [16:27:30] it only uses the full calculation on scenario load [16:27:53] and afterwards a simpler calculation on every sim step, which is still accurate over shorter periods of time [16:28:32] so I was doing something that Orbiter even tries to avoid, on every integration step of a trajectory :D [16:39:47] morning! [16:48:54] hey Mike [16:54:40] how are Sunrise and Aurora treating you [16:54:53] Aurora is still glaring at me from a distance [16:55:02] Sunrise is treating me okay haha [16:56:06] 5099 words to go [16:56:32] I've had to make a few patches to yaYUL because it was assembling things wrong, but in a way that happened to work for Solarium lol [16:57:32] not unlike yaAGC with the CMC only at some point... [16:57:44] heh yeah [16:58:21] luckily I have my python port of Yul to reference now, so I can very easily see what it should be doing :D [17:01:24] still want my help at some point with orbital integration? [17:02:23] yes! I will be getting there shortly [17:02:29] only a few banks away from having to deal with that [17:04:58] fun [17:05:05] probably [17:38:07] bank 10 is 100% correct now! 4866 words remain [18:16:54] very nice [18:23:02] Bank 25: 0000/2000 words used. [18:23:16] well that's going to be a good chunk to fix lol [18:34:34] apply instruction 0 to address 0? :D [18:51:31] this code was hanging out in bank 22 which should be empty [18:57:41] what code? [18:58:46] inflight alignment routines [18:59:00] SMNB, NBSM, and friends [19:59:16] n7275, do you have a setup where you can Orbiter in a VS debugger? [20:08:49] like, Orbiter itself? [20:09:24] yep [20:09:56] I'm just seeing a dumb possible bug that is driving me crazy lol [20:10:03] the time display in the top right [20:10:07] okay, sure [20:10:15] in certain scenarios it lags behind 0.5 seconds it seems [20:10:22] like a rounding thing [20:10:39] but using the code from Orbiter it apparently uses there I can't replicate it [20:12:51] seems to happen with certain MJDs [20:13:32] like if I start the DG Mk4 in Orbit scenario [20:13:40] open scenario editor, put in MJD = 51685.0044827187 [20:13:50] 0.1x [20:14:09] refresh data page of scenario editor and compare the seconds to the time display in the top right [20:14:17] I have done the math, scenario editor does it correctly [20:15:00] if e.g. the seconds are 36.1 then it should show 36, which the scenario editor does, but time display shows 35 [20:15:24] time display switches to show 36 at 36.5 seconds [20:15:59] I had noticed when flying SSV that the GMT display of their Shuttle was wrong in leap years, but after fixing it now we find this dumb thing haha [20:16:17] and it seems to be an Orbiter issue rather than SSV [20:17:12] where is this in the Orbiter code? [20:17:31] well I thought it was the function DateStr in Astro.cpp [20:17:39] used in MenuInfoBar.cpp [20:17:50] But I can't replicate it if I use that function [20:18:21] in MenuInfoBar.cpp it only seems to use the updated date string if it changes to the previous string [20:18:23] it does a strcmp [20:18:35] maybe that has something to do with it, but I am not seeing how [20:19:33] it's such a little thing, you only notice it when you are fixing a GMT clock... [20:19:44] and as I said, only specific MJDs are affected it seems [20:37:50] I will take a look into it. [20:39:19] thanks! It's a tiny thing of course and I am pretty sure it's not something I got wrong with the GMT calculation, so just a tiny Orbiter bug probably that would be nice to fix at some point [20:40:24] haven't tried building Open Orbiter in a while, I wonder what didn't work for me there... [20:42:00] ah, d3dx9.h missing [21:56:46] night! [14:15:57] hey [16:19:53] hey [16:30:07] hey Nik [16:34:48] what's up? [16:34:58] got as nice views of the Moon as Artemis 1? :D [16:42:53] Apollo in Real Time website now has transcripts of all Apollo 13 MOCR channels [16:43:18] annoyingly the only download option is all channels in one file [16:45:49] looks a good enough transcript that I can search things in it, definitely not good enough to have transcribed all the technical lingo properly :D [16:47:52] ah found a way to get single channels from the website [16:48:47] 0285719|Oh, let's see. That DOI in there now is the integrated DOI, right? [16:48:49] 0285723|Oh, yes. [16:48:50] 0285728|In case you're interested, it took a little over five minutes. [16:48:52] just the important stuff :D [16:52:15] oh that's very cool [16:52:25] will have to check it out [16:54:12] you can download the whole thing in one file or individual channels like this [16:54:13] https://apolloinrealtimemedia.nyc3.digitaloceanspaces.com/A13/MOCR_audio/transcripts/CH20_transcript.txt [16:54:16] channel 20 being the FIDO [16:56:06] LM ephemeris = lemma femoris, good to know :D [16:57:06] pericynthion = pair of Cynthia [16:57:48] lol [16:59:54] probably a bit to technical for your average speech to text algorithm [17:00:25] yep [17:00:43] overall good enough to search for things and then in doubt listen to the audio [17:01:50] I hope they do it for 11 soon, there were still a few things I never found, like some TEI calculations [17:03:59] all of the lunar orbit TEI calculations were like "use same inputs as before" [17:04:06] and I never found the initial inputs :D [17:20:55] I had another MPT question for you [17:21:24] is there a separate LEM table view? [17:22:52] no, the MPT display just has the maneuvers in one table [17:23:10] you can see with the maneuver code on which MPT the maneuver is [17:24:33] okay good. DOI is not ending up in the wrong place then [17:25:28] first letter is either nothing, E for executed, or F for frozen [17:25:39] executed is just a maneuver in the past [17:25:46] frozen isn't really supported yet [17:25:54] second letter is the MPT, C or L [17:26:11] then comes the vehicle actually performing the maneuver [17:26:21] which doesn't have to be the same as the CSM vs LM MPT [17:27:12] and then the other stuff [17:38:53] makes sense [17:40:14] so when I refer to that maneuver in a MED that needs a table ID and maneuver number is it something like LEM,8 or LEM,1 [17:41:02] yeah that would be the 8th maneuver in the LM MPT [17:41:05] not 8th maneuver total [17:41:38] that number is part of the maneuver code on the MPT display and other displays [17:42:46] somehow I missed that [17:44:44] I promise you I can in fact read... [17:46:33] Is there even a place where you can read about that? :D [17:48:00] oh I mean it's probably pretty obvious from the maneuver codes [17:50:10] I was like "6th row, 6th maneuver" without looking for a maneuver number in the code [17:50:58] morning! [17:51:10] hey Mike [17:51:24] making some good progress I see [17:53:35] yep! got it down to 2500ish words [17:54:04] now getting to the rough part where I'm going to have to write some log sections from scratch, like SYSTEM TEST and PRELAUNCH ALIGNMENT [18:03:35] awesome, down from 5000 yesterday :D [18:08:55] getting close :) [18:09:10] I had to make some changes to yaYUL to get PINBALL to assemble correctly [18:09:56] which was kind of weird. I had to build up enough confidence that my source code was definitely correct and I hadn't disassembled it wrong haha [18:14:13] the kind of feeling when you find a AGC software bug [18:15:07] can't be a bug because smart people in the past have looked at this... or? :D [18:15:20] hahaha [18:15:42] luckily Ron had comments in the offending opcode to the effect of "I have no idea what this does", so it wasn't too hard to believe that it was misbehaving [18:16:37] yeah, I also insult my own bad code in my own comments, definitely useful [21:34:16] night! [17:49:35] morning! [18:36:25] hey [18:43:41] two days ago 5000, yesterday 2500, so by my linear interpolation Sunrise must be completely done now :D [18:51:03] hahahaha [18:51:12] it's at 1990ish [18:51:29] almost entirely in banks 22 and 23, so prelaunch alignment and orbital integration [19:04:17] the fun parts [19:04:32] although I have a bit of a trauma with Block I prelaunch alignment... [19:11:03] hehehe [19:11:28] I'm fine with it because of https://www.ibiblio.org/apollo/Documents/agcis_22_prelaunch_alignment.pdf :P [20:25:43] hmm, what sort of V numbers have AGCs and ropes [20:26:12] I found a list of reused equipment on ASTP, very detailed [20:26:22] didn't we wonder if they maybe reused Skylark modules? [20:30:18] V56-786508 is a bag for a camera [20:33:27] yeah I think there's a good chance they did reuse Skylark modules [20:33:45] where's that list? [20:35:06] ASTP flight readiness review for the CSM [20:35:09] https://ntrs.nasa.gov/api/citations/19750020036/downloads/19750020036.pdf [20:36:15] ooo [20:36:49] oh there's a column called "HRE", fascinating [20:38:35] no PGNCS stuff listed [20:40:15] but lots of other major stuff [21:56:03] night! [17:32:42] morning! [17:33:28] hey Mike [17:39:01] what's up? [17:40:58] hey [17:42:12] yo [17:42:18] @n7275 : the connector class is not using the winapi [17:56:24] ? [17:56:53] that is interesting [17:57:11] so I can probably remove some windows stuff then [18:01:38] looks like a good ol' synchronous software bus [18:03:35] https://github.com/TheGondos/NASSP/blob/linux/Orbitersdk/samples/ProjectApollo/src_sys/thread.h [18:03:43] posix thread API instead of windows one [18:04:07] that is the most windowish stuff I had to port I think [18:04:45] still don't understand why they don't add semaphores to std c++... [18:32:24] I'm pretty sure we had multithreading back in 2006, so long before C++11 [18:34:19] I've wanted to replace our threads for a while. [18:43:22] gondos, if you want to make pull requests for anything you're need to change for cross-platform support, we're happy to give it a thurough test and merge it [18:49:49] I don't do it because I don't have a windows computer to test with :/ [19:02:33] you can always leave them as draft pull requests until someone can build and test on Windows [19:13:19] yes, that makes sense [19:29:58] hey Nik [19:31:27] hey [19:31:56] hello [19:33:02] interesting numbers [19:33:32] oh the orbital integration stuff we were talking about last night? [19:33:44] yeah [19:34:00] have you found the code that uses it yet? [19:34:07] I haven't found where they actually get used yet. that entire table gets copied vector by vector into erasable memory [19:34:18] but then I haven't found a reference to it [19:36:20] and definitely for orbital integration? [19:40:35] yes definitely [19:40:51] they get copied into erasable at the beginning of orbital integration [19:41:15] and the AGCIS memory maps say that the address range this table fills belongs to orbital integration [19:43:47] I haven't actually started on bank 22 / orbital integration proper yet. I just needed to put in this table because it fills up the beginning of bank 23, where prelaunch alignment and RTB opcodes live, and I'm working on those now [19:44:25] it will probably become clear what it is once you have reached the code that uses it [19:44:26] and I figured I'd ask about it while I was filling it in haha [19:44:34] if there is code that uses it [19:44:46] I did look for a bit last night and didn't spot anything immediately [19:44:57] haha yeah, who knows, could be some experimental unused code [19:45:11] it wouldn't be the first unused thing I've found in Sunrise [19:55:38] would copying it to erasable always mean that it will probably be changed or could there be another reason [19:55:52] like something with bank switching and erasable being easier to access? [20:09:03] too much guessing involved, I'll jump on it when I can see orbital integration code proper :D [20:28:16] hahaha [20:28:18] fair enough [20:28:38] and I honestly am not sure. I would guess that copying to erasable would be so it can be modified [20:28:49] this stuff is mostly done in interpretive which I think can cross banks [21:45:15]