[13:19:59] NASSP Logging has been started by indy91 [13:20:01] n7275, I'm sure there is a good improvement possible without overcomplicated code [13:20:14] rcflyinghokie, I made two good improvements for the SPS-7 targeting I think [13:20:27] excellent [13:20:34] the main issue was probably that it did place perigee correctly, but not on the correct rev [13:20:50] oh interesting [13:21:08] what I wanted it to do was find the upcoming perigee from the maneuver [13:21:19] and then X revs later the perigee should be placed correctly [13:21:32] that X is 46 for Apollo 9, almost 3 days between SPS-7 and deorbit [13:21:48] but it didn't find the upcoming, but the previous perigee instead [13:21:58] oh ouch [13:22:14] and the Earth rotates more than 20° per orbit [13:22:38] I think even with the update there can be a bit of an issue when the maneuver is close to perigee [13:22:57] just before vs. just after [13:23:23] it seems like with the old logic it found a perigee at about 237h [13:23:30] now it finds it at 240h [13:23:33] which is correct [13:23:48] the orbit should be optimized for a SM RCS deorbit, one rev after nominal SPS deorbit [13:24:09] is it having issues because the rev change being close to perigee? [13:24:33] yeah, that is a potential issues that still exists, although it hasn't really caused problems in any of the scenario I tried today [13:24:43] issue* [13:24:47] Hmm ok [13:24:56] in your old scenario it definitely found the right one [13:25:02] As I said I am flying 9 again, just finished SPS5 [13:25:15] so I can give it another test after the LM work [13:25:38] the logic doesn't actually integrate the orbit all those 46 revs and then iterates it. That would take ages to converge. [13:26:03] The second improvement I did was a better estimate of the orbital period, with nonspherical gravity taken into account [13:26:12] that being off could also have caused it to find the wrong rev [13:26:48] So definitely a lot happier now, but, potential problems still existing. [13:26:54] hey [13:26:58] hey Alex [13:29:14] rcflyinghokie, maybe you can give me another pre SPS-7 when you get there. Just another test case [13:29:17] hey its headed down the right path! [13:29:19] scenario* [13:29:21] Absolutely [13:29:30] and morning Alex, good to hear about the LM! [13:32:42] should fly the landing today [13:33:49] excellent [13:34:11] It still needs more tweaking I think but I want to make sure its stable first [13:52:51] LM gets a little warm in LEO coasting flight [13:53:02] ECS cools it right down though [13:58:19] also I noticed (properly) because the heat has been better redirected to the plates, the water consumption has increased [14:13:57] things are getting better [14:14:01] like the SPS-7 targeting haha [14:14:06] slowly but surely [14:28:50] dare I say it, the rate needle changes are starting to grow on me [14:29:46] I have begun to adjust [14:31:29] fyi, suit temp is 54 F and cabin temp 58 F after undocking [14:31:32] crew in suits [14:32:06] little cool but not bad [14:32:23] but again we are missing a lot of heat haha [14:32:52] right [14:33:03] better that then too hot [14:34:15] hows the stability [15:04:42] very stable [15:06:28] im running the apollo 9 EVA in 10 [15:06:30] 10x [15:06:52] cool but otherwise very stable even switching panels and spacecraft [15:09:26] If we jettison our LM's with no real issues between now and then, I say this can move to a PR [15:15:11] indy91, is the TPI times page MPT compatible? [15:15:34] it is not [15:15:38] rcflyinghokie, I definelty think its PR ready [15:15:44] the MPT procedure is to use the sunrise/sunset table [15:16:01] that's what RETRO did, in assistance to the FIDO [15:16:23] of course requires subtracting numbers [15:16:26] very stable across the board [15:17:29] indy91, sounds good [15:17:51] I see there is no option to specify the vehicle on that page though [15:19:47] it can only use the CSM ephemeris [15:20:39] which is a restriction of the real display [15:20:52] so it's just always the CSM [15:21:01] ah [15:21:12] so it should be MCC VC compatible already [15:21:16] yep [16:17:06] eva was pretty good [16:17:08] very stable [16:54:50] indy91_ all pre-PDI pads were flawless with the RTCC MFD and from MCC VC [17:00:21] great to hear [17:05:28] PDI is about 20 seconds off from FP, this is unacceptable! [17:06:08] :D [17:06:14] I blame DOI residuals trimming [17:06:17] and crossrange 0.2 NM [17:07:20] Apollo 14 has a "steep" approach azimuth, so that crossrange is indeed very good [17:23:54] morning! [17:29:59] hey [17:32:34] what's up [17:32:38] ? [17:33:05] AlexB_88 did you get any solder balls in your LM? [17:33:52] Dont want it to abort you by accident [17:34:24] I was trying a few things with the Return-to-Earth processor, but I think I'll need the help of at least one document at NARA. So I guess that project is on ice for a few months. [17:34:36] at least* [17:34:43] yeah [17:35:00] NARA came up in an email chain on the apollonauts mailing list [17:35:22] from Ron: [17:35:26] NARA is not fulfilling requests from the public at all at the present time. Or rather, they have only been fulfilling "emergency requests" for about the last year. Or so I was informed a month or so ago. I'm told that there is light at the end of the tunnel now, given that the covid-19 emergency is winding down a bit, and that some of their workers are returning, but I wouldn't start holding my breath on new requests just yet. [17:36:32] yeah I guess my request from last week is a long way down the line for even getting an answer that they have received it [17:36:42] probably yeah :/ [17:42:14] 3rd LM powerup, cabin temp 52 glycol temp 47 [17:42:17] I like it [17:55:15] rcflyinghokie, yep all good :D [17:55:45] btw 404-12345 [17:56:07] in the AGS initialize just before PDI, anyone know what thats for? [17:58:06] Vehicle unstaged [17:58:28] making sure the AGS knows you have a descent stage attached [17:59:17] it resets the velocity counter to prevent overflow [18:00:01] ok, I had crossed it out of my checklist a while back, but I dont know why I did that [18:00:04] https://www.dropbox.com/s/ncz5uwqwyuls01y/Screenshot%202021-04-17%20135945.jpg?dl=0 [18:00:07] sounds like its needed [18:00:12] from the FP6 manual [18:00:56] im running FP8 [18:01:06] I think [18:01:06] pretty sure its the same, I'll check [18:01:28] says 12345 in the 1A14 timeline book [18:01:29] yep exactly the same [18:01:32] ok [18:01:47] FP-8 is 12345 [18:01:53] FP-6 is 12346 [18:02:00] same address though [18:02:05] ah ok [18:02:10] thanks [18:02:58] and btw, suit temp 52 F, cabin temp 62 F glycol temp 34 F and glycol press is 25 PISA [18:03:05] just before PDI [18:06:37] yeah your glycol temp will probably stay under 40 right now [18:07:04] you will notice it warmer during ascent though, the tracking light puts out a lot of heat [18:11:06] One issue I found is the LM temps really drop when doing EVA [18:11:19] the glycol gets pretty cold [18:11:37] need to look into what all is generating heat when powered down [18:16:29] I think I'll start flying Apollo 9 once the LM ECS updates are merged [18:16:38] to update the MCC [18:20:23] only Apollo 7 then left that needs the same treatment [18:21:37] we are getting close to green lighting this [18:23:05] My branch is all up to date with the current as well so it should present zero merge conflicts [18:25:32] also, for the record, my N2 PP is negligible [18:26:11] of course, I have had cabin depress, but still before that the cabin purging works pretty well [18:26:32] it might need better numbers going forward but the current behavior is pretty on par [18:26:57] just has to go away over time [18:32:40] yeah [18:33:19] waste stowage valve is in a simple form right now, but it seems to vent the cabin nice and slow [18:35:08] enough you get a little o2 flow increase but it doesnt peg [18:35:54] that whole procedure sounds a bit O2 wasting to me [18:36:05] well it is technically [18:36:11] I guess better to have another Apollo 1 [18:36:16] than to* [18:36:22] yeah [18:37:13] But I did the cabin purge per the FP/procedures, and a cabin depress with LM repress and I am sitting at 74% O2 in the CSM at 89hrs [18:37:57] on apollo 9 [18:38:08] N2 PP is like 0.0003psi [18:38:51] oh 74% remaining in the tanks [18:38:55] yes [18:39:06] I thought: 74% doesn't sounds like a very successful purge :D [18:39:10] Haha! [18:39:18] Yeah considering it started with 40%N2 [18:44:44] its also nice to see some water consumption in the LM now [18:54:59] suit 54 F cabin 60 F at touchdown [18:55:12] ECS looks quite stable so far [18:56:37] get ready for a powerdown chill lol [18:56:57] but excellent news [19:02:39] I have to go now, but Ill carry on tomorrow and ascent within the next few days [19:02:41] cya! [20:13:37] got the 211/217 again haha [20:32:34] what are you doing Colossus 249 [20:33:16] which P52 is that? Which REFSMMAT? [20:38:49] Yeah apollo 9 [20:38:59] Rendezvous REFSMMAT [20:39:02] P52 option 2 [20:39:08] oh option 2 [20:39:10] 1* [20:39:11] sorry [20:39:13] oh [20:39:14] haha [20:39:25] I was just going to say, it can't be a bad uplinked REFSMMAT then [20:39:30] but it could [20:42:19] but it shouldn't [20:42:40] while I have changed certain uplink functions, Apollo 9 still uses the old functions [20:42:51] with hardcoded uplink addresses [20:43:34] I think its just the attitude you begin with maybe [20:43:49] yeah, that definitely plays into it [20:44:06] when I playing around in a scenario you gave I got the alarms in one attitude, but not some other [20:44:12] and after drifting flight and time accel who knows where I am [20:45:00] but it's still something that shouldn't happen. Sounds very unlikely that it's Colossus bug [20:47:55] agreed [20:56:52] when you originally got the issue, what REFSMMAT was that [20:57:38] 191:20h has a P52 option 2 [20:58:06] a scenario with the 211/217 alarms already present is shortly after that time [20:58:46] I think you got it more than once [20:58:59] so might happen with any coarse align [21:05:54] night! [21:58:08] .tell indy91 yeah I have had it on later coarse aligns as well, I think the attitude you are in plays a big role...maybe something to do with what it has to drive through to get to the preferred orientation? [13:35:20] hey [13:35:47] good morning [14:00:04] I think I found a bughaha [14:00:26] I keep getting CTD if I am looking out the 2d LM window and either changing FOV or saving [14:00:52] https://www.dropbox.com/s/3lwisg01lkxq4qp/Screenshot%202021-04-18%20095948.jpg?dl=0 [14:14:11] oh no [14:14:17] something's null [14:14:29] I can reproduce it [14:14:33] 100% of the time [14:15:12] https://www.dropbox.com/s/nkq2uuotgkb6te0/Apollo%209%20MCC%20-%20Undocking%20CTD.scn?dl=0 [14:16:58] Did we ever fix the CSM clickspot thing? [14:17:51] I dont know, i think it was fixed? [14:19:31] is this sceneriao on your branch? [14:20:38] yes [14:25:18] rebuilding now [14:27:38] uuuuh yeah. I'd say something's very wrong here [14:29:41] same thing? [14:30:12] yeah [14:30:35] only happens in the window [14:31:30] if I load that scn and change fov or save in another view then come back it wont ctd [14:32:55] going to try to debug [14:34:42] thanks [14:46:32] weird, I get an assert failed loading in debug mode [14:46:49] it appears to be related to the checklist controler [14:46:56] not sure if related [14:47:34] hmm [14:47:48] not sure either [14:54:09] yeah same memory offset for me [14:55:06] I just reloaded that scn and no ctd [14:55:45] I was getting it every time [14:55:51] reloading again [14:57:20] no ctd [14:57:21] lol [15:00:41] okay, that's even more strange [15:04:54] did you do anything different? [15:05:43] nope [15:11:38] maybe it has to do with textures, where I was over the earth? [15:36:25] If I start paused sometimes it let's me adjust FOV with no crash [15:36:43] and other times it just crashes instantly with no error [15:38:58] very odd [15:49:33] I really have no idea [15:52:23] me either [15:52:33] something to keep an eye on I suppose [16:32:50] yeah, definitely [16:39:07] hey Nik [16:39:41] Hey Alex [16:39:56] hey [16:41:09] so Ryan found a strange bug [16:43:44] https://www.dropbox.com/s/nkq2uuotgkb6te0/Apollo%209%20MCC%20-%20Undocking%20CTD.scn?dl=0 [16:44:55] if you open that sceneriao and change FOV, orbiter crashes [16:47:05] hey guys [16:47:29] even opening the camera menu already crashes that scenario [16:50:47] access violation trying to access the zero address [16:50:55] something Orbiter tries to access is nulled then [16:52:49] any ideas? [16:54:48] are you making checklist updates, too? [16:55:03] can't load the scenario in debug mode [16:55:13] gives a Checklist MFD error [16:55:24] I will delete the checklist section from the scenarios [16:55:58] scenario* [16:59:17] might have to switch to your branch [16:59:26] getting a CTD in ship_system::Refresh now [17:01:15] only in debug mode though which is weird [17:02:07] I had the same issue [17:08:29] still getting more CTDs [17:08:36] it can't access PRIMGLYCOLACCUMULATORACTUAL:PRESS [17:09:23] or mass [17:10:10] those should be commented out [17:10:51] why does that crash though [17:11:15] Ohh [17:11:37] let me look at something.. [17:11:56] ah [17:11:59] PRIMGLYCOLACCUMULATORACTUAL is commented out [17:12:02] so PRIMGLYCOLACCUMULATORACTUAL doesn't exist [17:12:16] yeah but the pointers are not [17:12:18] thats why [17:12:31] right [17:12:47] in release mode it doesnt cause a problem for me [17:13:42] fixed [17:14:37] there was no pointer to mass though [17:14:46] only press and volume [17:15:07] yeah, I wasn't sure exactly where it was crashing [17:15:19] those 2 lines are commented out now [17:15:32] but now I can debug it and it still crashes in an undebuggable way [17:15:43] when I open the camera menu [17:15:49] I wonder if its a texture or something [17:15:50] what could that be... [17:16:06] Alex did a bunch of camera work, but only for the VC really [17:17:31] it only happens on that panel [17:17:36] I can open the camera menu elsewhere [17:17:51] me too [17:23:11] so fun fact, the descent batteries are 70 degrees at the TPI0 time on Apollo 9 [17:23:16] I think thats healthy [17:23:41] 145 is the upper limit [17:24:09] I wager they will run a little warmer when the glycol is warmer due to more system heat to be added [17:24:17] but I am happy with how the battery heating turned out [17:31:09] great [17:31:17] if I click the Info button I also get a CTD [17:32:34] thats so odd [17:33:12] I went to another screen and did the camera button and came back to the crashing window and now have zero issues [17:33:52] I get that mostly, too [17:34:05] once I got the CTD on the COAS view after I had switched elsewhere [17:35:38] indy91, try starting with orbiter paused [17:36:30] for me it either crashed before loading, or loaded and the issue was not present [17:36:37] like, 50/50 [17:37:20] did we fix the csm clickspot issue in scenarios with lems [17:39:22] not sure [17:39:28] I also get a CTD when closing the scenario [17:39:36] caused by "LM-DESBAT4-ECA-Plate" [17:39:49] when it calls [17:39:50] Thermal_engine::RemoveThermalObject [17:40:02] in the h_Radiator destructor [17:41:29] taking a look.. [17:41:53] that seems to be the last thermal object in the list [17:44:03] why would it be removing it [17:44:32] part of the battery disable()? [17:44:48] or setpumpoff() [17:45:29] it's in the h_Radiator destructo [17:45:30] r [17:45:41] right [17:45:52] so why would it be causing an issue [17:45:53] radiators always remove itself from the thermal systems in the destructor [17:46:04] it seems to go through the list of thermal objects [17:46:10] and each object has a pointer to the next one [17:46:21] the last one should have a null pointer [17:46:53] but it's not null [17:47:13] what is causing that then [17:47:38] it's probably null when the radiator gets added [17:47:42] have to check what happens then [17:48:20] that one in particular is a normal radiator [17:49:05] oh no [17:49:09] it's the batteries [17:49:16] ah but [17:49:18] it's fixable [17:50:09] I was thinking about this when we first thought about adding batteries as thermal objects actually [17:50:15] but forgot about it [17:50:21] no destructor in the battery class? [17:51:25] yeah [17:51:32] and that needs to remove the thermal object [17:51:43] battery gets deleted first [17:51:49] but didn't remove itself from the thermal [17:51:52] systems [17:52:01] and then the last h_system tries to access the battery [17:52:06] which already got deleted [17:52:38] ahh [17:52:50] I assume you are writing a fix then? [17:53:00] feel free to add it to my branch [17:53:15] so close to being ready lol [17:53:29] ecs is very stable in LEO [17:54:26] yeah, this requires a few parts, I'll create a PR for your branch [17:54:49] I doubt this will fix the Camera/Info box issue though haha [17:56:33] nowadays these lists of systems would rather be handled with std::vector or so [17:57:15] yeah the camera thing I have zero idea about [17:57:34] something about the LM state might be bugged [17:57:45] not sure what else could cause the Info box to crash lol [17:58:11] but again I loaded the scn went to a different window, did the camera, and went back and no crashes [17:58:20] its been fine since [17:58:27] so maybe the scn file holds clues [17:59:43] Testing irc on the phone [18:00:08] works [18:00:58] only got the camera menu CTD on the second try this time [18:01:11] hmmmmm [18:01:25] I think when I clicked the camera button the tracking lights appeared [18:01:27] at that moment [18:01:31] when it usually crashed [18:01:37] that seems related [18:01:56] Orbiter closing bug seems fixed at least [18:02:14] those lights are right in your face [18:02:20] when they decided to load [18:07:21] yeah I notice that time to time [18:07:42] you can see the blur of the dock lights [18:07:46] but only sometimes [18:08:26] PR is up [18:08:35] in this case they loaded when the CTD usually happened [18:08:43] so that seems suspicious [18:08:48] sounds like a divide by zero problem [18:13:05] ok ECS branch up to date [18:13:40] thanks for that [18:14:04] no problem [18:14:49] you can change the FoV with the mouse wheel [18:15:03] in that scenario I can trigger a CTD just by moving the mouse wheel [18:15:10] yep thats how I first found it [18:17:22] maybe the field of view of that panel is bugged then [18:21:13] that seems like a bear to isolate [18:22:52] Just tried saved mission scenerios for Apollo 9, 11, and 5, same issue in that view [18:23:49] more fun issues [18:23:49] POWER_BATTERY 2419200000.0000 -nan(ind) [18:23:57] S-IVB battery [18:24:09] BATTERY_DUMMY 10000000000.0000 -nan(ind) [18:24:24] BATTERY_A 5236711.5234 -nan(ind) [18:24:31] all the batteries in that scenario have that [18:24:53] oh that's very bad [18:25:13] that's temperature [18:25:29] What's happening? [18:25:43] nan battery temperatures [18:25:48] in that scenario [18:25:50] all of them [18:26:58] Maybe its a corrupt save [18:27:14] Because my temps are normal continuing from that point [18:27:39] I don't have any NaNs in my Apollo 7 saves, so it wasn't something in my commit [18:27:44] probably [18:28:13] I also think that those temperatures aren't actually initialized [18:28:39] because we aren't even using the temp for all batteries yet [18:28:52] I mean we can, it won't hurt anything [18:29:17] Its not like the heat is going anywhere in the CM or being measured yet [18:29:48] so when going back in your scenarios, where do the NaNs start? [18:32:09] oh actually [18:32:13] I think it's not a problem at all [18:32:30] it's just that the temps aren't initialized [18:32:45] only for batteries that get used as thermal objects [18:33:49]