[16:08:47] NASSP Logging has been started by indy91 [16:08:49] hey [16:17:37] hey Niklas [16:23:52] morning! [16:32:37] I'm getting very close to having full BLK2 interpreter support in pyul :D [16:32:50] great! [16:33:00] it already does this first block completely correctly [16:33:29] AlexB_88, the new LM VC textures are by far the largest textures we have, that's probably why they are slow to load. [16:34:02] there are two 16MB ones, the next largest texture is the new LC-39 with 8MB [16:34:12] everything else is a lot smaller, 2MB and lower [16:36:24] I wonder if they can be reduced in size [16:36:47] other than that there is probably not a lot we can do [16:36:54] oh wow [16:37:36] expanding my Apollo 5 work and already have the LM on the pad I guess [16:37:36] theres 2 16 MB files for the LM, I hadn't even noticed [16:37:44] I am sure something can be done yeah [16:37:51] would be nice [17:00:29] MCC-2 was 10 fps [17:08:06] normal number for Apollo 15 [17:10:15] yep [17:10:48] so at least the intermediate solution for the Saturn V isn't broken. I didn't expect it was, but you never know [17:11:05] LOI & DOI will both 1 minute from flightplan [17:11:37] could probably be improved with some more number tweaking, right? [17:11:40] LOI DV 2999 fps, flightplan says 2997 fps [17:11:52] and the full Saturn V update shouldn't take too long anymore now either, as I already made it past TLI [17:12:00] yeah I did some tweaking [17:12:38] REV2 crossing and DOI DVZ 0 is what I tweaked for [17:13:01] right [17:58:33] once I finish 15 I will look into making the textures smaller [17:58:50] then I think I will slowly start work on the CM VC [17:59:17] :D [18:00:06] theres more stuff to animate but I think it shouldnt be too bad since Ive already learned how to do it [18:01:04] and the panels themselves exist already [20:37:24] indy91, will there still be the post-insertion "cheaty" SV update for the LVDC? [20:37:34] after the update I mean [20:37:35] probably not [20:37:55] now that the state vector can be updated with the RTCC MFD [20:38:20] and even without update the accuracy is ok [20:38:36] right [20:40:13] and I could teach the MCC to do such an update if the error is too large [20:42:07] is there a way to check the error? [20:42:12] other then the log [20:42:38] that would probably be the vector compare display which already exists [20:42:47] right [20:42:54] but I think I still have to teach it to process IU state vectors [20:43:12] havent tried that one et [20:43:17] yet* [20:43:48] it can already use state vectors from the MPT, CMC, LGC and "radar", aka Orbiter API [20:44:41] I find it useful to compare a state vector in the AGC with the actual [20:45:14] it works in non-MPT mode as well, but then it's a hassle to get e.g. the actual LM state vector if you are interested in the CMC [20:45:40] oh, and on that particular display I made the font size as it actually was [20:45:58] so you need high resolution monitor, or better open an external MFD [20:47:55] right [20:48:09] I see theres a lot of new rendezvous displays I can use [20:49:10] which ones do you mean? [20:52:54] Rendezvous Eval. display [20:53:28] and relative motion digitals I guess [20:53:34] yeah [20:53:52] there is kind of two rendezvous evaluation tables [20:54:03] one for DKI and SPQ, the other for the lunar launch window [21:16:52] hmm [21:17:12] I have LOI on the MPT and its showing 182.2 x 54.6 NM [21:17:24] should be 170x60 [21:17:41] was anything calculated with CSM only, vs. CSM/LM docked? [21:18:38] sorry, I meant MCC-4 + LOI [21:18:56] should be all CSM/LM docked [21:19:05] if I calculate LOI without MCC4, its fine [21:20:55] sounds like an issue with the MCC-4 calculation then [21:21:27] I used option 1 with my MCC-2 nodal target [21:21:40] either MCC-4 calculation or state vector supplied to LOI calculation [21:21:59] and you already did MCC-2? [21:22:02] yes [21:22:59] well difficult to tell, maybe redo the calculations and make sure it's all CSM/LM docked [21:23:49] I am still at 53 hours GET, and MCC-4 is at 73 hours [21:24:43] oh and also check the online monitor [21:24:46] there could be an error [21:25:08] maybe with the powered flight iteration [21:25:54] and please don't post an entire RTCC log here :D [21:26:11] no error [21:26:14] the last one took a minute to load, as it was limited to one line every 2 seconds [21:27:01] maybe some wrong vector time [21:27:02] ah sorry haha [21:27:04] could be many things [21:27:44] oh lol [21:27:48] dumb me [21:27:55] "maybe some wrong vector time" [21:28:05] bingo [21:28:09] ha [21:28:24] I used a LOI vector time before MCC-4 [21:28:28] well there is so many things to get right, even if most of them aren't difficult, that these errors happen [21:28:34] they happened to the actual flight controllers [21:29:08] yeah [21:29:36] that's probably the most common errors causing these small trajectory issues, CSM/LM docked vs. undocked, and vector time [21:30:00] the real flight controllers had simulation experience for a specific mission and some worksheets [21:30:10] I really would like to see these worksheets they sometimes talk about [21:30:14] they sound super helpful [21:31:07] it's like your RTCC guide, it tells FIDO and friends what to tell the RTCC guys to get the desired results [21:32:39] yeah, its definitely helpful [21:33:10] I wrote it with the goal to help others...but the other reason was to help future me who hasnt done this in a while :DD [21:33:57] alright, works perfectly [21:34:03] MCC-4 3.4 fps [21:34:27] I could skip it, but DOI DVZ goes up to 27 fps [21:34:43] with it its 0.5 fps or so [21:34:51] DOI DVZ is 0.5 fps [21:35:22] that and fixing the rev 2 crossing time made the actual Apollo 15 MCC-4 fairly large [21:35:43] 5.4 ft/s [21:36:02] did you do any adjusting for that? [21:36:55] I had already adjusted it in MCC-2 [21:37:39] right [21:37:47] they probably did some more adjusting [21:38:23] a bored night shift FIDO with lots of time, doing lots of mode 1 calculations and changing the arrival time at the moon [21:38:28] what I did for MCC-4 is use the SF2 nodal target, then check the REV2 crosiing and it was already perfect [21:38:44] SFP2 nodal target with option 1* [21:38:59] real mission must have had some more disturbances of the trajectory [21:39:09] yeah [21:39:24] I think they used option 4 [21:39:28] for MCC-4 [21:39:32] ah right [21:39:54] audio tapes for that mission aren't available yet [21:40:03] but I know they are doing Apollo 16 next [21:40:12] Apollo in Realtime that is [21:40:20] I even have a note in my guide: MCC 3&4 Option 1 (on Apollo 13+, Option 4 may be used to ensure proper post-LOI elipse) [21:40:41] that was the pre COVID plan though [21:41:05] I doubt they even started the process of getting the audio tapes digitalized yet [21:41:51] Apollo 13 was a bit of a transitional mission for the RTCC, so getting a later mission will be great for me [21:42:02] yeah I bet [21:47:18] getting late, good night! [21:52:27] he left just in time to miss the OSIRIS-REx sample collection! [21:52:34] https://www.youtube.com/watch?v=A6K2dqCoin8 [22:03:08] ah damn [22:03:14] looks cool though [22:03:25] I gotta run too, cya! [16:09:10] hey [16:17:06] hey Alex [16:28:41] LOI went well [16:29:06] I'm always impressed how quickly you get to lunar orbit :D [16:30:27] well, I am eager to test the LM out so I skipped some non-essential stuff in TLC :D [16:30:40] LM VC* [16:31:25] actually, that is a bad excuse since I always skip those anyways haha [16:31:50] I usually skip the P23s, but not much else [16:33:08] yeah thats what I skipped [16:33:47] I dont do all the P52s [16:34:02] since ours doesnt drift [16:34:21] and there are some attitude maneuvers for science in the later missions [16:35:05] I did the SIM door jet procedure of course [16:35:31] it even has the attitude for it in the flight plan [16:35:37] yeah [16:35:38] based on the PTC REFSMMAT [16:35:51] we probably should take the mass of the panel into account [16:35:51] which I think is pretty accurate in NASSP [16:37:49] SIM door weighs 160.0 pounds [16:38:03] less than I thought [17:03:43] any more progress with the LVDC? [17:06:48] yeah I actually started implementing a feature of the later programs, called the Events Processor. In general I try to stick to the program flow of the earlier programs, or rather Apollo 11 I guess, but I think this is a useful feature [17:07:08] morning! [17:07:43] any routine in the LVDC software that is scheduled to be run with fairly precise timing is called from the Events Processor [17:07:45] hey Mike [17:08:01] the same kind of code in e.g. the AS-206RAM listing is probably all over the place [17:08:25] and it's pretty well documented in a document we found on NTRS [17:10:20] I guess it's somewhat similar to the switch selector processing, but that is sending signals out of the LVDC to the Saturn stages [17:10:32] right [17:11:05] the document even shows the table with the times when things are schedule [17:11:09] for timebase 1 to 3 at least [17:11:33] so it has TB0+16.0, that is probably the time when it starts for liftoff [17:12:28] starts checking* [17:13:51] I was just tired of needing some flag that checks if some timed code was already run [17:14:44] e.g. there is an event at TB3+299.0 seconds, which we of course also have [17:14:49] that is the S-II inner engine cutoff [17:15:12] but that signal only needs to be sent once [17:16:22] and as there are a lot of these, it's just very convenient to implement this feature [17:16:37] the document says there were 131 events in total [17:17:48] makes sense [17:29:18] yeah that sounds like a better way to do it than distributing that logic all over the place :) [17:32:03] and not needing flags for it to make sure it gets only called once. What pushed me over the edge was the attitude rate limits in timebase 7 [17:32:17] normally those are 0.4°/s for pitch, yaw and 0.6°/s in roll [17:32:21] during any coasting period [17:32:36] but the maneuver to the separation attitude after TLI is done at 1°/s [17:32:49] and once that maneuver is done, it is back to 0.4 and 0.6 [17:33:00] so those parameters need to be reset twice [17:33:57] I can see how that would be tricky [17:34:26] I did: if (LVDC_TB_ETime > TI7F11 && LVDC_TB_ETime < TI7F11 + 0.02) [17:34:40] so that call is only true in a 0.02 seconds window [17:34:52] the LVDC timestep is called every 0.01 seconds [17:35:00] so no problem, aside from it being bad code [17:36:42] heh [17:37:45] so I finished interpretive support in pyul last night [17:37:53] I'm sure there are bugs but it seems to be pretty much working :) [17:38:01] I did hit a really interesting crash though [17:38:10] remember that giant interpretive data table I was afraid of? [17:38:20] turns out the table itself is fine [17:38:32] but when I hit an "SL1" instruction pyul crashed [17:38:48] because pass 1 assigns that index 0o142, even though the table is only 0o140 items long [17:39:14] YUL bug? [17:39:16] those shift instructions apparently cause pass 2 to index past the end of the data table and use a random TS instruction as their data... for a little bit until they discard it [17:39:32] I would say not a bug, because it does end up working out fine [17:39:48] probably more just a measure to save a bit of memory lol [17:39:48] for the real YUL at least :D [17:39:54] heh yeah [17:40:04] for the python port I had to add a special case for indexing past the end of the array lol [17:40:32] although maybe it would be better to just add that TS instruction to the table... [17:40:56] right now I'm just giving it 0 so the program flow will be very slightly different, probably [17:41:15] yeah, porting is fun. This "flight program language requirements" document with the LVDC ports is full of notes of things that don't work in the one or other language [17:42:08] SPL works fine for the most part [17:42:25] "Since CLASP and HAL do not permit multiple entry [17:42:25] points for a module, the MEP05 module must call the [17:42:26] MEP10 module for these languages rather than trans [17:42:26] fer control to it as shown in the flowchart" [17:51:19] hahaha yeah I've run into all sorts of things like that :D [17:52:28] I guess one difficulty with adding the TS to the table is that we only have the source for YUL, and no working H-1800 assembler, so it will be difficult to know what it even assembles to [17:53:11] 2755 INT OP COD TS B46B48M Z,R2 INT OP SET C GO SET VARIOUS ESSENTIAL REGISTERS [17:53:27] since I don't know the address of either B46B48M or INT OP SET [17:58:26] as long as it doesn't crash pyul, most solutions should be fine [17:59:05] yeah, wrapping the table lookup in try/except and return 0 if it indexes past made the SL1 assemble correctly [17:59:16] so I'll just keep that for now [17:59:59] the SL1 was in this function: https://github.com/virtualagc/virtualagc/blob/master/Aurora12/RADAR_LEAD-IN_ROUTINES.agc#L619 [18:00:22] which is a pretty good test case for the interpreter, so I'm pretty happy that it is all working :D [18:01:12] yeah, lots of interpreter math [18:01:43] with lots of pushing up :D [18:01:50] and a STADR as well [18:11:21] indy91, this is the 1st time Ive used the new REFSMMAT features in the RTCC MFD and it looks very good. The only question I have is regarding the P30 desired orientation [18:12:10] sure [18:12:46] in the REFSMMAT page, option P30 (Heads Up/Down) it requires a TIG and DV target [18:13:08] this is a bit cumbersome to get unless you are in non-MPT mode [18:14:05] the reason I wanted to use it in MPT mode is for example calculating the TEI-4 pad which is before LOI' [18:14:42] so, in reality there is (of course) a MED for that [18:14:55] G11 [18:15:08] the TEI-4 pad uses the LOI P30 desired orientation, but this pad is pre-MCC-4 so I am still on the PTC REFSMMAT [18:15:14] ah ok [18:15:21] it mainly saves REFSMMATs from the GOST, but can also calculate a DMT REFSMMAT from the MPT [18:16:09] looks like that is properly implemented [18:16:22] interesting [18:16:27] you can check in the usual document how that gets used [18:16:31] I think it is [18:16:57] hmm [18:17:54] so I guess that makes the P30 REFMMAT calculation page obsolete? [18:18:03] for the MPT mode yes [18:18:16] G11,CSM,DMT,1,DMT,1; [18:18:27] the first DMT is for the source of the REFSMMAT to be saved [18:18:43] the second one can also be CUR, so you can directly store it in the CUR REFSMMAT slot [18:18:55] uhh [18:19:00] G11,CSM,DMT,1,DMT,U; [18:19:07] U and D for heads up and down [18:19:11] 1 is the first maneuver on the MPT [18:19:33] is there a dedicated G11 button? [18:20:09] no, but the GOST would be a logical place for it [18:20:11] and also the DMT [18:20:42] I guess I can access it form anywhere [18:20:47] from* [18:20:50] yep [18:21:43] so that basically saves a REFSMMAT at the selected maneuver? [18:22:17] yeah [18:22:33] it's the same REFSMMAT as you can tell the DMT to calculate for some display values [18:23:27] U20 for the DMT has both "DES" and "DMT" REFSMMAT options [18:23:39] DMT uses the DMT REFSMMAT from the REFSMMAT table [18:23:48] so one that you can calculate with G11 [18:24:05] DES does the same calculation but only for the DMT display [18:24:33] so you can basically check with DES if that gets you a REFSMMAT you like [18:24:42] and then you can save it with G11 [18:25:05] but it's not required to generate the DMT display before using G11 [18:26:29] right [18:27:46] so is there other REFSMMATs that have a new way of being calculated in MPT mode (ie. LVLH, landing site)? [18:28:21] yes, LVLH is G03 [18:28:41] ok [18:28:55] G03,CSM,123:45:67; [18:29:10] just interpolates the ephemeris [18:29:17] pretty straight forward [18:29:33] the real G03 had Earth/Moon inputs as well [18:29:34] Ill add those to my guide [18:30:11] but that doesn't work yet in the RTCC MFD [18:30:34] We have a LVLH and Lunar entry page in the REFSMMAT section, but I guess in reality those were both done with G03 [18:30:39] so, for whatever reason, you would be able to generate a Earth relative LVLH REFSMMAT in lunar orbit [18:31:04] as I understand Lunar Entry REFSMMAT is just an LVLH with 0.05 G time [18:31:08] yeah [18:31:26] actually, I never made it past TEI in any of the Apollo flight controller audios [18:31:35] so, I don't 100% know [18:31:50] but it's probably done with G03 [18:31:58] what about landing site REFSMMAT? [18:33:39] that's a LLD REFSMMAT [18:33:50] d for desired [18:34:04] there is LLA, but I think that get's calculated by the LOST from P57 telemetry or so [18:34:07] A for actual [18:34:22] so we mainly need LLD [18:35:01] I'm not quite sure right now how that got generated [18:36:07] it's not implemented in the proper way yet in the RTCC MFD [18:36:38] right [18:36:53] it works well with the RESFMMAT page anyways [18:37:22] it was only the P30 REFSMMAT I was having trouble, glad to see that is updated [18:37:24] yeah, still the old way [18:37:29] testing the G11 now [18:37:45] even though the old way can already use the MPT, but just for trajectory [18:38:15] ok the LOST is just for on orbit stuff [18:38:24] so P51 and P52 in the LM [18:38:43] there is a Lunar Surface Alignment Display [18:38:53] and that can calculate LLD REFSMMATs [18:39:47] a bit unrelated, but one suggestion I have for the LOI processor is saving the init values [18:40:00] specifically R1 and ETA [18:40:16] sure, that makes sense [18:40:20] since those sometimes get updated from the TLMCC [18:40:44] I mean I manually transfer the values [18:40:53] but they are not saved for later sessions [18:41:51] right [18:42:59] it's probably G50 on the lunar surface alignment display [18:43:12] and then it's like a DMT REFSMMAT [18:43:21] you need to save it with G21, which is the same as G11 but for the LM [18:44:06] makes sense [18:44:06] but that all doesn't work yet [18:44:11] right [18:44:20] and I don't think the CSM REFSMMAT table even has a LLD slot [18:44:53] need to check what they used instead [18:45:05] but you would have to copy it from the LM to the CSM in an additional step [18:45:13] so a bunch of steps to generate that [18:47:07] I haven't listened to the FIDOs in a while, I'll check on the LOI-2 calculations [18:47:14] ah wait [18:47:20] that will just be the CUR REFSMMAT [18:47:28] they will have generated a LLD one much earlier [18:47:30] pre MCC-4 [18:48:06] and I only listened to the FIDO, not the GUIDO [18:48:09] so much audio... [18:50:58] hmm I did G11,CSM,DMT,2,CUR,D; [18:51:18] but the online monitor said it was ok, but the REFSMMAT saved to DMT001 [18:51:27] and not CUR [19:07:23] also, it says NEW IMU MATRIX DMT 001 but it looks to be saving the PTC REFSMMAT [19:09:52] no matter what maneuver I select on the MPT (I have MCC-4 and LOI) it saving the same REFSMMAT [19:14:36] hmm, I don't understand what I did there [19:15:02] with the current code the first REFSMMAT has to be DES, and not DMT [19:15:13] and it does indeed always save as DMT [19:18:33] no wait [19:18:54] first one being DMT is correct [19:20:37] ah [19:20:39] ok, I think I explained it wrong [19:20:44] and implemented it correctly :D [19:20:49] haha [19:20:59] I just got it to work I think [19:21:10] I have a MED list in the RTCC MFD manual, just hadn't added these [19:21:22] I used G11,CSM,DMT,2,DES,D; [19:21:24] this information goes to the notes [19:21:32] yep [19:21:44] so always DES? [19:22:06] I guess I can manually transfer DES to CUR [19:22:15] DMT to CUR you mean [19:22:29] right [19:22:44] let me do a bit more reading before I give a final answer how G11 works :D [19:22:59] sounds good, Ill read too [19:23:14] do you mind giving me the page number in that doc? [19:23:38] 407 [19:23:53] thanks [19:24:08] but searching for G11 in the document gives some interesting explanations [19:25:22] I think in general with G11 the REFSMMATs are saved in a specific slot automatically [19:25:37] specifying DMT uses special logic [19:26:33] if you put DMT after CSM it will always save in the DMT slot [19:28:21] I think this is relevant [19:28:23] "Upon direction by GDO (RTCC Dyn.) save (G11)/(G21) any other [19:28:24] valid CSM/LM REFSMMAT or a desired REFSMMAT computed for a [19:28:24] particular maneuver as the CSM/LM DMT REFSMMAT. " [19:28:53] but two things confuse me [19:29:09] you can use DMT twice. So store DMT REFSMMAT as DMT REFSMMAT??? [19:30:00] also, you always need to specify maneuver number and heads up/down [19:30:05] even if you don't use DES [19:37:22] right [19:37:52] I guess the other thing that is confusing is that there is also M58 to specify heads up/down [19:38:20] and in U20 you specify it [19:38:42] that one I know how it works [19:39:12] that sets a heads up/down flag in that maneuver block of the MPT [19:39:43] so when it simulates the maneuver during a trajectory update, it calculates the burn attitude from the DV and heads up/down flag [19:39:44] does G11 look at that? [19:40:41] no [19:40:55] just the trajectory update calculations [19:41:11] it calculates a body attitude matrix with that [19:41:21] I know doing the M58 seems to affect the attitude displayed on the MPT [19:41:24] which gets used in DMT calculations [19:41:29] right [19:41:41] that is the actual attitude of the maneuver [19:41:45] vs. any REFSMMAT in use [19:41:52] ok [19:42:07] U20 also has a heads up/down entry [19:42:20] just for REFSMMAT like G11 [19:42:30] or is it [19:43:25] yes [19:44:57] maybe the maneuver number and heads up/down input from G11 get saved somewhere else, not just as REFSMMAT calculation input [19:48:42] remember the ZZZZZZ on the GOST? [19:49:08] the other RTCC document says that gets display when "Requesting boresight and/or [19:49:09] scanning telescope informa- [19:49:09] tion with DMT or DOD data" [19:49:29] and that would be a maneuver code [19:49:48] but right now there would be no way of knowing which maneuver goes together with the DMT REFSMMAT [19:49:53] so maybe that gets saved somewhere [19:50:46] a different theory, but I don't think it is true, would be that it saves one DMT REFSMMAT for each maneuver [19:51:09] but the DMT REFSMMAT is used in a bunch of places where you can't specify a maneuver number [19:51:11] so, if I wanted to have 0,0,0 for LOI and be heads down I do M58,CSM,1,D; then G11,CSM,DMT,1,DES,D; then on the DMT U20,CSM,1; [19:51:12] so that doesn't really work [19:51:48] that would use the CUR REFSMMAT on the DMT [19:51:53] but other than that, yes [19:51:58] right [19:52:10] so U20,CSM,1,54,DMT,D; [19:52:23] or I can use G00 to transfer it into CUR [19:52:26] no [19:52:39] the D in U20 only goes together with DES [19:52:53] if you let the DMT calculate a REFSMMAT without having saved it first [19:53:02] and the 54 is the default [19:53:10] so better would be [19:53:14] U20,CSM,1,,DMT; [19:53:23]