[12:30:30] NASSP Logging has been started by indy91 [15:57:15] hey [16:02:58] hey Alex [16:11:10] On panel 181, "DOOR JETT" is that just a light? [16:18:46] I think that is a guarded toggleswitch [16:23:48] I don't see much unusual on that panel [16:24:13] there is a protective cover over the logic power CBs it seems, but we don't really need that [16:24:52] 5 CBs, 2 toggleswitches, 2 three position switches, 1 guarded toggleswitch [16:30:13] ah, a guarded toggle switch [16:30:48] although it seems weird that the label would be on the guard [16:30:53] I am really horrible at identifying stuff from top-view 2D graphics :D [16:31:02] another reference would be really nice [16:39:33] but it might be on the switch guard, it's that way in the few diagrams from checklists and AOH I could find [16:43:42] right [16:44:03] in the Systems Handbook on schematic 2.9 the DOOR JETT is just above the switch [16:44:40] which is probably easier to implement anyway, otherwise we need to add another switch guard bitmap [16:44:57] right [16:45:10] Ill put it above the switch [18:12:47] alright, the background of the panel is shaping up [18:12:59] I modified the ordeal panel to get the right look [18:33:02] great [18:53:04] haha [18:53:22] I was wondering why the heck there were random switches in the lower left corner of the LEB [18:53:31] lower-right* [18:53:47] you added them for testing [18:56:25] just below those switches, I have the 1st preview of the panel, still early of course. I just pasted it on the LEB bitmap for testing but when its done it will be its own bitmap (like the ordeal) [18:56:31] https://www.dropbox.com/s/ku5azkcn7hk4zlz/Screenshot%202020-02-09%2011.54.54.png?dl=0 [18:57:19] lower left corner? Isn't it lower right? [18:57:28] I think I placed them, roughly, where panel 181 is [18:57:40] looks nice so far! [18:58:02] ah here they are [18:58:18] the switches I added. Yeah that was for testing. [18:58:30] the jettisoned panel appears inside the CSM right now :D [18:58:43] just some numbers to adjust though [18:59:10] yeah I saw [18:59:25] shouldnt be too hard to adjust [18:59:34] hmm [18:59:42] I think you made the panel too small [18:59:58] did you see the panel on page 212 of the Systems Handbook? [19:00:06] yeah [19:00:47] ah, you put it below the switches that I added [19:00:59] I guess the panel would just go up to the stuff above [19:01:31] well if you compare with the "access for VHF panel" above it its about the same width as that [19:01:33] so you can remove mine and move the panel higher or so [19:01:53] yeah, you are right. the size is right [19:02:00] just needs to be where my switches are [19:02:06] so a bit higher [19:02:18] sure [19:02:26] no gap to the VHF antenna access [19:02:33] I just positioned it roughly for the test [19:02:40] ah, ok [19:02:54] its pasted directly on the LEB bitmap right now in my copy [19:02:55] but yeah, I think the size is good [19:03:05] maybe slightly too small [19:03:13] but it will be a separate bitmap in the final version [19:03:15] it looks like it is slightly wider [19:03:30] I can make make it slightly bigger, sure [19:04:14] difficult to say [19:07:41] for the LM we would know such things in the future [19:07:49] as Ron is scanning the Grumman schematics right now [19:08:04] so we would know the exact measurements of everything I guess [19:13:33] oh now I remember [19:13:38] AlexB_88, don't delete my switches [19:14:29] ok [19:14:34] https://github.com/indy91/NASSP/blob/SIMBayPanel/Orbitersdk/samples/ProjectApollo/src_csm/satswitches.h#L891 [19:14:40] I already added all of them [19:14:48] not all of them were drawn yet [19:14:56] but they are otherwise coded [19:15:05] and more important, already used in the SECS code [19:15:29] so you'll get a nice amount of build errors if you delete them :D [19:17:25] https://github.com/indy91/NASSP/blob/SIMBayPanel/Orbitersdk/samples/ProjectApollo/src_csm/saturnpanel.cpp#L3163 [19:17:35] and this is where the init functions are called [19:17:42] for the switches already there [19:38:23] but you can of course change the location of the switches, was just a rough positioning from me so far [19:39:47] right [19:40:05] the switches, are already on a separate pop-up panel? [19:41:46] not a pop up panel [19:42:11] but they are coded in such a way that the switches only appear if the panel exists for the mission [19:42:26] bit of an experiment what the best way is to implement that [19:42:56] so the switches aren't directly in the Saturn class, but in a dynamically loaded Panel181 class [19:44:19] ok [19:44:41] so the panel itself should also be loaded that way I guess? [19:46:11] yes [19:46:17] if (Panel181) [19:46:20] in the Saturn class [19:46:34] been a while since I coded that [19:46:44] have to fully understand it again myself [19:47:15] ok [19:47:28] also we have to take in account split panels [19:47:57] true [19:48:04] it's completely on the right one at least, right? [19:48:19] yes [19:48:39] I think that is already handled for everything on those lower panels [19:49:56] ah, right the offsets [19:50:18] but I'm not sure that applies to drawing an extra bitmap [19:51:12] haha [19:51:17] past me is pretty smart [19:51:25] if (id == AID_CSM_PANEL_181) [19:51:25] { [19:51:26] //TBD: Draw panel 181 background [19:51:27] } [19:51:29] I already added this [19:51:47] and that is only ever called if panel 181 exists [19:51:52] but [19:52:01] it will probably need separate numbers for the split panel [19:52:19] but you can use a check on the panel [19:52:24] e.g. PanelId == SATPANEL_MAIN [19:59:56] ok [20:00:28] so, you have all the switches/CBs added, but just need repositioning if I understand? [20:01:39] pretty much [20:01:48] the switches exist in a Panel181 class [20:01:56] their Register function is called for all of them [20:02:18] the Init function (with the position data) is only called for the 3 switches you can already see [20:02:42] so you can reposition them as you want, and then it also needs the other switches and CBs [20:03:35] and the split panel thing [20:03:40] I think that is solved [20:03:48] as the offset is applied to the whole panel area [20:03:57] and all the switches are relative to that panel area [20:15:49] ok [20:55:33] https://www.dropbox.com/s/2thkyrv8urdzrni/Screenshot%202020-02-09%2013.54.51.png?dl=0 [20:56:02] just needs some labels [21:09:35] it's taking shape [21:20:05] luckily most of the labels are found elsewhere [21:38:59] night! [15:58:52] hey [16:09:52] hey Alex [16:10:27] fun fact. out of the 4 major coordinate systems our RTCC uses (ECI, ECT, MCI and MCT) only MCT is actually the same as in the real RTCC :D [16:11:11] ah really [16:11:41] I never really studied what those acronyms were yet [16:12:15] Earth Centerered and Moon Centered [16:12:17] Inertial and True [16:12:36] True meaning relative to the rotating Earth [16:12:39] or Moon [16:13:13] well, in the case of the Earth ECT would actually be inertial too, defined at midnight before launch. That's the difference to our RTCC right now [16:13:47] right [16:13:53] for us that means (at the moment) that you can calculate e.g. the current longitude directly from the true coordinates [16:14:15] just some fun I am having thanks to the AEG... [16:14:41] the lunar AEG is using the MCI coordinate system [16:14:48] so I need to convert back and forth a bit [16:15:07] I see [16:15:22] it's funny, we used to have 3 out of 4 correct coordinate systems [16:15:27] ECI and MCI is what the AGC uses [16:15:31] exact same [16:15:41] so no conversion necessary for e.g. state vector uplinks [16:16:18] but then I changed the coordinate systems from Earth equatorial to ecliptic, as that made more sense in Orbiter. Orbiter calculates everything in ecliptic [16:16:18] on my end panel 181 is pretty much done [16:16:30] great! [16:16:49] https://www.dropbox.com/s/5ipbp3gytw4wvnq/Screenshot%202020-02-10%2009.14.13.png?dl=0 [16:16:50] so eventually, I'll change the ECI and MCI coordinate systems back to what we had a few years ago... [16:17:00] totally looking forward to that [16:17:08] haha [16:17:18] must be quite the job [16:17:25] looks really good [16:17:34] thanks [16:18:17] yeah, that will be a large undertaking. But at least I will be able to use many real RTCC routines more directly then [16:18:40] instead of modifying them all the time to work in the right coordinates [16:19:04] ok, so what enables panel 181 in the code currently... [16:20:02] ah [16:20:05] https://github.com/indy91/NASSP/blob/SIMBayPanel/Orbitersdk/samples/ProjectApollo/src_csm/satsystems.cpp#L2335 [16:20:18] so based on mission number [16:20:35] but with that logic it would be fairly easy to instead make that a customizable parameter [16:24:04] so I guess when the panel is done, you would make it a separate bitmap [16:24:17] and then add it in that panel redraw event section [16:28:10] so you mean call the panel from Saturn::CreateMissionSpecificSystems()? [16:29:19] no, what I linked yesterday [16:29:20] https://github.com/indy91/NASSP/blob/SIMBayPanel/Orbitersdk/samples/ProjectApollo/src_csm/saturnpanel.cpp#L4372 [16:29:50] it would be very similar to the ORDEAL above that [16:29:50] oapiBlt(surf, srf[SRF_ORDEAL_PANEL], 0, 0, 0, 0, 477, 202, SURF_PREDEF_CK); [16:30:05] the numbers there are just the size of the bitmap [16:30:54] I only asked you to create the bitmap, your choice if you want to implement the whole thing or let me do it [16:31:13] no problem either way [16:35:20] well I see most of the logic is already there, I think I should be able to implement it [16:35:29] Ill give it a go [16:35:40] great [16:37:36] the very last step will be adjusting the position and velocity of the jettisoned panel [16:38:06] the SM panels have always been separate panels [16:38:22] I guess back in the day they were already forseeing the SIM bay panel jettison [16:38:31] and Apollo 13 [16:38:53] always been separate meshes* [16:43:04] yeah [16:54:36] should I add another Panel181 check in the panel redraw event section? [16:54:57] no, I don't think it is necessary [16:55:04] ok [16:55:16] the panel shouldn't be registered if it doesn't exist [16:55:25] so that id == panel181 will never be called [16:56:03] right [16:56:23] so I just called the oapiBlt without any checks [16:56:37] yeah [17:09:17] alright panel is loaded [17:17:17] now to re-align the switches and add the others [17:19:33] I guess you had to adjust the oapiRegisterPanelArea for panel 181 a bit? [17:21:04] yes [17:21:22] it was just a bit too much left [17:22:25] https://www.dropbox.com/s/zin2wzu5xtyherr/Screenshot%202020-02-10%2010.21.55.png?dl=0 [17:22:32] that is without the adjustment [17:22:59] so I guess we want it to line up with the VHF panel above? [17:23:45] yeah [17:24:03] in the systems handbook it looked like it's pretty much centered below it [17:24:09] yeah [18:10:57] alright, switches are done, now the CBs [18:11:21] indy91, switch save/load isn't done yet, can I let you take care of that afterwards? [18:12:33] hmm, isn't that done automatically? [18:13:36] what I also just thought if is the default switch state [18:13:58] InitSwitches() [18:14:07] I think it needs entries in there [18:15:52] hmm [18:16:05] there is a separate register function for all the panel 181 switches... [18:16:11] but is that called [18:17:04] not that I can see [18:17:08] but I can take care of it, sure [18:17:18] so, I just found something [18:17:24] a panel 181 with a different layout [18:17:30] from the Apollo 16 AOH [18:19:54] what you implemented and what is in the Systems Handbook agrees with the Apollo 15 Launch Checklist [18:20:04] the one from 17 is missing some pages [18:20:18] I think you had requested that from UHCL at some point [18:20:47] oh [18:20:55] and Apollo 16 launch checklist also agrees what we have [18:21:04] so I think we did it right [18:21:11] whatever that alternative layout is [18:22:17] great [18:23:57] when you are all done it's probably best if you PR it to my development branch [18:24:18] from there it will get into indy91/Orbiter2016 [18:24:27] and from there to dseagrav/Orbiter2016 :D [18:25:00] indy91/Orbiter2016 has the whole TLMCC update I didn't want to merge yet [18:27:20] morning! [18:27:51] hey Mike [18:29:05] how goes it? [18:29:23] I'm testing some new RTCC functions [18:29:32] and Alex is implementing the panel for the SIM bay door jettison [18:29:48] I started a branch for that a while back [18:29:59] and dumb as I am I actually had a separate feature in that branch [18:30:19] loading custom AGC ropes with a line in the scenario [18:30:42] I implemented that for Sundial and Terminus [18:31:32] and when I realized I had that in the dev branch I couldn't merge yet I never progressed with Terminus... one of the reasons anyway [18:32:09] hahaha [18:35:31] I'm going to have to take another go at Terminus at some point [18:35:45] now that I have Luminary 178, so I know for sure what the changes are from that to Zerlina, and from that to 210 [18:35:54] and I'll have to get it off the ground at all [18:35:58] :P [18:36:14] I have a padload worksheet for it [18:36:36] I don't seem to have a scenario yet for it [18:38:14] I'm not sure I had decided yet where to land with it [18:38:41] maybe to Tycho again, but this time to the exact spot where the other Surveyor landed [18:41:05] hey Mike [18:41:59] indy91, just some small final adjustments and I'll PR this to your dev branch, maybe in 20 mins or so [18:43:15] great [18:43:18] back in a bit [19:16:55] indy91, PR sent [19:17:54] and merged [19:18:02] thanks! [19:18:14] awesome [19:19:51] I should get the rest done today or tomorrow [19:20:36] ok [19:25:11] all this makes me want to fly a J mission haha [19:48:05] saving of the switches already works [19:48:34] but not loading [19:48:36] weird [19:49:20] probably something that isn't done in the right order [19:55:56] ah damn [20:04:19] it is an order thing. And I was pretty sure I had solved that. Apparently my memory was wrong [20:14:37] but I think I have it [20:15:08] load APOLLONO parameter, register panel depending on the mission number, load panel states [20:15:20] the issue was that it created the panel 181 after loading all the panel states [20:22:57] I think now I just have to spawn the panel right [20:47:28] ok I got it [20:47:36] right speed and direction [20:47:44] 13.7 ft/s according to the CSM Data Book [20:53:09] AlexB_88, I have merged the branch and pushed it to indy91/Orbiter2016 [20:53:19] have fun trying it [20:57:54] ok great [20:59:50] I guess I can also add panel 230 now [20:59:53] we have the bitmap [21:00:28] yeah [21:02:30] so do we have a way now to handle different panel/sytem configs for different missions? What would be the consensus on starting work to implement the rest of the J mission differences? [21:05:26] I can take care of all the panel bitmaps when the time comes [21:05:42] is there even much bitmapping to do? [21:06:05] a bit [21:06:06] ah panel 230 has mission differences [21:06:20] but we do have a system I think, yes [21:06:23] the LM has some differences for sure [21:06:34] EPS comes to mind [21:08:37] right [21:08:49] well, there is a bit of code now in the CSM to handle the differences [21:09:16] I wouldn't say we have a really good system in general to handle differences for many missions [21:09:47] right [21:11:21] I guess I will slowly start to make the bitmap changes and then when the time comes they will be ready for implementation [21:11:49] or I mean add the bitmaps, but like panel 230, not yet in code [21:12:59] maybe only sections of panel that would be changed for the J-mission, made as "overlay" bitmaps that can be added [21:13:43] a bit like what we did for panel 181 [21:14:41] yeah, that's probably easier [21:15:14] and the panel 230, we had that laying around for a decade now. So I guess it doesn't hurt adding new bitmaps early, haha [21:15:45] yeah haha [21:15:54] tested your latest changes [21:15:58] looks good [21:15:58] already found a logic flaw for the SIM bay door jettison [21:16:06] it doesn't check on the pyros [21:16:13] pyro circuit breakers [21:16:15] ah right, I was just thinking that [21:16:27] its not an independent system? [21:16:57] well a little bit [21:17:03] it doesn't need the pyro arm switches [21:17:14] but it gets its power from the pyro batteries [21:17:29] right [21:17:33] I have to run, cya! [21:17:38] cya [21:20:51] night! [16:35:56] hey [16:39:47] hey Alex [16:51:51] tried my hands at an alternative AEG formulation which would be closer to how it was really coded in the RTCC software [16:52:08] turns out the RTCC requirements document is missing two important equations... [16:52:42] potentially a recoverable issue, as I have the IBM RTCC documentation for it as well. But it's not exactly the same [16:54:04] always great how reliable the RTCC requirements documents are... [16:59:06] but I am making small steps towards putting the lunar AEG to some use [17:08:16] sounds great [17:09:44] will the AEG be used globally, or just in certain functions? [17:13:08] I guess step by step globally [17:13:32] as I don't fully trust the Earth orbital AEG yet I won't implement it in functions that are used for both Earth and Moon [17:13:47] so no GMP or rendezvous programs yet [17:14:06] but I could do the LDPP and a new lunar launch window processort [17:14:19] right [17:15:24] the first very small application of it will be the equatorial/ascending node crossing longitude on the DMT [17:15:48] very simple, separate logic for Earth and Moon [17:15:51] a good place to start [16:36:15] hey [16:43:18] hey Alex [17:06:40] I'm kind of just waiting for the LOI targeting document to appear until I really work on something meaningful again, haha [17:07:07] I could look at some non-RTCC related things [17:09:12] like that SM jettison controller change they did after Apollo 11 that made the SM reenter [17:09:50] right [17:10:38] I wanted to say, my Apollo 12 entry interface quicksave gives A CTD [17:11:07] oh [17:11:18] caused by the RTCC MFD? [17:11:26] is that pre EI? [17:11:41] It happens at the end of loading, when the last vessel shows, it hangs [17:12:03] I would like try debugging it [17:12:21] Ill get you a scn [17:13:14] when the MPT mode is enabled it does a bunch of stuff, not just generate an ephemeris [17:13:25] also rev crossing table, station contacts table etc. [17:13:33] could be something unsafe with thosre [17:14:05] https://www.dropbox.com/s/04vcrioz2mjyx45/Apollo%2012%20-%20RRT.scn?dl=0 [17:14:59] thanks [17:15:27] hmm I think I gave you the wrong one [17:17:40] https://www.dropbox.com/s/04vcrioz2mjyx45/Apollo%2012%20-%20RRT.scn?dl=0 [17:18:18] the other one was just before lunar ascent :D not bad to have either I guess [17:19:00] true [17:19:38] oh and you may have to remove the surveyor entry [17:20:12] already used to that [17:21:19] before even trying I already have a theory what could be wrong :D [17:24:21] I will soon try to make a surveyor 3 mesh that we can make part of NASSP [17:26:53] nice [17:27:03] yeah it's pretty much what I thought it would be [17:27:09] the ephemeris 4 state vectors long [17:27:20] the ephemeris is* [17:27:36] and a lot of "customers" of the ephemeris use 8th degree interpolation [17:27:44] which needs 9 state vectors [17:27:51] that case is handled in most cases [17:27:54] but apparently not al [17:27:56] l [17:39:50] fixed [17:43:45] in reality it would generate 9 state vectors for the ephemeris no matter what [17:43:53] but I haven't implemented that yet [18:16:43] morning! [18:23:57] hey [19:02:18] indy91, for the J mission CSM, only changes on the main panel seem to be the CRYO labels/switches [19:03:49] and then panel 277,278 [19:03:52] and 230 of course [19:18:37] yeah, that one row of panel 2 switches is quite different [19:18:41] otherwise not very different [19:26:58] btw our panel 230 bitmap is a bit different from CSM 114 systems handbook [19:30:02] maybe reflects Apollo 16/17 [19:31:32] yeah I think each 15, 16 and 17 had slightly different versions of it [19:33:49] ah [19:34:04] the systems handbook for 112 to 114, different version, has all of them [19:34:24] that systems handbook is a bit inferior quality, so I don't tend to use it often [19:34:48] https://www.ibiblio.org/apollo/Documents/HSI-480977.pdf [19:34:54] PDF page 204 [19:38:30] hmm does ours cover all functionality? [19:39:55] sub satellite, check [19:41:14] lunar sounder, no [19:41:22] looks like ous is CSM 113 [19:42:10] I would have said 112 [19:42:16] because of the subsatellite [19:43:57] ah yeah [19:44:16] the labeling was not clear, so yeah 112 [19:49:51] I think in that case we would want 3 separate bitmaps [19:50:08] using bitmap overlays would get too complicated [19:50:19] mostly thanks to the 114 configuration [19:52:41] right [19:53:40] panel 278 has 2 configs [19:54:58] switch S7 [19:55:14] one is ALPHA/X-RAY and the other is IR [19:56:26] SSU has pretty good code for this kind of stuff [19:56:30] all 3D panels of course [19:56:41] but the Shuttle aft station was very configurable [19:56:49] so they implemented it that way from the start [19:57:16] right [19:59:17] new SMJC version implemented [19:59:24] only in the SM vessel so far [19:59:46] but I'll use the same mission specific code as for panel 181 [20:00:13] to be fair, the SMJC is NOT a system that should do anything until millisecond before CM/SM sep [20:00:28] but I'll still implement it right in the Saturn class :D [20:01:56] nice [20:04:19] especially in the earlier version a failed-on SMJC would be one of the worse things that could happen [20:05:29] I'll start by making panels 277,278 I think [20:06:05] are those completely new? [20:06:07] anyways Ill be back in a bit [20:06:13] no modified [20:06:17] ah [20:06:19] cya later [20:06:55] cya [21:36:30] night! [17:00:05] hey [17:04:17] hey Alex [18:23:06] morning! [18:23:10] hey [18:23:14] what's up? [18:23:47] just little things with the RTCC [18:23:52] mainly waiting for Ron :D [18:23:57] hehehe [18:24:33] I got the LM-3 Systems Handbook and AOH [18:24:44] awesome [18:25:06] I haven't figured out how to scan them yet with all of the foldouts, but if there is anything in particular you want to see let me know [18:25:18] the AOH is early, it still shows LM-3 being launched on a Saturn IB :) [18:25:19] hmm [18:25:24] haha [18:27:29] is it closer to the LM-1 or the LM-8 Systems Handbook in its structure? [18:28:06] there is a system that was only flown on Apollo 9 and 10 [18:28:15] basically a successor to the programer [18:28:25] for remote controlled APS burns [18:29:18] ascent engine arming assembly [18:29:41] that's the main thing I can think of that we wouldn't have in the other System Handbooks [18:33:28] oh interesting [18:33:38] I'll have to look [18:33:55] I got the vague impression it was closer to LM-8 but haven't dug too deeply yet [19:10:45] difficult to tell what else will be useful [19:10:57] when was LM-3 even last assigned to be launched on a Saturn IB [19:11:25] I think at one point they planned for two unmanned flights of the LM, but that was with LM-2 I believe [19:13:30] yeah, I have no idea [19:13:38] maybe they just hadn't updated that from the LM-2 AOH [19:14:26] could be [19:14:29] what's the date on it? [19:14:40] early 1968? [19:15:02] uhh, something like that, I'll have to check tonight [19:15:08] I don't have it here with me right now [19:15:59] LM-3 was assigned to a joint CSM/LM mission (with CSM-103) in October 1967 [19:16:31] LM-2 assigned to a possible, but unlikely Apollo 5 reflight on AS-206 [19:17:01] but surely that mission together with CSM-103 would already be on a Saturn V [19:18:32] yeah, later in October 1967 there is talk of the "AS-503/103/LM-3 (Apollo 8) mission" [19:30:38] hmmmm [19:30:44] it did definitely say 1968 on it [19:31:14] then it's probably as you said, they simply hadn't change it yet to say Saturn V :D [19:33:06] indy91, any idea where panel 277 was? I want to say between 276 & 278 [19:34:13] for that the Systems Handbook page a few pages later probably helps [19:34:17] 277 is the tiny panel with the CSM/LM final sep breakers and 2 other switches [19:34:43] yeah, page 212 [19:35:05] unfortunately its not very clear, I cant find panel 277 anywhere on that view [19:35:47] I see 275, 276 and 278 [19:36:16] same here [19:36:33] 277 must be elsewhere then [19:49:20] is 277 J-type mission only? [19:49:28] I think so [19:49:38] were there no CSM/LM final sep breakers before? [19:50:06] not on our panel [19:50:11] https://www.airspacemag.com/panoramas/apollo-command-module-007a-180947951/ [19:50:19] yeah it's not used in the SECS logic [19:50:28] this one shows panel 277 between 276 & 278 [19:51:04] seems to be a J-config mockup [19:51:21] it sure does [19:51:32] I looked at the Apollo 11 CM 3D [19:51:34] scan [19:51:38] nothing there of course [19:51:57] so I guess that answers it [19:52:42] pretty nice panorama [19:56:51] very easy logic for the two breakers if we want to implement them [19:58:01] maybe one of the changes done after Apollo 15, where they looked at what certain switch failues could do [19:58:13] and CSM/LM final sep is pretty final [20:01:04] yeah [20:01:18] Im working on the bitmap right now [20:02:42] it also has 2 switches SPS PRESS FUEL & OXID 1/2 [20:26:50] those switch between redundant pressure sensors it looks like [20:29:37] from the exact same location in the SPS [20:30:10] SPS tanks [20:36:16] https://www.dropbox.com/s/6xehhrh6xrvsngi/Screenshot%202020-02-13%2013.35.45.png?dl=0 [20:39:13] https://www.dropbox.com/s/lq86lvsdpd57zv5/Screenshot%202020-02-13%2013.38.55.png?dl=0 [20:51:05] for adding this panel, should we make a separate "Panel277" variable? [21:02:24] hmm, good question [21:03:30] we could create one variable to cover everything all J-type CSMs have [21:03:46] wait [21:04:12] do you mean something in the scenario that says the panel is there? [21:04:23] or do you mean the way I implemented panel 181? [21:04:39] dynamically loading the panel if it is supposed to be there or not [21:06:19] well I mean the best way to do it [21:07:16] "one variable to cover everything all J-type CSMs have" thats what I was thinking it could work [21:07:54] well right now panel 181 is just loaded based on the mission number [21:08:44] right [21:08:54] not a parameter in the scenario [21:09:06] not one specific to panel 181 anyway [21:09:23] well there is a "Panel181" variable in code [21:09:59] oh you mean the class? [21:10:00] class SaturnPanel181 [21:10:00] so a "Panel277" equivalent is what I meant [21:10:17] yeah, I think that should be implemented exactly the same as for panel 181 [21:10:36] ok [21:10:54] even if all J-type CSMs have both those panels, I think it's still a good idea to keep it somewhat modularized [21:11:05] right [21:11:16] every self contained box in the CSM should be a separate class [21:11:22] and panels are boxes :D [21:12:29] I don't want to find some special down the road where a switch is different from what we thought [21:12:44] yeah [21:12:45] special case* [21:13:05] if that happens then it will be easier if we just make different versions of one panel [21:13:11] and not the whole J-type mission thing [21:13:28] makes sense [21:13:33] so if you want to do a bit of panel 277 coding, be inspired by panel 181 [21:13:45] I'll give it a go [21:14:06] not the perfect implementation I think but at least it doesn't have any overhead of unnecessary code running for the earlier CSMs [21:14:34] yeah [21:20:09] SSU has cleaner code for all of this, but that's because they spent all their time with pre-planning their coding and not actually making progress :P [21:20:50] haha ouch [21:20:54] slinging some shade :D [21:21:27] otherwise SSU might have already features such as orbital insertion into specific orbital plane and not just in any kind of orbit with the right inclination [21:21:39] hehe [21:21:40] making the Shuttle FDO MFD's launch window targeting mostly useless :D [21:25:44] alright, i've added class SaturnPanel277 [21:25:56] based on Panel181 [21:26:10] looks quite straightforward' [21:26:46] yeah, just the instanc of the class being created, deleted [21:26:58] registering the switches [21:27:17] not that complicated as compared to "normal" switches [21:27:26] not much more* [21:27:53] and I guess in the SECS code it will check if panel 277 exists [21:28:01] if yes, it will check on the two new CBs [21:28:20] ok [21:28:33] I can do that once the panel is done [21:28:39] sounds good [21:28:51] Ill add the class and map the switches [21:29:07] great [21:29:09] good night! [21:29:24] cya [15:52:01] hey [15:54:30] hey Alex [15:56:06] https://www.dropbox.com/s/h1ydvoaljbdrnti/Screenshot%202020-02-13%2020.01.09.png?dl=0 [15:57:19] thats CSM 114 version (Apollo 17) [15:57:34] panel 278 [15:58:59] oh awesome, that was quick [16:00:16] yeah I did it until late last night, I was on a roll lol [16:00:27] I also did CSM 112 version [16:02:04] I already added logic to load it based on mission, based on your panel 181 logic. So a class for Panel278CSM112 and another for Panel278CSM114 [16:02:54] CSM112 format was Apollo 15-16 and CSM114 format was Apollo 17 [16:03:12] basically its one switch haha [16:05:16] Panel 278 already exists of course in our CSM, so the panel 278 I added is just the additions [16:07:30] how do the additions work bitmap wise? [16:07:48] is it overlaying a new bitmap for the whole panel 278? [16:07:53] no [16:07:58] all but the old cbsè [16:08:02] cbs* [16:08:03] only the previously empty parts [16:08:10] yes [16:09:37] yeah additions are easier to handle [16:12:42] I just have the switches left to add, then Ill push to my repo [16:16:21] how did you do the letters in the new panels? [16:18:13] all the letters I take from other parts of the panels [16:18:43] if its the whole word thats right great, if not I copy/paste letter by letter [16:19:18] so the end result is the letters are in the exact format/font as the other panels [16:19:49] right [16:36:15] talkbacks are class IndicatorSwitch, right? [16:38:39] yeah [16:39:52] I think so [16:40:44] hmm [16:40:52] I need it sideways [16:41:03] doesnt look like that class supports it [16:41:26] but there does seem to be a bitmap for a sideways talkback indicator [16:41:45] I wonder if there is another class for it then [16:42:47] probably [16:43:39] hmm that bitmap is not loaded by the CSM though [16:45:06] yeah [16:45:11] I am not finding a class for it [16:45:19] guess the bitmap was added just in case [16:47:01] yeah [16:47:12] for the normal toggle switch it uses the same class [16:47:19] but then does this [16:47:20] SCIInstSwitch.SetSideways(true); [16:47:44] right [16:48:26] I guess the same can be implemented for indicatorswitch [16:48:53] should be pretty easy [16:49:22] hmm [16:49:29] or not even not necessary? [16:49:39] try loading the 90° bitmap [16:49:46] and use it for the indicator [16:49:52] it might work without any code changes [16:53:00] right [16:53:48] we still would need a way to load both [16:54:28] what do you mean? [16:55:04] can't you just load the other surface in the switch init? [16:55:48] ah [16:56:17] you will still need to add a new surface, but that should be simple [16:56:28] yes I can do that [17:01:33] yeah, pretty sure it will work just like that [17:14:21] I'm implementing AEG utility routines [17:14:35] not particularly exciting, but it's needed in many functions using the AEG [17:14:43] nice [17:15:12] e.g. find time of longitude crossing. We already have about 2-3 functions for that problem, but the AEG needs one as well :D [17:15:39] the RTCC had at least 2 functions for that as well [17:15:44] the real RTCC* [17:15:57] one using the AEG, and one interpolation from the main ephemerides [17:16:43] general purpose maneuver processor would use the AEG function for finding the longitude, FIDO Orbit Digitals interpolates the ephemeris, for example [17:18:12] I'm going through the lunar launch window processor flowchart. One of the first things it does is propagate the CSM state vector to the landing site longitude [17:44:50] sounds like quite the project [17:45:31] on my end, just the talkback indicators left to add [17:59:32] well the worst thing about that project was trying to replicate the AEG input/output properly. Especially the lunar AEG is quite weird in that regard [17:59:41] I'm sure there will be lots of tweaks to that over time [18:00:20] and I don't think getting the RTCC requirements document for that is going to help much [18:00:37] I have nothing on the lunar AEG but a few pages [18:00:43] it was on ebay at one point [18:02:22] the real lunar AEG will try to account for some non-spherical gravity we don't have in Orbiter [18:02:42] and maybe even the disturbing force of the Earth, which we should have in Orbiter, but I never looked much into that [18:02:47] how strong it is etc. [18:10:50] morning! [18:12:05] indy91: AOH is from January 1, 1968, so just about as early 1968 as possible :P [18:12:13] Systems Handbook is March [18:12:20] and both of them have sections on the AEAA [18:12:32] er, the systems handbook doesn't have a section, per se, but it does show up in the APS drawings [18:13:43] hey [18:13:45] great [18:13:55] well, I think the AEAA is mostly a bunch of relays [18:14:05] connected to the control assemblies [18:14:23] https://photos.app.goo.gl/N2RSaDRnZSbxWjy49 [18:14:55] hey Mike [18:14:58] also, systems handbook is like LM-8, and it may be the first one to be in that format [18:15:12] it has all of the drawings that were deleted for the LM-8 handbook, which is nice :D [18:15:16] the later AOH actually does have some things on the AEAA, but it had just been deleted, a bit incomplete [18:15:36] Apollo 11 AOH, so first mission without AEAA [18:15:59] indy91, here is what I pushed if you want to look before I PR: [18:16:00] https://github.com/jalexb88/NASSP/commit/0af84190c2ac71d99806ce329dba44894f8254d9 [18:16:19] yes I'll look at it [18:17:12] I think one thing I couldn't figure out with the limit info we had was how the commands got from Earth to the AEAA [18:19:04] some of those pictures are pretty crappy, if there's something you want a better pic of let me know [18:19:13] and I'll talk to Marc about scanning it, I think he has something now [18:19:44] so, the missing pieces for me to implement the AEAA might actually be in the comm section of the Systems Handbook [18:20:02] oh interesting, okay [18:20:06] or the AOH [18:20:14] I would guess it works very similar to the CSM [18:20:36] any uplink to the CMC and LGC had some code to it [18:20:55] and if something was not supposed to go to those, then there would be a different code [18:21:28] RTC, real-time command system in the CSM [18:21:40] you can switch e.g. the active omni antenna from the ground [18:21:43] that flew in all CSMs [18:21:51] works in NASSP, too, via the telemetry client [18:22:27] I don't know if that is based on reality, but that ID in the CSM is [18:22:37] 21 for CMC [18:22:42] right yeah [18:22:51] and 50 for the RTC [18:22:54] you recognize the 21? [18:23:24] oh no, I just recognize the topology of a code for what is receiving the command, haha [18:24:02] I assume one of the handbooks must have a list of codes or something [18:24:06] the number might not be based on how it actually worked [18:24:18] the general logic is definitely [18:24:23] how it worked [18:25:29] I'll have to do some research [18:25:36] but I can implement it the same way as in the CSM [18:26:34] what is the RCCA? [18:26:37] never heard about it [18:26:54] and RCCRA [18:26:58] remote control for RC? [18:27:53] hahaha, uhh [18:27:56] good question [18:28:14] Rough Combustion Cut-off Assembly [18:28:20] where do you see that? [18:28:30] google [18:28:52] I also find a link to the LEM schematics from Ron when I google RCCA :D [18:29:06] hehehe [18:29:09] also [18:29:10] https://ethw.org/First-Hand:Rough_Combustion_Cut-off_Assembly_for_Lunar_Module [18:29:27] oh damn [18:29:28] nice! [18:30:40] seems like what Ron already scanned is for the structural support of the RCCA [18:32:08] yeah, I don't think we'll get into schematics like that for... quite a few boxes still [18:32:20] Apollo 10 Mission Report: "and deleting the rough combustion cutoff assembly" [18:32:43] so LM-3 only, or LM-3 and before only [18:32:51] ah, interesting [18:33:19] so not related to the AEAA, but interesting nevertheless [18:35:01] AlexB_88, https://github.com/jalexb88/NASSP/commit/0af84190c2ac71d99806ce329dba44894f8254d9#diff-03479c016ded22132654ab4855a8ffcdR1033 [18:35:20] is that supposed to be an "else if"? [18:35:53] I don't know how it handle the else and the if in different lines [18:36:05] and without the brackets after the else [18:36:24] oh [18:36:59] right I guess I should add that [18:37:35] or maybe it an else if [18:37:41] if that is supposed to be an else if [18:37:46] and not else, bracket open, if [18:37:56] just looked weird to me [18:39:24] else if (Panel278CSM114) [18:39:31] on the same line? [18:40:48] yes [18:40:52] that's normal how it is done [18:40:55] normally* [18:41:02] and I guess if/else if makes sense there [18:41:16] in the unusual case that both panel versions are defined, only use one [18:41:37] I have it changed in my repo [18:41:40] normally one of the two would be valid and the other NULL [18:42:28] yeah [18:42:29] everything else looked good, so feel free to do the PR [18:42:33] ok [18:44:34] Ill PR to your Orbiter2016 [18:46:23] yes [18:47:01] everything will be normal again soon in terms of branches... hopefully [18:52:42] PR sent [18:52:58] thewonderidiot, in the AOH picture of the AEAA (figure 2-67) it says "from DCA" [18:53:11] so I guess the next thing I would need to know more about is the DCA [18:53:28] I think they added a different system there in later LMs which only served the LGC [18:53:35] so I don't know much about it [18:54:41] AlexB_88, hmm [18:54:47] I think I see a problem [18:55:19] in Saturn::CreateMissionSpecificSystems [18:55:20] okay, sounds good [18:55:40] it probably creates a Panel278CSM112 even for non J-type missions [18:55:53] it checks on "ApolloNo > 16 && Panel278CSM114 == NULL" [18:55:59] and that is false, as ApolloNo is e.g. 11 [18:56:07] but then it has [18:56:07] but its all within if (ApolloNo >= 15 && ApolloNo <= 17) [18:56:09] "else if (Panel278CSM112 == NULL)" [18:56:11] oooh [18:56:12] ok [18:56:18] I don't see that on Github, right [18:56:29] because it only shows one passage [18:57:05] then it's good [18:57:21] in the future this would be handled in a mission config file [18:57:31] yeah it was confusing to figure it out for sure haha [18:57:36] maybe with a PANE278 parameter that has 3 versions [18:57:39] right [18:58:08] merged [18:58:10] brb [18:58:13] thanks [19:01:57] one thing I havent looked at yet is the initial switch positions and whether we need to add spring-loaded flags or not [19:19:29] just looking at your code again [19:19:34] I think it can be simplified [19:19:47] SaturnPanel278J *Panel278CSM112; [19:19:47] SaturnPanel278J *Panel278CSM114; [19:19:53] that probably only needs to be one [19:20:17] ok [19:20:39] I had thought of doing that too actually [19:21:17] the one thing I need though is a way to differentiate between the CSM112 and 114 for the panel bitmap loading [19:21:30] right [19:21:32] hmm [19:21:59] like [19:22:00] AID_CSM_PANEL_278_CSM112 [19:22:07] and AID_CSM_PANEL_278_CSM114 [19:22:10] yeah [19:22:21] well I guess we'll keep it the way it is right now [19:22:28] I'll think about a better solution if there is one [19:22:37] but if theres a way to simplify it Im all for it [19:24:02] I actually has 2 seperate class for CSM112 and 114 when I started [19:24:40] but they were identical so I figured I could merge them into one "SaturnPanel278J" [19:24:51] yeah, I was just thinking about it when you mentioned the initial switch positions [19:24:58] so I looked again how you did it :D [19:28:01] I think that when we get to panel 230, we'll have to have 3 separate class for each version [19:29:35] yes [19:29:49] I mean, they could have a shared base class [19:30:00] with all the switches in it that are common to all 3 versions [19:30:43] but apart from that, yes, 3 separate classes [19:31:23] right [19:32:09] maybe I'll try to implement the basics of a mission config file soon [19:32:17] panel 278 CSM112 and 114, the only difference is one label. I was almost embarrassed to make a separate class haha [19:32:31] haha [19:33:35] mission config file would be great [19:34:13] I will be working over the next few days but afterwards I plan on making the CSM pain panel bitmaps changes [19:34:39] I have ideas of how I can start with that [19:36:16] you'll love the Skylab and ASTP ones [19:36:21] all LMs changed to DM :D [19:36:51] oh right [19:37:15] I guess I could use overlays for that too [19:37:39] I dont think we should have 4 different versions of the main panel :D [19:39:14] ASTP with DM [19:39:21] Skylab missions had different labels [19:39:39] CSM/LM TVC switch for example [19:39:44] ATVC GAIN HI and LO [19:41:20] for the J-mission CSM its just the CRYO labels/switches [19:41:59] and I'll experiment with a mission config file in the mean time [19:42:00] that whole row of switches can be loaded based on the mission I guess? That config file could be useful there [19:42:02] SSU has code like this [19:42:04] if (pMission->HasTAA()) psubsystems->AddSubsystem( pTAA = new eva_docking::TunnelAdapterAssembly( psubsystems, pMission->AftTAA() ) ); [19:42:19] so instead of checking on the mission there as well, you call pMission->HasTAA() [19:42:45] what about the systems logic changes? We'll need to add the extra tanks [19:43:12] in some cases we will have to add separate classes for modified subsystems [19:43:28] in other cases a check on such a mission file parameter will work good enough [19:43:48] right [19:48:24] that sounds like a fun programming challenge for me [19:48:50] one that actually isn't "try replicate program structure of 1960s code" [19:49:30] haha [19:52:41] and feel free to modify/improve my panel code while Im away [19:58:53] I still have a switch guard to add to the SM PWR SOURCE switch [19:59:31] we dont have a sideways switch-guard it looks like, so Ill look at making that next week [20:06:30] haha, we have many things sideways, but not everything [20:07:09] we have toggleswitch and three position switches in many, many variations [20:07:22] -90°, -30°, -20°, 0°, 20°, 30°, 90° [20:09:32] yeah [20:09:49] the left and right CSM panels have weird switch orientations [20:10:32] thank god none for the J mission changes [20:10:54] wouldn't be a problem on a 3D panel I bet [20:19:47] gotta go! cya guys [21:36:39] night! [19:10:57] morning! [19:16:56] hey Mike [19:17:28] what's up? [19:18:02] added the mission config file support I was talking about yesterday [19:18:07] basically this: [19:18:12] Name=Apollo 5 [19:18:12] LMDSKYVersion=1 [19:18:13] HasLMProgramer=TRUE [19:18:13] HasAEA=FALSE [19:18:14] LMHasLegs=FALSE [19:18:43] nice :D [19:18:51] and that's in a text file and being read by CSM and LM [19:19:03] what I am thinking about now is if that should be separate files for CSM and LM [19:19:34] probably not, but it would be cleaner in some ways [19:19:45] hmmmmm [19:20:07] oh are you going to put AGC program in that file too? [19:20:16] yeah [19:20:21] awesome :D [19:20:40] I did add support already for loading that in the scenario file [19:20:58] that was the feature that was asleep in the SIM Bay door jettison branch for months [19:21:22] but config file makes more sense [19:22:12] yeah for sure [19:22:20] I'm sure I'll add parameters for S-IVB etc. at some point [19:22:30] that would suddenly be many, many config files [19:22:53] if I separate the config files [19:23:41] the way I have it set up right now is that each vessel is loading the full config file [19:24:00] so the LM would also know about CSM parameters, which it doesn't really have to [19:26:11] that seems fine [19:26:19] yeah [19:26:33] not the most efficient as the file is loaded twice (in CSM and LM) [19:27:28] CSM and LM are in separate modules (dll), that makes it a bit annoying to have it loaded once, globally [19:28:13] yeah, not worth it [19:28:59] not worth it until the config file has grown considerably in size at least [19:29:35] I have heavily borrowed the code from SSU [19:29:59] they also have a provision to load an ILOAD (in our world that is the padload) [19:30:26] but it doesn't look like they would put the whole ILoad in that file [19:30:37] instead it has the name of another file, which then contains the I-Load [19:31:20] that would work well in my case, too, as e.g. the LM would just load the name of the CMC padload, but not the whole thing [19:31:42] if I ever move the padload from the scenario [19:32:54] anyway. Have you looked for the DCA in your new documents yet? [19:33:02] I found it in the AOH [19:33:11] am actively digging through the systems handbook [19:33:31] not quite sure where it will be in here [19:34:18] communication [19:34:48] in the LM-8 handbook the DUA (digital up-link assembly), which is the successor system, is on schematic 8.2 [19:34:57] Communication System [19:35:24] 8.1 (Communications Overview) was deleted from the LM-8 Systems Handbook [19:35:59] the DCA might require the Updata Link switch in the right position [19:36:06] hmm [19:36:08] I do have 8.1 here [19:36:09] as does the DUA, so maybe look for that switch [19:38:47] LM-1 had a DCA [19:39:06] and one drawing in the Systems Handbook referes to a more detailed drawing [19:39:11] which is not in the document... [19:39:20] not seeing it on 8-1 or 8-2 [19:39:23] the LM-1 Systems Handbook we have is mostly updated pages [19:39:32] and not complete [19:39:42] hmm [19:39:55] maybe there is a separate section for it like there was for the programer [19:40:17] uhh [19:40:28] I think I just found what I was looking for in the LM-1 Systems Handbook :D [19:40:36] hahaha [19:40:45] not in a schematic [19:40:54] but there is a section "DCA System Description" [19:41:17] only one page of it [19:41:20] rest is missing [19:41:29] but that might be quite good already [19:41:39] it's gotta be in here somewhere [19:41:58] I'm sure it is [19:42:39] well it seems like the most important number is missing from the LM-1 handbook [19:43:14] https://photos.app.goo.gl/38DZe4FJGpKKUhjm8 [19:43:36] didn't we know about an earlier revision of the LM-1 Systems Handbook somewhere... [19:46:39] well the DUA in the LM-8 handbook is where the LM-3 handbook has a gap, lower end of 8.2 :D [19:47:02] oh! [19:47:03] surely that means there is a schematic just for the DCA... [19:47:05] it has its own section I think [19:47:22] sure does [19:47:33] final section, 13, "Development Flight Instrumentation" (DFI System) [19:47:59] ah [19:48:07] in the LM-1 handbook that is section 16 [19:48:22] which has a general overview which also contains the DCA [19:48:32] and referes to section 13 (LM Programer) for the more detailed version [19:48:57] I think I just found what you're looking for [19:49:54] ! [19:50:23] probably very similar to what the LM-1 handbook [19:50:26] but, complete :D [19:50:29] haha [19:50:33] one sec while it uploads [19:52:18] okay, added to that album [19:52:44] yes [19:52:52] system address [19:53:05] 101 for DCA Test, I knew that from the one page in the LM-1 handbook [19:53:25] and then RTC A, B and PRA [19:53:29] hmm [19:53:43] I didn't know LM-3 still had a PRA [19:54:14] thought that was an integral part of the programer [19:54:18] not needed if the LGC works [19:54:27] but used on the actual Apollo 5 mission [19:55:23] there's a little box in the upper left of the DCA section that says "PRA LOGIC DRIVERS (NOT REQ'D ON LM 3)" [19:55:43] ah [19:55:49] that explains it [19:55:54] so it's all the RTC [19:56:01] in the CSM that is also called the RTC [20:00:51] that does help a lot, thanks so much! [20:01:45] my pleasure :D [20:01:56] there doesn't happen to be a list of codes? [20:02:11] with the 6 bits for the RTC [20:02:23] not that I see -- that is the entire DFI section [20:03:03] that's why the LM-1 handbook is better in some ways than the later ones, haha, it does have sections with text describing things [20:03:27] so why does the LM-6 AOH not have anything on the AEAA, but the LM-10 AOH has... [20:03:38] did they add the AEAA again to later missions??? [20:04:07] hahaha [20:04:10] great question! [20:04:58] it's not very detailed, but has the AEAA connected to the DUA [20:05:18] I didn't think the DUA supported anything but the LGC [20:05:28] oh weird [20:06:13] looking at the sources used for drawing 13.1 in the introduction -- they're all Grumman drawings, LDW 360-xxxxx [20:06:26] so we'll get them from Ron eventually, but not for quite a while with numbers that high [20:08:11] he just scanned box 515, and these are going to be in... 562 and 563 [20:08:47] yeah, that will not be for a while [20:09:28] we did start getting some more interesting drawings in box 515 [20:11:02] starting at LDW 280-23000 https://archive.org/details/apertureCardBox515NARASW_images/page/n1107/mode/2up [20:12:11] great [20:12:25] was looking at this document already, but apparently not long enough [20:12:27] the top level assembly for LTA-3 and its bigger parts [20:14:30] I still haven't been able to figure out the grumman numbering scheme at all [20:15:26] I still haven't figured out the MIT one [20:15:50] haha [20:15:56] I've gotten that one down pretty well [20:16:33] I know, that's why we needed you for figuring out the optics panel revision history :D [20:17:10] there must have been another version of the AEAA. The LM-10 AOH describes it differently than the LM-3 AOH [20:17:12] hehehe [20:17:13] more relays [20:17:47] the date on those pages is 1 February 1970 [20:17:58] oh interesting [20:19:09] but I am not seeing any reference to it being re-added [20:20:13] were they planning to add the system again but didn't [20:22:19] what is that Antares rocket doing [20:22:43] the engine section almost looked stuck on the umbilical tower [20:22:49] everything normal now it seems though [20:23:24] huh, yeah I am not seeing anything from beyond apollo 10 other than the LM-10 AOH [20:25:20] I think some umbilical was initially stuck on the Antares. So it had a weird pitch a few moments after liftoff [20:25:29] maybe I am just seeing things :D [20:27:11] hahaha [20:27:23] I'm going to have to go back and look for that [20:30:13] wow yeah it does look like it followed the strongback for a bit there [20:54:23] I'd call it a yaw maneuver [20:56:34] "Transporter-erector avoidance to minimize damage, Antares has been doing that since day 1." [20:56:36] apparently [21:46:54] night! [18:34:49] hey [18:56:35] hey Alex [18:56:54] the mission config file works very well [18:57:02] already added a bunch of parameters to it [18:57:12] ah nice [18:57:25] simplifies the panel 278 code for sure, among other things [18:57:41] yeah [18:57:55] I think it works good enough that I can merge the branch for it already [18:58:00] ok [18:58:35] I’ll be home tonight, I’ll give it a test [18:59:42] the only slightly scary thing in terms of loading order was the AEA software [19:00:16] already move the selection of the AGC and AEA software version from code to the config file [19:00:47] but if the AEA managed to guide the LM into a good orbit then it loaded correctly I think :D [19:01:09] hehe [19:01:42] so I guess you made the panel 278 logic changes already? [19:02:04] For it to use the config file [19:02:39] yes [19:02:55] great [19:03:22] for the whole panel 278 there are 5 different versions actually [19:03:34] we have the first 3 now [19:03:39] I guess it just reads a variable from the config to know what version to load [19:03:49] yep [19:04:07] Skylab and ASTP also had different panel 278 configurations [19:04:35] right [19:04:35] I only added a comment on that (versions 4 and 5 for Skylab and ASTP), no logic for it yet [19:05:37] but there are already a bunch of parameters and more to come [19:07:25] https://github.com/indy91/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_aux/Mission.h#L41 [19:07:36] I guess we’ll need a parameter for the different CSM ECS configs [19:08:03] H mission and before, and J mission [19:08:26] sure [19:08:41] I plan on making those bitmaps next [19:08:44] if that's all the same in J-missions vs. before then it can be covered by the J-type mission parameter [19:08:57] right [19:09:35] and we probably want a bit smarter system on how to load subsystems and panels etc. [19:09:41] but that can be introduced over time [19:09:55] right [19:09:57] which then makes it easier to support e.g. different ECS versions [19:10:19] yeah, the systems config file [19:10:58] That will need to be updated for the J missions (or load a separate file) [19:12:02] probably a separate file [19:12:19] I guess it’s just an extra identical O2H2 tank [19:12:35] O2 & H2 tank* [19:13:00] the Systems SDK config file also covers electrical [19:13:06] so there is more [19:13:08] aux battery [19:13:31] Ah right [19:13:47] I made a switch for it :) [19:14:47] which is the only one I changed [19:14:51] as its initial position is FC2 [19:14:59] oh, also [19:15:05] the panel 278 looked weird to me [19:15:07] shadow wise [19:15:28] I tried to make them use the three position switch that is flipped 90° the other way around [19:15:45] but then there is a mismatch between actual and visual switch position... [19:15:54] right [19:16:07] Some switches use a darker grey [19:16:36] I guess the bitmap for the switch has to be changed [19:16:41] the one you didn't use [19:16:48] the order of switch positions [19:16:53] I think then it would be right [19:17:01] so I didn't change those switches yet [19:17:06] ok [19:17:26] and that SM power switch still needs a cover, right? [19:17:44] The 90 left switch wasn’t good? [19:17:47] Yes [19:18:21] you used the 90° left switch. It works correct, but it looks a bit weird to me [19:18:29] I’ll have to make a sideways cover [19:18:33] like the shadow is in the wrong direction [19:18:43] Ah i see [19:18:57] I’ll look at it tonight [19:18:58] so I tried the 90° right switch, but the bitmap has the switch positions in the wrong order or something like that [19:19:02] it wasn't used so far [19:19:12] I kept the loading of that bitmap and surface etc. [19:19:58] I guess the bitmaps of 90° left and right will look almost identical [19:20:01] except for the shadow [19:20:18] threeposswitch90_right [19:20:30] I think that needs the 1st and 3rd positions switched [19:20:58] ok [19:21:09] Should be easy to do [19:21:10] hmm [19:21:12] or [19:21:26] maybe there needs to be an otion in that SetSideways function [19:21:37] option* [19:21:50] I'll test that before any changes are done [19:22:57] it could be that the switch is then visually correct, but the up/down positions are exchanged, haha [19:25:38] yeah [19:26:07] Did Apollo 14 have some of the J mission systems? [19:26:39] it had some updates, yes [19:26:45] it already had the aux battery [19:26:56] which is a good point [19:26:59] right [19:27:05] one more config file??? [19:27:40] maybe that should be handled differently than having 3 of those systems config files [19:27:58] Sounds excessive yeah [19:28:35] Can’t there be some parts of the config file not loaded for certain missions? [19:28:52] Systems config file* [19:29:59] yes [19:30:04] it could be disconnected [19:30:21] So have one config file with all the systems [19:30:35] or at least have Apollo 14 use the Apollo 13 and before file [19:30:54] you also have systems that exist in both versions, but with different tank sizes, right? [19:31:04] sure [19:31:09] Yes [19:31:16] Hmm [19:31:22] or only additions [19:31:44] actual different tank size would be the DPS tanks, but that is not relevant for the config file [19:32:06] I think H and J have the same tank sizes, with an extra H2 O2 for J [19:32:28] But the same physical size, I think [19:32:39] But I’ll have to check again [19:33:03] it is also not technically required to have a system in the config file [19:33:12] the additional tanks could probably be code only [19:33:15] I think that is possible [19:34:15] either that or have them in the config and then disabled in code [19:34:40] right [19:34:50] maybe I try that with the aux battery, have it in code only, just as a test [19:35:00] many ways to do it I guess [19:35:41] code only would be more efficient, as it then doesn't need to simulate disconnected tanks [19:37:11] So the same tank would be loaded from the config file, then treated as tank 3 in code? [19:38:12] no, the two options are: tanks 3 don't exist at all in the config and only get added in code for J-type missions [19:38:35] or third tanks exist in the one config we have, but get disabled/disconnected in code for non J-type missions [19:39:12] Ok [19:40:08] I guess whichever will be the most efficient [19:40:30] of course it's much more than just adding tanks or not [19:40:36] aux battery [19:40:43] for switching it needs that SM power switch [19:40:54] which gets power from a panel 226 CB [19:41:04] panel 226 is also very different for the J-type missions [19:41:17] we do have Apollo 14 CSM CB charts if we need it [19:41:36] yeah that would be great [19:42:02] SM power, that’s on 278 right? [19:43:07] yeah [19:43:19] oh right, Apollo 14 also already had the 3rd O2 tank [19:43:33] looks like panel 226 is the same for Apollo 14 and the later missions [19:43:39] so that makes it a bit easier [19:44:15] of course that requires the whole panel 226 to be made dynamic like the panels we added [19:44:19] I’d like to see Apollo 14 panel 278 [19:44:30] yeah [19:44:44] panel 278 is same as pre Apollo 14 [19:44:59] ok [19:45:15] https://history.nasa.gov/afj/ap14fj/pdf/csm_sys-data.pdf [19:46:12] thanks [19:46:57] I have to go, cya! [19:47:15] cya [20:08:41] afternoon! [20:13:41] hey [21:10:52] night! [16:39:35] hey [16:43:33] hey Alex [16:43:58] panel 226 is a bit easier than I thought. Only the labels and the wiring has changed, the CBs are all in the same place [16:44:06] so we can use the same circuit breakers for all missions [16:44:12] just wire it differently [16:44:18] and a separate bitmap of course [16:45:55] oh and about panel 278 [16:46:02] we need another one for Apollo 14 :D [17:03:20] oh 14 is different? [17:04:42] yeah, it needs the two switches to the right [17:04:51] for power and O2 tank 3 [17:04:58] but it has none of the science switches [17:05:22] in that systems data document I gave you that is not even mentioned [17:05:38] but it is in the CSM Systems Checklist from shortly before launch [17:13:20] I wonder if we should split panel 278 even further [17:13:31] have the two switches to the right separately [17:25:52] yeah [17:26:21] so no new switches, but just remove the 2 experiment covers switches & CB [17:28:34] yeah, that's the Apollo 14 config I think [17:57:00] adding O2 tank 3 to the systems in code, very difficult [17:57:05] adding the aux battery, not so bad [18:04:21] interesting [18:04:27] what makes the tank harder? [18:05:42] a lot of parameters to initialize the tanks [18:05:56] also, the function that adds tanks from reading lines in the config file is quite complicated [18:06:04] beyond just reading parameters [18:06:16] and that function can't be called from somewhere else in the code [18:06:23] only reads the config file [18:06:38] right [18:06:42] I guess what I could do is add a modified version of that tank adding function [18:07:49] Ill start on the J mission ECS labels/switches today [18:09:35] ok [18:30:38] would it be easier to just have a separate config file after all? [18:32:22] yeah, maybe [18:32:31] I'll try that [18:32:37] just testing a few things right now [18:32:46] just to see what is best [18:33:58] morning! [18:35:37] hey Mike [18:38:35] what's up? [18:40:29] testing a few things, what we would have to change to add some of the systems of the Apollo 14-17 CSMs [18:40:40] O2 tank 3, additional battery [18:40:46] and lots of panel and wiring differences [18:58:06] oh I didn't know that much changed [19:42:10] oh yeah [19:42:22] a bunch of stuff to support the additional O2 tank and battery [19:42:46] and Apollo 15-17 had a whole bunch of science equipment which needed controls [16:41:58] morning [16:42:56] hey Alex [16:43:14] how did I get the basics so wrong with the cryo tanks? [16:43:22] Apollo 14 added an O2 tank [16:43:31] and then Apollo 15 added an H2 tank [16:43:49] so no, Apollo 14 and later are not identical in the CSM EPS [16:43:56] yeah [16:44:23] once I realized that and how complicated that could be to implement I moved on to another topic :D [16:44:37] failure support in the PAMFD [16:46:02] I had started that a while back [16:46:11] ah yes [16:46:16] already supports most of the failures we can have [16:46:31] should be fun playing around with that [16:46:41] and I'm thinking about moving all the failure code to the MFD [16:46:50] so have a button randomize failures [16:48:20] I also discovered bugs in testing [16:48:35] an engine failure at T-1 second should stop a launch [16:53:29] but it's definitely much nicer using the MFD than having to add failures to the scenario [16:56:03] yeah I would imagine [16:56:26] I think its a good edia [16:56:28] idea* [17:41:47] with that I can also delete all saving and loading of failures [17:41:54] or can you think of anything why we would need that? [17:46:11] hmm not really [17:47:33] almost all failures are related to launch [17:48:07] the other ones would be randomized or set not too long before they would occur [17:48:09] reentry [17:48:21] maybe IU platform failure during TLI [17:51:15] what would be nice for randomized failures is a way to also specify a max number of failures, for example if you want just 1 random failure, not many over and over [17:52:12] in my tests it made it hard to test one specific event like platform random failure when I was also getting other random failures like engine failures [17:53:03] but also if you want to fly a whole mission and get 1 random failure of any system at any point during the mission [17:53:23] right [17:53:45] or you can say I want max X number of random failures [17:53:55] the last part is probably more relevant once we have more types of system failures [17:54:00] not just launch and landing [17:54:07] right [17:54:46] and your first part, the first thing I did was that you can set specific failures [17:54:55] that's for testing [17:55:15] and what also was supported before and is now easier is a failure multiplier [17:55:32] that is one way to control how many failures you get [17:55:43] at the normal rate you get about 1 failure in total it seems [17:55:56] in doubt you can also reroll the dice [17:57:00] one aspect that isn't covered right now is "secret" randomized failures [17:57:25] so as you were talking about, maybe 1 random failure that it doesn't show to you [17:57:37] maybe an input where you can say, I want 1 or 2 or 10 failures [17:57:44] and it randomizes the time they happen [17:58:52] where I am right now is having moved all that you could do with lines in the scenario or randomization from the Saturn class to the MFD [17:59:15] so nothing really new yet, just a nicer interface [18:20:34] morning! [18:22:28] hey Mike [18:22:38] indy91, yeah that sounds good [18:29:15] hey [19:09:34] there will be a dedicated engine failure page I guess? [19:11:14] yeah [19:11:33] I have all the switch and SECS failures (all discrete failures, on or off) on one page right now [19:11:40] and all the Saturn specific failures on another [19:12:03] which is the engine failures, IU platform and S-IC/S-II separation [19:12:33] right [19:12:35] not sure why we only had that one sep failure [19:12:53] if those fail to separate it's an abort anyway [19:13:20] same for the S-II interstage [19:13:50] the engines would overheat and explode before you can do S-II/S-IVB direct staging [19:14:34] according to the mission rules you have about 90 seconds from S-II ignition until things get bad if the interstage doesn't separate [19:15:52] before you can do S-II/S-IVB direct staging and still reach orbit* [19:16:54] I see [19:17:56] I could easily add failures for all the stagings [19:18:35] sure [19:19:51] S-II/S-IVB sep failure might be the most interesting one, as that is a mode IV abort case [19:24:26] havent tried a mode IV yet [19:24:56] that surprises me, haha [19:25:12] what about mode III? [19:25:32] I think so yes [19:25:37] its been a while though [19:25:58] mode 4 is SPS to orbit? [19:26:04] yeah [19:26:23] some later missions, I think only Skylab and ASTP, also had a mode IIIA [19:26:47] mode IIIB was the normal mode III, so SPS back retrograde to not fall on Africa and instead in water [19:27:08] IIIa was a prograde SPS burn to also hit that target in front of Africa [19:27:25] makes the wait for the recovery crew shorter :D [19:33:17] yeah [19:34:15] on my end I am just starting the panel 2 J mission cryo labels [19:34:43] nice [19:34:49] the switches themsleves are in the same order, just the labeling different, and switch type in some cases [19:35:33] 3 position instead of toggle switch for some of them [19:36:06] for Apollo 14, was the panel the same as the J missions? [19:51:10] hmm [19:51:45] I fear it's another intermediate solution [19:53:46] the two O2 fans switches were deleted from Apollo 13 to 14 [19:54:16] there were still two cabin fan switches for 14 [19:54:41] so just the 2 O2 fans deleted? [19:55:34] I cant find any images showing that panel [19:55:37] for Apollo 14 [19:58:20] what we could do now is not worry about Apollo 14, and just do the J config if that makes things easier in the short term [19:59:06] Apollo 14 is short enough that it can be flown with the Apollo 13 and prior config just fine [20:06:34] I think it's the same number of switches [20:06:48] minus 2, and at least plus for the H2 tank 3 heater [20:07:01] H2 tank 3 fan [20:07:15] no [20:07:16] nonsense [20:07:26] O2 tank 3 heater [20:07:29] that :D [20:09:12] but there has to be some additional switch to monitor the tank 3 quantity and pressure [20:09:39] it's not like the Apollo 15 config [20:09:54] the Apollo 15 mission report mentions changes [20:10:23] oh [20:11:07] it is like the Apollo 15 config [20:11:13] with those switches [20:12:12] still would mean that Apollo 14 had one unused switch there [20:13:19] no [20:13:21] haha [20:13:24] I am confusing myself [20:13:40] I have it now [20:13:57] Apollo 14 had the Apollo 15 config of that panel 2 switch row [20:13:59] except [20:14:08] no H2 Fans 3 switch [20:14:17] but two instead of one cabin fans switch [20:14:25] then it works [20:14:39] that makes sense [20:15:02] feels like the issues I have with the RTCC MFD all the time [20:15:06] running out of buttons [20:15:39] and then reduce two cabin fans switches to one [20:15:50] sure, that works :D [20:15:58] so all switches from PRESS-CRYO IND QTY are moved to the right 1 spot? [20:16:06] for Apollo 14 [20:16:13] compared to the Apollo 15 config [20:16:37] I think so [20:16:55] there are some closeup shots from onboard video [20:17:04] but it's so blurry that you can't really see anything [20:18:05] Ill start with the Apollo 15-17 config [20:18:16] then modify it for 14 afterwards [20:18:52] hmm [20:19:08] from what little I can see it looks like the order if switches is still more like pre Apollo 14 [20:19:25] cabin fans 1 and 2, that is clear [20:19:44] then H2 heaters 1 and 2 [20:22:26] then the cryo press switch [20:22:51] no [20:22:57] so difficult to tell... [20:43:58] UHCL has a bunch of Apollo 14 checklists we don't have yet [20:44:16] among them CSM Contingency Checklist and CSM Malfunction Checklist [20:54:10] yeah [20:54:18] I can request some [20:56:53] the Apollo 15 CSM Contingency Checklist has a "dormant configuration list" [20:57:04] a list of all switches in a specific, in this case power critical, position [20:57:13] a list like in the launch checklist [20:57:24] so the Apollo 14 one probably would have that, too [20:59:37] right [21:06:56] night! [16:14:09] hey [16:21:54] hey Alex [16:22:09] I pushed my update with the failure simulation stuff moved to the PAMFD [16:22:30] also, I found a copy of the AS-504 Saturn V Flight Manual. Don't think we had that yet. Do you want it? [16:22:40] I saw, I have just updated to it [16:22:43] sure [16:22:47] ok [16:23:29] takes a bit to upload [16:23:43] it's somewhat available online, but difficult to get. And not as a whole [16:24:06] I put together the complete PDF though [16:28:52] ah great [16:30:30] the Saturn V flight manuals usually have the CSM panel layout I think [16:30:50] yes [16:30:50] I wonder if SA-509 one is available somewhere [16:31:04] that's how I found the SA-504 one actually, I was looking for 509 [16:31:06] without success [16:31:08] Apollo 14, so we can look at the CRYO switches layout [16:31:17] ah right [16:32:03] oh [16:32:07] UHCL has that one [16:32:13] 39159 08/15/1969 SATURN V flight manual SA-509 ( SATURN APOLLO 509 ) APOLLO 071-55 [16:32:23] hmmm [16:32:27] I do not like the date [16:32:34] I don't think it's worth requesting just for the panel [16:32:37] it won't be right [16:32:55] the CSM Contingency Checklist might be more useful for that purpose [16:33:11] UHCL also had 504 [16:33:23] but I found it elsewhere [16:34:32] ok [16:40:01] thanks! [16:43:10] no problem [16:45:24] I finished the Apollo 15+ cryo switches/labels last night [16:46:02] https://www.dropbox.com/s/2724f3mfh7oo3or/Screenshot%202020-02-19%2009.44.49.png?dl=0 [16:46:25] nice [17:06:32] right now I am trying to load an overlay bmp, but for some reason its not showing in-sim [17:15:58] forgot the oapiSetSurfaceColourKey thing? [17:16:36] nope thats in [17:17:41] in what function are you oapiBlt'ing the bitmap? [17:18:53] clbkPanelRedrawEvent [17:19:01] same as we did for the other J panels [17:19:12] just a test for now [17:19:25] hmm [17:19:27] no idea then [17:19:52] its weird [17:20:09] I did it the exact same way I did for panel 277,278 [18:43:35] alright well I narrowed it down a bit [18:45:13] the bitmap itself is being loaded [18:45:40] its the if (id == AID_CRYO_IND_J) check in clbkPanelRedrawEvent [18:46:45] if I call the oapiBlt without the if check, then it loads (very weirdly of course, with it repeated all over the panel) but at least I know its loading it [18:47:00] at 1st I thought the bitmap was not being read at all [19:04:30] ok [19:04:55] I got it to load by using the already existing AID_CYROTANKINDICATORS [19:05:50] I think what Ill do is make that panel area load the J labels above it when appropriate [19:06:19] the labels bitmap itself is a small strip 269x9 pixels [19:06:35] above the cryo indicators [19:13:26] maybe it was some issue with overlapping panel areas? [19:13:37] but yeah, I think only loading the labels makes sense [19:14:19] no not overlapping [19:14:34] it was because I had created an AID only for the labels [19:15:35] but I think it needed a switchrow.init further down for that new AID [19:16:16] but I didnt need any switches for it so instead I am just using the already existing one AID_CYROTANKINDICATORS [19:21:07] all this makes me want to implement a better system for different panel configs, but for the 3D panel as that is what we want to have at some point anyway [19:21:25] guess I'll do another round of "learn a new Orbiter API feature without planning to use it anytime soon" [19:23:17] right [19:23:59] wasn't that what you just added a few days ago? [19:31:51] or you mean the whole panel handling in general [19:51:46] ok labels above the cryo indicators are displaying correctly [19:55:52] the oapiBlt checks on pMission->IsJMission() [20:07:19] my monitor died [20:07:27] that's been coming for a long time lol [20:07:40] finally I can justify getting a new and better one, haha [20:07:51] haha [20:10:03] expect my future videos to be proper 1080p [20:10:37] right [20:11:03] I have an Asus VG278Q gaming monitor, love it [20:11:27] good color tones and such [20:12:32] oh, just checked the chatlog, I was talking about 3D panel earlier [20:12:46] ah ok [20:13:18] if/when we tackle that it's probably good to implement something with all the panel differences in mind [20:13:25] from the start [20:13:43] yes [20:14:03] like for the issue I am confronted with now haha [20:14:18] the different cryo switches versions [20:16:20] AID_CYROTANKSWITCHES, that is the row of cryo tank switches [20:17:43] what I was thinking is we have separate switch classes for that row, for J mission and pre J? [20:18:23] a bit like panel 278 [20:18:51] either that or give each switch a generic name [20:19:00] they have numbers like S138 [20:19:04] oh right [20:19:14] and then use them differently depending on the mission [20:19:28] that's how I was thinking about doing it with the panel 226 CBs [20:19:42] one thing is 1 switch is a different type for the J missions [20:19:53] 3-pos instead of toggle [20:20:42] actually, 2 are changed [20:20:49] and that's why we need a whole new system for these [20:21:01] or at least, it should be dynamically loaded [20:22:58] by which I mean, right now the Saturn class directly has the switches there as objects [20:23:29] and what it should be is that the switches aren't starting to exist until it is known which version of the panel to load [20:23:56] right [20:24:54] and what makes that better is to have a system where panels are registered in some centralized way [20:25:03] so that you don't even need to manually delete them [20:25:35] SSU takes this abstraction even further, although it has that somewhat based on how it really worked in the Shuttle [20:25:46] I believe basically all switches were connected to the computer [20:26:23] so all switches had some fairly uniform way of interacting [20:26:34] doesn't really apply to Apollo [20:27:01] but we might still want to have an additional abstraction layer, which would rewiring easier [20:27:27] yeah [20:27:43] hopefully not too hard to implement [20:29:30] should be possible, the dynamic panel handling can definitely be "borrowed" for the most part from SSU [20:30:00] how SSU handles different wiring is by having the switches "register" in a central place under some name [20:30:30] and anything that connects to it needs to call that names, at least when it gets wired together [20:30:46] that way, if the panel doesn't even exist for a mission, no harm is done [20:30:53] there just wouldn't be a connection [20:31:34] I see [20:36:46] I think I'll get basically the same monitor as you, but 24 inches [20:37:02] not enough space for 27 [20:40:04] right [20:42:28] https://www.dropbox.com/s/xtonwjltvhhiddl/Screenshot%202020-02-19%2013.41.30.png?dl=0 [20:43:09] so I have added the background overlays, but I did not touch the switches themselves yet [20:44:02] I think I will comment the oapiBlt until a system for the switches is figures out [20:46:03] yeah [20:46:21] I think that has to be done in one go, don't want to make the J-type missions worse instead of better [20:46:39] your monitor has speakers, right? Are you using them? Any good? [20:47:14] it does [20:47:37] they are not bad quality-wise but the max volume isnt anything very loud [20:47:48] hmm, ok [20:48:00] I am using them right now, yes [20:49:07] a feature I like on mine is g-sync [20:49:47] certain applications like P3D are pretty fluid with it on [20:50:58] yeah, unfortunately the 24 inch version doesn't seem to have that [20:51:45] although [20:51:50] there are several 24 inch versions :D [21:12:38] alright I am ready to PR the J mission cryo panels, added in code but disabled for now [21:13:13] you can test it by uncommenting the oapiBlt [21:14:10] sure [21:14:17] when I have a monitor again, haha [21:14:41] got rid of an old one last year I could have used in the mean time... [21:15:36] I have decided on the ASUS VG248QE. A bit cheaper, but no G-Sync [21:16:36] should still be good [21:17:00] I think so, yeah [21:18:38] the current monitor works for half a second and then stops working. First thought it was a PC issue, but it does that with both DVI and VGA and any connected computer [21:19:01] I need to transfer some files from the PC on my phone. Will be fun doing that, half a second at a time... [21:19:41] I bet I'll break it completely in that process [21:19:58] PR sent [21:21:19] yeah. What are all the changes in the satswitches? [21:21:28] in the oapiBlt calls [21:21:37] ah yes [21:22:00] those changes are compatible with both old and new cryo versions [21:22:51] I had to modify the AID_CYROTANKINDICATORS's top pixel location to include the label overlay [21:23:04] oh I see [21:23:08] and for that had to shift the switches/indicators by the same amount [21:23:16] you moved the location of them [21:23:20] right [21:23:34] just the location is changed down 20 pixels [21:23:56] couldn't you have moved the panel area? [21:24:08] and then also the switch location [21:24:16] but not the switch code [21:24:34] that seems like like a less invasive change [21:24:53] well I did for the switches [21:25:18] but the H2/O2 inicators needles init fucntion tont include an overload for the location height [21:25:20] ah right [21:25:27] dont* [21:25:46] so I had to go directly in the switch code to change it [21:27:15] does that not cause problems at the upper or lower end? I am having trouble visualizing the effect of changing that code [21:28:08] well the aid is moved up 20 pixels, and the switches moved down the same amount [21:29:24] the reason was so that I could add the label changes at the top of the H2/O2 qty/press indicators [21:29:36] right [21:29:44] so before the panel area included the labels [21:29:48] and have the label strip load with the AID_CYROTANKINDICATORS [21:32:30] you moved the upper end of the panel area lower, to not include the labels, is that right? [21:33:30] no [21:33:45] the panel are was in the way of the switch labels [21:33:49] not the indicator labels [21:33:54] panel area* [21:34:38] I guess my question is if the new panel area still contains the whole indicators [21:34:59] not I only moved the top part of the panel area up, so the panel area is now taller [21:35:12] so that it covers those labels above it [21:35:27] because the labels load based on that panel area [21:35:38] so it needs to cover it [21:35:41] it's late, sorry :D [21:35:45] haha no worries [21:35:52] so that's what you did [21:35:56] indicator panel area larger [21:36:13] yes [21:36:15] and I guess the indicator needle is references from above [21:36:22] yes [21:36:31] hmm [21:36:35] and moved down the same amount that I moved the top up [21:36:41] I still don't really like it [21:37:05] if you can't give the indicators an offset then that needs to be implemented [21:37:14] instead of changing the indicator code [21:37:19] oh I agree [21:37:28] I thought of doing that [21:38:31] I can change the init function to include the offset [21:39:10] I think I'll take a good look at it tomorrow and then have a better idea what and if it should be changed [21:39:20] sure, no rush [21:39:54] the indicators are probably all the same in the DoDrawSwitch [21:40:09] just different based on the scaling of the displayed value [21:40:16] wouldn't want to change that really [21:40:18] I guess it doesn't help that I have this daunting PR and your looking at it from your phone :D [21:40:40] haha, it's all good, it's my netbook [21:40:54] right [21:40:55] which is not much larger than the phone really [21:41:03] and has about a quarter of the pixels [21:41:22] ouch [21:42:34] that's a pretty good guess actually [21:42:37] phone has 2560x1440 [21:42:54] netbook has 1376x768 [21:45:49] data transfer to phone achieved [21:46:00] only had to switch on the monitor 15 times, not too bad [21:48:01] nice [21:51:46] have you tried the failure stuff in the PAMFD yet? [21:52:22] some of the failure types were actually quite buggy, found those when I tested it after moving it the MFD [21:53:42] I did actually [21:53:57] gave myself a platform failure [21:55:59] I think it works and looks decent enough as the first version [21:56:16] we can get creative from there on [21:57:00] yeah, I like it [21:57:03] let's see how many on-switches I need to shut down the PC in a normal way [21:57:11] good night! [21:57:15] cya [15:52:30] hey [15:54:08] hey Alex [15:54:21] didn't have time yet to look at your PR [15:54:50] well, I just got started I mean [15:55:36] because the indicator classes are so specialized and only used once or twice I actually think now that it's ok to merge it as it is [15:56:20] no rush! the main part of it is commented anyway so its not like were in a hurry to get it in lol [15:56:55] right [15:58:49] well getting your PR merged is the only thing I can work on right now anyway, so I might as well focus on that, haha [15:59:22] replacement monitor is due on Saturday [16:01:09] I merged it [16:02:24] thanks [16:02:46] I think Ill do the panel 226 changes next [16:03:25] I still also have to fix the switches (shadows) on 278 and add the cover to that one switch [16:03:52] oh and add the Apollo 14 version of 278ç [16:06:19] pretty sure there is only one additional version for panel 226 [16:06:22] Apollo 14-17 [16:06:28] but I got that wrong before, so what do I know :D [16:09:05] is there a way right now to specify Apollo 14 in the mission file? [16:12:22] for panel 226? [16:12:40] yeah [16:12:58] and 278 I guess [16:13:18] and the cryo switches if we ever find any differences [16:13:32] that probably should be a "has 3rd O2 tank parameter" [16:13:38] and no, that's not in yet [16:13:56] and that would be for Apollo 14 and get's overriden by the J-type mission parameter [16:14:14] which then is everything for the 2rd O2 and H2 tanks [16:15:15] or alternatively we make it a panel specfici parameter [16:15:21] panel 226 version [16:15:33] that also works, although probaly requires more parameters in total [16:21:21] you can add parameters yourself if you want [16:21:41] sure [17:29:42] I think Ill add a 3rd O2 tank parameter [17:30:55] hmm, Panel278Version [17:31:38] I could just make the Apollo 14 panels read that [17:32:06] even cryo when we figure out if there are any changes [17:32:43] that way I dont have to add another parameter in the mission file [17:33:24] well, maybe we would need a 3rd O2 tank parameter anyway, in other areas of the code [17:35:43] I dont have any cryo panel changes that I can make right now anyway for Apollo 14 [17:36:19] just the panel 278 changes so I will simply add a Penel278Version and down the line if needed we can add the parameter for the 3rd O2 tank [17:40:06] ok [17:40:51] I will also need to make a separate class for the Apollo 14 panel 278, since there are less switches [17:41:17] all J missions use Panel278J [17:49:09] might be a good case to have one class for all of panel 278 [17:49:24] and dynamically load the switches [17:49:39] the panel278 class constructor would have a parameter with the version number [17:49:52] and the switches are loaded accordingly [17:52:02] ok [17:59:56] but that needs a bunch of housekeeping coding [18:07:00] I'll let you take care of that then, then I'll make the Apollo 14 panel 278 [18:07:25] today Ill fix the switches and add the cover [18:08:03] sounds good [18:49:52] indy91, so for the threeposswitch90_right, if I see it correctly, needs the left and right sides of the bitmap interchanged [18:50:01] then it should display right [18:50:59] and the middle one flipped [18:51:12] basically all shadows to the left [18:51:22] no, right* [18:52:45] actually the middle one is fine I think [18:53:15] the shadow is correct on it already but for some reason whoever made this made the left and right sides point inward [18:57:17] yep that did it [19:16:42] yeah, the shadow was right [19:17:12] the switch was unused before, so whoever created it didn't test if the switch behaved right [19:20:31] the shadow was correct on all three switch positions, right? [19:22:14] yes [19:22:42] pretty much the only difference to the other bitmap I think [19:22:47] direction of shadow [19:31:50] now I am doing the cover on SM PWR Source switch [19:32:00] that is a sideways cover [19:32:26] which isnt even supported yet, so I will have to see about adding that [19:38:27] it should be pretty much the same as a normal cover code-wise [19:38:31] except click area maybe [19:41:17] yeah, I am looking at that right now [19:41:50] maybe a set sideways can be added to the GuardedToggleSwitch class [19:44:12] hmm, actually it may support a modified bitmap [19:48:18] I'm sure it does, but it still needs a different click area [19:48:27] set sideways functions seems like a good idea [19:49:33] right [20:17:27] I think the right mouse click is for the entire area of the guard [20:17:48] its not like on half to open and other half to close [20:18:09] so it shouldnt matter what orientation it is [20:18:21] one* [20:21:33] ah right [20:21:49] so it could work just by a bitmap swap? [20:22:56] I think [20:23:22] 1st test is good, but I think I may have made the order wrong on the bitmap [20:28:39] ah [20:29:16] not the bitmap, I have to set the xoffset in the InitGuard call for the 3pos guard [20:33:26] yep that did it [21:00:09] night! [16:52:23] hey [16:56:30] hey Alex [16:56:41] I think we did bad with that guard switch on panel 278 :D [16:57:07] guarded* [16:58:21] the bitmap was correct [16:59:26] because right now it shows the switch position "up" as "down" [16:59:42] we should have changed the click area only and left the bitmap alone [17:08:06] hmm, I am trying to understand, we only have an up/down switch guard bitmap before, so we need a new bitmap anyway? [17:08:59] I'm not talking about the guard, but the switch itself [17:09:16] the guard has some bug as well it seems, but that's not what I mean [17:09:22] the switch itself now displays correctly [17:09:43] but its up position in the logic is the displayed down position [17:09:49] so the bitmap was correct before [17:09:52] I think [17:10:01] I'm trying the fix right now [17:10:13] a fix* [17:12:30] I thought the click area didnt matter, as a click anywhere would have the same action [17:12:56] right-click for the cover/un-cover I mean [17:13:35] oh the switch itself [17:13:40] I see [17:14:22] it should default to the switch position down [17:14:24] but it's in up [17:14:42] but somewhere my logic is failing [17:17:01] ah, it didn't triger a rebuild [17:17:11] but I think I have it now [17:17:26] old bitmap, and an additional option for the click area [17:17:37] before we just had sideways false or true [17:17:57] but now I implemented 0 and 1, the old false and true, and also 2, which is sideways right [17:18:25] where the action of the left or right side click is exchanged [17:18:54] in your PR it also displayed the guard weird [17:19:04] but it was missing some guard initialization or so [17:19:07] looks good now [17:19:13] ok [17:19:26] SMPowerSourceSwitch.SetGuardResetsState(false); [17:19:29] needed this [17:19:35] ah [17:20:23] hmm [17:20:38] ok now it looks and works right with the guard open [17:20:45] but with it closed it has to be switched [17:20:59] you implemented it to work with the modified switch bitmap [17:22:41] then we have it right [17:24:14] yeah [17:24:43] so what I need you to do is exchange the last and the third last position of the sideways guard bitmap [17:24:54] so that the order agrees with the not-sideways one [17:28:15] probably easiest if you give me that modified bitmap and I do the commit, as I already have the whole fix apart from that [17:51:05] ok sounds good [17:51:18] Ill have it in a few minutes [17:52:50] great [17:59:41] I also implemented the beginning of some dynamic panel code [18:00:21] it's not much yet, not so easy to make compatible with switch rows, and the way switches get registered, but at least the panels that are not always loaded are now managed so that they are automatically deleted [18:00:48] doing the same thing with optional subsystems will be easier [18:06:32] nice [18:10:44] also nice is my new monitor [18:10:54] finally no 16:10 anymore [18:11:08] nothing is properly compatible with that anymore [18:11:11] well, NASSP is :D [18:11:40] haha nice [18:12:10] so you settled on the Asus one you spoke of? [18:12:15] yes [18:12:27] 24 inch, 1080p, 144Hz [18:13:18] expect some nicer looking videos from me in the future [18:13:41] good screens for sure, Ive had mine for a few years now with no issues [18:13:50] morning! [18:13:53] still have to adjust the colors a bit I think [18:13:55] hey Mike [18:13:58] hey [18:14:00] oh man you have a proper screen now :D [18:14:16] my old one was a proper screen [18:14:20] from a 2008 perspective [18:14:25] hehehe [18:15:00] 12 years for a screen, I'd say that is a great investment! [18:15:39] yeah, pretty good [18:15:49] I couldn't even remember when I got it [18:15:54] but all the Amazon reviews are from 2008 [18:15:59] so it must be around that time [18:16:10] definitely before 2010 [18:17:22] I'd love to do a video on the LOI abort mode which has a 30 minutes activation checklist for the LM [18:17:47] pretty intense [18:19:11] or maybe a video to advertise the new way to generate failures with the PAMFD [18:20:47] yeah [18:20:49] https://www.dropbox.com/s/8j5oibf8nfktq84/SwitchGuards90_right.bmp?dl=0 [18:20:55] or maybe a 5 hour tutorial on how to use the mission plan table in the RTCC MFD... [18:22:16] thanks! [18:25:43] I think the panel is all correct now [18:25:48] I'll do the commit soon [18:26:26] ok [18:26:37] Ill take on panel 226 next [18:27:05] I guess just label changes for the J missions [18:27:23] and Apollo 14 [18:27:46] pretty sure, even with the addition of the 3rd H2 tank, 226 stayed the same for Apollo 14-17 [18:27:47] right [18:30:48] which is interesting for the H2 tank heaters [18:31:14] if I understand the systems handbook correctly the third H2 tank does have heaters, but they are only used when powered by GSE [18:34:52] interesting [18:35:28] also, there seems to be no switches for the O2 Fans in the J missions [18:35:58] to be fair those were apparently very dangerous switches :P [18:36:26] true :D [18:38:08] only trust GSE with it, not astronauts :D [18:38:40] there are no O2 fan switches because there are no O2 fans [18:38:43] they got removed [18:39:53] heaters were changed a bit it looks like, but essentially the same [18:56:51] AlexB_88, I pushed the update [18:58:41] I've stared at many drawing numbers in the last few days [18:58:53] all IU or GSE/ESE [18:58:58] oh man [18:59:09] and KSC launch procedures [18:59:19] what's the format of those numbers? 40Mxxxxx, 50mxxxxx, 615xxxx? [18:59:20] pretty sure those will all be at NARA Atlanta [18:59:33] 40M sounds familiar [18:59:35] yeah we really need to figure out what all is at NARA Atlanta [19:00:06] 50Z35300-001 [19:00:20] Flight Control Computer, Saturn V, 504-515 [19:01:17] or my usual favourite [19:01:23] 7910418-031 [19:01:33] EDS Distributor, 506 [19:01:41] as in, AS-506 [19:02:28] I've mainly been thinking about the umbilicals [19:04:49] why, what are you working on now? [19:05:33] well it's my long time goal to implement the EDS prelaunch tests properly [19:05:55] that involves a semi-automatic test procedure [19:06:11] so a sequence of commands from the ground computers [19:06:35] but also all the right commands from the computer, through the electrical support equipment to the IU [19:06:37] mainly IU [19:06:57] the Saturn Systems Handbook skips over a lot of ground signals [19:07:45] and apart from tests the ground electronic still needs a bunch of improvements [19:07:49] terminal countdown sequencer [19:07:53] countdown holds [19:08:13] if certain conditions aren't fulfilled, like happened on Apollo 17 [19:08:32] there is a bunch of it already implemented, but not enough :D [19:08:46] you can already stop the launch by e.g. switching EDS power off [19:09:06] I just found a lot of documents with a lot of drawing numbers [19:09:09] and 0 drawings [19:09:13] yeah [19:09:20] and I'm guessing none of those drawings show up at NARA :/ [19:09:33] at least, not in Fort Worth [19:09:40] no, not Fort Worth [19:10:05] but maybe somewhere [19:10:52] definitely all the KSC launch procedures at NARA Atlanta [19:11:09] I think I know which document would have all the steps of the EDS test [19:11:38] oh nice [19:13:20] the procedure has a lot of crew involvement [19:13:25] it happens at about T-1:30h [19:13:31] but there is no checklist for it [19:13:35] not a crew one anyway [19:13:50] the LCC people guide the crew through it [19:15:01] that's the procedure I found in one of the Apollo 11 audio loops and wrote down every step as best as I could [19:15:09] but it's not the same thing as the original documentation [19:16:06] oh, Mike [19:16:07] https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19660022072.pdf [19:16:14] look at PDF page 256 [19:16:22] looks interesting? :D [19:16:46] some connectors and their pins for the FCC and what they do [19:17:27] oh nice :D [19:17:31] thanks! [19:17:44] but it's for a Saturn IB, different in many ways from the Saturn V one [19:22:57] hmmm [19:23:05] how different are we talking? [19:36:05] in terms of inputs [19:36:09] same rate gyros [19:36:32] Saturn IB gets an additional input for an accelerator that is used in the S-IB control law [19:36:47] some difference in mode switching and gain scheduling [19:36:56] mainly due to lack of a S-II [19:37:14] S-IB and S-IC both have 4 engines that gimbal [19:37:18] so that should be similar [19:37:42] S-IC engine cant [19:38:10] Saturn V will have some more relays and inputs for them [19:41:38] so some significant differences, mainly due to the additional stage on a Saturn V, but otherwise probably not too different [19:42:23] a lot of the logic for the FCC is actually happening in the control distributor and not in the FCC itself [19:42:31] so that helps making them more similar I guess [19:47:27] oh that's where I saw the 40M [19:47:33] 40M433221 [19:47:38] IU Electrical Schematics [19:47:48] maybe that 40M33221 [19:47:51] make* [20:23:02] hmmm interesting, okay [20:30:58] well, I'm sure you will study the FCC much more when the time comes :D [20:35:18] haha yep! [21:09:50] night! [15:29:20] hey [15:29:53] hey Alex. I got here 40 seconds before you :D [15:34:10] haha [15:34:43] this is the earliest i've logged on in a while I think [15:35:00] still probably pretty late for you ;) [15:35:14] oh I haven't had time to be early here as well [15:35:23] not my usual 2pm, haha [15:36:00] so what's next [15:36:43] one thing I'd like to implement is the LCC [15:37:11] just an optional way of interacting with the vehicles on the launchpad for now [15:38:50] SSU has an LCC vessel in the simulation and also a LCC MFD [15:39:05] ah, right [15:39:40] if we ever implement the LCC consoles it would probably make more sense to have them as an external application, like the telemetry client [15:39:59] MFDs aren't the best for interactive consoles like that [15:43:54] http://apollolaunchcontrol.com/Apollo_Launch_Control/Control_Panels/Pages/IU_Panels_files/Media/BB13%20EDS%20PREPARATION%20FR1/BB13%20EDS%20PREPARATION%20FR1.jpg [15:44:17] this EDS console is one of the few we could implement also completely [15:44:22] already* [15:47:11] well, I'll first think about what a LCC could already be used for [16:02:40] looks interesting [16:47:10] most recent LM drawings finally finished processing [16:47:26] the last batch started to get interesting, some bigger LM structures with all measurements etc. [16:52:22] oh nice [16:55:52] yeah [16:55:52] https://archive.org/details/apertureCardBox518NARASW_images/page/n1021/mode/2up [16:55:59] this is apparently the start of the cabin drawings [16:56:03] docking tunnel before that [16:56:16] usually not easy to see what it actually is in the drawing :D [16:59:10] https://archive.org/details/apertureCardBox518NARASW_images/page/n1795/mode/2up [16:59:17] forward hatch latch assembly [17:01:17] yeah pretty cluttered :D [17:01:37] https://archive.org/details/apertureCardBox518NARASW_images/page/n1897/mode/2up [17:01:41] the forward hatch itself [17:03:15] definitely starting to get interesting [18:11:10] morning! [18:18:57] hey Mike [18:19:24] what's up? [18:20:07] researching ATOLL, the Saturn checkout language [18:21:12] oh nice [18:21:38] I'll probably implement something like it actually [18:21:52] that reminds me, I should look in that AS-503 verification procedures book I have for FCC info [18:21:59] that talks about ATOLL a lot [18:22:01] yeah [18:24:02] I wished we had that document for a later mission [18:24:10] or at least the missing procedures [18:24:25] has a bunch of procedures "will be supplied at a later date" [18:24:43] yeah :/ [18:31:57] so I think at this point my Yul port might be capable of assembling Retread 44 [18:32:12] finally got back to working on that [18:32:28] great [18:32:47] still nothing whatsoever implemented for the block 2 interpreter, but that is a bridge that I will cross when I get to Aurora, since Retread has no interpretive code whatsoever :) [18:34:01] also I've started in on the CDU project and am working on trying to build the coarse system module's op amp directly from the MIT drawings [18:34:03] https://i.imgur.com/HXJek4I.png [18:34:37] needs a bit of work but I'm narrowing in on a workable procedure for making boards for cordwood things :D [18:36:20] I saw a CDU Github project by you a few days ago :D [18:36:27] haha yeah [18:36:49] I was originally going to be putting the PCB designs in that when I started it [18:37:13] but then as I was making the PCB I realized that it was going to have no traces, the text was too small to be silkscreened on, etc. [18:37:21] and so it was just going to be FR4 with holes drilled in it [18:37:38] and I have a bunch of strips of FR4 sitting around so I changed my mind and decided to try to just completely DIY it lol [18:37:49] I will put in the cleaned up drawings I'm making though [18:38:30] that sounds useful [19:04:01] also I finally asked Ron about those system status reports [19:04:07] he's going to do them at the same time he does your requests [19:04:14] which he says should be in the next couple of weeks [19:04:47] great [19:05:10] it's been a month since I asked him, I would have contacted him soon just to ask if he forgot :D [19:05:40] on the LM side it looks like we have two more boxes of LDW280-28xxx drawings (so likely more of the same as the most recent), and then in box 521 there's a sudden jump up to LDW280-51xxx [19:05:41] haha [19:06:04] I looked at the recent one [19:06:17] has some stuff about the LM cabin and forward hatch [19:06:24] I haven't gotten a chance to go through it yet but it looks like we're getting into some interesting stuff [19:06:27] and much more I didn't see [19:06:41] yeah, definitely [19:07:25] at box 529 we get out of LDW280-xxxxx and it becomes LDW280Mxxxxx [19:07:29] no idea what that is about [19:07:42] and then box 540 we finally break out of LDW280 and into LDW300 [19:08:14] which means...? [19:08:23] still working on that :D [19:08:30] I think LDW370 is all PGNCS stuff [19:08:34] 280 may be mechanical? [19:08:49] what are some things with LDW300 numbers... [19:09:21] I have one [19:09:24] Gimbal Actuator Stiff Links, LDW300-11700-3 [19:09:24] LDW300-56003 [19:09:30] what's that? [19:09:36] Engine/Thrust Control (CES) [19:10:05] LDW300-21800-3 is Translation Control Assembly [19:10:06] the elementary schematics documents are also proper LM drawings [19:10:10] https://www.icollector.com/Lunar-Module-Translation-Control-Assembly_i16195356 [19:10:14] they sure are [19:10:14] LDW267 [19:10:41] ah, NARA doesn't really have LDW267 :/ [19:10:52] well luckily we already have them then :D [19:10:56] if they have any we've already scanned them [19:11:07] would be in the very first box [19:11:46] LDW320 is explosive devices [19:11:52] hahaha that's fun [19:11:59] or "mechanical design sub-system" [19:12:03] ED and some other things [19:12:28] LDW390, EPS [19:12:48] LDW360, Instrumentation [19:13:00] LW330, ECS [19:13:04] LDW* [19:13:13] hmm [19:13:17] ECS starts in box 544 [19:13:21] LDW310, RCS [19:13:47] LDW350, Displays and Controls [19:14:08] do we have 270? [19:14:11] that is propulsion [19:14:27] yeah, there was a good chunk of 270 stuff [19:14:32] in the first box or two [19:14:45] I think these are all top level drawings [19:14:52] yeah [19:15:13] a lot of them are LDWXXX-60001 [19:15:28] https://archive.org/stream/apertureCardBox503NARASW_images#page/n605/mode/1up [19:15:39] LDW 270-54000, the level 3 schematic for populsion [19:16:01] that's the equivalent of the drawing we first found AGC pin numbers in [19:17:01] https://archive.org/stream/apertureCardBox503NARASW_images#page/n709/mode/1up [19:19:04] definitely looking forward to LDW300, all the control electronics [19:19:37] will there be AEA drawings? [19:19:56] unlikely [19:20:11] unless there's only a small number and they're in the Grumman vendor boxes [19:21:12] an AEA has TRW part number 220000-9 [19:21:24] SCD number LSC-300-330-3-11 from Grumman [19:21:54] none of the boxes at NARA match the TRW number scheme [19:22:36] they should build more systems in-house so that we can get the drawings :D [19:22:39] but there are 5 boxes filled entirely with "GAC vendors" [19:22:51] haha yeah [19:35:40] cya! [21:25:40] night! [15:50:42] hey [16:05:44] hey Alex [16:50:37] it's an annoying amount of work adding a new project to the NASSP VS solution file [16:51:49] my first development goal with the LCC is a simple LCC MFD that can set discrete inputs to the Saturn ground computer [16:53:44] these can be many things, some of which are already supported, switching the abort in the CSM on [16:53:46] abort light* [16:53:54] for example [16:57:24] ah nice [16:58:39] and all of the light show that is currently the EDS test [16:59:13] I guess it will be possible to simulate the entire EDS test [16:59:58] yes. For that I probably want to have all the steps of the test in a text file instead of code [17:00:03] which will be a bit more work [17:00:11] but it would be possible to do the test manually [17:01:40] I've seen some pieces of the checkout language used for this, called ATOLL [17:01:49] actually looks a bit like our Checklist MFD files [17:01:59] with commands, time delays etc. [18:09:31] morning! [18:22:51] hey Mike [18:23:48] what's up? [18:23:55] working on some LCC code [18:24:14] how far is your RCA-110A emulator along? :P [18:24:37] hahaha [18:24:51] way further behind than my Honeywell 1800 emulator [18:24:57] which I have no code for :D [18:25:12] so by that logic the LVDC emulator is almost ready :D [18:25:43] I mean it pretty much is, it's just that it's unclear if we can put out the code for it :P [18:25:50] or rather, the software to run on it [18:26:03] speaking of, I finally got that listing from Ron a few days ago, haha [18:26:15] yeah, you mentioned that [18:26:29] the first thing I would be interested in is actually the implementation of the logarithm [18:26:51] I mostly know it from the EDD, but it leaves some things open for interpretation [18:27:03] hmm [18:27:11] I feel like i should be able to answer questions about that [18:28:07] The EDD says [18:28:34] "The algorithm must accept alpha (input variable) in the range 0.125 < alpha < 8 [18:28:35] " [18:28:44] what happens if it is not in that range [18:29:07] the AGC would maybe have a program alarm for that [18:29:11] it has for the square root [18:29:19] but that wouldn't make sense for the LVDC [18:29:27] any idea what the name of the logarithm function is? [18:29:58] normally log or ln [18:30:02] natural logarithm [18:30:03] AULN - NATURAL LOGARITHM ? [18:30:07] yes [18:30:54] or even if it doesn't have something specifically about 0.125 and 8 [18:31:07] what about the case of smaller than 0 [18:31:23] that used to cause a CTD in NASSP :D [18:31:45] you can get that under realistic circumstances [18:31:46] hmmmm [18:31:59] S-II/S-IVB staging immediately after S-IC/S-II staging [18:32:03] the IGM really doesn't like that [18:32:04] I'm not seeing any particular checks [18:32:14] but I also don't know how to read LVDC assembly yet [18:32:17] then it might check in IGM code where it is used [18:32:18] the comment at the top says [18:32:23] * INPUT TWO ARGUMENTS, X IN ACC AND Z IN PQ, SCALED THE SAME * [18:32:23] * * [18:32:24] * OUTPUT LN (X/Z) IN ACCUMULATOR, SCALED B2 * [18:32:29] oh [18:33:16] but it is the same implementation as the EDD I would expect [18:33:29] I don't see any checks in the place it's called either :D [18:33:37] a polynomial solution [18:33:59] I would believe that [18:34:11] with numbers like 0.99990167 [18:34:28] yep, that number appears here [18:34:31] ok, good [18:34:46] two inputs... [18:38:35] oh wait [18:38:39] man this would be so much easier if you weren't German lol [18:38:40] output LN (X/Z) [18:38:42] so just scaled [18:39:04] well [18:39:36] so it's pretty much one input, X/Z, but probably two for some numerical precision reason or so [18:40:16] yeah [18:40:39] let me look at what's in the EDD :D [18:40:55] the document with the number 5 at the end [18:41:02] PDF page 15 [18:41:54] does it show where this routine is used in the IGM code? [18:42:13] oh yes [18:42:21] PDF page 35, same document [18:42:38] only in the remaining DV calculation, yeah [18:42:52] that is what I see in the code, the numerator and denominator of 4.4.20 are passed in to this routine as X and Z [18:42:53] so variables L [18:43:00] oh [18:43:07] so the tau and tau minus T [18:43:10] yep [18:43:39] definitely no checks outside of the log routine [18:43:56] interesting [18:44:30] tau minus T [18:44:43] under extreme, but realistic circumstances that can become negative [18:44:49] hmmmm [18:45:06] so it would just overflow? or underflow rather... [18:45:25] is that single or double precision? [18:45:42] not sure [18:45:48] seems single? [18:45:52] hmm [18:45:57] so we're talking about the Z, in PQ [18:46:15] yeah [18:47:45] the first thing it does is (X - Z) and takes different code paths if that is positive or negative [18:49:35] tau is the time it would take to consume the mass of the whole vehicle with current thrust and mass loss rate, T is the time-to-go into orbit [18:49:58] so that's why I always explain this issue as "it takes longer to get into orbit than burn up the whole Saturn" [18:50:25] heh [18:50:27] as you can imagine, not unrealistic for the earliest possible S-II/S-IVB staging [18:50:35] yep [18:50:36] but also can happen with the Saturn IB [18:50:45] as pre and post MRS are separate stages [18:50:47] IGM stages [18:51:18] different codes paths is interesting [18:51:55] as you can see in the EDD it first needs to find that integer N [18:52:02] and it probably starts with some initial guess [18:52:23] I think I tried my hand at implementing that algorithm but couldn't be 100% sure it was just as in the real LVDC [18:52:29] so I didn't use it [18:53:41] I was expecting it to have some error handling [18:54:03] does the AGC have a natural logarithm function? [18:54:32] so (X - Z), given the numerator and denominator going into it, will just give you T, right? [18:55:37] looks like LM ascent guidance does [18:55:49] ah of course [18:56:09] and yes [18:56:13] T = X - Z [18:57:03] it can only become smaller than 0 in equation 4.4.26 actually, not 4.4.20, but it's the same thing [18:57:06] back in a bit [18:58:41] so if that is negative, it does X/Z and initializes its guess to 0, and if it's positive it does Z/X and initializes its guess to -.69314718 [18:58:47] if it's exactly zero it just bails [18:59:24] or maybe not guess, but some temporary is set that way [19:14:20] that number is from equation 13.4.2 [19:14:43] multiplied by N [19:14:52] so if N is 0 anyway, then the number times N will also be 0 [19:25:58] that is assuming N might be 0 in that negative case [19:26:30] I'm implementing the EDD version in MATLAB and will experiment what the LVDC code might try to do there [21:09:29] night! [16:16:23] hey [16:39:25] hey Alex [16:39:45] got the Saturn ground computers working [17:02:10] great [17:02:29] that will be part of the MFD? [17:04:23] well the LCC is the only way to interact with it right now [17:04:25] LCC MFD* [17:04:44] but there is a LCC vessel, which would have other, maybe external interfaces [17:04:49] simulating an LCC console or so [17:05:04] the only thing the MFD can do right now is issue discrete inputs to the computer [17:05:27] and depending on the input it sends a signal to the ML and from there to the IU ESE and to the Saturn [17:05:42] one simple thing I have implemented is the signals to the Q-Ball [17:05:59] power on, power off and simulate command [17:06:33] the simulate command can already be seen on the CSM panel [17:08:42] most switches on LCC consoles have On, Off and Auto settings [17:08:49] On sets one discrete input [17:09:17] Off sets another discrete input and also a computer independent signal to the electrical support equipment to definitely turn off what you want to turn off [17:09:40] Auto let's automated checkout programs in the computer decide on the output [17:09:52] so most of the time switches will be in auto [17:16:02] in the other direction there is of course also a lot to do [17:16:09] inputs from the Saturn to the ML computer [17:16:13] from there to the LCC computer [17:16:20] and then any displays [17:20:50] but the whole I/O stuff from LCC to the vehicle is implemented. There is a giant pile of signals that could be wired to switches or displays [17:21:57] you can easily set a signal from the LCC using the LCC MFD and it will stop the launch :D [17:24:46] nice [17:25:43] so I guess everything is automatic by default, but you can mess/control with stuff with the LCC MFD [17:26:32] that's the plan [17:28:55] still need to decide how I want the manual inputs to work [17:31:38] the LCC is a vessel [17:31:44] I could give it 2D panels :D [17:37:42] hmm [17:37:55] that would be interesting :D [17:45:32] but really, the best solution would be an external application like the telemetry client [18:15:34] morning! [18:18:43] Hi, I'm re-flying Apollo 9 and on SPS-2 there's a 40% stroking [18:18:49] what is it exactly? [18:20:22] hey Mike and MrFickles [18:20:32] it makes the SPS wobble around [18:20:40] they did that to test the dynamics of the CSM+LM stack [18:20:59] It's simulated in NASSP yeah? [18:21:03] yep [18:21:08] ok [18:21:09] it's done by the AGC [18:21:18] the test is done during a SPS burn and there is an extended verb to start it [18:21:23] I was worried that the DAP is going haywire [18:21:34] there is a variable in erasable memory that decides how strong the test is done [18:21:40] it's padloaded to 40% strength [18:21:46] I see [18:21:47] and it will later be changed to 100% [18:21:59] I got worried and did a MTVC [18:22:03] oh, haha [18:22:05] was it so strong [18:22:17] just unexpected [18:22:20] right [18:22:36] there is a nice graphic of what happens [18:22:45] I was assuming the 40% stroking was like a 40% throttle or something [18:23:11] so when it deviated from 0,0,0 I just took manual control\ [18:23:33] a natural reaction, haha [18:23:35] https://www.ibiblio.org/apollo/NARA-SW/R-577-sec3-rev3.pdf [18:23:38] PDF page 121 [18:24:41] The sequence ocillates for 7 seconds? [18:25:07] with the amplitude getting smaller, yeah [18:25:16] at 100% strength the amplitude is 0.02 rad [18:25:20] 1.146° [18:25:30] so about 0.5° at 40% strength [18:25:40] alright, perfect. I'll restart the sim from before SPS-2 [18:25:50] at least I know what to expect now [18:25:57] and that will have happeend when you entered that verb [18:26:18] Verb 68 I think [18:26:25] yeah it's V68 [18:26:38] that's all there is to it. The DAP should be able to handle it [18:26:55] they would have skipped over the 100% test if it didn't behave nice at 40% [18:27:03] 100% test is for SPS-3 I think [18:31:19] right'' [18:31:25] looks good [18:31:33] saw the GPI needles wobble [18:32:42] yeah [18:32:57] there are some details in the flight plan [18:33:27] "If maximum value of FDAI rate indicator exceeds 0.8°/s (peak to peak) then full amplitude test will not be performed on Burn No. 3" [18:33:55] stroker did almost nothing [18:34:20] mostly just normal SPS oscillations [18:34:25] right [18:34:31] I guess in reality there is a bit of body bending going on [18:34:38] CSM+LM stack is quite long [18:34:47] that's what they wanted to test [18:34:52] yeah I'd assume it would be to check the docking interface [18:34:54] if the wobbling causes problems [18:34:55] yeah [18:35:23] not actually surprising it did nothing in orbiter [18:35:56] it still gives the DAP a bit of extra work to do I guess [18:36:02] but nothing major [18:37:05] imagine what sorcery a pentium CPU would have been in 1969 [18:37:15] not even an i5 or i7 [18:37:50] a Pentium CPU can easily run emulators of two AGCs and one AEA [18:37:54] at the same time [18:38:11] the DAP does output 10 commands per second [18:38:13] plenty fast [18:38:36] would it have had more computing power than the entire RTCC? [18:39:30] what, the AGC? Or Intel Pentium? [18:40:49] https://en.wikipedia.org/wiki/IBM_System/360_Model_75 [18:40:54] this is what the RTCC ran [18:41:51] back in a bit [18:43:19] Oh yeah, you remember the MTimer MFD [18:43:34] It wasn't working for me a few days ago [18:43:59] It didn't show up as one of the MFD even though it was enabled under modules [18:44:24] I have no idea what I did to get it working [18:44:41] I tried to recompile using the .sln, failed. and then it worked [18:58:21] hmm, ok [18:58:27] I'll take a look some time [19:04:52] honestly no idea what I did [19:07:47] by the way, you know the clickspot on the top right corner of the CSM optics to bring up the DSKY [19:07:58] is there any such clickspot on the LM optics? [19:09:51] I don't think there is [19:10:10] it is indeed a bit of a hassle to input AOT data [19:10:21] you have to look at the data, switch to the main panel, then back [19:11:45] Yeah exactly [19:11:54] It [19:12:07] it's not exactly a easy keystroke combination [19:12:41] Ctrl down. look at data. ctrl up, left [19:12:49] right* [19:13:16] LGC is also at the bottom of the main panel [19:13:30] might be a bit tricky to find a good spot for the DSKY on the AOT panel [19:13:56] maybe on the left side, middle [19:14:15] right above the AOT angle display [19:14:43] indeed, the AOT takes up the majority of the screen space [19:14:58] maybe it could be possible to have a smaller sized DSKY? [19:15:32] it would be possible, yes [19:15:41] we do it with some of the optics switches [19:15:53] in the CSM [19:16:04] on the sextant and scanning telescope views the switches are smaller versions [19:16:08] than on the LEB panel [19:16:59] I didn't even notice [19:17:27] I'm so used to what all the switches do that I don't even pay attention to the details [19:17:46] I know the feeling [19:21:10] thanks for your help indy, I gotta go now [19:21:16] have a great weekend [19:33:58] cya