[18:55:03] NASSP Logging has been started by n7275 [18:55:05] the city I live in changed the street name and number for where I live. I just don't get packages any more. [18:59:26] n7275, why would they do that??? [18:59:53] I've never heard about that happening here. Not since they had to rename streets named after Nazis [19:14:16] "to reduce confusion" [19:14:32] according to the post office [19:14:51] I would say they have largely failed in their goal [19:20:19] I live in an apartment in what was a textile mill in the 1820s through 1950s, so the "streets" around the mill mean that the same building had to have multiple street addresses. [19:21:59] hmm, maybe in about 20 years the confusion has been reduced [19:22:31] until then, tough luck :D [19:23:02] Where I used to live the same exact address had two entrances [19:23:24] so packages were often delivered to the other one and I had to go on a hunt where or who had it [19:24:08] also fun, I've had it multiple times that some Chinese food was delivered to our house entrance and it was kind of difficult to communicate that they should try at the other entrace [19:25:44] I have that exact problem too haha [19:26:27] in one case they insisted to go up one more floor to check if the right person was living there [19:26:35] just an attic up there [22:22:59] night! [15:56:10] good afternoon [15:57:05] hey Matt [16:11:57] morning! [16:19:40] hey [17:35:40] the pericynthion issue from two days ago is easy [17:35:45] the flowchart was wrong [17:35:53] the text says it doesn't enforce that limit at first [17:39:18] the lesson is, unless you have a printout of the actual code, there will always be errors... [17:48:23] hah, yeah [20:40:31] ah moon-centered RTE logic mostly working again after lots of changes [20:40:38] didn't think I would get there haha [20:40:51] don't have to delete everything [21:55:30] that's always good [22:31:00] not really giving the DV improvements I hoped for [22:31:28] but I know there were some cases where the DV optimization of a moon-centered RTE burn was suboptimal, should definitely be better now [22:31:35] just have to find those cases again [23:07:02] night! [17:05:30] hey [17:07:52] n7275, "Will almost always be CM, unless Apollo 5 gets MCC support, then you'll need logic for that" [17:08:01] it has had MCC support for a long time :D [17:10:28] but I guess it has never updated the rev counter or so [17:10:38] because of [17:10:46] if (cm == NULL) { return; } [17:12:21] hmm [17:12:33] how did Apollo 5 MCC support ever work with that return though :D [17:13:06] that comment did it's job in making sure the right questions got asked :) [17:15:05] ah it only does this logic once per second [17:15:18] so it only returns one timestep per second [17:15:27] otherwise it goes through the normal MCC logic [17:15:46] that probably would mean though the Apollo 5 MCC doesn't work if you have time acceleration with timesteps taking more than a second [17:17:05] there is no protection against cm == NULL anymore with your update I think [17:17:39] yeah any scenario that doesn't have a cm would crash [17:21:22] yeah, I'm going to add some better checks for that [17:21:57] in the RTCC you could actually set a vehicle as the primary one for the mission [17:22:10] although I am not quite sure what that did :D [17:22:18] but maybe that would work for the rev counter [17:22:27] choosing a primary vehicle (CSM or LM or S-IVB) somehow [17:22:41] oh interesting [17:23:05] hmm, it calls it "primary ephemeris" actually [17:23:12] on the mission initialization MED [17:23:22] so probably just does some display or processing only with one ephemeris [17:25:19] saves that in system parameter MCGPRM. Where does it use that... [17:26:23] it also calls it "first launch vehicle" [17:26:47] The first mission the RTCC software was really developed for was a dual launch CSM and LM mission, like AS-258 [17:27:04] so maybe it would just treat the liftoff time of the chosen vehicle as the main liftoff time [17:27:24] so maybe not something that should be directly used in the MCC [17:28:02] I mean, this whole rev counter thing, the MPT creates one, too, for both vehicles. Eventually the MCC and RTCC classes should use the same one for its processing, but that is still some time away. [17:29:15] anything that I can do by just looking at an RTCC routine I would like to [17:30:02] now that updateRevCounter is a function we can just delete it's contents down the road and add: [17:30:22] RTCC->function() [17:30:36] yeah, I don't think there is an easy way to do that right now. Given that there never was rev counter support for the LM before anyway, just make sure it doesn't crash on Apollo 5. Don't have to support it with your PR. [17:31:25] one day the MCC will automatically manage the MPTs [17:31:35] and then it doesn't have to do its own processing for this [17:32:00] sounds good [17:32:01] also with the AOS/LOS stuff [17:32:19] for the actual comm systems that can be moved to a MSFN class [17:32:47] something I haven't implemented yet is RTCC processing for AOS/LOS messages to the ground stations [17:32:59] or at least they get send a message on AOS... [17:33:39] that was a topic on Apollo 13 before the accident. They wanted to do DOI calculations early, but for that you need the LM MPT [17:34:11] but they didn't want to "activate" that MPT yet, or otherwise all the ground stations would get wrong acquisition messages haha [17:34:32] so that involved a bit of RTCC trickery [17:36:58] "acquisition data which will acquire [17:37:02] within the next thirty minutes will be transmitted to all remote stations and will [17:37:04] be regenerated every thirty, minutes." [17:37:24] not really useful for the AOS/LOS annotation in the MCC [17:56:20] is that the SCM info? [17:56:33] or part of it [17:56:54] SCM? [17:58:14] Station Configuration Message [18:00:02] I'm not sure, that's not the terminology used in the IBM document [18:05:40] I'm trying to find the document that I found that term in [18:05:50] it's one of the NASCOM ones [19:07:47] hmm, got myself into a nice goto loop :D [19:29:00] uh oh [13:57:23] .tell indy91, I seem to have caused an interesting bug... [14:37:54] hello [14:40:16] hey hey [14:40:32] uh oh [14:43:25] so if you have Vesim enabled, you get full deflection TTCA signal [14:43:49] and it seems to be related to some sort of DX8 null pointer [14:44:14] because I get an access violation when the LM destructor is called [14:44:25] I can't see how I'm causing this though [14:44:40] are you sure you are causing it? [14:44:58] there was a recent PR by Gondos that got merged related to the destructors, I think [14:45:10] hmm [14:45:29] maybe that's it [14:46:24] no, I'm not sure it's me. I guess I just assumed because I'm messing with pointers and casting [14:47:20] might already happen in the current Orbiter2016 branch [14:49:18] don't have a joystick handy right now, but I can try [14:55:33] hmm [14:55:37] anything I can do to replicate it [14:55:46] oooh [14:55:47] haha [14:55:49] TTCA [14:55:52] not THC [14:59:21] hmm I'm not sure about the TTCA, but I definitely get rapid fire RCS when I load a scenario with the LM [15:01:45] but I haven't any control device connected, so I am not sure if it's related to that [15:29:22] it happens to me with or without [15:29:34] in Orbiter2016 too [15:29:42] so it isn't me.... [15:48:48] with or without joystick you mean? [15:56:43] yea [16:00:26] + [16:00:41] whoops [16:35:11] do you think this is related to the initmodule/exitmodule pull request? [16:35:23] on the face it doesn't seem obvious how [16:53:21] my joystick is weird so I'm always suspicious [17:58:45] n7275, ah only because you were mentioning the LM destructor [17:58:56] thought it might be related because of that, but maybe not [18:00:30] has anyone noted this on forums/discord? [18:00:40] I haven't seen anything [18:00:58] me neither [18:01:08] but then VESIM is kind of experimental [18:01:15] not that many will use it [18:01:28] I wonder how long it has actually been this way [18:01:45] I think this is recent [18:02:02] within a week or so [18:02:48] uhh [18:03:09] oh [18:03:26] order of merged PR is when they were created [18:03:39] so I was confused, because there weren't many merged in the last week :D [18:03:58] many were just checklists [18:04:03] that Init/ExitModule one was 10 days ago [18:04:44] i think we're going to check out some earlier commits to find where it started [18:07:00] https://github.com/orbiternassp/NASSP/blob/776eca8107ce7dfdde88c2fd63ccaddada98280a/Orbitersdk/samples/ProjectApollo/src_lm/LEM.cpp#L507 [18:07:11] is where the crash comes from [18:08:09] dx8ppv is already null when release() is called. it's probably always null [18:08:33] ...which would explain the random rcs activity [18:08:46] I think [18:18:18] how does the LM destructor cause this though [18:19:21] because it only gets called when you close the session I would think [18:24:16] well that's where I get the crash [18:24:57] when [18:25:11] exiting the simulation [18:25:12] when loading the sim, in between or when closing it? [18:25:13] ah [18:25:30] could be related of course [18:25:40] but that won't be the code causing the RCS activity of course [18:27:23] I'm thinking some joystick code is looking at the wrong place in memory and doesn't know it should be causing a segfault [18:43:34] hmm [16:31:35] good evening [16:45:00] hey [16:48:35] bugs, bugs, bugs, for everyone [16:57:14] only typos for thewonderidiot, "ime base 8 enable" [17:02:46] haha [17:07:15] I've had no luck with the LM/DX8 crash thing yet. definitely doesn't happen with the Saturn class but all the code looks the same [17:07:50] I'll probably just message gondos and see if they can find the cause of it. [17:24:38] I would focus the debuggin on the VESIM code [17:24:54] that's the bigger issue, RCS firing [17:25:36] yeah. rendering the LM useless is a serious bug [17:26:35] with VESIM enabled at least [17:27:17] effectively breaking VESIM [18:24:04] oh fun. I get an assert fail when trying to run in debug mode [18:32:26] unrelated to vesim. its coming from the checklist controler... [18:35:09] ahh, it was just that particular scenerio [18:35:27] I do have key callbacks showing up in the VESIM log [18:37:04] so these thrusters are firing because vesim thinks keys are physicially being pressed? or at lease the function that would imply that is getting called [18:57:46] hmm LEM::clbkConsumeBufferedKey isnt getting called though [19:21:09] VESIM is directly hooked into the JoystickTimestep [19:21:53] so the joystick code of VESIM is what has to think it's deflecting a joystick [19:24:59] vesim.getInputValue [19:25:08] that's what I would expect to return bad things [19:47:28] looking at that next [19:50:54] definitely something weird going on there. I can't get the values to change at all. keyboard input or joystick, both have no effect on them. [19:56:42] vesim.getInputValue is just returning 0 [19:57:03] it still works fine in the CSM though, which is interesting [21:01:15] I'll try looking into it, too. Top priority for me has this map update issue, can't have the MCC failing calculations. [21:01:18] good night! [14:54:53] good morning [14:56:39] hey Matt [15:48:41] I have had any major breakthroughs on the Vesim bug yet. [15:49:49] hmm, annoying [15:50:40] I also didn't find a great solution for the map update issue. There are some constraints on the calculation, directly from text books, that doesn't make sense [15:51:18] I think I'll just remove those constraints, add an iteration limit (which should have been done a long time ago) and call it solved :D [15:51:47] the two real RTCC calculations for this are a bit problematic [15:52:05] one calculation only works in near circular orbits [15:52:24] I think for any rendezvous calculation that uses lighting conditions [15:52:50] and the other one is one I don't have the flowcharts for and works, like many things in the RTCC, by interpolation of an ephemeris [15:55:35] that second method is what they would have used in reality I guess [15:55:41] call the sunrise/sunset display [15:55:56] and the predicted site acquisition display [15:56:17] but doesn't really work well without the MPT [15:58:49] and I don't know this exactly because the FIDO wasn't responsible for map update, but someone called Flight Plan Support, who doesn't have a separately recorded MOCR audio loop and who I just hear faintly in the background talking to the RTCC occasionally :D [16:00:28] ahh, that's annoying [16:20:23] there's always lots of voices in the background, I was never paying much attention to it until I noticed Flight Plan Support was talking to Dynamics a lot, who is sitting in the RTCC to take calculation requests [16:20:36] then I was thinking "wait a moment, maybe he does important things after all" [16:31:46] morning! [16:32:12] hey Mike [16:32:47] got some nice quality scans that I never get to see? :D [16:33:11] but also maybe added motivation for your LVDC emulator [16:33:17] hahaha yes [16:33:22] and I have some questions for you [16:33:26] haha, I bet [16:33:37] not sure I'll be able to answer [16:33:40] 1) what is the newest LVOT we have? [16:33:45] uhh [16:33:53] ASTP [16:33:59] but for Saturn V, Apollo 14 [16:34:14] should be quite similar in terms of "padload" [16:34:27] okay, next question -- do you think there's any chance we might be able to pull 17 presettings out of this? or is there no chance those were determined at assembly time [16:34:36] ooooh [16:34:41] huh [16:34:48] probably not but... maybe? [16:35:45] like with the LVDC there is also going to be some mission specific ones, some launch vehicle specific ones etc. [16:36:08] right [16:36:11] I think the flight evaluation report has some presettings, for comparison with planned because of the delayed launch [16:36:24] let me check [16:36:33] oh right, delayed launch. they probably didn't know about that when they assembled the flight program :D [16:37:18] ah no that was 14 [16:37:30] presettings have everything for the full daily launch window [16:37:43] there wasn't any presettings change required for the late launch [16:39:21] I'm checking if there is any number I could tell you that says "yep, this is for that launch day" [16:39:32] ooh actually [16:39:35] maybe liftoff time [16:40:24] which I think is just called TL [16:40:26] TLO* [16:41:06] uhh, I am confused by our number :D [16:42:01] oh right, GRR [16:42:06] not liftoff time [16:42:09] 10363 seconds [16:42:23] that is 2:52:43 GMT [16:42:29] with planned liftoff time of 2:53:00 [16:44:41] it could be a few seconds off [16:44:42] earlier [16:44:57] the launch window opened at a full minute [16:45:28] but the calculated launch time for 72° is not on a full minute of course [16:45:37] so they just launch on the full minute rounded up [16:45:48] to 72.1° or something, different for each mission [16:45:58] hmmmm okay I will look for a TLO [16:46:28] no idea how that memory is structured of course [16:46:34] the LVOT has three parts there [16:46:39] EPO, TLI presettings [16:46:42] found it haha [16:46:44] which don't change for every launch day [16:47:10] 10304.57 [16:52:05] ooooh [16:52:12] surely that is the correct day then [16:57:16] oh I think for some reason they also have a DAY presetting [16:58:16] I think that must be 341 [16:58:48] 1972 was a leap year, so it would be the 342th day of the year, but they start counting January 1st as 0 [16:59:08] oh it's called DATE [16:59:57] can confirm, 341 [17:00:02] ! [17:00:38] so considering the Apollo 14 LVOT is on the current, public NTRS... [17:27:27] and if we were to find an Apollo 17 LVOT we'd share the same numbers [17:34:12] would be great to support the full launch window :D [17:34:28] and better numbers for planned and actual launch time as well [17:34:48] I was able to reconstruct some things in the past, like the launch time vs. launch azimuth calculation [17:35:07] so our Apollo 17 Saturn V already launches in the right direction with a delayed launch [17:35:11] but that's about it [19:22:07] ok, map update fix done, I hope [19:32:22] n7275, looking at VESIM. To be honest, this behavior kind of has to have been the case for a long time [19:32:27] at least with no device connected [19:32:42] vesim.getInputValue returns 0 without any connected device [19:32:50] but 0 is full deflection in one direction [19:32:55] 65536 - vesim.getInputValue(LM_AXIS_INPUT_ACAY); [19:33:01] and that is full deflection to the other direction [19:40:54] I can try with a joystick connected when I get a chance [19:48:42] I agree that it doesn't look like anything has changed recently [19:49:19] but it also worked for me a few weeks ago...and now it does not. [19:50:17] and you are sure you had VESIM activated all this time? [19:50:41] very sure [19:51:40] it's probably worth going back to the commit before the InitModule change [19:51:58] I've even forgotten to plug my joystick in before, but the first time I ever saw this RCS behavior was a few days ago when I pulled the last few weeks of commits [19:52:41] yeah. I never got around to trying that this weekend. got too obsessed with trying to debug the bad pointer [21:10:21] night! [23:04:16] .tell indy91, I can confirm that 9cce195445f1bc9a668ef269de1ce64b916aa765 was the last commit where we did not have this issue [13:54:07] hey [13:55:20] hey Matt [13:55:42] is that just before the Init/ExitModule [13:55:44] ? [13:55:52] yes [13:55:59] very strange [13:56:19] indeed [13:56:47] the fact that the Saturn classes work, and the LM doesn't makes me think this is a simple one-line fix though [13:57:02] it's just a question if which like though... [13:58:29] s/like/line [14:00:26] yeah [14:00:39] I'll try to fix my fix from yesterday then I can look at it :D [14:20:50] I'm just happy it's not my bug this time :) [14:24:02] but a bug I merged [14:24:08] ... so like, nearly all of them :D [16:54:59] morning! [17:00:51] hey Mike [17:01:34] what's up? [17:02:17] bugfixing my bugfixes [17:02:19] and you?:D [17:03:22] 675 pages into the AS-513 scan. hopefully should be able to finish it tonight [17:03:31] great! [17:05:28] and then the Saturn IB launch sim left? [17:06:28] yeah. that one should be a one-evening scan job [17:06:56] ^^ that has been my life for the past few days lol [17:07:32] haha oh boy [17:07:35] but so worth it [17:08:21] DSKY sitting in the background, watching judgingly [17:08:45] really just a DS since it's unfinished, so it is definitely judging me [17:09:03] still more than a LVDC had [17:09:32] an LVDC can turn a light in the CSM on and off at least :D [17:09:39] hehehe [17:11:51] did you have any more questions yesterday? I think all we ended up talking about is presettings [17:12:03] nah that was most of the things I wanted to ask about [17:12:12] I haven't gotten too far into looking at AS-512 [17:12:33] I guess with the later Apollo missions they really only wanted to launch at one day in a month, to a specific launch site [17:12:39] at worst launch a day later to the same site [17:12:48] honestly mostly have been digging through it looking for possible test cases for the MPY instruction for my simulator, because I think it might be working but also it very much disagrees with yaLVDC [17:13:05] so I wouldn't necessarily expect an Apollo 8 LVDC listing to have the December 21 launch presettings [17:13:15] right [17:13:31] but yeah, looking for MPY instances is what led me to find that "using MPY to temporarily inhibit interrupts" thing [17:14:22] yeah I kind of doubt early flight programs have anything close to the final flown presettings lol [17:17:45] wait, so MPY is multiply and is as slow as DIV, divide? [17:18:02] MPY takes 5 cycles to complete. DIV takes 8 cycles [17:18:24] and it inhibits interrupts because there can't be a any interrupts while an instruction is still processing? [17:18:31] basically yeah [17:19:00] same idea as the AGC inhibiting interrupts between EXTEND and the instruction following, or when the accumulator has overflow [17:19:08] jumping into the interrupt would cause loss of that state [17:23:21] I wonder if there is anything in the listing that is not code but still useful. The flight sequence program I guess, but I have that mostly figured out for 15-17 [17:24:21] at this point our LVDC is probably advanced enough that the only major upgrade is an emulator :D [17:24:31] and more presettings of course [17:25:47] hahah yeah [17:25:54] I figured as much :D [17:30:28] and any prelaunch program is missing? So the software could not be run as-is? [17:30:44] are there many jumps to undocumented memory locations? [17:31:16] I cannot imagine that being a huge obstacle really, the flight program should be quite self contained [17:31:50] there were a lot of jumps and such for AS-206RAM, but my initial reading of AS-512 is that it is basically self-contained [17:32:18] we'd have to make our own little preflight program to call the GFP initialization functions and jump to its main entry point, but I think/hope that's about it [17:33:28] yeah it shouldn't be too bad. Many things are done by the ground computer [17:33:38] like, driving the IMU to the initial attitude [17:33:56] with the PGNS that is done by AGC software of course [17:35:06] clock initialization would be one thing [17:35:26] LVDC and ground computer talking to each other for that [17:36:53] the start of the flight program should actually be a GRR interrupt [17:37:06] maybe that is all you really have to do, but I am probably thinking too simple [17:40:48] that flight program language requirements document might be helpful [17:40:54] it has an initialization section [17:41:14] some of which is called when the prepare to launch signal is given [17:41:43] which is at T-10 or 20 min or so [17:41:55] oh interesting [17:42:04] yeah PTL is what causes the jump to the flight program right? [17:42:17] hmm [17:42:25] I think that doesn't happen until GRR [17:43:34] "...and to transfer program control to the flight routines. This transfer is initiated upon receipt of the Guidance Reference Release (GRR) interrupt, at which time the flight program will be initialized" [17:44:27] yeah PTL is handled by the LVDC preflight program [17:44:47] gotcha [14:36:58] hey [14:59:46] hey Nik [15:08:40] any more progress with the VESIM issue? [15:09:42] nope :/ [15:11:12] I'm all the way down the probably cause list to: a random muon is coincidentally hitting the same bit in your and my RAM [15:36:14] oh I was wrong with the previous behavior [15:36:29] the CSM still has input devices listed with no joystick connected [15:36:33] but the LM didn't load them [15:40:45] Vesim::setupDevices isn't call for the LM [15:41:21] oooh [15:41:26] HINSTANCE dllhandle; [15:42:11] dllhandle = g_Param.hDLL; [15:42:53] for the LM this is done in the LM constructor [15:43:18] hmm, but for the Saturn, too [15:51:10] confirmed, dllhandle is NULL for the LM when it tries to set up VESIM [15:51:16] that fails so it is never set up [15:52:40] don't know why just yet [15:52:47] code looks about the same for Saturn and LEM [16:00:07] the two classes handle g_Param differently [16:01:29] LEM: static GDIParams g_Param; [16:01:34] Saturn: GDIParams g_Param; [16:02:01] and then Saturn uses "extern" to use it in other places [16:02:09] LEM class just has static twice [16:04:40] if I change it in the LEM to how it works in the Saturn class then the bug is fixed [16:05:57] all I did was, in LEM.cpp remove the "static" from GDIParams g_Param; [16:06:12] and in lempanel.cpp change static to extern [16:06:19] not sure how that all works yet... [16:07:36] static has more than one meaning in C++ :D [16:14:08] oh I see [16:14:37] before the InitModule change the code did [16:14:41] InitGParam(hModule); [16:14:45] g_Param.hDLL = hModule; // DS20060413 Save for later [16:15:05] the hDLL in LEM.cpp was initialized here [16:15:11] and InitGParam was in lempanel.cpp [16:15:17] and initialized the other one :D [16:16:46] n7275, I'll create a PR a bit later, you can check that it actually fixes the issue for you then, as I don't have a VESIM device set up [16:51:52] awesome. just getting back to this. I got very distracted for a bit. [19:54:10] I wished we had never gotten the AS-206RAM listing [19:54:55] the only reason we are all so careful about this all is because the owner of that was being careful [19:55:26] and some other people saying it's all so secret [19:55:43] I still wait for the Sunburst code to be taken down [19:56:02]