[14:54:41] NASSP Logging has been started by alexb_88 [14:54:43] good morning [14:55:04] hey [14:55:19] difficult to say [14:55:32] n7275 tried something random and found a bug, so, that was successful :D [14:56:10] a lot of bugs in this update will manifest itself not by something not working but by being less accurate [14:56:40] although others would maybe show up in the wrong coordinate system, which is a significant diffeence [14:56:45] difference* [14:58:26] right [15:03:14] do the different missions need there own coordinate system configuration? [15:03:22] their* [15:05:48] yeah the RTCC internally will now use a different coordinate system for each year [15:06:01] which is a bit of a problem with "constants" [15:06:56] the star vectors file for example is still in ecliptic coordinates. And gets rotated to the right coordinates when the RTCC mission file is loaded [15:08:55] the layers of RTCC loading are basically: [15:09:18] 1. load from the mission file, which is like an initial program load of a IBM computer [15:09:33] that contains all the constants that are specific to a mission, but not for a specific launch day [15:09:43] like the epoch of the coordinate system [15:09:46] uplink addresses etc. [15:10:05] next layer is mission initialization with a launch day [15:10:08] basically the P80 MED [15:10:38] those are saved in scenarios [15:10:49] numbers that come from P80 [15:14:55] it takes a bit of additional code to make sure everything gets converted to the right coordinate system [15:15:08] but that is all in place now, so hopefully no further issues from that [15:19:26] hey guys [15:23:42] hey Matt [15:34:17] hey [15:34:34] indy91, I got the branch setup, I guess Ill try a few different things [15:34:46] sure. As random as possible :D [15:35:50] basically just different types of calculations with the RTCC MFD I guess? [15:36:04] maybe I can run through some MCC threads too [15:36:06] yeah [15:36:17] that's the issue with coordinate systems [15:36:21] they affect everything [15:36:41] right [15:37:04] what was the issue Matt had? [15:38:24] MPT display showed zero HA and HP in lunar orbit [15:38:43] something thought it was in Earth orbit and it refused to calculate it then [15:38:49] was a simple fix [15:39:11] AlexB_88, do you remember, is the abort light in the CSM not implemented in the VC? [15:39:26] I only see some commented code [15:41:02] hmm [15:41:21] maybe it isn't yet [15:44:52] it looks like its not, I can't remember why I left it out [15:44:59] should be easy to add [15:45:40] it has some fairly complicated logic to it [15:45:49] I always hate when we have to duplicate code for 2D and VC [15:46:05] the light should have its own little class [15:46:15] maybe I said I would implement such a class [15:46:19] and never came through? :D [15:47:46] do we have a generic "panel light" class? [15:50:25] I don't think so? But I would first search for it before I would implement something like that [15:50:35] maybe I created one for the LM and then forgot about it [16:08:57] I have some ambition of fixing some factory pattern stuff in the future. it works pretty well but it's very messy and only works for core systems [16:15:26] morning! [16:24:16] hey Mike [16:25:10] indy91, if I am trying one of my Apollo 17 scenarios to test your branch, should I delete the RTCC from the scenario and let it load from scratch? [16:33:48] hey Mike [16:33:50] hmm [16:34:03] don't think deleting the RTCC from the scenario does much [16:34:16] not much coordinate specific is saved [16:35:07] REFSMMAT is [16:35:16] but deleting doesn't replace it with a good one [16:40:41] unless you are very unlucky your Apollo 17 MCC shouldn't break [16:40:58] scenarios between the TLI+90 and the TLI PADs might [16:41:10] if you did the same method with using the MPT to simulate TLI [16:45:23] hmm [16:45:40] I am having trouble with the DOI-2 calculation [16:45:44] with the GPM [16:45:56] just testing with the RTCC MFD right now [16:46:33] DOI-1* [16:46:46] I have a scenario before LOI, I put LOI on the MPT and then calculate the DOI-1 with the GPM [16:47:55] so with a Apo/Peri change with point time 93:13:08 and 59x13.18, the LONG P is ~45W [16:48:28] before it would be close to the desired, so +/- 10 degrees of 31 E [16:49:15] unless you chose a TIG that was after the pericynthion, then it would pop to a west longitude [16:49:22] but not before [16:49:29] now its doing it before as well [16:50:38] interesting [16:50:52] yeah calculations involving longitude could be affected [16:53:33] so I have a checkout monitor with the conditions at perilune on the DOI-1 orbit (only LOI on MPT): [16:54:36] https://www.dropbox.com/s/lh528966ulqb03l/Screenshot%202023-06-19%2012.53.48.png?raw=1 [16:55:03] used FPA = 0 [16:55:39] just thought I'd share that if it revealed anything odd [16:56:38] LONGC 162.77 E for perilune after LOI. I guess thats sounds right [17:04:51] hmm [17:05:07] I think there is a bug with the periapsis location calculation [17:05:25] it's related to the "one crisis I had in this branch" I mentioned to thewonderidiot a few days ago :D [17:05:36] I think I forgot to fix something for it [17:05:48] hahaha [17:06:17] the latitude of periapsis on the display is a bit nonsense [17:06:20] I think that is related [17:06:26] does a coordinate transformation wrong [17:07:16] on the GPM display that is [17:07:40] but both latitude and longitude will be wrong [17:07:48] ah [17:07:54] just a lot more obvious in latitude in the Apollo 11 scenario I tried [17:08:15] it would make sense since using the same times as before, and it gives the same DV's [17:08:29] yeah [17:08:32] but with a completely different peri location [17:08:36] just the displayed periapsis data wrong [17:08:41] right makes sense [17:09:37] well until that is fixed, Apollo 17 MCC is definitely broken :D [17:10:04] haha [17:10:10] easy fix [17:10:24] well, maybe it would still work, but you would have a pretty insane DOI-2 [17:11:00] I mean I did make it switch to DPS if its higher then 30 ft/s as per mission rules [17:11:25] so your DOI-2 calculation iterates on this? [17:11:38] no just DOI-1 [17:11:47] ah right [17:11:50] DOI-2 is just a normal LDPP calculation [17:13:49] but I think it will try to fix the orbit to a certain so that it meets the constraints right? (perilune realtive to LS) [17:14:21] so if DOI-1 is off then LDPP solution can have high DVZ component [17:15:04] bug seems fixed [17:15:24] was trying Apollo 11, which had a very equatorial orbit [17:15:32] so was strange to see 15° latitude :D [17:16:58] update pushed [17:17:29] thanks! [17:26:16] thanks for finding it [17:26:20] won't be the last one... [17:28:06] fixed [18:55:25] cya! [20:48:01] night! [14:54:39] hey [15:21:19] hey Niklas [15:24:47] hello hello [15:24:53] https://github.com/orbiternassp/NASSP/pull/1013#issuecomment-1598964795 [15:25:04] and I haven't forgotten about your e systems PR [15:25:22] but it does change more than the last PR, so I wanted to take a proper look [15:29:40] yeah that's fine. should probably have been two commits [15:30:00] one was just fixing whitespace so the code is more readable [15:30:38] the other was removing the "startup" code from the fuel cells that I should've done a long time ago. [15:32:47] right [15:33:01] just the "new" startup code I really wanted to look at [16:15:55] yeah definitely worth a second pair of eyes [16:25:34] morning! [16:26:44] n7275, is this actually new FC code or something one of your branches has been doing for a long time? [16:26:46] hey Mike [16:27:53] done with Corona for now? [16:28:01] can't say I have contributed that much to it... [16:28:10] always got stuck on some annoying scaling [16:29:05] haha, for now. I was staring at FFFLAGS, which still has like 12 flags I don't understand, and SITENUMB, whose bits together with the flags lead to very complex partially-overlapping execution paths [16:29:43] and thought, man this is complicated, it is going to take a long time to fully understand. and then I thought about Sunrise, which has some weird self-test stuff, and Sundial with its earlier gyrcompassing program, and Aurora with its LORS code [16:30:12] and realized that if I don't just make preliminary source trees and submit them to the virtualagc repository, but instead strive for perfection in the disassemblies.... I will never get them all done :P [16:31:20] let's do something easy next. Like modifying Artemis (or I guess rather Athena) to use the Skylark PIOS, so that I can test the 1950 coordinate system [16:31:25] so in the short term I'm going to build source trees that assemble correctly, name as much as I can without too much effort, and then submit them as-is without bothering to try to eradicate all of the UNKs [16:31:34] lol [16:31:37] only like 1% serious there :D [16:31:54] hey we do have the Norton document for Skylark 48 [16:31:57] and its erasable memory map [16:33:11] yeah, possible to do I guess [16:33:51] for sufficiently crazy people :D [16:33:59] I'm not sure even we are that crazy yet [16:34:05] not yet [16:35:03] what we can't do is go through the list of PCRs and implement them one by one [16:35:13] because I see PCRs that weren't actually implemented [16:35:22] like deleting P65 and P66 [16:35:28] pretty sure that wasn't actually done [16:35:58] oh interesting [16:36:41] oh about PCR 888 from yesterday, I noticed the PCR was made mid 1969 and then the memos saying "nah, not so important" was from a year later haha [16:37:18] so one year of not doing anything about it. And then deciding to not ever do anything about it. [16:37:32] hahaha amazing [16:37:52] MIT simulators were taking into account the deflectors, so, they must have been happy enough [16:38:03] ahh okay yes that makes sense [16:38:33] I thought it was funny they added the deflectors to 11 and but then didn't think about added code to account for them until Luminary 1C [16:42:43] indy91, what do you mean? did I forget to push something? [16:43:29] I mean, did you write this code with "tooCold" in the last few days or did it already exist in one of your branches before that [16:43:52] like, is it already code tested a lot by you and Ryan over months [16:45:07] ahh. okay. it's new. [16:47:01] there was a switch statement for "status", and since the only "status" now is temperature that that could be eliminated [16:47:49] SM sep still disables the cell, and purging just uses the purging flags directly rather than setting status indirectly [17:07:52] aaaaah [17:08:20] removing the status made the code a bit confusing to read [17:08:28] most of this code already existed [17:08:32] just not the tooCold flag [17:08:51] but the whole checking the temperature, waiting 100 timesteps etc. isn't new [17:09:03] just moved to a different place when you read the diff [17:11:42] so I thought this was a much more signficiant change than it really is [17:19:01] the diff is extremely messy, but hopefully the end result is a bit more simple. [17:20:48] yeah not really much you could do about that [17:21:16] I'm not even sure that 100 timestep check for the FC being too cold is strictly necessary. it might be okay to have a 2-5 volt output with. very cold cell. I'll need to do some testing first to make sure my voltage map doesn't create NaNs or negatives at weird temperatures [17:29:58] oh nice trickery with the sscanf for backwards compatibility [17:45:54] I have the occasional bright idea :) [18:00:18] ideas which I will steal for sure [20:37:34] I will have a few more cleanup PRs coming for some other parts of the systems code. I need to wait on anything with hSystems though unless I want merge conflicts with my other stuff [20:41:53] sounds good [20:42:15] I'll merge your PR tomorrow, it's definitely good code wise, just wanted to load it up in a few scenarios just to see [20:57:20] yeah definitely. thanks [21:17:05] night! [16:05:12] morning! [16:19:24] hey Mike. [16:20:13] what's up? [16:22:31] not too much. work mostly. you? [16:23:04] same, mostly. Sunrise 69 is falling into place pretty quickly -- I think I should be able to submit a source tree for it in a couple of days [16:23:16] hey guys [16:24:01] yo [16:25:58] hi Niklas [16:26:24] anything in the source reconstruction backlog after Sunrise 69 still? [16:27:14] Sundial E and Aurora 88 [16:28:06] both of which have the old gyrocompassing code, and the latter of which has a bunch of LORS code [16:28:14] so there will be some fun to be had in figuring them out lol [16:29:52] I've already "flown" Sundial E almost 3 years ago :D [16:31:21] yeah I know, I'm a slacker haha [16:33:29] hardly haha [16:33:44] on the padload generator front, when adding new versions I am trying to avoid code duplication [16:34:00] but there are always these small little differences [16:34:17] I think I am going to break the Apollo 11 padload stuff when implementing Apollo 10 padloads... [16:34:56] either I have to be really careful or even better, I implement some sort of validation that tests if padloads for each mission are still being generated correctly [16:35:41] maybe with expected and unexpected differences to the flown padload [16:35:59] oh yeah, tests are a good idea [16:36:27] well I am already running a diff in Notepad++ comparing to the flown padload, checking it line by line. But maybe something more automated is better [16:37:20] I don't know if I can actually generate a CMC padload that bit by bit the same to a flown one [16:37:38] that would require having the same JPL ephemerides they used to generate the numbers [16:38:03] they had that on tape [16:38:11] haven't seen a digitized version of it yet [16:40:27] if I recall correctly one of my long running projects might benefit from those, or something similar [16:42:36] I generated some text files using the Orbiter ephemerides, for use in my TLI targeting project [16:42:46] but those will be a bit different to the JPL ones [16:42:53] there also is this time difference [16:42:56] no leap seconds [16:43:46] so they won't be exactly like the JPL tapes [16:46:04] leap seconds strike again [16:46:08] those things are the worst [16:47:21] and so random sometimes [16:47:34] can we not do enough SLS booster tests to avoid them :D [16:48:31] hehehe [17:20:57] maybe they're doing them in the wrong direction [17:23:28] making Earth nutation worse by pointing it north or south [17:27:09] the SLS booster test facility points about east-southeast :D [17:29:00] if there was no atmosphere it would even matter [17:51:02] n7275, merged your FC change [18:14:33] nice. thanks! [15:25:52] hey [16:36:06] hey [16:38:21] hmm, one of the uses of the mission number in the RTCC MFD is the Ascent PAD [16:38:52] because of an address difference in FP8 it has 224 vs. 225 based on the mission number right now [16:39:01] if I want to get rid of the mission number, how do I solve that [16:39:19] a button that cycles between the different Ascent PAD versions I guess? [16:40:01] but I don't really want to save that in scenarios. If I don't you have to manually change the Ascent PAD version every time, for certain missions... [16:42:55] maybe a line in the RTCC mission file? [16:43:57] I don't want to load the actual mission file in the MFD. That is for vessels [16:44:16] such a dumb little thing :D [17:37:43] yeah, that's annoying [17:38:35] but an ascent pad type in some RTCC mission file is probably the most robust solution [17:41:44] the Apollo 12 Ascent PAD was already sufficiently different enough that Alex implemented a separate PAD type for the MCC [17:41:50] something I should consider there as well [17:49:07] I think I'll start with a MFD button, just because it's simpler [17:49:27] if it gets too annoying I'll change it to a RTCC mission file parameter [18:01:17] morning! [18:02:23] hey Mike [18:02:42] what's up? [18:03:13] working on the followup project to my RTCC coordinate system change [18:03:50] throwing out the mission number parameter out of the RTCC MFD [18:03:58] better for custom missions like MaxQ is doing [18:10:12] oooooooo nice :D [18:10:18] that is a very good improvement to make [18:19:40] I'm trying to decide if I want to abandon my Sundial source reconstruction attempt from 3 years ago, or start over from a clean slate [18:20:00] I've certainly got a lot better since then, and definitely don't remember what all I changed and why [18:26:06] picking up old projects is hard [18:26:38] yeah. I'm leaning towards starting over, but keeping the original attempt on a separate branch for reference [18:27:03] also hard is going to be thinking in Block II again, after spending months working on Block I disassemblies [18:33:40] oh yeah I know the feeling. When I want to quickly check something in Colossus or Luminary code after having looked at the midcourse navigation game... [18:40:29] branches I haven't looked at in more than a few months are almost always abandonware for me [18:40:46] I just don't remember enough from them to have them be useful [21:03:53] night! [14:27:16] hey [14:36:38] hey Matt [14:39:23] what are we doing about my RTCC branch? I guess the track record isn't so great, both you and Alex both found bugs pretty quickly when doing random testing :D [14:40:51] should I just do some more testing myself, or do you want to do some more, or should we just merge it... [15:03:54] I will be out of town until Monday so I don't have many options to help test until then. it's probably worth a few more random tests from you, then merge it. our userbase is pretty good at finding bugs and we're pretty at fixing them and getting them back on track when they do [15:05:14] sounds good. Yeah, a few "more than minor" bugs are probably going to be found quite quickly, after the update is merged [15:07:49] one thing I checked yesterday was my nemesis [15:07:56] Apollo 9 SPS-7 [15:08:21] slightly different DV, but I think that is due to drag and/or different time of calculation [15:08:27] close enough [16:26:28] morning! [16:48:07] hey Mike