[16:14:26] NASSP Logging has been started by thewonderidiot [16:14:28] morning! [16:21:16] hey Mike [16:22:43] what's up? [16:24:21] playing around with some lunar trajectories haha [16:27:33] nice :D [16:28:25] most simple version of a three impulse LOI [16:29:11] mission to Tycho, free return, because enforcing the non-free return constraints is more difficult than free return... [16:29:28] 3940 ft/s for the three LOIs combined [16:29:46] which is definitely nicer than anything you could do with the normal profile, but still high [16:30:10] high inclination orbit, that's what you get with three impulse LOI [16:30:46] all the additional DV savings will come from relaxing free return [14:55:52] nice Internet failure there last evening :D [16:07:14] morning! [16:07:43] haha what happened? [16:55:42] hey Mike [16:57:00] ah nothing unusual, it just decided for me when I signed off yesterday haha [16:57:12] hehehe [17:12:29] so, I didn't know so much of the Apollo Telescope Mount electronics was just taken essentially directly from the IU [17:14:46] oh was it? IBM getting paid for a full new system but only half the work? :D [17:16:44] apparently! [17:17:07] https://ntrs.nasa.gov/api/citations/19740023221/downloads/19740023221.pdf [17:17:45] pdf pages 226-227 discuss some of the minor changes they made [17:19:05] I went down this rabbit hole because I picked up a Mod 410 Remote Digital Multiplexer that should be arriving this week. I want to try to get it working, because it was the box that interfaced with the LVDA for telemetry output [17:19:16] but this specific mod 410 appears to be of the model they modified for use in the ATM [17:23:50] looks like changes for longevity, but nothing really functional [17:24:10] yep! [20:46:03] night! [14:50:53] hey [14:52:11] hey Matt [14:52:38] I really need to stop myself from taking apart the ContinuousSwitches PR again... [15:16:34] hello [15:16:52] hey Alex! [15:17:23] whats up? [15:17:39] long time I haven't logged in here :D [15:18:28] haha yeah [15:18:51] I have implemented a class of rotational switches that don't have integer states, but can be changed continuously [15:19:00] for lighting and antenna controls [15:19:08] trying to get that project finished [15:19:31] ah yes I actually am testing that right now [15:19:47] with your branch [15:19:51] fun [15:19:56] works wonderfully [15:20:10] great. I have run into a bit of trouble with the checklists with it. [15:20:34] The checklist code still works in integer states, both for setting and checking switch states [15:21:10] So how fine control is the checklist supposed to have for setting and checking if you set it to the desired position... [15:22:05] right [15:22:27] at the moment it would be 0.1°, which is too small. You would have to position a rotational switch to within that limit for the checklist to detect it as the correct state. [15:22:49] Usually you get this by accident "passing through" the correct position [15:23:00] But still, it's a bit too small of a tolerance [15:23:36] trying to find a good balance between a good user experience with that but also not making checklist creation any worse... [15:26:48] makes sense [15:29:34] somehow I have gotten terrible at finishing projects so I am putting all my concentration in this haha [15:30:43] its nice to finally be able to manually fine-tune for peak signal strength with the s-band & HGA [15:30:58] haha [15:31:07] yeah that works nicely, also the lighting control [15:31:40] I might use the same class for some more thumbwheels in the future, volume and one CSM temperature control [15:32:16] should the TVC thumbwheels also use the new class? [15:32:26] that's what I started with [15:32:31] it does use the class [15:32:40] but the controls essentially stayed the same [15:33:13] There was just this awkward intermediate solution where those TVC thumbwheels don't save/load their position at 0.1° precision [15:33:20] only 0.5° like the bitmap [15:34:15] ah ok [16:10:13] have you tried the new controls of the same rotational switch on the 2D panel? [16:10:19] I wanted to make it consistent with the VC [16:10:28] it's not super intuitive maybe [16:10:52] but that's probably better than 2D/VC inconsistency [16:16:01] yep I did [16:16:03] I like it [16:16:46] in theory we can have animated meshes even on the 2D panel, but it would require substantial changes [16:18:01] even if the rotary doesn't show the fine animation, it is still intuitive I think [16:19:34] good to hear [16:19:56] like if you are manually adjusting the HGA angles for example, while dragging with the mouse you would be looking at the HGA pitch/yaw/strength indicators and not the rotary animation [16:20:02] if that makes sense [16:20:06] yeah [16:20:12] if the meter moves by a pixel :D [16:20:50] right :D [16:21:10] long term the 2D panel is on the way out [16:22:50] yeah [16:24:31] so I guess the VC's are slowly graduating from their status of "experimental" :D [16:25:24] haha yeah, I've been using them mostly, just for the sextant/AOT not [16:25:47] when I am out of projects in about 2030 I will try to get sextant/AOT working in the VC... [16:25:55] ah yes the sextant/AOT stuff [16:26:02] keep forgetting about that lol [18:12:14] oh hi Alex [18:17:32] indy91, 2030 is very optimistic lol [18:18:34] optimistic is my middle name! [18:18:42] no it isn't, I have no middle name [18:35:21] hey Matt [18:37:35] Orbiter 2024 should have released by 2030...probably [18:40:34] surely [18:42:06] ah I can't wait to be honest [18:42:58] with a stable release we'll be able to move NASSP development to it I guess [18:46:46] and with NASSP 8.0 finally being on a non-beta version of Orbiter, maybe work can start to clean-up and finalize NAASP 8.0 into release form [18:48:02] yeah, I think that is a worthy goal [19:27:24] like how C++0x eventually became C++11 :P [19:29:25] the 2020 Summer Olympics were pretty fun to watch in 2021 [20:41:31] night! [16:22:16] hey [16:31:21] hey [16:31:33] morning! [16:31:37] hey guys [16:42:50] AlexB_88, I had also started to update the systems failure branch again [16:44:43] I basically didn't do anything with it since you last were here 4 months ago or so [16:44:59] you had poked a bunch of holes in the logic of it :D [16:45:18] so far I made a new UI in the PAMFD and switch failures are saved/loaded, compared to 4 months ago [16:46:06] hey guys [16:46:47] all non-switch failures are now programmable with all options (failure on mission time, S-II/S-IVB staging, TLI cutoff etc.) in the PAMFD that previously were only possible with scenario editing [16:46:49] hey Matt [16:47:03] indy91, how hard would it be for me to add IMU drift rates and biases into your new failure code? [16:49:36] indy91, ah great [16:49:44] n7275, depends on the failure type [16:50:03] both "active" and "passive" failure are supported [16:50:14] so the failure class call a function in the IMU class [16:50:24] but the IMU class could also call a function in the failure class [16:55:04] "analog" failures are sort of supported, but not properly yet [16:55:33] like, in the failure class you could have a failure type called "IMU X bias shift of 50 meru" or something like it [16:55:41] the failure code has a function to call from the IMU for that [16:55:42] double GetAnalogFailure(unsigned i); //Analog failure, e.g. a sudden shift in an accelerometer bias [16:55:52] but that might not be the best way to handle it in this case [16:56:08] probably better would be for the IMU class to have a function to set the bias externally [16:56:15] and then the failure code calls that function [17:05:53] I'll have to think about that a bit more [17:17:27] these different ways to do failures was mostly to support all old failures we already had haha, not to confuse you with too many options for it :D [17:19:35] what the failure code can not do yet is specify an amount for a failure [17:19:50] like, adjust the amount of bias shift with a UI or so [17:20:01] the amount would have to be set in code [17:20:08] but this can be added in the future [17:22:37] this is how it was in the actual mission simulators as well, it had the two types: digital or analog malfunctions [17:22:45] digital were many things to just fail on/off [17:23:10] for analog I think they even had knobs to adjust the amount of a malfunction in real time [17:23:29] not sure what IMU failures they could simulate [17:25:46] in Block I I see a bunch of relay, power failures mostly [17:25:53] but maybe there was an analog malfunction for it [19:21:12] so I've been reading more about the multiplexers in the IU in preparation for that reverse engineering [19:21:48] they're more interesting than I thought. they all have 10 boards called "MCRs", each of which has 10 bits of magnetic core storage [19:22:43] and they're fully "programmable" via a patch cable. so for each application you make a harness that effectively specifies what order you want it to sample bits in, and in what order to spit them out to the PCM/DDAS [19:23:20] oh that's pretty neat [19:25:48] There is definitely a lot of interesting things happening with IU telemetry, all the way to LVDC having AOS/LOS calculations and storing and sending data based on being in AOS/LOS [19:26:00] hahaha yeah [19:26:15] I was not expecting this thing to have a small amount of core memory inside -- I figured it would be all silicon [19:26:31] it'll be very interesting to see how that's implemented [20:12:43] ah nice to see the PAMFD time change when updating RTCC liftoff time [20:18:45] ah yeah, that got implemented a bit ago [20:44:11] night! [15:17:06] hey [15:17:26] ok next project to finish, the failure simulation [15:18:59] hey Niklas [15:22:48] hey Alex. I will do a bit of chatlog reading again to remember what you said a few months ago about my failure PR :D [15:24:24] does it use the Orbiter failures flag? [15:24:26] it does now [15:24:43] I failed my CMC CBs but it does not seem to save the failure [15:24:46] it does now :D [15:25:04] and all failures (except switch failures) can be set in the PAMFD [15:25:09] ah nice! [15:25:18] I'll have to give that branch another go [15:25:19] that are the changes I made this week [15:27:00] well maybe the Orbiter failures flag thing is a bit trivial, but I think it should avoid confusion to have it used [15:29:00] not all failures that previously occured will be completely cleared by unsetting that flag [15:29:11] not if it was saved in the specific system e.g. EDS [15:29:20] but all other failures and switch failures will be cleared or won't occur [15:29:31] right [15:33:07] One of the failures I added won't be processed yet, but will be sort of interesting in the future [15:33:13] S-IVB O2/H2 burner failure [15:33:52] LVDC would run an alternative timebase for it and start the ullage thrusters early because the burner gives a bit of thrust for ullage that still needs to be done [15:34:01] but the LVDC processing of that isn't complete [15:34:17] I'll transition to some LVDC fixes and enhancements as one of my next projects [15:35:23] and wire the handling of that correctly [15:35:29] that failure* [15:37:23] I would like to include all failure types for the random failures, but the problem is the timing of the failures. Wouldn't make much sense to have a randomized S-IC engine failure at T+2 hours :D [15:38:06] so the random failures basically still work like before this PR [15:41:19] would the random failures only cover launch and EPO or the whole mission? [15:45:51] they do right now. Saturn vehicle failures are timed to make sense, actually during S-II flight for S-II engine failures etc [15:46:07] randomized CWS light failures are happening immediately [15:46:33] switch failures, too [15:46:37] uhh well [15:46:47] the type of switch failures we had before for the ELS and such [15:47:00] not the new generic switch failures I added with this PR [15:47:07] and those are also instantly [15:47:15] so an ELS switch might not work anymore [15:48:56] but I think randomized failures can be revisited again in the future if it should be enhanced [15:53:13] I'm trying to finish some projects, so, I don't want to add many more features to PR, just clean up the existing ones :D [15:53:58] to this* [15:56:59] the generic switch failures still need scenario editing right now, but I am not sure a UI in the PAMFD would improve that much [15:57:11] you still need to get the switch name from NASSP code [15:57:18] and would have to type it in [15:57:45] some of them are lengthly like [15:57:46] HighGainAntennaPitchPositionSwitch [15:57:47] :D [15:57:53] right [15:58:11] I just tested the cam view branch [15:58:22] all looks good I approved it [15:58:45] ah great, thanks! [15:59:01] I don't think we can even do copy & paste in Orbiter MFD input boxes [15:59:21] so the MFD is inferior to a text editor for switch failures :D [16:01:15] aside from that, having the current switch failures listed in the MFD would be nice [16:01:47] then you could e.g. prepare a sequence of failure entirely in the MFD and later copy and paste it to another scenario for someone else to "experience" [16:15:11] by the way, I have been using the RCSBehavior branch to help the LM be stable with a bit of time accel. Is that branch up for merge sometime or was it just experimental? [16:20:17] ah right, one more unfinished project that I almost forgot I had :D [16:20:23] Skylark got in the way [16:21:12] well I was sort of thinking that the CSM RCS behavior update worked pretty well and was quite simple compared to this LM one [16:21:28] so I at least wanted to give that variant of improving the behavior a try, which I haven't done yet [16:23:38] advantages of the current LM RCSBehavior branch: can very precisely do the exact RCS impulse that the PGNS wants, works well at moderate time acceleration [16:25:07] ah right [16:26:01] I wonder if it should be added as a draft PR so it doesn't get lost in the rear view mirror [16:26:47] yep, I will do that [16:27:29] sorry for reminding you of more unfinished projects :D [16:27:31] it's been a while, I don't even remember how the AGS likes that branch [16:27:32] haha [16:28:16] ah great, I got some merge conflicts... [16:29:10] ah yes, I think it was a minor one [16:45:55] the fix for some radar related problems in ApolloGuidance [16:46:37] no more 1210 alarms when the LR spurious routine is running during the Apollo 9 Docked DPS burn [16:46:47] yeah, very minor [16:47:08] I had a much worse merge conflict to solve yesterday for Jordan's VC branch [16:48:17] I have been wondering why there were no SSV updates in a while, seems like GLS has taken the job of compiling the documentation for Orbiter 2024 :D [16:50:47] morning! [16:51:51] hey Mike [16:52:16] indy91, yeah I saw...hopefully a step closer to the release of Orbiter 2024 [16:54:49] hey Mike [16:59:55] I have one RTCC project not as a draft PR yet, but then I am actually out of ongoing NASSP projects and maybe can even dare soon to start some new ones [17:00:12] like a tweak burn display with the documentation we found for it [17:00:43] oooh [17:00:48] :D [17:01:23] nothing big, not many surprised on it, but it gives a fixed set of inputs and display outputs, always good to have that [17:01:38] no need for guessing [17:01:46] right [17:02:13] speaking of guessing, with my other RTCC project (RTACF really, another mode for the generalized optics program) I also made some changes to RTCC displays. [17:02:21] I have really the dumbest holdups with those [17:02:27] sunrise/sunset display [17:03:02] the order on the display is: terminator rise, sun rise, terminator set, sun set [17:03:06] from left to right [17:03:34] but the current time (or rather input time) might have any of these as the next "event" [17:04:21] I think right now depending on that the times on the right side (set) can be earlier than the times on the left (rise) [17:04:52] it always puts the first sunrise it finds on in the first row of the display [17:04:58] and first sunset, too [17:05:13] let's say you are in eternal sunshine during TLC [17:05:25] so the flyby event will be a sunset next [17:05:43] should the display have blank or zero for the first row sunrise [17:06:08] then the sunset on the right side, first row [17:06:22] and then sunrise on the other side of the Moon on the second row, left sid? [17:06:24] side* [17:06:40] these are the questions that take the longest in my brain :D [17:11:18] I guess this is where proper documentation or a picture of the real display would help [17:12:06] I have quite good documentation, at least in the RTCC "Mission Systems - General" [17:12:29] definitely has a bunch of requirements and such [17:12:39] but not for this specific questions [17:13:19] and not a flowchart of how the display is actually implemented in code, that is in another type of IBM document that we don't have [17:13:49] https://i.imgur.com/VzUv8Zw.png [17:14:01] this is the detail level we have for the display [17:14:08] pretty nice [17:15:33] but not enough for me :D [17:16:15] now that I think about it, terminator rise will always be later than orbital sunrise, yet it is to the left of sunrise time on the display. So that is already not really in order from left to right. [17:26:28] oh it might work like some other displays, although it isn't explicitiely stated. If you are already in sunlight it would use the current time (or state vector time) as the sunrise time, but with an asterisk to show that. [19:08:13] hi Alex [19:08:48] hey! [19:33:50] hey guys [17:18:26] morning! [17:50:49] hey Mike [17:56:10] what's up? [18:12:44] not too much, had to run in to work this morning to check something I have running in the lab [14:37:45] hey [15:12:45] morning! [15:47:59] hey Mike [15:56:26] I found the drawing that I had been missing for the PSA [15:56:45] https://archive.org/details/apertureCardBox471NARASW_images/page/n1235/mode/1up?view=theater [15:57:04] they're long... but sane and consistent PSA wire names :D [15:57:56] must have been really hidden if you didn't even find the drawing at first :D [15:58:53] hahaha I probably should have found it. it's not really *that* hidden, just not referenced by anything [16:19:07] what was I working on... [16:19:34] I'm still playing around with an automatic optimization of a lunar mission. ATDP needs many manual tweaks for the trajectory right now. [16:20:09] it can even do a hybrid mission now, that is what I was trying last [16:21:32] nice :D [16:29:17] Apollo 11 launch day got optimized to a 300 NM flyby with 10 ft/s MCC-2 [16:29:57] I wonder what their criteria were for free return vs. hybrid in those days [16:32:06] thewonderidiot, random LVDC listing question. Apollo 17, it has D.VDPM. But does it also have V.DOFF like the Saturn IB LVDC? Not mentioned in the NTRS document. [16:32:36] so question just is, does it have a mask word with the name V.DOFF [16:33:32] it does, yes [16:34:34] great, thanks :D [16:35:06] the Saturn IB LVDC flowcharts talk a lot about separate processing of discrete inputs going from OFF to ON vs. ON to OFF, just hadn't seen that referenced for the Saturn V yet [16:35:11] but it makes sense that it has that [16:35:39] no doubt being checked in the Discrete Processor (DP) module [16:36:30] there a lot, yes, and also in Events Processor, and once in Switch Selector Processor [16:36:57] yep, events processor will enable and disable them [16:37:15] switch selector is probably that water valve processing :D [16:37:43] the AGC is a guidance computer, but the LVDC has at least one IU ECS management task haha [16:37:51] hehehe [16:38:22] and I think I saw all that in the flowcharts for events processor and switch selector, just discrete processor wasn't clear [16:40:00] I have to think several steps ahead with the LVDC, what I am working on first, or else I will get ugly intermediate solutions for some fixes I want to do [16:47:47] should be a nice cleanup though switching some discrete inputs on/off properly [18:14:20] <indy91> flags that need to be reset somewhere between 1st and 2nd S-IVB cutoff, I am not finding where that is done in the flowcharts... [18:14:30] found it :D [18:14:53] the very last step in phase initialization for phase III [18:25:45] nice :D [19:39:35] cya! [16:45:16] hey [16:46:02] morning! [16:46:56] hey guys [16:47:10] guess I might be flying Apollo 12 soon [16:47:22] hopefully :D [16:53:55] what a coincidence, me too! [16:54:00] ...up to first PTC [17:07:52] and are there external factors at play, such as a new CMC software possibly coming available soon, that makes it NOT a coincidence? Of course not! :D [17:17:17] sounds unlikely, how often does that even happen?? [17:18:18] it's going to start becoming much rarer. the rope reader is putting itself out of business [17:20:07] the FSRR has a couple of nice relevant slides about PTC: https://www.ibiblio.org/apollo/Documents/apollo_12_fsrr_slides.pdf#page=17 [17:24:39] the flight plan doesn't even have V79 so often, but apparently they did use it for PTC during the actual mission [20:48:26] night! [15:28:47] morning! [15:30:26] hey Mike [15:30:31] what's up? [15:31:02] working on LVDC discrete inputs [15:31:05] speaking of [15:31:13] there is a difference between DIN and DIS??? [15:31:36] I think there are 8 input discretes that are called DIS [15:31:41] they are all spare as of Apollo 12 [15:31:49] there are, yes [15:31:53] confused me a bit, that terminology [15:33:47] hahaha I think the S in DIS actually stands for spare :P [15:34:01] oooh [15:34:14] "DIS1-8 Spare discrete input line 1-8, output of a discrete transient protector and input to the level shifting inverter" [15:34:28] "DIS1X-8X Spare discrete input interface line 1-8 input to discrete transient protector" [15:34:33] hmm, the Discrete Processor flowcharts disagree [15:34:50] it has separate logic for processing DIN and DIS [15:35:07] I'm looking at the book of schematics for the LVDA [15:35:11] let's see what the listing says [15:35:36] flowchart has two very similar sections, one starts with "Read DIN register", the other "Read DIS register" [15:35:47] yep, I see that [15:38:18] it's talking about them as "DISCRETE INPUT SPARES", which matches DIS as an acronym [15:38:44] but also it's using DIS1 and DIS2 in relation to the ECS water valve [15:39:21] in M.DP25 in the discrete processor [15:40:42] the other DIS's appear to be unused [15:44:19] ah yeah, that probably was already like this on Apollo 12 (in the ICD) [15:44:37] it has LVDA pin numbers, but it has two water valve inputs last in the list of discrete inputs [15:44:52] oh I know LVDA pin numbers [15:44:56] what are they? [15:48:29] nevermind, found them -- J2AA and J2m [15:48:57] and can confirm J2AA is DIS1, and J2m is DIS2 [15:52:04] yep, makes sense [17:06:03] you might be surprised to hear it, but I don't actually have any code yet in our LVDC for the water valves [17:14:33] shocking :D [19:33:14] cya! [16:36:15] morning! [16:52:21] hey Mike [17:20:27] what's up? [17:21:53] LVDC flowcharts are trying to confuse me, so I have switched over to cleaning up some code in a RTCC branch. [17:22:08] and you? Weekend plans still on? [17:37:57] I haven't heard anything to the contrary. the actual schedule isn't supposed to firm up until today or tomorrow [17:39:07] and of course the threat of major new projects is making me not want to work on the many other projects I have going :P [17:39:33] haha [17:39:43] I had too many projects at about 80% completion [17:39:56] this optics calculations display should be the last one of those [17:40:47] and then I can maybe start new projects that aren't just extended bugfixes [17:41:37] with the LVDC, apparently there is a separate mask word for discretes that start timebases as a backup to interrupts. But that means, in the flowcharts, the comments don't distinguish enough between the timebase mask and the general discrete on mask. [17:42:20] so in one case, in the events processor submodules, it basically says it inhibits and enables the same discrete input on the same step... [17:43:11] but I think it inhibits it in the ON mask word and enables it for timebase start [17:43:27] but that takes deduction just from reading the flowchart :D [17:51:24] oh yeah, that gets confusing :D [15:16:56] morning! [15:17:49] hey Mike [15:20:01] what's up? [15:22:18] got the optics calculations branch ready as a PR [15:22:42] aside from this recent LVDC work I am down to zero local branches that I don't have as a PR yet :D [15:23:26] makes me feel a lot better about starting something new [15:26:50] that's awesome! [15:27:07] congrats on finishing a lot of projects :D [15:29:13] haha, they just needed that last push, the most boring part with testing and writing documentation. [15:29:48] takes more motivation than starting something new [15:32:01] yeah I totally feel that [15:51:01] I think I'll implement that tweak burn display [15:51:09] should be a fairly contained project [15:51:16] ... which I always say before a new project [15:52:44] hehehehe [16:03:26] not even OCRed, NARA scam prices :D [16:04:16] although this one was for free, so, I didn't say anything [16:05:59] I can do some processing on it if you want! [16:07:49] ah don't worry about it, just a few pages [16:08:06] and the way it was scanned looks weird, too, maybe it's not even easy to OCR [16:08:22] lol sounds like classic NARA [16:11:32] Ron still in the queue for 2030 to renew the training to be allowed to do scanning himself? :D [16:11:46] right after the MOCR audio digitization people [16:12:08] I think the holdup on more Apollo in real time missions was exactly the same [16:12:31] oh man I have no idea, I haven't asked him about it in a long time [20:21:33] night! [15:58:50] morning! [16:21:08] hey Mike [16:23:27] what's up? [16:47:54] hey hey [16:49:07] hey, good evening [16:51:49] how's it going? [16:53:18] I enjoyed the good weather until now. And you? [16:55:06] doing good! today is neurotic testing and lab-packing day [16:55:40] haha I bet [16:56:16] I'll create a branch tomorrow morning, the preparations I can do are really just 5 minutes of work [16:56:55] with Skylark I was overtaken by people who used higher time acceleration than me, to get to launch quickly :D [16:57:03] hahaha [16:58:19] by now I have high confidence in padloads and handling new ropes, I'll go through TD&E and would do some V79 testing afterwards. That should be enough for a PR. [16:58:40] Yesterday I had a last minute "wait, are there any uplink address differences" panic, but no, there aren't any [16:59:49]