[13:00:32] NASSP Logging has been started by n7275 [13:00:34] good morning [13:04:41] hey [13:49:43] Hey n7275 didnñt saw you [13:49:50] *didn´t [13:53:29] n7275, TurryBoeing had a bit of trouble with manual SPS engine shutdown during his SPS-5 burn [13:53:44] the idea is to add keyboard commands to switch down he DV switch in the CSM [13:53:59] we thought the * and - buttons on the numpad for the two switches [13:54:53] how does that sound? [14:03:39] that sounds good. those can be very hard to hit in a pinch [14:05:33] I'll also ask Ryan about it, but I think that would be a good feature [14:49:17] I'm thinking about writing a small python utility for automaticially editing scenerio files. [15:43:40] *** [15:43:47] Uploaded file: https://uploads.kiwiirc.com/files/fce0f82ef5880a4327b391f7c075675c/CMC%20Clock%20analysis.zip [16:18:55] n7275, I wanted an automatic scenario creator to set up real simulation scenarios [16:19:04] but we have a lot of things in the scenarios... [16:19:10] and its format seems to always be changing [16:49:00] indy91, something like this could help with that https://gist.github.com/n7275/f85a3eb06981715fc9171ab3fce7805d [16:56:20] right, to calculate some initial conditions for the tanks [17:28:19] I'm pleasantly surprised how well my fuel cell cooling code works with the new substances [17:53:41] the new substances is causing suit compressor alarms, right? [17:53:54] only just updated my NASSP with it [17:54:05] in old mission scenarios [18:06:48] o2 flow high. but only for a few seconds [18:16:45] hmm [18:16:59] in the Apollo 11 MCC-2 scenario the temperature is skyrocketing [18:23:04] maybe it recovers, I have to check [18:23:15] but after 90 seconds the cabin temp reaches 120°F [18:24:05] ah yes [18:24:07] it does recover [18:24:18] at 180 seconds it comes below 120°F again [18:24:22] just hadn't seen this yet [18:24:26] I'm sure it's all fine [18:25:44] going to switch branches. [18:26:14] it's probably just everything equalizing in old scenarios [18:27:16] I can take 120°F for 2 minutes :D [18:27:31] yeah, but I don't remember it being that bad [18:28:04] it's so quick. both going up and then down [18:28:17] I'm sure after 5 minutes it's all back to normal [18:28:38] I'm not to worried as long as it doesn't trigger anything in the crew health simulation [18:28:41] too* [18:32:03] doesn't cook the crew by the looks of it. it takes a little under 20 minutes in that sceneriao to fully stabilize. [18:32:29] any idea why it happens? [18:33:28] every substance in the system has to adjust slightly to a new boiling point/phase equilibrium [18:37:16] "Apollo 11, Houston, stand by for a quick physics update. It might get a bit heated for a moment" [18:37:36] haha [18:39:06] thewonderidiot, TurryBoeing had an issue with standby mode. I don't think he did anything wrong. When he came out of standby mode he didn't have a flashing V37, but the display in P06 instead. And the clock didn't get updated. [18:40:10] at 7 days 04:38:22 in his stream, if you want to check. [20:03:05] indy91: Taking a look at that standby issue. Any idea if he reloaded Orbiter with the computer in standby? [20:14:21] possible, we would need to check in the video [20:14:40] he was only in standby for 1:15h [20:15:03] he realized he went too early in standby and would be above the limit [20:15:07] so he went back out of it [20:15:43] I'm looking into the save load code to see if there's something we missed to restore [20:16:18] sounds like a possible issue. I would think the Virtual AGC code should be good [20:17:36] sadly you can't see the simulation time in the stream [20:18:28] ah you can in some parts [20:19:09] I would love to have telemetry [20:19:20] Maybe for his next run [20:20:14] he has not reloaded [20:20:28] right now his simulation is running for 70,000 seconds [20:20:38] almost 20 hours [20:20:48] I wonder if that might even be a possible issue [20:20:58] some Virtual AGC variable overflowing? [20:21:16] that somehow has caused no serious issues... [20:21:40] CycleCounter maybe. It increments each timestep, let me check [20:21:51] with time acceleration we of course have done 20+ hours many times [20:22:03] True [20:22:33] It's a 64 bit counter, no issue there. 32 bit would be around 14 hours. [20:22:42] yeah, was just looking at that comment [20:23:06] So 64 bit goes well above the actual mean time between failure of the AGC. [20:23:12] of course always a possible issue with the Virtual AGC, as Ron surely has never tested a full mission worth of computer cycles [20:23:33] Exactly, The CycleCounter is not persisted on save IIRC [20:24:01] https://github.com/orbiternassp/NASSP/blob/c8d2cee4977982b81a31c4ede0c18f537b34c349/Orbitersdk/samples/ProjectApollo/src_sys/apolloguidance.cpp#L529 [20:25:47] oh nice, he has a scenario in standby [20:26:07] and I can replicate the issue there [20:26:46] scenario 00008 [20:26:54] is when he just went into standby, I think [20:27:10] Does he uplload them somewhere? [20:27:26] Oh [20:27:31] nevermind he posted them here [20:28:38] Link is no longer active though [20:28:41] I think the AGC should have been doing a restart when it didn't [20:28:46] ok I'll post it [20:30:33] must have been saved just after going to standby as the clock error is only like 2 minutes [20:30:52] if I go out of standby and then do a V69 then the clock seems to update [20:31:05] might have been a trick that Mike showed me at some point [20:32:49] so V69 before resetting or going to P00 [20:33:57] V69 and coming out of standby both cause a GOJAM [20:34:50] at least it's a simple procedure, even if we don't know yet why standby doesn't do that on its own [20:35:14] it has worked on the previous several times he went to standby of course [20:37:41] REDOCTR didn't increment coming out of standby so somhow the GOJAM was bypassed. [21:42:05] night! [21:44:44] His standby AGC has a pending downrupt. This is getting serviced immediately coming out of standby [21:47:51] thewonderidiot: yaAGC only performs GOJAM actions entering standby, so if a interrupt is requested by the downlink after GOJAM actions were performed the AGC never jumps to 04000. I believe this behaviour is incorrect and can be prevented by doing the GOJAM after coming out of standby [21:48:38] I think this has gone undetected for so long because originally yaAGC came out of standby with interrupts inhibited, this was changed not too long ago as you may remember. [22:38:59] Hello hello [22:41:08] So, any conclussion? [22:42:47] Should I apply to betatester jobs? :D [22:44:05] I understand that if I have this issue again, a V69 after powering up again or going to P00 after the power up [23:21:17] Hey, I'm erring towards a V36 to be sure, have to look what else you would need to recover [23:21:26] What have you done now? Only reset the clock? [23:35:49] TurryBoeing: A V36 would do a fresh start and rest some flagwords. If you're not busy I still would like you to do a V69 to be sure all the initialization done normally is run. [23:36:02] So V69, reset, go to P0) [23:36:16] s/0)/00 [23:36:56] @Thym [23:36:59] You will get a hardware restart but I ensure you no other side effects will happen [23:37:19] @Thymo Hello We just did a clock uplink [23:37:25] Using RTCC MFD [23:38:02] Uplinks -> Time Increment [23:38:32] Cool. There probably is nothing wrong, but I would still like you to do a V69 so that your AGC is in a known good state again. [23:38:33] Now the computer is on P00 and the rest of the G&C is down [23:38:57] Don´t know if you are watching [23:39:04] I am [23:42:14] Just a V69 now, right? [23:42:29] Yeah, V69, then just go to P00 and hit reset [23:42:54] Just want to make sure that the flags normally set by the AGC out of standby are actually set. [23:43:03] Because they weren't when you came out of standby. [23:43:35] V69 runs the same code, but only by causing a hardware restart (via an infinite loop) instead of standby [04:48:09] .ask rcflyinghokie are these changes still necessary? https://github.com/orbiternassp/NASSP/commit/d3bc4c30#diff-21ef0a0cc57366752e32325a5adfba2c4a0deb5aa70982fe64ebfcc2679bb525R995-R997 [10:50:54] Good morning, just took the computer aut of standby [10:50:58] Everything normal [14:01:49] hey [14:02:05] hey [14:12:05] I'm looking at the Star.bin file [14:12:17] that's where Orbiter has all the stars stored that are visible in the sky [14:12:37] I would like to move some stars to where they were in 1970 [14:12:39] instead of 2000 [14:12:58] the we wouldn't rely on the markers so much [14:13:12] and the new reticle works better with the stars themselves than the markers [14:14:45] the file is not in a text editable format sadly [14:18:37] we do have the orbiter source to look at how it is loaded though [14:18:46] yep, just did that [14:18:50] I can decode the file now [14:19:11] next I have to figure out how to write it again in the exact same format [14:20:25] I'm going to have to brush up on my star knowledge... [14:21:12] maybe I should first check if martins has provided some tools for this [14:25:17] really strange that he chose to save this as binary, when almost everything else is loaded from ascii config files [14:26:32] it's over 100k stars [14:26:38] maybe more efficient for loading? [14:27:29] oh. yeah that makes sense [14:31:02] well, my output file has the same size as the Star.bin file \o/ [14:41:23] Wait a sec... I think that X-Plane has a similar file my 2 cents [14:41:30] *(my 2 cents) [14:41:53] Maybe if that is the case the file comes from some database where you can get information? [14:42:21] possible [14:42:34] Nah, discard that [14:43:14] X-Plane uses a 849 kb file wich is called earth_astro.dat [14:43:21] May not be the same... [14:43:57] ok I read the Star.bin file, write the data to a text file and then "recompile" it [14:44:58] let's see if Orbiter likes reading that file... [14:45:40] I think it does [14:54:16] so as a test, which star has a large proper motion [14:55:27] oh [14:55:34] "Orbiter uses the Hipparcos star catalogue with more [14:55:36] than 10^5 entries." [14:57:43] but did he create that file himself or not [15:00:32] Will have to check with The Architect, in The Source [15:23:23] I read that as "10^15" for some reason. I was like wow that's a few... [15:27:26] ok, changed the coordinates of Sirius [15:30:28] and it's not perfectly centered [15:30:48] oh, the marker is probably different from the Colossus nav star coordinates [15:30:54] might have used Apollo 14 as reference [15:31:06] January 1971 is nice and centered for the Apollo missions [15:42:39] no I used the year before [15:52:32] I've been infected with coordinate system confusion again [15:57:37] Is it better than infeted with timezone confusion? [15:57:46] *infected [15:58:21] not really [16:03:29] the way I calculated the marker positions and also the star positions isn't ideal [16:03:40] but at least I know how to make them agree now [16:07:42] markers can be displayed in celestrial or ecliptic coordinates [16:08:23] but for celestial Orbiter uses a fixed Earth axial tilt of 23.45° [16:09:27] which used to be the Earth axial tilt in Orbiter 2006 [16:09:42] and is configurable in the config file [16:09:48] but that value for the markers is hardcoded... [16:09:53] so I better use ecliptic for that [16:10:11] Yeah [16:10:12] one coordinate conversion less :D [16:11:01] now the only assumption that is done is that the conversion from AGC coordinates (for the star vectors) to Orbiter J2000 ecliptic is correct [16:11:28] same conversion in reverse is done for state vector uplinks [16:52:28] indy91, do you know any context about https://github.com/orbiternassp/NASSP/commit/d3bc4c30#diff-21ef0a0cc57366752e32325a5adfba2c4a0deb5aa70982fe64ebfcc2679bb525R995-R997. [16:52:47] it's probably a question for Ryan [16:54:09] I can't remember [16:55:20] I think that is just a little bit too early for an IRC log [16:58:54] seems to me like you could have the same effect by setting the min temp to 0 on systems where it causes issues [17:05:39] right [17:06:12] I'm looking at the visible magnitude of the navigation stars [17:06:26] I kind of want to change them, too, based on what the GSOP says [17:06:41] I'm seeing some bigger differences [17:06:59] so have to check first if that is a different kind of magnitude or if the star really changed over time [17:07:08] like Theta Eridani [17:07:13] 2.88 on Wikipedia [17:07:19] 3.4 in the GSOP [17:42:58] Just completed the last O2 stratification test [17:43:16] Got again the CYO PRESS light, can manage it [17:43:21] *CRYO [17:43:32] But in case you want to review the data: [17:44:02] ---Will send you a picture in 5 minutes [18:00:16] cryo pressure behaves nicely, it will be normal soon I am sure [18:01:07] Me too [18:01:21] But the light is Annoying [18:02:52] Uploaded file: https://uploads.kiwiirc.com/files/0c0b85344d2137c6ec88ce34ccb2ef26/photo_2021-11-15_19-02-24.jpg [18:03:17] Dont know if you can see it there, but some finished data from Apollo 7 :) [18:03:53] Sorry for my bad letter, I was a bad student [18:05:14] morning! [18:06:51] hey Mike [18:06:52] Hey sir [18:07:18] Pressure is not decreasing :C got O2 heaters and fans to off [18:07:27] Do I do another FC purge? [18:07:39] This makes me anxious :D [18:15:45] Light OFF! [18:26:21] hey Mike [18:26:44] thewonderidiot, we had some messages for you yesterday, TurryBoeing had a bit of standby mode trouble [18:29:40] oh? [18:29:50] *cue Mike hiding* [18:30:17] Thymo mostly figured it out I think [18:30:29] "His standby AGC has a pending downrupt. This is getting serviced immediately coming out of standby" [18:30:35] "yaAGC only performs GOJAM actions entering standby, so if a interrupt is requested by the downlink after GOJAM actions were performed the AGC never jumps to 04000. I believe this behaviour is incorrect and can be prevented by doing the GOJAM after coming out of standby" [18:30:41] " I think this has gone undetected for so long because originally yaAGC came out of standby with interrupts inhibited, this was changed not too long ago as you may remember." [18:31:03] n7275 many of those have been adjusted further or replaced since, any thing in particular you were eyeing? [18:32:25] rcflyinghokie, also something for you. TurryBoeing had trouble doing the manual engine cutoff on the Apollo 7 SPS-5 burn. [18:32:44] especially in the VC switching off both DV switches at the right time is tricky [18:33:03] Hmm I have seldom spent time in the VC [18:33:08] so our idea was, now that Orbiter has no control anymore over the engine, use the * and - keys [18:33:20] to switch the two DV switches to off [18:33:29] That seems like a reasonable work around [18:33:31] it's nearly the same issue on the 2D panel [18:33:37] true [18:34:14] all you need is two fingers to switch it off [18:34:23] what would be better though would be a solution to operate 2 switches simultaneously, this would also be useful technically for the redundant jettison and sep switches [18:34:41] that would even be easier [18:35:07] like maybe a keypress+click? [18:35:30] for what [18:36:23] * key on the numpad is standard Orbiter control for cutoff [18:36:35] - key technically fires the retro thrusters [18:36:40] but also stops the main engine [18:36:54] so if it was only one keypress for the 2 DV switches to off, then it would simply be * [18:37:55] and I agree, there isn't much of a point to do the two switches individually [18:38:13] the button would be for precisely timed manual engine cutoff [18:38:25] doesn't matter if only one of the switches was even up [18:40:09] oh now I understand you. You were thinking for the jettison and sep switches. Click plus some keypress on one of the switches then actually uses both switches? [18:41:01] for the DV switches it should simply be a keyboard button. In the VC you might not even be looking at those switches, but zoomed in at the FDAI or so [18:41:28] so you would then move the mouse, find the switch and press it. Not good for split second cutoff decision [18:47:28] yeah thats what I was getting at [18:50:03] I can look what kind of button is still available for that [18:50:48] using * for the DV switches would be in the spirit of Orbiter [18:50:58] just like we basically use standard Orbiter controls for the DPS [18:51:09] except using our own code [18:51:33] maybe ALT [18:51:49] ALT + tower jettison [18:51:58] and it would use both switches? [18:52:18] although that is not so easy to set up... [18:53:23] if nobody knows a reason why we should have separate buttons for this I will just make * on numpad switch down both DV switches. And not * and - doing them separately. Sounds good? [18:53:46] because for testing I had them separate [19:01:32] rcflyinghokie, I need it for the fuel cell condenser regen heat exchanger. you can get the same effect as the commented-out code by setting the min temp to 0 [19:02:04] indy91 I cant see a reason not to right now [19:02:44] one button it is :D [19:02:45] n7275 oh that section...yeah that was commented out before I ever got into the code, the reason its commented back out is I was testing it prior to that commit [19:03:01] Last time I messed with it it was unstable [19:03:50] please feel free to test it though now [19:04:57] I will. [19:07:01] rcflyinghokie, I am playing god and try to move some stars [19:07:18] the Stars.bin file contains all the stars that Orbiter can show [19:07:22] Thymo, I didn't guard against that case because all of the circuitry related to interrupts in the AGC is powered off in standby -- so it's impossible for a downrupt to be "requested" in standby [19:07:24] some of them have moved a bunch [19:07:29] since the 60s [19:07:54] thewonderidiot, sounds like something needs to be disabled in NASSP code then [19:07:55] oh are you trying to move them to the proper places so we dont "need" our markers? [19:08:30] yes, or at least so that marker and star show the same thing [19:08:37] oooooooo [19:08:38] right now using the markers is more accurate [19:08:41] that would be awesome [19:09:29] I've decoded the binary file, wrote the data to text file and "compile" the data again [19:09:45] and now I can, in between those steps, manipulate the star positions [19:10:37] have to find the stars individually though, the file only has declination, right ascension and magnitude [19:11:05] I'm using the AGC star unit vectors for Apollo 11-13 [19:11:11] are we going to need a different star file for each year to match the different AGC star tables? [19:11:47] I think using the data from the middle of the Apollo program is good enough [19:12:03] there just is a bit of movement for some stars to the year 2000 [19:12:12] so 30 years [19:12:32] so a few years only isn't a big deal [19:12:53] even the 30 years is ok for most stars [19:13:01] yeah the markers are not different mission to mission as it is anyways [19:13:06] yep [19:13:07] and results are favorable [19:13:14] my main issue is the new reticle [19:13:19] it works great with stars [19:13:23] not so great with markers [19:13:40] I have issues with the AOT spiral and markers as well [19:13:47] my P52s have become worse and I am trying to find something to blame other than myself [19:13:53] because you have to "hit" the center of the marker with it [19:14:02] haha [19:14:11] I have a lot more 00001's now [19:15:36] I also noticed an issue with the markers themselves [19:15:52] actually an issue with Orbiter itself [19:16:27] it has a hardcoded number for the Earth axial tilt [19:16:35] for displaying markers [19:16:58] but that number isn't what Orbiter uses anymore itself [19:17:14] but I have two coordinate systems to choose from for markers [19:17:18] ecliptic will work better [19:17:36] so hopefully overall accuracy improvement [19:18:13] What I don't like is that I would be adding a file (the Stars.bin) that overwrites something from Orbiter [19:18:35] So should I release that bin file separately? [19:18:51] pretty sure the file name is hardcoded in Orbiter [19:19:08] so we can't tell it to use a special NASSP file just for the NASSP solar system [19:20:34] yeah a separate release would probably be wise since it would effect any orbiter mods [19:21:07] I dont know which other mods use celestial navigation though lol [19:21:17] I'm only changing the AGC navigation stars [19:21:27] but I could try to use a whole old star catalog instead [19:21:39] those were a lot smaller though [19:21:47] that Stars.bin file contains 100k stars haha [19:21:56] I say it could be worth it since marks were taken on other stars not on the nav star list as well [19:22:06] yeah [19:22:14] some of which I have loaded in the RTCC [19:22:16] even in that first P23 I am troubleshooting, the third star is not a known nav star [19:22:41] (the forum post re Apollo 15) [19:23:08] https://en.wikipedia.org/wiki/Catalogues_of_Fundamental_Stars MIT at least was using the FK4 catalog [19:25:02] I'll research that a bit [19:25:21] I haven't found the RTCC star catalog either, but it might be derived from that [19:25:31] not the full one at least [19:25:35] seems reasonable [19:25:40] why redo the work [19:26:30] the replacement Stars.bin will be a lot smaller, but I don't think anybody uses graphics settings where you see 100,000 stars [19:27:16] I mean I have mine maxed out ;) [19:29:12] I'll not manually replace a few 100 star coordinates haha. I can only do the whole thing from scratch, using a lot fewer stars in the old catalogs, or only replace a few of the stars in the current file with 100k stars [19:29:51] which settings do you use? [19:29:53] thewonderidiot: I can understand that. How do you want to go about this? Fix it in yaAGC so it gets the AGC in the proper state coming out of standby? According to the documentation what we are doing is not invalid, of course we can change NASSP to check for Standby before touching anything inside agc_t but to me that's more of a workaround than a solution. [19:30:45] is creating downrupts in NASSP code already a workaround? [19:31:11] looking at the current code there is really no handling for standby mode. Even if the AGC is off and the PCM is on it will generate downrupts... [19:31:18] in our PCM code [19:32:48] I think it would be better to not generate interrupts if the computer is in standby... the relevant yaAGC code is a bunch of spaghetti and moving it around without breaking it would be a lot more work [19:33:36] we have a function [19:33:37] void ApolloGuidance::GenerateDownrupt(){ [19:33:38] vagc.InterruptRequests[8] = 1; [19:33:39] } [19:33:46] that gets call to do this [19:34:05] maybe that should just check on standby mode and if the AGC has power? [19:34:22] yeah that would be the best, I think [19:34:30] Everything involving telemetry in NASSP is a mess right now. I plan on completely rewriting it at some point. [19:35:15] hmm, if I just do that, it still gets AGC data for telemetry [19:35:23] but maybe that is realistic? [19:35:28] Would it send some garbage? [19:35:32] if AGC is in standby [19:35:45] What do you mean exactly with "still gets data"? [19:35:52] When I tried it I got all zeroes [19:36:07] PCM code still calls agc.GetOutputChannel [19:36:58] In standby the AGC doesn't do anything so nothing gets written to the PCM [19:38:59] it could be 0 [19:39:07] PCM is sending out something still at least [19:39:27] but if telemetry is still running with the AGC off or in standby, something would still be send as AGC data [19:39:30] even if it is all zeros [19:39:32] right? [19:41:51] It will still read whatever is in that channel but the AGC doesn't update it so yes, that data is meaningless. [19:41:59] yeah that's what I mean [19:42:09] so should be good enough to add a check in that downrupt function [19:42:23] definitely the easiest solution [19:43:11] Yeah, I guess I can change the downrupt stuff. I'll make a quick scan for anything else being done to yaAGC while it is in standby. [19:43:39] So basically agc_t.Standby is somewhat becoming a mutex now :P [19:44:26] that downrupt function is called a lot of times [19:44:36] I don't like it checking IsPowered() [19:44:39] not very efficient [19:45:08] maybe [19:45:51] if (vagc.Standby == 1 || vagc.CycleCounter == 0) return; [19:46:02] the second case should only be if the power is off [19:46:12] something like this [19:59:45] what happens there is more of a PCM implementation question I think -- the AGC has to manually pulse out both 1s and 0s, so if the circuit is off, neither 1s nor 0s get sent to the PCM [20:00:05] I have no idea how a real PCM would behave in such a situation [20:10:09] output shift register in the PCM might just have the same data as on the telemetry word before [20:19:03] agc_engine isn't being run if it's not powered so that wouldn't work. [20:19:08] In the timestep we check for IsPowered and if it's not we do our own GOJAM [20:19:10] As yaAGC doesn't export a method to do it [20:20:15] The PCM right now also is started when the AGC first starts, that's incorrect too. [20:21:06] hmm, I don't think that is right [20:21:14] if (!IsPowered()) [20:21:25] and at the end of that it does [20:21:26] / We should issue telemetry though. [20:21:27] sat->pcm.TimeStep(simt); [20:21:43] so if the AGC has no power it does a normal timestep with a normal timestep length there [20:21:55] if it is powered the PCM timestep is called within the AGC cycles [20:22:09] in CSMcomputer::agcTimestep [20:22:11] Yeah, it's good once its started but the sockets aren't opened until the AGC breakers are closed for the first time [20:22:17] oooh, I see [20:23:42] but it does still call PCM::TimeStep with the AGC off [20:23:55] and that calls the code generating the telemetry [20:24:10] Yeah, but there's no way to read it without those sockets open [20:24:16] yeah [20:24:20] just thinking about the downrupts [20:24:26] I think those are generated in any case [20:24:33] Yep [20:25:05] just not some stuff in perform_io() or so [20:26:43] rcflyinghokie, another idea for the star catalog. I use the one that Orbiter is currently using and account for 30 years of proper motion [20:27:14] the star catalog has that data [20:27:27] the drift [20:27:39] ? [20:28:01] which would be less invasive? [20:28:13] As I think the accuracy differences for our purposes will be negligible [20:28:17] well I could use the whole 100k stars then [20:28:21] ah true [20:28:29] if I use an earlier star catalog it's always going to be a lot smaller [20:28:36] that's the main advantage [20:29:33]