[15:32:45] NASSP Logging has been started by n7275 [15:32:47] morning [15:38:04] hey [15:54:50] I have pushed my ATCA update, but holding off on the ascent stage center of gravity a bit longer [15:55:02] it's just a major change I want to get right [21:28:38] night! [13:59:38] good afternoon [14:12:38] morning :) [14:19:32] my computer tricked me [14:19:57] I ran my monitor at 144Hz, but wanted to test 60, so I set Orbiter to 60 [14:20:01] but it was still 144 [14:23:18] for some reason I thought I had fixed the issue with LM PGNS minimum impulse where the LGC switches a thruster on and then off within a single timestep, so that the thruster is never switched on at all [14:23:41] but I didn't change that at all and didn't notice running 144 Hz [14:24:00] before the issue vanishes once the timestep is shorter than 14ms pulse the LGC is sending [14:24:06] because* [14:24:22] I didnt even think about refresh rates in that context [14:28:35] I already tried and failed today to fix that issue haha [14:28:46] because you can in theory add some logic that sees that [14:30:09] PGNS switching the same thruster on and off before it actually gets processed by an ATCA timestep [14:32:11] oh btw, I had already pushed my ATCA update [14:32:21] shouldn't be a big difference you are noticing in AGS mode [14:32:44] however, I haven't pushed yet a small update that makes the ATCA behavior mission speicifc [14:33:36] that you would probably notice for anything under AGS control. Especially pulse mode. I think that only fired the RCS 1.5x per second instead of 4.3x times in LM-4 and later [14:33:52] have you ever seen that 1.5x rate in any Apollo 9 document? [14:35:22] I have not, but I havent looked for it either [14:36:04] I am approaching docked DPS in my run through though, so its only a matter of time before AGS stuff is visited [14:37:06] I haven't pushed yet the ascent stage CG update [14:37:30] still thinking about it, if there is any problem at a lower framerate [14:45:25] would using 60 vs 144 cause issues elsewhere? [14:47:03] generally no [14:47:19] there was one bug that Alex found because he ran unlimited, without VSync [14:47:34] what was that... [14:47:46] aha [14:47:47] https://github.com/orbiternassp/NASSP/issues/545 [14:50:33] 144 Hz is definitely better than 60, because it can resolve 100% of the 14ms RCS commands from the AGC [14:51:10] at 60 you are gonig to loose some RCS commands of these minimum duration [14:51:12] about 16% [14:53:00] mostly noticable during pulse mode [14:53:11] the PGNS one in this case [14:53:56] well I am stuck on 60Hz lol [14:54:14] as will be most people [14:54:45] I was just switching to 144 for a while, usually I am testing at 60, at least if my computer isn't trcking me about it [14:54:49] tricking* [14:58:55] haha lies! deception! [15:26:33] so regarding the RCS flags, looks like the TCA ones are back but the ACA ones are still missing [15:26:45] same logic problem perhaps? [15:27:06] oh never mind [15:27:08] hmm, not sure what you mean [15:27:18] I paused orbiter somehow [15:27:25] no wonder they didnt flag [15:27:29] yeah haha [15:30:01] ok so 3 times during this rcs testing, "quad flags and TCA warning lt on" shows up on the checklist [15:30:12] I thought the MA popped back on at each of these points [15:30:31] unless the checklist means they are still on, which really seems pointless [15:33:17] I guess if you reset the flags they can be quickly on again [15:35:47] hmm but resetting them is further down [15:35:54] in the procedure at least [15:36:26] is that from the actual checklist? [15:38:22] well the apollo 12 LM activation checklist [15:38:33] ok, let me check [15:39:33] pdf pg 32 in the 12 lm act ck [15:39:50] back in a bit [15:41:01] the Apollo 13 LM Activation Checklist just says "QUAD Flags - Red & RCS TCA Lt - on will occur during cold fire checks" at the top of the RCS checkout procedure and then doesn't mention it again [15:41:23] so I am pretty sure it just means, the alarm and red flags can and will occur during any of the steps [15:41:38] once you have all red flags there shouldn't be another master alarm, pretty sure [16:44:42] ok just double checking [16:57:08] hmm random ctd [16:58:19] happened when I tried to display the mcc pad [16:58:40] fun [16:59:02] what dll is it blaming? [16:59:08] I dont know [16:59:15] I didnt have it on a debugger [17:01:34] I don't have random CTDs often, but occasionally [17:01:40] never really able to debug them [17:02:06] I have suspected for a long time that something with the PAD displays is up, but no idea what. Didn't have any problems with it really during my last few missions [17:02:24] yeah I havent at all [17:03:16] I'll make up for it with a pretty plot [17:03:18] https://i.imgur.com/YWhZTlq.png [17:03:38] data taken directly from the LGC [17:04:13] that's how much the DAP is thinking how large the angular acceleration is without RCS firing [17:04:38] padload is 6.25° in pitch [17:04:40] blue is pitch [17:04:51] actual is about 7.6 at liftoff [17:05:29] I cut off when pitch reached 0, as the logging I set up couldn't handle negative numbers [17:06:08] every iteration of Excel has made setting this up more complicated [17:06:46] oh excel woes [17:07:10] what is orange? [17:07:35] same in roll [17:07:40] ok [17:07:51] so the padload doesnt quite agree with the actual [17:08:06] mainly because I modelled LM-7 [17:08:15] actually, have some data for that [17:08:41] 7 is aquarius, is it not? [17:09:31] so we wouldnt have any data of the LM by itself [17:09:48] https://i.imgur.com/Z1KHcXC.png [17:09:56] oh yeah, this is preflight estimate [17:10:01] look at the numbers on the right [17:10:06] pitch and roll moment offset [17:10:21] seem to agree quite close with this ascent data I generated [17:10:24] any idea of Aquarius' padloading for this? [17:10:28] yes [17:10:49] but yeah that data does seem to match your plot [17:10:57] 7.63 and 0.57 [17:11:03] I smell a plot with these overlayed lol [17:11:44] LM-7 definitely seems to be on the larger side for pitch compared to other LMs [17:11:57] maybe I should use data for a more average LM [17:12:08] J-type mission LMs seem to be in the range of 5° [17:12:13] most are 6, some 7 [17:12:36] Apollo 12 is the winner [17:12:42] at least when it comes to the padload [17:12:47] 7.97°/s^2 [17:12:58] so I could have used even worse [17:13:09] I think I'm too lazy too switch to another LM [17:13:13] haha [17:13:27] oh, getting consistent CTD [17:13:34] I like that better [17:13:40] it happens on that cold fire scn I sent you even [17:14:37] whenever you look at the PAD from MCC? [17:14:47] and just loaded it again no ctd [17:15:28] and again no ctd... [17:15:33] well so much for reproducing it [17:15:40] 3 in a row it did [17:16:07] and that was when you look at the PAD [17:16:13] which PAD? [17:16:25] it was a block data [17:16:30] yeah when I redisplayed messages [17:17:46] iirc Block Data was the main offender for any random MCC CTD I ever had [17:18:07] I should switch everything in the MCC to use sprintf_s instead of sprintf [17:18:17] that would get a hard CTD whenever something memory unsafe is done [17:18:29] that could be useful [17:18:40] especially for this case [17:21:32] did you know I added the feature to the MCC that it writes all PADs from the current session to file? [17:21:37] MCCPreAdvisoryData.log in the main Orbiter folder [17:21:51] can you put the Block Data in a pastebin or so? [17:22:09] I want to take a look at it [17:22:19] I might already have an idea what is unsafe there [17:22:46] yeah one sec [17:23:12] uhh [17:23:21] its a DOI P30 pad [17:23:38] hmm [17:23:46] do you have PAD auto show disabled? [17:23:56] no [17:24:15] I guess you crashed before it could write to that file [17:24:29] Why would I have a P30 DOI though lol [17:24:36] https://pastebin.com/zDMczkUq [17:24:49] ohh [17:24:59] Apollo 10? [17:24:59] I bet it was from loading another mission [17:25:04] I am flying 9 [17:25:09] I know [17:25:18] but that DOI looks like Apollo 10 [17:25:32] maybe you opened a scenario there not long ago? [17:25:38] possibly [17:25:53] if I decrease and increase state it should write the correct one though [17:25:54] unless PAD auto show is disabled it should write new data to that file tohugh [17:26:03] or reset state, yes [17:26:13] I would at least think so, otherwise there is a bug [17:27:43] and you know NASSP has no bugs [17:27:51] just like AGC code [17:27:55] yeah that printed block data [17:28:29] https://pastebin.com/8X0D8rhe [17:29:13] hmm [17:31:10] what is the last thing I said? [17:31:41] hmm [17:31:50] *that is what you said* [17:32:01] ok thanks, than it missed a bunch [17:32:05] the whole PAD has 538 characters [17:32:10] that should be safe [17:32:13] But maybe I shouldn't print a character array to itself [17:32:17] probably should just switch to std::string anyway [17:32:22] I'll investigate that, hopefully it doesn't hinder your progress [17:32:26] it should be random and rare enough that it won't always happen [17:32:53] yeah I save before and after any major procedure or event [17:32:58] also, for block data that isn't filled out, there is no weather entry, so the scenario safes "blank" [17:33:00] saves* [17:33:01] so I am not worried about the progress part [17:33:17] maybe reading blank from scenario is also a problem [17:33:38] back in a bit [17:57:08] isnt cycling the CWEA breaker supposed to reset the TCA flip flops? [17:59:46] yes [17:59:53] occasionally it doesn't work for me either [17:59:57] and I don't know why [18:01:09] interesting [18:01:46] have to investigate that [18:01:52] I thought it worked before [18:02:14] it worked like this before. Usually works right, but resetting sometimes doesn't work for some reason [18:02:58] morning! [18:03:26] hey Mike [18:04:02] what's up? [18:04:17] https://i.imgur.com/YWhZTlq.png [18:04:33] made a nice plot of a DAP related erasable during powered ascent [18:04:39] or two rather [18:04:45] oh nice [18:04:48] blue for pitch and orange for roll [18:05:10] pitch has 6.25°/s^2 as the padloaded initial guess [18:05:22] but with my LM-7 data that is a bit off [18:05:33] actually, the padload document that we have for Apollo 11 has 7.8 [18:05:36] but we changed it [18:05:42] I was at first confused why [18:05:48] but it's from Don's simulation [18:06:02] oh huh [18:06:07] and the DAP postflight analysis document confirms the values in the simulation :D [18:06:23] so that was a good change then [18:06:43] interesting, so do you think Don changed it to match the flight, or do you think our padload document isn't final? [18:08:53] DAP postflight analysis document confirms that the values in Don's simulation were used on the actual flight [18:09:10] and not the ones in the padload document [18:10:23] I doubt they updated this during the mission [18:10:38] but it could be a quite late change, based on updated mass data [18:11:02] huh, that's super interesting [18:11:18] which padload is this? something something AOSQ or AOSR? [18:12:22] yep [18:12:31] IGNAOSQ and IGNAOSR [18:13:01] yeah the first page of that padload packet says it's from the FSRR on 7/1/69 [18:13:03] so, very late change [18:13:18] padload packet? [18:13:20] for the sim? [18:13:31] http://www.ibiblio.org/apollo/Documents/padload_11_lm.pdf [18:13:37] the one I scanned at Don's place [18:13:39] oooh [18:13:43] of course [18:14:02] I knew we had that [18:14:04] at one point [18:14:08] hahaha [18:14:39] oh this already has the 6.25 [18:14:42] yep [18:14:46] and it's the older one from the LM data book that has the 7.8 [18:14:59] yeah, I'd definitely believe whatever is in the packet from the FSRR [18:28:09] so the set flip flop is what energizes the flag to go to fail, am I reading that correctly? [18:29:39] if so, I am having a hard time figuring out what allows it to reset [18:31:58] if TCA breakers are put in and CWEA is reset, they all reset [18:33:03] that's how it should work [18:34:36] right, but with the breakers out, what is allowing those flip flops to reset logically [18:34:57] still the CWEA, but the condition for fail are still there [18:36:26] but what do I know, I implemented it in such a way that it constantly causes issues... [18:37:24] well I guess the thruster isolation valves being closed also reset the flip flops [18:37:33] when you manually switch a thruster pair to off [18:37:49] so close and then open should clear the flag [18:38:34] I have a special Reset function for the case where the CWEA breaker is cycled [18:38:54] maybe that should also be called when you switch the thruster pair off and on [18:40:44] of course it should [18:40:57] there is even a path to the pulse counter from the thruster pair switch [18:43:45] yeah I am just trying to wrap my head around the TCA CWEA logic [18:44:09] when did you have an issue? Was it cycling the breaker that didn't reset the flags? [18:44:59] yeah, but this was also when the TCA breakers were open so I dont know if that was correct behavior or not [18:45:29] hmm right [18:45:59] I guess if the conditions persists to fire the RCS but it doesn't the flags might be red again within 0.08 seconds [18:50:22] yeah I just dont know the logic well enough for those [18:50:43] something else though...the radar test for the ldg rdr is not driving the tape meters [18:51:17] ah breakers [18:51:34] they are missing in my checklist now to figure out where they belong [18:53:16] ahh thats why, because I used the 12 checklist, RR test is before LR test, and they are closed in that one [18:54:55] we have that page from the actual checklist I think [18:55:40] lay it on me [18:56:10] https://www.invaluable.com/auction-lot/jim-mcdivitt-262-c-e8a9c98e06 [18:56:23] a bunch of pages there on the left [18:56:44] hmm [18:56:47] wrong auction :D [18:57:06] haha I was going to say I have those [18:58:04] well I don't know where I got it, but I saved the page [18:58:11] https://i.imgur.com/YN6F4AL.jpg [18:58:15] thanks [18:58:55] interesting [18:58:58] hmm [18:59:01] also no mention of the breakers [18:59:02] I think [18:59:30] hmm? It does close the landing radar breaker [18:59:36] but I think this is from after the burn [18:59:47] no [18:59:47] weird [19:00:11] I have another page, SYS-60 and 61, which seems to have the docked DPS burn itself [19:00:55] ah, that isn't page 64 and 65 [19:00:56] it's 55 [19:01:08] SYS-55 with the DPS press [19:01:16] SYS-60 has the burn [19:01:23] and 64 must be a test after the burn [19:01:43] yeah, they are doing another self test [19:01:46] interesting none of the landing radar powerup/test procedures mention those breakers [19:01:55] which ones? [19:02:01] rendezvous radar ones do [19:02:06] the 2 for the alt/rng tapes [19:02:12] tapemeter doesn't need RR breakers [19:02:40] no, RR powerup checklists mention them closed [19:03:17] yet ldg rdr checklists do not, yet they reference the tapes being used [19:03:41] most cases the RR checks are done before LR, so the breakers are still closed from that [19:04:32] ah [19:04:57] so just a procedural difference and having taken parts of checklists from other missions has those breakers still open [19:05:40] exactly [19:06:06] but I am curious that the LR self test procedure both in what you shared and from the AOH do not mention those breakers either [19:06:12] not even so much as a verify [19:06:48] unless there was a CB diagram that was used in 9 that included it that we do not have [19:08:57] sounds likely [19:09:11] we have the complete rendezvous activation checklist [19:10:45] I think CB diagrams hadn't been invented yet [19:11:37] can you link me that checklist? I have the rendezvous checklist but not an activation checklist for 9 [19:12:24] oh, I don't have the rendezvous checklist [19:12:34] or do you mean the rendezvous procedures? [19:12:50] I have the rendezvous procedures [19:12:55] ah [19:13:02] but I dont have a rendezvous activation [19:13:02] I never even found a hint of a rendezvous checklist [19:13:13] I don't have a PDF [19:13:16] let me find the source [19:13:19] thanks [19:13:26] I think I had contacted the owner of the flown one [19:13:37] he got me some pages [19:13:43] but he gave it to a museum [19:14:00] and they put photos of it on flickr or so [19:14:09] ill take what I can get! [19:14:37] ah [19:14:42] my memory hasn't failed me [19:14:43] https://www.flickr.com/photos/sdasmarchives/albums/72157705290322601 [19:17:26] oh that's interesting [19:17:44] that's not the same copy [19:18:09] the person I contacted who has one of these, his copy is slightly different [19:18:16] either not flown, but there could have been two [19:18:26] true [19:18:34] either way this is very helpful I can go back and tweak [19:18:50] I have a few pages in better quality [19:18:55] but only some [19:19:09] in case you need it [19:20:03] im copying all of these right now, they seem to be pretty legible [19:21:54] even that one's LR test has no mention [19:23:11] well they just close those tapemeter breakers early on [19:23:33] RDZ-8 [19:23:44] first the AC breaker and then most of the other breakers in that row [19:23:54] including the DC breaker for the tapemeter [19:27:45] yep thats what i assumed was the case [19:27:50] I just wanted to find out where [19:47:44] thewonderidiot, hey have you tried anything with that pulse ratio modulator circuit yet? [19:47:53] nope sorry [19:47:59] I'll try to get to it tonight [19:51:02] unrelated though, Debbie just finally got the other half of the MIT Museum's AGC back from Draper [19:51:13] I was right, it is indeed S/N 9 from 2TV-1 :) [19:51:32] well I have both versions of the PRM function in the ATCA code, whenever you get to it, we can choose the right one [19:51:34] ah nice [19:51:42] what did Draper want with it? :D [19:52:12] just to display I think haha [19:52:56] I also fell super far down the research rabbit hole and have confirmed that all of the AGC software modification reports existed at least up through the mid-1990s [19:53:11] need to send that info to the air force... [19:54:21] mid 90s, what happened then? [19:54:38] that's the last explicit reference I have to it [19:55:00] the database it was a part of ended up going to CSIAC, who discontinued the public portion of it in 2015 [19:55:20] I hope that them "discontinuing" it does not include destruction of its contents [19:55:39] yeah, hopefully not [19:56:08] it's "project 4" in the BSDS (Baseline Software Data System), which got incorporated into the SLED (Software Lifecycle Empirical Database) [19:57:27] one side effect of this is that I might have to go through the Department of Defense rather than the Air Force... and I feel less good about the possibility of getting anything out of them [19:57:46] but we'll see what the person handling my USAF FOIA request says [19:57:52] right [19:58:48] do we modle the self test values being different between LMs? for example the tape meter displays [19:58:49] I also once tracked down something to the 90s [19:58:54] model* [19:59:07] but sadly it was people working on RTCC stuff passing away [19:59:23] I don't think we do [20:00:13] ok [20:27:23] we are really in need of a LM telemetry tool [20:28:22] need to look into that some time [20:36:10] That would be awesome [20:38:35] would make it much easier logging and plotting that LGC data, or any other LM data [20:38:53] writing to the Orbiter log and then struggling with Excel wasn't ideal :D [20:38:54] man it would be a lifesaver for ECS [20:39:19] debug lines only give you so much to play with at\ a time [20:40:41] I usually just open my own file with fopen() in one of the constructors (like LEMComputer) and fwrite to that [20:41:35] yeah, that works as well [20:42:32] but you never know what data you want and you can't write everything to some file at once [20:43:08] oh and with the ECS, I think telemetry has a bit more than displays, but the values of it (e.g. temperature) are usually limited to the same kind of range like the meters in the LM [20:43:41] so you wouldn't see how much the cabin has heated up beyond 100°F [21:04:57] honestly if its >100 its a problem regardless :P [21:06:06] ok back to displayed values...the values displayed in the LGC during RCS checks shouldnt they match up? [21:07:38] assuming we have the same software as the checklist refers to [21:10:43] mostly, yes [21:10:53] the ACA inputs can vary slightly from mission to mission [21:11:11] the proportional inputs [21:12:07] but everything else should match exactly [21:12:14] anything that doesn't? [21:14:29] testing using that rcs cold fire checklist [21:17:02] I think with the ACA it's a variation with the hardware, it doesn't always reach the extreme ends of the proportional inputs [21:17:23] so you see a difference in the expected value in the checklist between missions [21:18:29] ah I see [21:19:15] also being keyboard limited that would mess with it not seeing soft stops, correct [21:21:20] would you see that with a joystick? [21:21:31] Isn't that just when there is more resistance to your input? [21:21:48] so that you can differenciate between full normal deflection and hardover? [21:22:06] I think theres hardover logic though the computer sees [21:22:20] engaging secondary coils or something? [21:22:37] so first there is out of detent [21:22:45] small deflection, PGNS and AGS get that signal [21:23:15] some bit further are the breakout switches [21:23:19] I think that is what you mean [21:23:28] LGC gets input bits for that [21:23:49] PGNS and AGS pulse mode use those those [21:24:00] hardover is not something the computers see [21:24:14] but that does use the secondary coils of the RCS, yes [21:24:25] with keyboard I have that usually switched off [21:24:54] ACA/4 Jet switch [21:25:30] for the proportional inputs, those have their max values at the soft stops [21:26:31] ok so the LGC readouts shouldnt be any different? [21:27:28] proportional can be different [21:27:36] but not the input bits the LGC gets [21:28:04] ok first part of this test is ACA tro soft stop [21:28:09] to* [21:28:20] which procedure do you use for reference? [21:28:25]