[20:55:27] NASSP Logging has been started by thewonderidiot [20:56:32] at the very least, I think you guys can probably write a very solid case for having it scanned :) [20:56:41] yeah [20:57:03] enjoy the launch-pad aborts, I'll have to fix the Saturn1B ones next [20:59:58] we are alternating with email writing duties, right? Alex, when was the last time we made you write an email requesting documentation? :D [21:00:11] hahaha [21:04:07] I guess that would of been the LM-8 databook, quite a while ago yes lol [21:04:40] I can do another, sure [21:06:25] that reminds me, I still wanted to request another Saturn V Systems Handbook [21:17:06] Well, im off. I can e-mail for docs if need be tomorrow. Cya! [21:23:39] night! [22:23:11] .ping thewonderidiot [22:23:38] what's up? [22:25:44] I'm trying to implement the AGC in Java (using JNI) and my IDE tells me there's a couple of functions that have an undefined reference. [22:26:09] They are in agc_engine.h under "API for yaAGC-to-peripheral communications.". Do I need to give my own implementation for those? [22:26:21] It works when I add {} to them but that's not really a fix. [22:27:02] The specific functions are ShiftToDeda, ChannelRoutine, ChannelInput and BacktraceAdd. [22:41:18] yeah [22:41:28] yaAGC's implemenation is in SocketAPI.c [22:42:05] I see the implementation for BacktraceAdd in Backtrace.c [22:43:02] Hmm, how to best go about this. I don't want to alter any of the vAGC files to prevent diverging like NASSP did. [22:43:31] I don't need the socket stuff quite yet, I'll just null implement it for the time being. [22:48:02] It builds now. [13:03:52] .tell thewonderidiot I also saw that agc_symtab.h is being included in agc_engine.c but is never used. Might be worth removing it? [17:57:48] morning! [17:58:05] Hey there [17:58:26] what's up? [17:59:08] Working on LM press/depress, trying to find a stable solution to both the right times per the AOH and time accel instability [17:59:27] If I increase the valves, I get the right timing for press and depress using 1x [17:59:47] However just pushing to 10x creates unstable back and forth flows [18:00:41] And if I decrease the sizes, press and depress take too long [18:00:50] Rock and a hard place [18:03:53] yeah that sounds tough [18:04:10] Its just frustrating [18:05:09] hey [18:05:16] morning! [18:06:48] Hello there [18:08:35] I am trying to make pressurization happy with time acceleration [18:09:05] I'm sure the large new valves don't like that too much [18:09:09] Nope [18:09:18] Though using 50 on them works nicely in 1x [18:09:53] potentially stupid question [18:10:05] can you tune the loop differently depending on the current time acceleration? [18:11:15] what we can do is cap the timestep length for the systems simulation [18:11:37] so it would do multiple systems timesteps per actual Orbiter timestep [18:12:02] ohhh, that is a good idea [18:12:18] that system is already in place, but only takes effect at very high time acceleration [18:12:20] 1000x or so [18:12:31] but that can be changed [18:13:39] With systems becoming more complex it might be necessary [18:13:51] So valve sizes of 10 make it happy [18:14:11] I am going to check press/depress times [18:14:55] I think being able to open the upper hatch too early is fairly small issue compared to LM pressurization and general stability [18:15:14] so don't make the valves too large, if it is only for the upper hatch behavior [18:15:24] No it was for lm press time as well [18:15:29] ok [18:15:30] I was trying to find a happy medium [18:15:52] I am going to try 20 and see what happens [18:17:23] Nope [18:22:30] Haha with size 10 valves in the tunnel I can get the LM to 4.6 in 11 minutes [18:22:37] Smaller we go [18:30:05] when I am working on the MCC I always look at small details of specific calculations, which I never really do for the general RTCC MFD calculations [18:30:27] one thing Apollo 10 is really inconsistent about is event times during translunar coast [18:30:57] the MCC-2 TIG is suddenly X hours relative to TLI ignition [18:31:08] while most events just after TLI are relative to TLI cutoff [18:31:15] Interesting [18:31:38] Yeah most flight plans I have looked at were TLI+xx [18:31:50] Including MCC approximate times [18:32:57] well, rounded down to the next minute. So TLI ignition is nominally 2:33:26 or so. So the impulsive planned TIG of MCC-2 is TLI+24, 26:33:00 [18:33:37] and, the same way as the RTCC MFD does it, the actual TIG is adjusted to compensate for the non-impulsiveness of the burn [18:33:56] actual burn time of MCC-2 was 7 seconds, so the actual TIG is "26 hours, 32 minutes, 56.10 seconds." [18:34:27] it's just tricky to follow this logic, when they use both TLI ignition and cutoff as time references :D [18:34:51] but that's the kind of stuff I do (once) when going through a mission for the MCC [18:35:13] just have to get it right that one time [18:35:15] I think you enjoy the challenge [18:35:40] yeah, it's rather fun [18:36:21] the PTC REFSMMAT is also not the same as it would be calculated with the RTCC MFD, so I decided to use the one from the Operational Spacecraft Attitude Sequence [18:36:35] so hardcoded, not calculated dynamically [18:37:16] what I also trying to avoid is make the MCC calculations incompatible with delayed liftoff, 2nd TLI opportunity etc. [18:37:47] Ah yeah [18:38:02] So why is the PTC attitude diffdifferent? [18:38:19] Typing while building in the background i guess duplicated that [18:47:11] Do I need double or float for valve size in a debug string [18:48:29] I would guess float [19:03:21] Hmm doesnt like float, nullptr [19:05:14] Hmm doesnt like double either [19:08:01] Why would this be nullptr [19:08:02] float *ovhdHatchSize = (float*)Panelsdk.GetPointerByString("HYDRAULIC:CABINOVHDHATCHVALVE:IN:SIZE"); [19:30:49] afternoon [19:30:51] hey Alex [20:12:06] rcflyinghokie, you can't access a valve via the connected pipe [20:12:15] only with via the tank that owns the valve [20:13:10] PTC REFSMMAT on Apollo 10 is a bit different than the one calculated with the RTCC MFD because there is an additional constraint for one of the defining axis, or something like that. [20:13:26] hard to implement as a calculation, so I'lm just hardcoding it [20:17:41] indy91, how's 10 going? Up to LOI yet? [20:17:50] didn't have any time today [20:18:11] so all I did was revising the MCC-1 TIG slighty, didn't actually fly MCC-1 yet [20:18:51] but with the MCC it's always a slow progress. Implementing new calculations, fixing a bunch of things, so for one maneuver like MCC-1 I am reloading the scenario 5-10 times until I am an happy and continue. [20:19:54] indy91 I forgot about that thanks [20:20:25] haha slowly but surely is the best way to do it [20:20:44] Also let me know if there are any timing issues with the checklist [20:20:59] there was one thing, with the PTC REFSMMAT actually [20:21:34] I'm working on the Saturn1B pad aborts now [20:21:41] flight plan says at 7 hours: "PTC REFSMMAT will be uplinked if MCC-1 can be made with PTC REFSMMAT." [20:22:05] otherwise it would be uplinked after MCC-1, which is where the Checklist MFD has it [20:22:09] flight plan actually as well [20:22:17] at 7 hours it's just in the notes [20:22:39] but it's very likely to be uplinked at 7h. [20:22:54] if MCC-1 is scrubbed anyway, that's how it happened during the actual mission [20:23:22] and in my case MCC-1 has a yaw angle of 352°, so nowhere near the limit [20:24:17] so either move it entirely to 7 hours or have it at both 7 and 12 hours GET, with PRO and FAIL options [20:27:01] Ok [20:29:18] to be fair, I haven't implemented that logic in the MCC yet either :D [20:29:41] it's always an uplink at 7h GET right now [20:29:59] making the MCC super flexible is rather tricky... [20:34:51] rest of TLC should be fairly straight forward at least [20:36:56] when I implemented the Apollo 8 MCC the map update calculations weren't reliable enough, so I hadn't included them for the MCC. But that will be one of the new things for 10. [20:37:19] then full landmark tracking PADs [20:38:33] and then I'll probably spent a lot of time on all the new LM stuff [20:40:02] CSM Rescue PADs, that's a lot as well... [20:41:23] Looking forward to testing all that! Looks like a lot of work though [20:42:43] yes, but especially the rescue PADs are exactly the kind of stuff that is fun for me [20:42:52] complex rendezvous calculations [20:44:49] and we have pretty good documentation for it [20:44:55] at least for Apollo 10 [20:45:25] haha right on, and there are lots of those left to solve in the remaining missions [20:47:39] and some documentation work will be necessary for Apollo 10, because we are lacking the flown checklists [20:48:02] yeah [20:48:30] I guess it would be similar to the Apollo 11 timeline book for LM ops? [20:48:42] yeah, should be [20:49:48] hmm [20:50:09] For this uplink, is a P52 option one implicit with that 7 hour uplink? [20:50:09] the AFJ has a bunch of single pages of the CSM Solo Book and the LM Timeline Book [20:50:35] yeah, they did that shortly after the uplink on the actual mission [20:50:40] Ok [20:50:41] https://history.nasa.gov/afj/ap10fj/fplan/csm-solo-ops-flight-plan-p32.pdf [20:50:46] https://history.nasa.gov/afj/ap10fj/pics/plane-change-cancelled-cdh-p18.jpg [20:52:32] wow [20:52:50] for the CSM Solo OPS I am just changing the page number in the URL [20:52:57] and I am getting a looot of pages there [20:53:13] there is no full PDF of it posted on the documentation page for Apollo 10 though [20:53:51] ok, not all of them [20:53:54] pages 30-35 [20:56:46] might be another case of emailing someone from the AFJ, who just has the whole document sitting on their hard drive... [20:57:56] That would be great [20:59:48] page 18-20 of the LM Timeline Book and page 30-35 of the CSM (or CMP) Solo Book are in there right now [20:59:57] correction, not page 20 [21:04:55] Ok for the 10 checklist, at 7 hours I have it tell the user "If MCC-1 can be made with PTC REFSMMAT, click PRO, otherwise click FAIL [21:04:55] " [21:05:07] sure [21:05:10] Pro brings up another group with the PTC uplink and P52 [21:05:13] Fail moves along [21:05:27] And after the burn, I have it say If PTC REFSMMAT not uplinked, click PRO, otherwise click FAIL [21:05:27] " [21:05:37] Brings up the same group [21:05:46] yeah, where you previously had the uplink in the timeline, right? [21:05:50] Yes [21:05:58] yes, I think that makes sense [21:06:11] It does in my mind but applying it is the best test, of course [21:06:23] So tunnel valves at 10 is very stable [21:06:31] The only instability is the overhead hatch [21:07:17] I am playing with that and the press eq flow but with the tunnel at 10, I can easily pressurize the LM in 30 minutes without stability issues at 50x [21:07:26] Apollo 10 Flight Journal is actually one with a lot of recent activity, so I am sure I can message that person (AFJ mentions 3 possible people working on it) and it's not like they had that document 10 years ago or so. [21:07:47] Just might need to figure out a better method to vent the tunnel when undocked [21:08:29] what is the issue with that even? Isn't the most relevant factor for that the valve size towards the vent? [21:08:56] oh [21:08:58] undocked [21:08:59] not docked [21:09:23] Yeah [21:09:36] What is reducing the flow when undocked is the pressure in the tunnel [21:09:41] right [21:09:51] Might it be ok to void those tanks when undocked? [21:10:03] or just not have that tank connected [21:10:09] just directly the cabin to vent [21:10:15] Yeah that could work [21:10:25] They arent tanks technically anyways when undocked [21:10:29] yeah [21:10:46] it's a real stretch using tanks for that [21:11:00] Yeah [21:11:05] It makes sense as a tunnel [21:11:24] But I think you are right we should vent to cabinvent when undocked [21:11:30] I could leave the valve at 10 [21:12:38] Let me get the LM Press time right I will push my valve changes and then I will look into the vent to space rather than the tunnel [21:16:24] should we even have both a LM and CSM tunnel then? [21:16:41] the default state (undocked) would not be using either one then [21:16:45] hmm [21:16:54] that might be tricky from the CSM side [21:17:12] because of the tunnel vent valve [21:17:21] Right the extra tunnel gave flexibility [21:17:22] that one has to go from CSM Tunnel to a vent [21:17:33] so we need at least the CSM tunnel as a tank [21:17:39] Pressure equalizes to 4.5 in 20-25 minutes now [21:17:42] or [21:17:44] 35 to 5.0 [21:17:55] At 30x and 50x stable [21:17:55] as done by other people in the past, just do a bunch of things in code [21:18:07] like the whole surge tank stuff [21:19:05] the bare minimum is a CSM tunnel tank [21:19:07] I think having a tunnel tank at least on the CM side would be wise [21:19:17] yeah [21:19:23] That would also prevent stability issues from flowing to another tank [21:19:47] having it disconnected it undocked state would technically work [21:19:56] in* [21:20:07] then we would need variable valve sizes in code [21:20:15] Let me PR my state [21:20:23] Things are stable [21:20:27] awesome [21:20:58] so eliminating the LM tunnel entirely or just using it in docked mode could make sense [21:22:35] I would say keep the CSM tunnel, make it the full size of both [21:22:52] And just attach the overhead hatch valve to it or cabin vent in code? [21:23:20] Depending on docked/undocked state [21:23:54] let's just have the cabin connected to the vent by default as step one, and leave the LM tunnel in there. Then I'll do the code changes for docked/undocked [21:24:23] hmm [21:24:28] that's just one config change [21:24:46] one changed valve for a pipe [21:25:12] I'll do that tomorrow, along with the docking/undocking code changes for it [21:25:33] Let me do one last 30x lm press and make sure the flow is good then I will have the PR [21:26:17] sure [21:26:36] in this first step, everything will stay the same for the docked version anyway [21:26:49] still separate LM and CSM tunnel tanks etc [21:27:02] if we then want to eliminate the LM tunnel tank we can still do that [21:27:40] the first change would just be connecting the LM cabin directly to the vent [21:28:41] About 25 minutes to 4.6 psi [21:28:45] I am happy with that [21:29:08] About 30-35 for 4.8-5 [21:29:59] Does the size for the cabin vent play any part? [21:32:16] I had some confusion about that yesterday, but in general, no. [21:32:28] for the connected pipe that valve will always be the OUT valve [21:32:54] and with the flow always in the direction towards the vent, its size is never used to determine the flow [21:33:18] Thats what I thought [21:33:19] for Q flow it uses the smaller of the two connected valves though [21:33:26] so there it plays a role [21:33:45] I have them all at 10 [21:34:20] hmm [21:34:31] let me check what the vent has as its temperature [21:34:47] I can revert them of course if that is a problem [21:36:03] why did you change them? [21:36:14] but no, shouldn't be an issue [21:36:28] the vent might have 290K as the temperature [21:36:42] which would only be used for a Q flow calculation [21:37:11] I wonder what temperature a tank directly exposed to a vent has then [21:37:23] maybe that is even part of the issue of the tank not emptying properly [21:37:28] I'll check that tomorrow [21:37:45] good night! [21:38:02] I'll merge your PR though [21:41:23] rcflyinghokie, did that flowmax thing in Hsystems help with stability finally? [21:41:42] I didn't see much difference in my testing so far [21:41:59] That only affects 2 way pipes I believe [21:42:08] We don't have many on purpose [21:42:23] But with that we can use them more often without worry [21:42:32] It helped in the tunnels for sure [21:42:43] And enjoy pressurizing the LM a lot faster :) [21:43:25] ah great [21:43:45] so it helped with faster flow between the two vessels [21:46:36] Yeah [21:46:54] The problem was twofold I think [21:47:05] One, back and forth flows between the tunnels [21:47:17] And two, very small valves between the tunnels [21:47:48] Now the only issue is I cannot make the LM overhead hatch valve big enough to do a 3 minute depress [21:48:10] But if we can remove the LM tunnel when it is undocked, I can get it down to the right time [21:48:30] Forward hatch depress doesnt have that problem since it is always vented to space, and LM depress using it works properly [21:48:44] And I have LM depress via that valve down to 5 or so minutes [21:49:15] Thats where I left off on 11 though, got sidetracked with pressurization [21:51:36] ill have to give all that a try [21:53:28] Also fixed a few procedure issues in LM depress that probably caused you guys trouble [21:54:01] One important one was the pressure regulators were never moved to egress, so the suit pressure relief kept venting into the cabin [21:54:24] One checklist I used omitted that step, but I found it in the eva final checklist added to it [21:54:32] And it makes a huge difference [21:54:39] btw I just noticed something... Our Saturn5.dll file has nearly doubled in size in just 4 months. In late October of last year it was 90 MB, now... 160MB! [21:55:12] maybe thats the fluctuations in fps I've been noticing lately [21:55:32] cant say I'm not to blame for part of it with all the new panel bmp's [21:57:43] wow, that's crazy [21:58:29] hmm, but I did not add many new bmp's to the saturns!? [21:58:53] Maybe its Niklas's new LVDC stuff? [21:59:03] must be [21:59:08] he has been going to town [21:59:16] I havent had any fps issues yet [22:01:08] but 70MB worth of code? maybe [22:01:25] yeah that is a lot of code [22:02:18] Ok off topic question, I am looking for a new gaming mouse to replace my logitech G5 and also an M.2 SSD for my laptop when it arrives...thoughts/suggestions? [22:10:35] hmm M.2 SSD... I've honestly never heard of that before, I'm looking it up now [22:12:19] pcie nvme [22:12:28] I have a logitech G502 and like it [22:12:46] Thats exactly what I am thinking of getting [22:12:53] but I'm kind of locked into logitech, so I didn't look too far [22:13:04] Haha same here I have had nothing but good results [22:13:05] I've become a slave to the ability to unlock scroll wheels [22:13:13] Yeah I saw that feature [22:13:24] How are the buttons to the left of the left mouse button? [22:14:05] they're nice, not hard to press [22:14:23] by default they change the sensitivity settings, which can be annoying if you accidentally hit them, heh [22:14:39] Ah yeah I have one of those on my G5 under the scroll wheel [22:15:20] the second button under the scroll wheel changes between three different "profiles", each of which can have three sensitivity settings controlled by the two buttons by the left [22:15:46] but I don't find myself changing sensitivity much [17:34:13] morning! [17:39:50] Hey there [17:55:45] what's up? [18:03:33] Just found out my laptop is in Dulles (about 15 minutes away) but fed ex wont deliver it till monday or tuesday [18:04:07] d'oh!! [18:04:10] Yeah haha [18:04:33] Apparently "weekday delivery" was selected as part of the shipping on the manufacturer's part [18:04:46] So it got to dulles at 7pm last night [18:04:57] 8pm is the daily cutoff window [18:05:20] My G502 will be here today though [18:08:54] oh awesome [18:18:50] are the msc forums working for you? [18:19:06] I havent been able to load anything but a cached copy since the 26th [18:29:09] hey [18:29:17] Hey good afternoon [18:30:46] Time accel is still not friendly to the LM ECS [18:30:58] Temps in the ecs climb [18:31:31] And the pressures fluctuate to the point that during EVA, if on 30x, it hits the circuit relief and vents into an empty cabin and thus into space wasting O2 [18:35:50] And in other news, my new laptop is at the fedex sorting center 15 minutes from my house...yet wont deliver till monday [18:37:03] so near, yet so far [18:39:18] I know, right? [18:39:31] Seems silly I cannot go pick it up [18:39:38] Saves me time and them money [18:55:21] rcflyinghokie: the forums kiiiiiind of work for me [18:55:37] I am able to reach topics I've never read before but sometimes it takes a few tries [18:55:37] I cant load anything but an old cached copy [18:59:41] so what's going to be the trigger to push us to moving to the orbiter forum? total permanent forum death? :P [19:09:23] These panel switching ctds are annoying [19:12:37] So ready to wipe my computer and fix this VS debug nonsense haha [19:19:49] hehehe [19:24:01] thewonderidiot: rcflyinghokie: I do seriously think we should be getting a backup of the forum sometime on that matter. :P [19:38:51] ugh [19:39:05] so I just moved to South San Francisco [19:39:31] and almost every online form I've used so far uses too few characters maximum in the city box [19:41:26] "S. San Francisco" or something like that? :D [19:41:54] yeah, that's what I'm putting down [19:41:58] hopefully that is acceptable lol [19:42:05] and I didn't have a panel switching CTD in years, really weird [19:44:44] later [19:50:03] .tell indy91 Alex and I both get it occasionally in the LM always caused by an MFD [21:43:58] .ask Not sure but aren't these part of the simple AGC? https://github.com/dseagrav/NASSP/blob/master/Orbitersdk/samples/ProjectApollo/src_lm/LEMcomputer.h#L30 [21:44:09] .ask indy91 Not sure but aren't these part of the simple AGC? https://github.com/dseagrav/NASSP/blob/master/Orbitersdk/samples/ProjectApollo/src_lm/LEMcomputer.h#L30 [21:44:32] . [15:16:00] Good morning [15:17:33] hey [15:17:59] "You have 2 new messages" [15:18:05] seems like it [15:18:11] Thymo looked at the wrong branch [15:18:15] I left that one right after you left [15:18:48] Orbiter2016 branch doesn't have those flagwords anymore [15:19:03] but I have good other news, I tracked down the LM power issue [15:19:09] Oh [15:19:25] it's a bug in the LEM_BusFeed class [15:19:48] it tries to draw power despite the voltage being 0 [15:19:56] Interesting [15:20:21] and in the other class it's not resetting the powerload, if the voltage is 0 [15:20:41] that leads to a powerload accumulating at the CSM/LM interface [15:20:47] that caused the random loads there [15:21:17] for some reason it adds a load every second [15:21:22] not sure why that interval [15:21:57] So that caused the random breaker popping [15:22:02] yes [15:22:10] it very quickly reaches a large power load [15:22:16] too much for the CBs [15:23:03] So what was keeping the LM from getting CSM pwr [15:23:19] that is another issue [15:23:30] so, the XLunar bus ties are open in the initial LM config [15:24:24] but it looks like that CB, or some other config on the LMP side, is required in our code for the CSM to LM power to work [15:24:31] Which is incorrect [15:24:47] I thin [15:24:49] think [15:25:09] In the LM 11 AOH, the initial closeout has them open [15:25:26] At least the one on panel 11 I dont have one for 16 [15:25:38] AOH says for the open state: "No loss of function, relay contacts in parallel with CB" [15:25:53] sounds like a missing feature [15:25:56] Yeah [15:26:04] oh, and another issue with the LM EPS [15:26:10] The wiring might answer that [15:26:11] it doesn't save the csm power latch [15:26:26] so you basically have to reconnect every time when you reload [15:26:42] That could explain the saving and loading to turn on the batteries [15:27:22] ok, let's find those relay contacts... [15:28:10] the detaild DC power page in the LM Systems Handbook is missing [15:28:23] but the CSM Systems Handbook is really detailed about the CSM/LM connection [15:28:29] Which CSM? [15:28:46] 114, but that page could be similar for all of them [15:28:47] maybe [15:29:15] drawing 2.8, CSM-LM electrical interface [15:29:46] hmm, the CSM-104 one just refers to the LM Systems Handbook for this [15:31:04] I am thinking the only difference in that connection was the extra breaker on the LM side [15:31:17] The one for emergency power back to the CM [15:31:43] only Apollo 14 had that one I think [15:31:51] it worked a bit different on later missions [15:32:00] I might misremember that though [15:32:25] but at least the CSM-114 Systems Handbook clearly shows the relays in parallel to the X-Lunar Bus Tie CBs [15:34:14] so we have 3 separate issues [15:34:19] all should be possible to fix [15:35:49] Yeah I saw they go to the bus ties and to the relay junction box [15:36:02] I need to pull that back up to refresh myself [15:42:38] hmm, there is a difference between staged and unstaged for CSM to LM power [15:43:09] Lots of relays in that [15:43:32] Yeah I see that [15:44:38] I think it just allows power to the x lunar busses and bypasses the descent stage [15:45:28] The circuit interrupter [15:47:43] yeah [15:48:14] it goes through the descent ECAs, when the descent stage is still attached [15:51:40] Which is what keeps the batteries from being able to be controlled in the LM while those relays are latched [15:56:11] In the LM 8 handbook I see that breaker just trying to figure out what it does, is it just a connection from the cdr bus back to the interface? [15:57:05] Ah [15:57:06] A circuit breaker was added to the lunar module to bypass the command module/lunar module bus connect relay contacts for transferring power between vehicles after lunar ascent and docking. The command module/lunar module bus connect relay control circuit is interrupted at lunar module staging. [15:57:35] So it isnt for powering the CM [16:00:33] hmm [16:00:40] so how did it work pre Apollo 14 [16:02:19] Not sure if it did [16:03:49] CSM to LM power in the ascent stage configuration? [16:04:14] I mean I am not sure if it was a contingency that was well documented [16:05:02] If they were still parallel to the x lunar busses they could put power on them [16:09:49] hmm [16:10:59] the random power load should be fixed now, but now I get 0 power load demanded from the CSM [16:13:14] What happens if you turn the batteries on LV then try [16:14:37] I feel like this has to do with the power load only increasing every second [16:14:44] and not every timestep [16:14:57] so only every 60 timesteps there is a load [16:15:36] or maybe I used the wrong function to test this [16:15:43] the one I used should probably not work without the bug [16:19:04] no, 0 load [16:20:23] Is the LM running off it's batteries? [16:20:42] don't think so, the ECAs are switched off [16:22:05] guess I have to go through the chains of CBs again [16:22:14] I started with the IMU standby heater [16:22:19] and looked if it had voltage etc. [16:24:43] On a similar note, when the LM spawns, is it properly giving power to these systems? [16:26:59] haven't tried [16:28:47] hmm [16:28:50] idea [16:29:00] the every second thing is a heater cylcing on [16:29:06] but just for one timestep [16:29:12] then the temp is ok for another second [16:29:16] and then it heats again [16:29:47] so on a second off a second [16:30:13] I mean they did cycle of course [16:30:20] on for one timestep [16:30:23] off for 1 second [16:30:37] took a few seconds until I got the first power load on the xlunar bus [16:30:43] 56.7W [16:31:58] There should be what, 4 heaters on? [16:32:10] IMU stby, RR stby, sbd, and ASA? [16:32:19] something like that [16:33:26] what draws 56.7W? [16:33:37] although that is the total power load [16:33:51] but it should be only one [16:33:58] because at all other times the total is 0 [16:34:20] Well the RR stby is 81W [16:34:37] and you can see the needle on the system test meter jitter for a moment, when something was turned on for a timestep [16:34:48] IMU stby is 109 [16:35:10] ASA 41.1 [16:35:45] Actually, asa HTR power is 253 [16:36:14] Sbd is 51.7 [16:38:36] ah [16:38:36] So I dont know where 56.7 comes in [16:38:44] 51.7+5.0 [16:38:48] I would guess [16:38:50] right from what [16:39:10] well, the whole CDR Bus is powered [16:39:55] lighting? [16:40:04] eca? [16:40:13] dc bus volt [16:40:24] I think thats it besides the heaters on that bus [16:41:13] also, it should draw that all the time [16:41:27] those 5.0 would be there all the time [16:41:30] but it's not [16:41:39] it's 56.7, every once in a while [16:45:22] I checked the heater numbers they seem to be correct [16:45:52] Also the sbd heater is on the LMP bus [16:46:12] Same with ASA [16:49:26] let me try and figure out what draws that amount [16:52:59] Maybe something in the ECA code? [16:57:04] ah, so I know already it's actually 27W, but with a 5% loss factor in the DCBus code [16:57:16] and times 2 [16:58:01] times 2 because it's split over the cross tie [16:58:11] so maybe 54W total? [16:58:54] ASA fine heater! [17:01:51] Ah hah [17:03:20] Well good that is actually what was the most notable cycle on the LM current I believe [17:05:44] yeah, but LM current is basically 0 [17:08:24] but I can get a nice current going on the system test meter if I activate a bunch of other systems [17:08:27] so that properly worsk [17:08:30] works* [17:08:39] it's just that the heaters aren't needed too much it seems [17:13:13] Well we spawn the LM with those temps at normal levels [17:13:27] Which is expected I would think since they are running on LM batteries during launch [17:13:40] right [17:14:48] But it would be nice to see at least 0.5V on the meter when it is connected [17:15:33] That umbilical doesn't charge the LM batteries it just makes them go offline correct? [17:15:47] Replacing the power source to the busses to the CM [17:24:28] yes, that is done when you place the LM Power switch to CSM [17:25:14] the worst LM EPS bug is fixed now at least [17:25:22] now the CSM power latch saving/loading [17:25:43] and then making the XLunar Bus Tie CBs half obsolete :D [17:25:51] Haha [17:26:04] I am concerned with the lack of current being drawn [17:26:14] ASA is probably going to be the primary draw [17:26:51] I know apollo 12 had low voltage when they hooked up [17:27:08] And then got a spike to 1.4 indicating a cycle [17:27:55] but it's basically just automatic heaters being on [17:28:00] and if the temperature is fine [17:28:14] maybe we just have to tweak the connected radiators to loose more heat [17:28:50] Yeah [17:30:24] I am also sure there is at least something drawing power all the time in the LM [17:30:57] oh wait [17:31:09] flood light [17:32:23] also, there is separate standby heater CB for the ASA, so, even withou most of the ASA powered down with the AGS Operate switch in off, something will draw a bit of power [17:34:17] The ASA breaker provides heater power [17:34:51] Flood light isn't on I don't think [17:35:20] I know the hatch has a switch in it that turns some lighting on when it is opened [17:35:40] flood light CB is in at least [17:36:02] oh, and I meant to say there is NOT a separate standby heater CB for the ASA :D [17:36:46] Ah ok I was going to say [17:36:59] And yeah the flood lights should be off when that hatch is closed [17:37:11] Unless the panel switch is on [17:39:02] So no lights should be on [17:43:26] just the heaters [17:48:01] at least that's a separate issue [17:48:19] so, when for some reason CSM to LM power worked on the past, then close to 0A was still ok [17:51:11] Good to know [17:51:23] That can be addressed in a lower priority [17:59:05] At least the heaters are working properly [18:02:17] morning! [18:03:03] Hey Mike how's it going? [18:03:39] pretty good! you? [18:07:05] Flying through a rendezvous, curious what the ascent batteries look like at docking with new power loads added [18:07:18] Still not happy about my laptop only a few minutes away :( [18:08:03] I am going to wipe my computer tonight or tomorrow I think, then I will try out my G502 [18:09:49] sweet [18:09:58] I think I am going to start working on wiping my computer too [18:11:03] Interesting during CSI I got a 1302 [18:11:23] SQRT called with negative argument [18:13:19] hey Mike [18:13:27] I'd say a wrong input is likely [18:13:50] let me check the GSOP program flow [18:14:46] I restarted P32 and so far nothing [18:14:54] maybe a wrong input as you said [18:15:45] yeah, difficult to say from the GSOP [18:19:02] I'd wager on pilot error :P [18:19:10] I will see if it comes back [18:29:35] Yeah didn't return probably a typo [18:31:19] saving and loading of the power connection is a bit tricky [18:31:42] I'll figure it out, just not so quickly [18:31:55] I believe in you :) [18:33:23] Speaking of power, did the LM rcs really spike the voltage that much every pulse? [18:38:56] I think the power usage of them is a bit high [18:39:16] Probably the primary reason of the ASC bats being depleted [18:39:21] but with the ascent batteries already having lower voltage it's of course more noticable [18:41:08] I never found how much power they draw [18:41:44] should be the same as CSM I suspect [18:42:47] The breaker load says 112W [18:43:13] yeah [18:44:44] are you using much manual, hardover control? [18:45:06] Yeah since I don't have the controller hooked up [18:45:15] But most of my maneuvering has been PGNS [18:46:22] well, you can simply switch hardover mode off, which I would always suggest when not using a joystick [18:46:29] CDR ACA/4 JET switch to off [18:46:51] Would that change how the PGNS uses the jets? [18:47:17] not at all [18:47:35] in fact using the 4 Jet mode overrides the PGNS [18:47:52] Ok well I have barely used any manual maneuvering as sort of a control to see what the battery drain is [18:48:00] Only for P52 [18:48:13] we use 46W [18:48:26] 112W is for a quad [18:48:45] 46 per thruster [18:48:48] yes [18:48:57] we use that with the primary coils [18:49:18] so under PGNS and AGC control [18:49:30] AGS* [18:50:37] secondary coils draw a bit too much maybe [18:51:13] it might also be the case that both primary and secondary coils are energized when using hardover mode [18:51:27] that is prevent through some additional logic in the CSM [18:51:31] prevented* [18:51:41] but in the LM you can actually make thrusters fight each other [18:51:56] or command them on twice, haha [18:53:31] Thus doubling the power draw [18:53:34] yeah [18:53:46] and we used too high numbers for the secondary coils anyway [18:53:49] but not much [18:54:05] hardover mode is really only for that, prevent a crash during the descent etc. [18:54:29] quickly fight the computers before you can get a more reasonable switch configuration [18:55:47] the secondary coils are only used by: ACA hardover with ACA/4 Jet enabled, Attitude control mode Direct, and +X Translation button [18:56:09] but of course in the Direct mode the auto commands from the PGNS and AGS are not coming through [18:56:15] so they can't fight each other [18:56:24] that can only happen in hardover [18:57:02] which, unfortunately, is what you do with the numpad [18:57:07] Right [18:57:36] but I decided to still use the full ACA deflection for the numpad, because you can easily disable hardover with the switch [18:59:00] same way in the CSM I think [19:01:49] so that is what I suspect, at least for the voltage drop. Multiple RCS engines plus both coils being energized [19:02:34] and I am not entirely sure this Bus Feed bug didn't cause some issues as well [19:03:53] it tried to draw power from e-objects with 0 Volts at least [19:10:29] Hmm my RTCC uplinks just stopped working [19:11:39] In both vehicles [19:11:48] LM nothing happens CM just the light comes on [19:12:19] Maybe I had some sort of TM failure, I did switch vehicles during one though probably why [19:12:37] hmm, possible [19:12:48] never tried switching vehicles during an uplink [19:13:09] but the two MFDs in CSM and LM should be completely separate [19:13:13] Even a reload they wont work [19:13:31] Maybe something is hung up [19:13:47] Yeah I wasn't thinking I was mid uplink and switched to the CM [19:13:51] must be in the AGC then, if a reload didn't help [19:13:56] And thats where it stopped working for both [19:14:01] V37E 00E and cylcing the uplink accept switches maybe [19:14:08] Tried it [19:14:24] and recalculating the uplink [19:14:30] Yep [19:15:27] No change in either vehicle [19:15:55] If you wish to take a look... [19:15:56] https://www.dropbox.com/s/e955m8aa45286tx/Apollo%2011%20LM%20Liftoff%200002.scn?dl=0 [19:15:59] yes, I will [19:16:42] nothing obvious in the RTCC MFD save [19:17:49] I can confirm the uplink light and no uplink happening [19:19:15] V36 helped [19:19:20] so it's something in the AGC [19:19:44] I am pretty sure interrupted uplinks happened during the actual mission as well [19:22:02] in the LM I could uplink a state vector without the V36 [19:35:29] http://www.collectspace.com/ubb/Forum9/HTML/003279.html [19:35:43] someone is digitizing telemetry(?) tapes [19:35:59] and here the first results of it: https://archive.org/details/SpaceData [19:36:03] actually quite interesting [19:36:30] although I can't quite figure out what it is, but I can clearly see Saturn IB and V telemetry or commands in there [19:36:49] stuff like "SIB LOX LEAK ENG 6 SENSOR 3" [19:37:54] but as I said, other than possibly being a list of telemetry items, I am not quite sure what it is [19:38:03] Hey [19:38:10] hey Alex [19:38:51] http://www.collectspace.com/ubb/Forum9/HTML/003279.html [19:38:56] what’s up? [19:39:17] and here the first results of it: https://archive.org/details/SpaceData [19:39:35] just posting that again, started talking about it when you joined, Alex [19:39:58] I can't quite figure out what the first digitized tapes really contain, but it looks interesting [19:40:12] list of Saturn telemetry data points maybe [19:40:51] Nice [19:41:51] and I've also figured out most of the CSM to LM power issues [19:41:57] working on fixing them [19:42:21] oh sounds great [19:45:42] I’m on the road for a few days but when I’m back I’ll work on Saturn 1B pad aborts [19:46:20] great [19:47:58] ah [19:48:13] there is a procedure for clearing a bad or interrupted uplink to the AGC [19:48:19] send up a 1 followed by 15 zeroes [19:48:54] although, not sure if that is applicable to the current, non-counter-based implementation [19:48:57] haha, I guess I have to teach the RTCC MFD that [19:49:09] On the Saturn V it works good, but there is another issue where if you abort at ignition, the CM gets thrown into the ground. I think it’s caused by the addforce [19:49:43] ah, interesting [19:50:40] I wonder if docking the rocket to the ML is still a possibility, now that we have a new way to get the physics working [19:50:43] haha, I saw these tapes on ebay! glad somebody got them that knows what to do with them [19:51:26] hmmm [19:51:44] Switch Action Table Magnetic Tape, AS-206 Current Configuration [19:51:53] yeah, but other than it being a list of telemetry measurements I can't quite figure out what they tell us [19:52:07] the other tape is Apollo 16 [19:52:10] AS-511 [19:52:32] hmm [19:57:55] yeah, not sure [19:58:22] it's not simply a list at least [19:58:31] most of the stuff listed is in there multiple times [20:00:57] wait [20:01:17] why does 1820 start off with a bunch of dates in '72? [20:01:46] if it's for AS-206... [20:03:12] AS-206 was launched in 1973 [20:03:22] oh right [20:03:24] Skylab 2 [20:03:28] first Skylab Saturn IB launch [20:03:49] okay so let's see [20:04:03] it begins with a list of engineering change proposals [20:04:12] those Saturn IBs are rather old at that point, haha [20:04:13] the 40M67790-6 is an IBM document number [20:04:16] yeah no kidding [20:05:24] and I guess maybe d/i could be date/integrated? maybe r/l is redline? [20:06:04] possible [20:06:30] the AS-206 S-IVB had its acceptance firing in 1966 [20:06:41] wow [20:07:02] 207 as well [20:07:10] 208 and 209 in 1967 [20:08:28] hmm [20:08:46] that SA-513 flight sequence program ICD has a document number of 40M33633A [20:09:09] so, maybe I was wrong in thinking it is an IBM number [20:09:37] because that document was prepared by the Launch Vehicle Systems Division at Marshall [20:10:10] Launch Vehicle Systems Division of Marshall or of IBM at Marshall? [20:10:49] the Mission Integration Branch [20:11:00] doesn't explicitly say IBM in that little blurb [20:12:13] oo yeah that could be a lot of things [20:12:21] looking through the AS-503 verification procedures... [20:12:29] 40M33221 was the IU electrical schematics [20:12:37] rcflyinghokie, pushed my update, CSM to LM power saving/loading is working and the Bus Feed bug is fixed. XLunar bus tie still needs to be closed for all of it to work. [20:12:39] 40M34240 was the S-IC stage simulator... [20:12:55] no results for 40M6* though [20:13:01] and Apollo 10 MCC is implemented and tested through MCC-1 [20:13:20] Hmm should we initialize the LM with those close for now? [20:13:25] ah yeah, that AS-503 could be a useful document for comparison [20:13:36] rcflyinghokie, nah, I'll fix that issue shortly [20:13:41] Ok [20:13:42] tomorrow or so [20:13:50] just have to understand the logic a bit more [20:14:22] the flight sequence program ICD for AS-503 was 40M33621B, which is pretty consistent with the AS-515 number... [20:14:53] 515? [20:14:55] ah right [20:14:59] Skylab Backup [20:15:07] er, 513 and 515, yeah [20:15:34] so what the heck is 40M6* [20:15:36] highest number you will ever see for a Saturn V, haha [20:15:50] a 516 was never ordered I guess [20:16:29] yeah [20:16:56] oh and that number for the AS-511 tape is 40M17360-11 [20:16:58] hmmm [20:17:44] oh, I have a hit!! [20:17:55] from my AS-503 procedures book [20:18:18] "Saturn V ESE Computer DEE-6 Running List, 40M17360-3", last revised 6/28/68 [20:19:51] yeah, that sounds connected [20:20:07] -3 is definitely just an older revision of the same document [20:20:56] so the DEE-6 is a Digital Events Evaluator that provides input monitoring for up to 3,220 discretes at a resolution of 2 milliseconds [20:21:25] https://commons.erau.edu/cgi/viewcontent.cgi?article=3231&context=space-congress-proceedings [20:22:18] so basically pad telemetry [20:22:31] the Apollo 17 flight evaluation report discusses debugging something with a DEE-6 printout [20:22:48] AS-206 actually as well [20:23:02] they actually had nearly a failure [20:23:14] something tried to cut off the power right at commit [20:23:21] oh wow [20:23:37] relays didn't energize fast enough so it didn't happen before umbilical disconnect [20:23:51] haha, damn [20:24:18] Booster performance was nominal except for one momentary glitch that could have threatened the mission - when the Commit signal was sent to the Saturn at ignition, the instrument unit sent a command to switch the launch vehicle from internal to external power. This would have shut down the Saturn's electrical system, but not the propulsion system and likely cause the disaster scenario of an uncontrollable booster, requiring the Launch [20:24:19] Escape System to be activated and the Command Module pulled away to safety, followed by Range Safety destroying the errant launch vehicle. However, the duration of the cutoff signal was less than one second, too short a time for the electrical relay in the booster to be activated, thus nothing happened and the launch proceeded as planned. This glitch was traced to a modification of the pad electrical equipment and corrective steps were [20:24:20] subsequently taken to prevent it from happening again. [20:25:10] wow that is crazy [20:25:13] I didn't know that [20:25:20] Pete "Power Loss during Launch" Conrad [20:25:29] lol [20:27:31] Laughed all the way into orbit :) [20:28:25] 000:04:07 Conrad: Hey, that's one of the better SIM's, believe me. [20:31:56] more consistency! [20:32:29] procedure 73V1604, S-II Propellant Level and Depletion Sensor verification [20:32:50] http://www.ibiblio.org/apollo/Documents/AS-503VerificationProcedures.pdf [20:32:58] PDF page 345 [20:33:07] what is that in reference to in the tape file? [20:33:27] the "MDI" numbers listed in this procedure have names that match similarly numbered lines in the tape file [20:33:49] e.g. 1520 == SII LOX #1 OPEN [20:34:33] 1540 = SII LOX DEPLETION ON [20:34:36] yeah they all match [20:34:47] oh, I see [20:34:48] at least, every one I've checked [20:36:42] the MDOs mostly match as well [20:38:44] there are of course differences between Saturn Vs [20:38:56] so small differences are expected [20:39:01] yeah, and AS-503 and AS-511 were pretty different, heh [20:39:39] oh wow, wait [20:40:04] 40M17360-3 == AS-503, 40M17360-11 == AS-511 [20:40:14] the number after the dash isn't a revision number, it's a saturn number [20:40:15] derp [20:40:39] still a revision number in some sense :D [20:41:01] haha yeah [20:43:46] okay so I think this is a big list [20:43:50] it's just, 5 different lists [20:44:00] yes [20:44:12] a list of all of the LDIs, LDOs, MDIs, MDOs, and DEE channel numbers [20:44:32] ah, so those 5 different telemetry devices in the ML [20:45:19] something like that, haha [20:48:07] oh wait [20:48:15] so is LDI/LDO for the LCC and MDI/MDO for the Saturn? [20:48:36] so and MDO would run into an LDI, and and LDO would run into an MDI? [20:49:26] I think that might be the case [20:51:38] ooooh [20:51:56] there's more goodies in here [20:52:39] in the LDI list [20:52:46] S 34 05 L DI 0797 IVB ENG RDY BYPASS ON 010 X J [20:52:56] see that 010? that's an S-IVB switch selector channel number [20:53:28] so you can probably extract most if not all switch selector channels from these things [21:02:22] for AS-503 I already have them all, but should be interesting to find any differences there [21:02:59] I had noticed some lines looked like switch selector channels, but I didn't check on the numbers [21:12:19] Just tried to load an old scenario. CTD in the PanelSDK. Any recent changes to that? [21:12:40] The therm_obj class specifically. [21:13:53] Yeah there were a few I believe as we hunted down nan's [21:15:47] still, old scenario shouldn't necessarily cause CTDs [21:16:00] Thymo, what mission [21:17:01] old CSM only scenarios still work [21:22:08] Merging the last changes. sec [21:34:27] Yeah it still doesn't work. [21:34:38] It's my Apollo 8 scn. [21:34:43] 9 didn't work either. [21:35:59] Hmm and ever since that uplink issue my P20 seems to want to point 40 some degrees away from the CSM [21:36:36] As if the uplinked SV's are wrong [21:36:45] indy91: It tries to get the IMU case temp but it gets an access violation instead. [21:39:20] in imu.cpp? [21:39:37] Yes. ln336 [21:40:08] It's like a null pointer without triggering an exception or something. [21:40:29] IMUCase points to 0xcdcdcdcd [21:41:09] You sure you have the up to date config files? [21:41:28] Should be a pointer to a radiator [21:41:29] LM-IMU-Case [21:42:37] Oops thats the CM imu [21:43:56] SaturnSystems.cfg? [21:44:01] I am not sure how the CM side works with that :( [21:45:00] The radiator is in code and not the config [21:46:16] try rebuilding instead of building, that's all I can recommend for now [21:46:20] good night! [21:46:55] I did rebuild [21:47:19] I usually clean and build [21:48:31] Hmm the imu.cpp does control the LM imu [21:49:32] That pointer is the LM IMU case [21:49:59] You do have the latest lemsystems.cfg? [21:50:31] Even so that is an older radiator in there it wasnt added by us [21:51:17] I do, I just merged upstream. [21:51:35] If it's the LEM. How come it's even loaded when this is Apollo 8? [21:51:58] imu.cpp is used by both IMU systems [21:52:23] I honestly don't know how the CM side works with temp/heat if at all [21:52:35] That line is for the LM [21:53:48] Trying a patch [21:54:00] I havent had any issues with CM only [21:54:05] It might be the scn though [21:54:09] Fixes [21:54:11] d [21:54:34] Changed: if (IMUCase) to if (IMUCase && LEM) [21:54:57] Weird that it doesnt cause any issues for our missions [21:56:00] The weirder thing is that IMUCase points to 0xcdcdcdcd reproducibly instead of 0x00000000. [21:56:26] Supposedly 0xcd is a debug value malloc initializes memory to. [21:57:22] Wonder if it is some conflict with your scn file [21:57:29] some save/load thing that was changed [21:57:40] I don't see IMUCase being initialized anywhere. [21:57:42] Can I have that scn and see if I get the same? [21:57:52] All of the other variables are nulled. [21:57:55] I have it initialized [21:57:56] Sure, gimme a sec. [21:58:01] I think? [21:58:39] You think it needs a NULL in the Init? [21:58:50] Maybe [21:58:58] I'll test it here in a second. [21:58:59] Well let me see if I can reproduce it [21:59:09] With that scn [21:59:23] https://vanbeersweb.nl/share/Apollo%208.scn [22:00:47] Also a disclaimer [22:00:55] A bunch of CSM internals were shanged in the config [22:00:57] changed [22:01:06] So your scn doesn't reflect that [22:01:13] Nulling it in the constructor works. [22:01:40] I loaded your scn just fine [22:02:07] Did you remove the && LEM [22:02:10] Before nulling? [22:02:23] Yes [22:02:36] Are we on the same branch? [22:02:45] Orbiter2016 [22:02:45] I'm on Orbiter2016 [22:03:00] I mean mine is a little different, but only checklists [22:03:14] Other than that I am up to date as of maybe 20 minutes ago [22:03:24] Hmm [22:03:27] Ah [22:03:28] And I load your scn with no issue [22:03:30] I'm on LEM. [22:03:41] Ah] [22:03:45] Thats an old one [22:04:04] It's mine. CWEA lives there. [22:04:20] That doesn't come even come close to touching IMU code though. [22:04:51] Well orbiter2016 has a bunch of thermal code for the IMU [22:05:04] The LM for example has a fully functional IMU case [22:05:12] Complete with blowers, glycol, and a radiator [22:05:17] And the TEMP light works [22:07:15] LEM is up to date with all that. [22:07:34] I just didn't change anything in that area. That's the weird thing. [22:07:48] I'm building upstream now, see if that works without any patches. [22:10:29] Orbiter 2016 in it's current state works just fine with your scn [22:10:37] No joy [22:11:07] So why can I load it and not you [22:13:13] Silly question, you are building in release? [22:14:38] Pretty sure I'm not. Otherwise malloc wouldn't free the heap to the debug value 0xcdcd but I'll check. [22:15:02] Yes, debug. [22:15:07] Ah hah [22:15:29] Should be in release :P [22:16:00] lol [22:16:11] but one of the reasons for debug is to catch problems like this! [22:16:58] Well building in release I would think resolves this issue? [22:17:08] There is no CTD building in release [22:17:15] Since when have we started building in release again? [22:17:28] I have been building in release since I started [22:17:34] rcflyinghokie: Building in release hides the issue. [22:17:55] But wouldn't the CTD show up in either [22:18:00] If it was a problem [22:18:44] I am going to build in debug and see what happens [22:19:13] It wouldn't because the memory allocator frees memory to 0x000000 instead of the debug value and that specific value is tested. [22:19:18] rcflyinghokie: it's accessing uninitialized memory [22:19:33] debug is detecting this by filling that memory with 0xcdcdcdcd [22:19:40] it's entirely possible that release is only working by good luck [22:19:41] The proper way to do it is to initialize it to 0 in the constructor. [22:19:44] So it does need a NULL [22:19:47] yeah [22:19:52] Yes. [22:19:59] I'll submit a PR now. [22:20:17] Cool [22:20:21] I'll add it to mine [22:20:56] By the way just unboxed the G502 [22:20:59] I like the feel [22:21:07] awesome! [22:21:14] Not used to a virgin mouse feel though [22:21:22] haha [22:21:41] My G5 feels more "solid" if that makes sense [22:21:51] Its also heavier believe it or not [22:22:03] Or very close [22:22:24] I will try it out tomorrow [22:22:36] After I wipe [22:22:43] even with all the weights in? haha [22:22:47] Yeah [22:22:50] wow [22:23:01] My G5 has 8 4.5g weights in it [22:23:06] dang [22:23:11] I don't know if I have any weights in mine... [22:23:21] I put all of them in the 502 [22:23:30] But the base mouse is heavy as well [22:24:30] Yeah building in debug I can duplicate the ctd [22:24:55] Thymo let me know when the PR is up so I can put it into my code [22:24:58] up [22:25:01] Never mind [22:25:02] haha [22:25:07] :P [22:25:08] hehehe [22:25:20] Did you try the debug build? [22:25:22] Yeah [22:25:54] That was both Niklas and my fault for missing that [22:26:04] We both were in that code a lot getting the IMUs tuned [22:26:11] Specifically the heating [22:26:15] Happens to the best [22:26:24] It's just a single line that was forgotten. [22:27:06] Attached the debugger once more to be sure. IMUCase is initialized to NULL now. [22:27:22] Good [22:27:28] And good catch [22:29:19] Just remember to build debug from now on and these things won't sneak in again. :) [22:29:59] I remember there was a reason we were building in release [22:30:06] I cannot recall though [22:33:04] AFAIK There were issues in the past building in release mode with the LVDC. That's why I switched to debug ages ago. [22:34:17] Oh well [22:34:38] Lets see if I can load a LM scn with debug build [22:35:25] I am also making sure I have everything backed up for a wipe [22:35:32] I always feel like I am forgetting something [22:36:15] Debug assertion failed [22:36:43] I have never seen this error before [22:37:05] isatty.cpp line 17? [22:37:29] Debug Assertion Failed! [22:37:30] Program: F:\Orbiter 16 Beta\Modules\ProjectApollo\LEM.dll [22:37:30] File: minkernel\crts\ucrt\src\appcrt\lowio\isatty.cpp [22:37:31] Line: 17 [22:37:31] Expression: (fh >= 0 && (unsigned)fh < (unsigned)_nhandle) [22:37:32] For information on how your program can cause an assertion [22:37:33] failure, see the Visual C++ documentation on asserts. [22:37:36] (Press Retry to debug the application) [22:39:26] _VALIDATE_RETURN((fh >= 0 && (unsigned)fh < (unsigned)_nhandle), EBADF, 0); [22:39:30] That is the line in question [22:39:34] I got that too a while back. It fixed itself when I merged my branch since I was on the old version. [22:39:43] isatty is some MS code. [22:39:57] Well building in debug I cannot loat any of my LM scenarios [22:39:58] load [22:40:04] I get that [22:40:05] To really know the issue we at least need the callstack. [22:40:30] I have that up [22:40:55] Might be easier if you just loaded my scenario on your end though you would know better what to look for [22:41:08] I also triggered the assertion [22:41:13] Apollo 17 - PDI [22:41:39] Ah same thing? [22:41:47] So its with the LM in play [22:42:01] Yeah [22:42:23] It can't get the lunar battery pointer it seems. [22:42:31] Ohh [22:42:42] Yeah its disabled right now, [22:42:57] Needs to be removed from old LM scn's [22:43:11] That shouldnt have been a factor in mine though [22:43:31] This scn was launched well after the removal of the lunar battery [22:45:03] What about ASC_BATTERY_B? [22:45:21] aka Battery6 [22:45:57] Unchanged [22:46:02] Thats very much still there [22:48:12] Whenever I load a scn with a LM or generate it via LM ejection I get the same error [22:48:15] Same line [22:49:26] Looks like some testing is ahead then. [22:50:04] I need to get some sleep. I'm mostly recovered from the flu but got a massive cold in return. Not feeling completely better yet. [22:50:57] Goodnight! [22:51:18] Ah I went through that in January, feel better! [22:51:31] Thanks. :) [22:52:20] I think I need to give my brain a rest and do some gaming :P Take care! [14:16:56] Good morning [14:17:27] hey [14:18:07] So what are your thoughts on building in release versus debug right now? Undoubtedly you saw Thymo's message? [14:18:30] I like having more than 2 frames per second [14:18:43] As do I [14:18:58] Also I cannot build any scn's with a LM in Debug [14:19:01] Well I can build [14:19:02] no idea what settings Thymo uses to be able to run NASSP properly in debug mode [14:19:04] I can't do it [14:19:05] But cant run [14:19:16] Ok then it wasn't just me [14:20:00] I got awful frames in a CSM scenario, and when i created a LM I got an exception in code I have never messed with [14:20:16] isatty.cpp [14:20:35] well, exception in debug mode points to bugs [14:20:47] but aweful frames, not sure [14:21:26] Forgive the copy paste from yesterday: [14:21:27] Debug Assertion Failed! [14:21:27] Program: F:\Orbiter 16 Beta\Modules\ProjectApollo\LEM.dll [14:21:28] File: minkernel\crts\ucrt\src\appcrt\lowio\isatty.cpp [14:21:28] Line: 17 [14:21:29] Expression: (fh >= 0 && (unsigned)fh < (unsigned)_nhandle) [14:21:30] For information on how your program can cause an assertion [14:21:32] failure, see the Visual C++ documentation on asserts. [14:21:34] (Press Retry to debug the application) [14:21:36] _VALIDATE_RETURN((fh >= 0 && (unsigned)fh < (unsigned)_nhandle), EBADF, 0); [14:21:38] That is the line in question [14:22:40] I don't even know what isatty is [14:23:07] Me either [14:24:16] could also always be a DX9 Client issue [14:24:26] that it doesn't really support debug mode [14:25:59] Which reminds me Thymo also said there was a new DX9 out? [14:26:20] r914 [14:26:54] DX9 or DX9 Client for Orbiter? [14:27:15] He said client for orbiter [14:27:30] I downloaded it but was hesitant to install [14:28:05] I don't see the update [14:28:07] where is it? [14:28:19] Let me see if I can find the link [14:28:55] https://www.orbiter-forum.com/showthread.php?t=18431 [14:29:41] Link goes here: [14:29:42] https://www.tuttovola.org/index.php?PHPSESSID=hl0clhtrm2tli3dscnh25b8ts3&action=downloads;cat=64 [14:31:05] oh, that already was released in October [14:31:09] pretty sure I've been using it since [14:31:46] https://www.orbiter-forum.com/showthread.php?p=565651&postcount=4436 [14:32:02] I thought 908 was the one we got when the beta was updated [14:32:23] Interesting [14:32:26] maybe [14:32:30] Oh well [14:32:42] Yeah I downloaded 908 on Oct 14 [14:32:57] in my dowload folder I have r723, r892 and r914 [14:33:32] so those I have used [14:34:14] Well I am behind then haha [14:34:19] just checked, I've indeed been using r914 since October [14:34:27] no major changes anyway [14:35:50] so, I still can't say I properly understand what the XLunar Bus Tie CBs do [14:36:08] What they do now or what they are intended to do [14:36:19] what they do in the real LM [14:36:28] Hey [14:36:40] if there is no loss of function if you have them open, apparently [14:36:43] hey Thymo [14:38:24] The xlunar bus looks like its own bus bar [14:38:36] And it uses it to tie the cdr and lmp busses [14:39:07] I think? [14:39:34] pdf pg 339 of the AOH volume 1 has a diagram [14:42:02] There are two negative busses as well [14:44:25] They act as ground returns [14:49:24] But what I am having a hard time figuring out is "CSM deactivates LM power and then supplies power to the LM critical equipment, using the LM translunar negative bus." [14:50:05] I guess it means it is powering the xlunar busses instead of the main busses? [14:51:07] Check out pg 356 [14:51:18] Has the switching logic with a blowup of the xlunar busses [14:52:12] They act as floating grounds and sources of return [14:53:14] "Loss of capability to tie LM structure ground to the LM xlunar ground (redundant)" [14:54:29] it doesn't look like those CBs really much of a function with our current simulation of the EPS [14:54:38] Nope [14:54:47] after all the bus is already connected through the ground with the relay contacts [14:54:53] And the condition that they be closed for powering the heaters is wrong [14:55:15] so I'll probabl change it to [14:55:16] lem->CDRXLunarBusTieCB.GetState() == 1 || lem->CSMToLEMPowerConnector.csm_power_latch == 1 [14:55:17] The bus ties I think are just as a precaution to keep a ground return [14:55:40] yeah [14:55:53] that's the condition for the voltage coming through [14:56:07] Hah [14:56:18] the new one [14:57:15] of course, if a voltage is there, the power latch will be 1 anyway [14:57:55] Is that for voltage to the xlunar bus? [14:58:23] Coming either from the CSM or the LM [15:00:29] xlunar bus control class [15:02:24] Ah I see [15:02:39] I see where they were going with that but it appears to be misinterpreted from the AOH [15:03:30] is that second section of conditions wrong? [15:03:40] The CSM directly feeds the CDR 28V bus, which is tied to the LMP 28V bus [15:03:51] oh, remember that we were missing the relevant section in the LM Systems Handbook? [15:03:58] I am just trying to figure out the xlunar path [15:03:59] http://moonpans.com/apollo_flown_items/a17-descent-schematic-big2.jpg [15:04:08] http://moonpans.com/apollo_flown_items/a16-asc-2000.jpg [15:04:33] I am on the LM 10 vol 1 "CSM/LM Primary Transfer Logic" [15:04:49] It has a good display of this but I am just trying to make sense of it [15:05:46] See if you can make sense of it [15:06:04] The direct connection to the 28V busses is very evident, so I know the CSM feeds them directly [15:06:19] Latching relays are what control the xlunar and negative bus connections [15:06:44] Ohh [15:06:51] They are connected to the CSM - bus [15:07:04] As a source of return and measuring current [15:13:18] hmm [15:13:53] Did you checkout the logic schematic? [15:15:15] doesn't help me much [15:17:56] So what I think... [15:18:28] When in CSM power, the CSM directly powers the CDR 28V bus, tied to the LMP 28V bus [15:18:47] Those busses ground on the respective negative busses [15:19:28] CDR and LMP bus are tied through the BAL LOADS CBs [15:19:31] And the latching relay connects the - busses to the xlunar busses even if the breakers are open to return to the CSM to complete the circuit to get an ammeter reading in the CSM and not just the LM [15:19:32] those are closed at launch [15:19:43] Yes [15:20:42] Does that kind of make sense? [15:21:24] probably :D [15:22:53] From that schematic the only reason it is tied to the xlunar bus is to provide a floating ground return to the CSM [15:23:29] The relays basically take the place of the xlunar bus ties [15:23:39] So they can remain open during TLC [15:24:01] So your "or" logic makes sense [15:24:24] But any logic that requires them closed for power transfer is wrong [15:24:51] yes [15:29:22] Ok time to switch to my old laptop while I wipe my desktop and await my new laptop [15:32:52] so what do we do with that "else" logic [15:33:07] actually tieing the CDR and LMP buses together is done somewhere else [15:33:16] I am updating VS here I will look in a sec [15:34:51] But yeah any tieing of the 28V busses should only be done with the bus tie breakers [15:37:41] so two ORs? [15:37:52] CSM power latch or one of the XLunar bus ties? [15:38:03] not that those are really necessary anyway right now [15:38:33] Are we talking about tying the xlunar busses or the 28v busses? [15:39:11] what are the xlunar busses even doing? [15:39:20] They are a floating ground [15:40:26] for what exactly [15:40:40] A return for DC current that is not actually the LM structure [15:41:29] Its a ground that isn't "grounded" if that makes sense [15:42:11] yes [15:42:14] In the LM case I believe it gives a more reliable "ground" source for the DC current [15:42:32] Instead of routing everything to the negative busses which are grounded physically to the structure [15:42:50] right [15:43:43] Now some components from the brief look at the schematic you sent ground right to the negative bus and some ground via the xlunar bus [15:44:07] And the xlunar bus tie just connects the xlunar bus to the physical grounded negative bus [15:44:17] but is it only used for the power coming from the CSM? [15:44:42] I need to look at it closer but I think some systems use the xlunar bus as a ground [15:45:11] It would be on that schematic you sent me, I need to go through it [15:45:29] I saw the lmp xlunar bus mentioned on it in the lower left but didnt trace [16:08:27] Wow my desktop was dusty [16:08:43] Data vac was the best computer cleaning investment I have ever made [16:18:16] yeah, PCs can collect a lot of dust real quick [16:18:44] Especially with a dog [16:20:55] If I am reading this right, it looks like the DES ECA's use the xlunar bus [16:21:13] But I cannot see any connections into it from the ascent stage [16:22:15] Just the grounded portion using the breaker [16:22:37] Might be why that emerg cm power breaker was added to allow csm power return without a descent stage? [16:56:18] How did you guys get textures working on orbiter beta? I added the TextureDir parameter to the Orbiter.cfg but it isn't loaded by the d3d9 client. [16:56:25] It works on DX7 though. [16:59:21] I don't remember offhand, there were instructions somewhere on orbiter forum I think [16:59:49] But I thought I just copied the DX stuff into my install and checked the boxes in the launchpad [17:00:13] The whole texture folder? [17:01:25] Yeah since I am only using the Beta [17:01:31] I just copied the whole thing [17:01:59] Otherwise what you are saying is to let the beta use the same texture files from the release install [17:02:39] Someone is begging to go on a walk since I dont have to work today, I'll be back [17:48:36] morning! [17:48:45] Hey Mike [17:51:35] what's up? [17:51:53] Trying to get my textures to work in orbiter beta [17:52:04] How about you? [17:58:21] indy91: Ryan and I came across another bug yesterday. Can you try rebuilding to debug and run a scn with the LEM in it> [17:58:22] ? [17:58:23] I think I have finally finished my gigantic spreadsheet of AGC pins [17:58:48] Oh nice [17:58:53] so now I need to feed it all into a database and make a consistency checker [18:00:55] dinner brb [18:04:24] rcflyinghokie, how about you do the XLunar Bus change? You seem to understand it better than me, haha [18:04:42] I'll just continue with the Apollo 10 MCC [18:05:56] Sure I will see what I can do [18:06:07] I need to learn the EPS code anyways [18:08:27] in the CSM it's all nice and straight forward [18:08:45] at the expense of having duplicate circuit breakers (MNA and MNB) for basically everything [18:09:20] Haha yeah [18:09:32] Hell I might even learn the ECA's a little better along the way [18:09:45] But I should be able to figure it out [18:15:24] found the issue in debug mode [18:15:30] LUNAR_BATTERY [18:15:46] it tries to initialize that in code [18:15:52] but in the config it's commented out [18:16:14] Right because its not carried until Apollo 15 [18:16:36] yeah [18:17:02] Did you merge your changes to the xlunar bus so far? [18:17:03] and the GetPointerByString function calls a BuildError if it can't find the connected system [18:17:14] no, but it's really only one line [18:17:19] the OR condition we talked about [18:17:30] lem->CDRXLunarBusTieCB.GetState() == 1 [18:17:32] changed to [18:17:32] lem->CDRXLunarBusTieCB.GetState() == 1 || lem->CSMToLEMPowerConnector.csm_power_latch == 1 [18:18:00] Ok [18:19:14] I'll comment out that lunar battery line [18:20:23] with that Orbiter loads [18:20:27] 8-9 frames [18:24:35] Yikes [18:24:47] but it's been always like that for me [18:24:52] hence I never use full debug mode [18:25:01] I often build the RTCC MFD in debug mode [18:25:08] but not the rest of NASSP [18:25:18] makes debugging the RTCC easier [18:25:35] you can debug in release mode, but not all variables are available etc. [18:27:05] Makes sense [18:27:15] Good to check once in a while but not for flying a mission per se [18:28:37] yeah [18:28:39] So I am probably removing a lot of this xlunar tie code since it mostly depends on those breakers [18:28:56] I will leave comments as I go to trace the steps like what was done before [18:29:23] sure [18:29:59] But basically we get flow if the relay is latched OR a complete circuit to whichever bus has the xlunar bus tie closed [18:30:14] I have the path right in my head, now to see if I can code it right [18:32:35] Quick question, where does dc_output.SetVoltage(sVoltage) output to? [18:33:25] Does that power the CDR 28V bus? [18:34:36] LEM_XLBControl is basically just a control class [18:34:50] LEM_XLBSource is the electrical device for it [18:34:55] dv_output is a LEM_XLBSource [18:34:57] dc* [18:35:22] usually e-systems derive their voltage from a directly connected system [18:35:28] e.g. battery or fuel cell [18:35:42] but in the case of dc_output its voltage is set every timestep "manually" [18:36:15] Basically I need this to connect the CSM power to the CDR 28V LM bus [18:36:18] short answer is, if you give it 0V then that is what the connected bus feeds in the LM are sensing as their incoming voltage [18:36:38] I cannot tell if it is already doing that [18:37:11] / So then, do we have xlunar voltage? [18:37:11] if(dc_output.Voltage() > 0){ [18:37:19] that is a check on that [18:37:32] and that's where it also draws power from the CSM [18:37:38] lem->CSMToLEMPowerSource.DrawPower(dc_output.PowerLoad()); [18:37:47] Right [18:38:30] I just cannot tell where it is putting that power [18:40:06] into the LEM_XLBSource class object [18:40:53] which is connected to the first LM bus [18:40:54] BTB_CDR_A.Init(this,&BTB_CDR_D,&BTC_XLunar.dc_output); // Tie batteries and XLUNAR feed for CDR bus [18:41:15] there is the dc_output again [18:41:31] so, basically, that is the voltage that actually arrives in the LM [18:41:49] or do you have trouble with the DrawPower line? [18:42:29] because of the connection in the Init line, systems in the LM are connected to the CSM power. Depending on the switch settings of course. [18:42:48] so that is how a power load can accumulate in the timestep as a demand to the CSM [18:42:58] dc_output.PowerLoad() is the sum of that [18:43:01] Well basically I just want to make sure that if it is drawing power from the CSM, it is feeding it to the CDR 28V bus [18:43:23] I had to draw myself a diagram to understand how we are doing it, haha [18:43:26] And then the only reason that power is shared with the LMP 28V bus is through the cross tie breakers [18:43:48] Yeah I guess thats what I am getting at, I am a little lost with how the code is doing things [18:43:51] CDRs28VBus.WireTo(&BTB_CDR_E); [18:44:06] that is the bus [18:44:15] and a (kind of fictional) bus feed [18:44:20] called CDR-E [18:44:22] and then [18:44:23] BTB_CDR_E.Init(this,&BTB_CDR_A,&BTC_MPX.dc_output_cdr); [18:44:52] so CDR-E gets its power from CDR-A and the "Bus Cross Tie Multiplex (Not real object)" [18:45:07] so there the power from the LMP bus would come from [18:45:15] Ok that sounds right [18:45:18] works the same way for the CDR bus [18:45:31] I just want to make sure that the csm power code isnt powering both busses [18:45:35] and then the init line above again [18:45:35] BTB_CDR_A.Init(this,&BTB_CDR_D,&BTC_XLunar.dc_output); // Tie batteries and XLUNAR feed for CDR bus [18:45:53] no, that should hopefully be through those bus feed connections [18:45:58] the CDR to LMP feed [18:45:59] Ok good [18:48:18] Oh so it looks like the DES ECA's ground to the XLUNAR busses [18:48:19] although I haven't really looked into the cross tie code [18:48:22] looks complicated [18:48:49] So I would think they need to be closed for the ECA's to work? [18:49:13] that doesn't seem right to me [18:49:25] Yeah it might just be an alternate ground for redundancy [18:49:47] But they do ground to the xlunar busses [18:49:53] Not saying thats the only path [18:50:21] hmm [18:50:39] the xlunar bus tie CBs are closed reeeeally early on in the activation [18:50:43] at transfer to LM power [18:50:53] Yeah [18:50:57] And left on throughout LM ops [18:51:02] Even on the surface [18:51:02] yep [18:52:08] having them open until LM activation would also stop the power from being accidentially disconnected [18:52:24] Yeah the floating ground [18:52:27] with unpowered ECAs you can't disconnect the batteries [18:52:30] Keeps the circuit complete [18:52:47] And open keeps the circuit open [18:52:51] Obviously [18:53:07] So maybe I was right about the ECA's being grounded solely through the xlunar bus [18:54:26] I am thinking though that the xlunar bus breakers really do not even need to be in that power latching code [18:54:41] yeah [18:54:54] one thing we also simulate right is the power latch [18:54:56] The only thing I can think of is powering the LM if the relays failed? [18:55:05] yeah, could be [18:55:07] those relays [18:55:12] they are powered from the CSM [18:55:15] Otherwise the position of the xlunar tie breakers is irrelivant [18:55:32] so only when there is actually coming power from the CSM, should the LV taps be disabled, right? [18:55:58] Thats what it looks like [18:56:01] the relay contacts switch CSM power to the CDR bus and disable the LV setting [18:56:09] Yes [18:56:18] So without CSM power, nothing powers those relays [18:56:22] in our case, it always switched to CSM power [18:56:29] even if the e.g. CBs in the CSM are open [18:56:55] Based on this, power would have to be transferred for the relays in the LM to function [18:57:04] just setting the switch in the CSM to "CSM" sets the power_latch variable to 1 [18:57:15] So that needs to check for voltage [18:57:22] On the breakers [18:57:51] wait, which ones? [18:58:06] The lm pwr csm switch needs power on the LM pwr breakers to latch [18:58:16] to latch the LM relays [18:58:22] yeah [18:58:25] the code is in LEMPowerConnector::ReceiveMessage [18:58:30] in lemconnector.cpp [18:58:48] Ok I am making a bunch of notes on this as I am slowly reinstalling everything on the desktop haha [18:59:18] Windows is doing all its updates then VS will go in [19:02:29] the determination of the relay state should probably be done in the xlunar bus control code [19:02:35] every timestep [19:04:11] Agreed [19:04:19] story of my life. moving relay code into timesteps called every frame. [19:04:26] have done that with so many systems [19:04:34] And I simplified the power code to just if the relay is latched or not [19:04:52] lem->CDRXLunarBusTieCB.GetState() == 1 || lem->CSMToLEMPowerConnector.csm_power_latch == 1 [19:05:05] oops [19:05:07] not that [19:05:09] if(lem->CSMToLEMPowerConnector.csm_power_latch == 1){ [19:05:10] // Yes, we can put voltage on the CDR bus [19:05:10] dc_output.SetVoltage(sVoltage); [19:05:11] }else{ [19:05:11] // No, we have no return path, so we have no voltage. [19:05:12] dc_output.SetVoltage(0); [19:05:12] } [19:05:36] seems simple and correct [19:05:43] Then the connector code can determine if the latch can be latched [19:06:34] indy91: How did you handle the textures for your beta install? Did you also copy the whole smack? [19:08:42] i am always using the beta install, so I just installed over Orbiter 2016, I think [19:08:50] I have a separate OrbiterBeta folder for testing [19:09:03] but I think I just used the default resolution textures there [19:09:18] so no, I never did the config edit stuff myself [19:09:39] Weird. In Orbiter Beta the planets are just black for me, no textures at all. [19:10:31] did you edit the Orbiter_NG config instead of the Orbiter one? [19:11:18] My changes appear to get wiped from the Orbiter_NG config, regular orbiter.cfg does work [19:13:35] Hmm [19:13:49] That's one solution. Making the file read-only... [19:13:54] haha [19:15:54] one thing I do not like is that the latch is controlled in the xlunar code as well [19:16:13] // If the CSM latch is reset, turn on the LV taps on batteries 1 and 4. [19:16:13] // And reset the latch to zero [19:16:14] lem->ECA_1a.input = 2; lem->ECA_1b.input = 0; [19:16:14] lem->ECA_2a.input = 0; lem->ECA_2b.input = 2; [19:16:15] lem->CSMToLEMPowerConnector.csm_power_latch = 0; [19:16:15] break; [19:16:23] Shouldn't that just be handled in the connector? [19:17:48] that's for the reset setting of the power switch [19:17:54] when you set it to reset then [19:17:54] csm_power_latch = -1; [19:18:24] and then the power is switched on again in the ECAs [19:18:31] but not every timestep, that would be bad [19:18:34] so only once [19:18:46] power latch is set to 0 to make sure it's only done once [19:19:06] case -1: [19:19:09] power_latch=0; [19:19:11] basically [19:19:35] that is the only reason for using two different states there, 0 and -1 [19:21:13] Ah ok [19:26:12] I am in the connector code now, where does it check the switch position? [19:29:48] LM or CSM side? [19:31:39] I guess I need the CSM side as the LM side recieves the message from it [19:32:06] I need to make it so that the relay only works if there is power going to the switch [19:32:13] that is in satswitches [19:32:15] And of course the switch is on [19:32:16] Ok [19:32:34] CSMLMPowerSwitch [19:33:16] hmm [19:33:30] I think checking the connection every timestep is a bit more complicated [19:33:44] probably needs a new connector message being sent [19:35:44] actually no [19:35:48] it's already there [19:35:52] a voltage check [19:36:12] so nothing has to be changed on the CSM side [19:36:43] Ok [19:36:44] of course [19:36:49] double sVoltage = lem->CSMToLEMPowerSource.Voltage(); [19:36:53] that's already there [19:37:10] so you just have to check that voltage every timestep [19:37:12] So the latch wont change if the switch is thrown with the breakers open? [19:37:18] and set the relays according to that [19:37:26] hmm [19:37:33] And it will unlatch if the breakers are pulled or power is removed from them [19:37:36] I'm not entirely sure there actually should be a latch [19:37:44] it's just a relay, or two [19:37:48] normal relays [19:37:51] not latching ones [19:38:25] Ah yeah [19:38:52] power removed wouldnt change the position in a latching relay without a specific input? [19:39:30] yeah [19:39:42] but I think these relays just work with powered/unpowered [19:40:03] and reset should be a separate signal [19:49:31] actually [19:49:37] there has to be some latch at least [19:49:41] in the descent ECAs [19:50:22] Ah yeah [19:51:05] The relay completing the xlunar circuit isn't one is it? [19:52:22] those labeled 4K3 and 4K4 in the CSM Systems Handbook [19:52:23] No on the schematic its a normal one [19:53:17] K3 and K4 in the LM aren't latching I don't think [19:53:26] yeah [19:53:47] we have a complete list of relays, and in the ECAs there are a bunch of relays with a "L" for latching [19:56:53] Makes things simpler in this case [19:56:54] "PNL XI 4K3" in the list, non-latching [19:57:05] Yep [19:57:13] so those two relays are directly in panel 11 somewhere [19:57:23] Thats the diagram I have up [19:57:54] No idea where in 11, but thats the title of the blowup with the latches [20:03:52] relays not latches [20:05:46] let's call them latches until they become latches [20:05:55] then we don't have to change the code [20:26:43] And IRC back on the desktop [20:26:53] And my laptop just got here [20:27:03] \o/ [20:27:27] Time to install VS on the desktop and see if I can debug [20:27:37] But first a reboot [20:34:20] Ok the definition of a fresh VS install [20:34:26] What should I include [20:34:57] debug mode [20:35:09] thank you CAPT obvious :P [20:35:19] Though I asked the question [20:35:31] Which workloads [20:39:50] Desktop development with C++ [20:40:08] not sure what else you need [20:40:22] I had some issues with choosing the right things on my netbook install [20:40:37] ended up choosing fairly modules randomly [20:40:44] I think I also had universal windows as well [20:40:58] But I will try first without it [20:41:09] yeah, start with a clean version [20:41:15] you can always add more later [20:41:55] night! [02:03:54] heyd [02:03:57] *hey [02:04:01] you debugging things over there? [02:07:24] I actually just got everything back up on the desktop [02:07:34] I am about to make an error to try debugging [02:07:56] I am noticing though my windows has features I did not have before, little things [02:08:05] So I think an update got messed up somewhere along the line [02:08:15] But I just built and ran NASSP [02:08:53] I also found that my HDD in my laptop is it's Achilles heel... [02:10:03] in terms of speed or space? [02:10:16] Speed [02:10:22] Its a HDD not an SSD [02:10:43] So its having trouble keeping up with the hardware [02:10:52] right, yeah [02:10:53] Which is why I am M.2 shopping :) [02:10:57] hehehe [02:11:01] gotcha [02:11:16] I have my orbiter repo 60 percent copied over there [02:11:22] Now to try debugging on the desktop [02:14:36] But with the wipe the desktop is much smoother [02:16:49] sweet [02:16:53] yeah I definitely need to do this [02:18:02] Its been Over a year for me [02:18:10] 15 months [02:18:19] Usually I do it every year at the most [02:18:36] But I had a lot of stuff on here for school last year I didn't want to lose plus moving etc [02:22:07] Ok put some bad pointers in and building [02:22:11] Lets see what happens... [02:25:42] Uhh I click debug and nothing happens [02:26:57] Ohhhh [02:27:10] I bet this was it and my problem before... [02:27:10] The solution was to switch off the "Automatically check for solutions" option in "Control Panel\System and Security\Action Center\Problem Reporting Settings" [02:29:01] Hmmmm [02:30:54] Where is that in windows 10 [02:36:57] Hah disabling windows error reporting was the trick [02:39:07] Disabling windows error reporting seemed to do it [02:56:07] And with that I am going to let both computers download a lot overnight and go to bed [02:56:09] Night! [12:37:58] Hey [12:40:35] hey [12:41:30] Looks like Ryan managed to get his debugger working again. [12:42:48] great [12:46:31] Apparently "The solution was to switch off the "Automatically check for solutions" option in "Control Panel\System and Security\Action Center\Problem Reporting Settings"" [14:37:34] Morning [14:38:02] hey [14:38:58] you implemented the CM staging while still on the S-IVB recently, right? [14:39:15] yep [14:39:20] there actually is a use for that [14:39:31] found it in the RTACF requirements for Apollo 10. [14:39:49] basically a hybrid deorbit maneuver, but with a S-IVB LOX dump as the first half [14:40:13] the RTACF has a requirement to calculate the duration of LOX dump to lower the perigee to 80NM from 100NM circular [14:40:26] and the using the RCS from the CM? [14:40:43] and then one orbit later you would separate the CM and do the CM burn procedure of the hybrid deorbit [14:41:01] I guess this is for the case that the SLA fails to open [14:42:11] interesting [14:42:46] yeah, perigee to 80NM and then one rev later a 80fps burn with the CM RCS [14:43:53] I think the LVDC is not flexible enough to do this with IU uplinks [14:44:00] at least it wasn't on Apollo 10 [14:44:10] so it would be done with LV takeover [14:44:14] plus uplinks for the LOX dump [14:44:24] Ah, right [14:44:44] Looks like that’s possible to simulate, now [14:44:50] simply keeping the S-IVB retrograde with the help of the ORDEAL [14:45:08] LOX dump TIG is fixed at "Texas ACQ + 2 minutes" [14:45:26] I guess to make sure that there is continuous tracking, to stop the dump [14:47:46] so landing is somewhere in the Atlantic [14:48:18] I'll have to add a few more calculation options to support that kind of deorbit [14:48:26] but otherwise, it should be quite possible already [14:48:56] maybe I'll make a video about the various deorbit methods :D [14:49:23] That would be great [14:50:02] SPS deorbit, SM RCS deorbit, hybrid deorbit, No SLA Sep Deorbit [14:51:36] I guess if SLA fails post-TLI similar procedures are available. [14:52:01] hmm, good question [14:52:25] SIVB stack on FR, maybe the LOX could be used for a FR MCC [14:52:32] right [14:52:34] or the APS [14:53:08] even on Apollo 8 already you could probably do a lot with creative use of IU uplinks [14:53:36] I still have to add the calculations for supporting finite S-IVB burns [14:54:09] Brb [14:54:16] even a mission like Apollo 17, which is very far from free return, should have enough DV in the S-IVB to return home [15:03:25] Yeah I’d actually like to try that [15:04:02] I guess you would target the least-DV free return maneuver possible [15:04:41] haha, Apollo 10 mission rule for this says "refer to MR [blank]" [15:05:35] also, "enter next best PTP (preferred targeting point)" [15:05:51] during TLC that is [15:06:44] says that for all missions [15:12:17] I’d probably use opt.8 for that one [15:17:19] ah, and of course for the deorbit types there is also SCS controlled ones [15:23:47] Good morning [15:24:20] Hey [15:24:23] hey Ryan [15:25:12] I can safely say I need an SSD for my laptop sooner rather than later [15:25:30] I didnt realize how much of a bottleneck a mechanical drive is when I have been using SSDS for a while now [15:26:59] But on to NASSP business, the code changes seemed to work on the LM power transfer last night, the only thing is, and I am not sure is this is normal, but when I went into the LM and turned on the EPS displays, battery 1 and 4 LO tb's were gray [15:27:20] I also could see bus volts and current on the CDR bus and LMP bus in the LM and on 4D [15:27:50] well, the buses are powered, therefore there will be a current [15:27:59] While I do not know about the tb's being able to be shown, I can say that there was no current on any LM battery [15:28:01] right? it's just not coming from the own LM batteries [15:28:04] Yes [15:28:30] bats 1 and 4 should not be grey [15:28:43] I thought not [15:28:55] They had no draw but the tb's were grey in LO [15:29:21] The current draw though after everything warmed up a few minutes settled to about 0.9-1.1V on the systems test meter though [15:29:42] they should be grey showing LO [15:30:15] but not fully grey [15:30:56] Ok so that is normal [15:31:00] Een under CSM power [15:31:03] Even [15:31:07] maybe, have to check [15:31:13] at least that's not something you broke [15:31:17] They did have zero current though [15:31:18] shows LO for me as well [15:32:10] 0 current or 0.9-1.1V, which is it? [15:32:12] Is the LM EPS bug where if you don’t reload after LM ejection fixed now? [15:32:26] it might be [15:32:48] fixed is the random power draw that accumulates at the xlunar bus [15:32:59] maybe that also fixes the reloading thing [15:33:24] I think it is [15:33:43] I tried it a bunch last night and never had any problems with EPS [15:33:57] I know it didnt occur every time, but I had no issues requiring a reload [15:34:07] PR is up with those changes [15:36:12] "normal" speed flyby for Apollo 10 is less DV than free return, haha [15:36:36] hmm [15:36:39] that's weird [15:37:07] oh I see, free return splashdown longitude is at 65°E [15:37:23] and the flyby PAD has the normal 165°W west landing [15:40:30] still, they chose the slower return for that flyby solution, which is more DV than the slightly faster one [15:40:50] either that runs into a reentry velocity constraint or they did a bad job selecting the flyby solution [15:44:24] close, but by my calculation it doesn't exceed the 36333 ft/s limit [16:15:07] morning! [16:19:59] Hey Mike o/ [16:21:55] hey early Mike [16:22:25] haha [16:22:33] hopping on before I head in to work with two little bits of news [16:23:36] first, I grabbed this when it popped up yesterday: https://www.ebay.com/itm/NASA-Apollo-IBM-ASTRIONICS-SYSTEM-HANDBOOK-Saturn-Launch-Vehicle-/292472506484?nma=true&si=PbnCAqWVoolE3bJcFowP6WKmyBk%253D&orig_cvip=true&rt=nc&_trksid=p2047675.l2557 [16:23:51] it says Astrionics System Handbook on the binder, but I think that might just be reused [16:24:00] inside is an IBM SLCC Programmer's Manual [16:25:14] wow, very nice [16:25:15] and possibly another IBM thing behind it, it's hard to tell, but it looked interesting and possibly useful [16:25:36] so, scans of that in a week or so [16:25:49] the other, more exciting news [16:25:50] surely a Saturn V EDD :D [16:26:02] hahaha, that would be amazing [16:26:28] anyways -- the guy with the AGC is definitely interested in mapping out his AGC [16:26:36] but! [16:26:51] he also said he's interested in trying to power it up for the upcoming 50th anniversary of the landing [16:26:58] wowoow [16:27:00] which would be suuuuuuuper cool [16:27:03] That would be so awesome! [16:27:27] as far as I know he doesn't have rope memory modules, so stand-ins would need to be made (I already have sketches of designs for these) [16:27:51] I guess we could try to use Comanche or Luminary 1A [16:27:53] and I think the EL phosphors in real DSKYs have probably decayed beyond the point of being usable so a stand-in would need to be made for that too [16:28:15] yeah, if I end up making a core rope simulator, it'll have all of our programs loaded onto it [16:28:30] indy91: Or rather Aurora or Borealis. [16:28:36] especially Aurora and Borealis :D [16:28:44] at least at first for testing [16:28:48] yep [16:29:01] what about erasable [16:29:13] thewonderidiot: You'd be the first one to have developed 3rd part software run on actual hardware. [16:29:26] I think that module is potted, so we just need to hope that all of the cores are still good [16:29:35] any rope can tell us that, though [16:29:46] hehehe, yeah [16:30:29] anyway this is very preliminary so it might not go anywhere, but it is too exciting to not share :D [16:30:44] indeed [16:31:06] what would be really fun is loading a core state into the ersable [16:31:13] erasable* [16:31:16] hahaha yeah [16:31:20] actually [16:31:36] it might not be a bad idea to try to dump erasable through the test connector before ever loading a program [16:31:49] just in case there is still data retained in it from when it was last run [16:31:57] yes [16:32:06] ...and also to correct the parity on everything if the data has gone bad [16:32:46] on the standalone Virtual AGC you can run P63 all the way through ignition without needing any connected devices [16:32:52] that would be the holy grail [16:33:05] hahaha yes, that would be awesome [16:42:06] you know [16:42:28] even damaged cores in erasable might not be the end of the world [16:42:46] I think I might be able to "fix" them through the test connector [16:42:49] (I love the test connector) [16:44:21] How do you even fix a broken core? Tickle it with electricity? [16:44:52] no, use offboard storage and inject the expected data when the AGC tries to read the affected word [16:45:24] enough control signals go out that you can save a copy of what the AGC has written to every address, and send it back in when it tries to read that address [16:45:49] anyways, time to catch the train, be back in a bit [16:46:31] Didn't know that. I really need to do some reading on that connector. [16:59:23] So when the LM is spawned, it is not running on it's batteries [16:59:39] At least from what i can tell [17:00:40] Which is why the systems cool during the 30-40 minute pressurization and then draw higher current when CSM power is applied [17:00:51] So the LM needs to start running on batteries 1 and 4 LV [17:01:03] And those switched off via the relays [17:02:48] Also when the LM is spawned, I cannot control the batteries [17:03:47] I'll do a bit of debugging on that [17:04:46] According to the comments it should be running on the batteries at spawn [17:05:46] The init looks right for the eca's and batteries [17:06:55] And if I give it CSM power the tb's show up and busses come alive [17:07:23] And I remove it and same problem [17:08:47] And a save and load makes it all work properly [17:11:32] yeah, I think something makes it work when it loads from the scenario [17:11:40] versus LM created from scratch [17:13:55] Something saved and loaded versus what is created with the LM? [17:14:22] probably the way it is initialized upon loading vs. creation [17:18:28] hmm, my LOI-1 TIG on Apollo 10 is quite a bit later than in the flight plan [17:20:05] although the same is true for the actual flight [17:22:30] That's a good thing [17:23:47] oh, we don't actually have the final, final flight plan [17:23:56] there was a revision on May 5th [17:24:00] we have April 17th [17:26:28] SCOT from April 28th still has the same TIG as the flight plan we have [17:30:38] maybe one of the 100 documents we have for Apollo 10 has the relevant changes :D [17:32:17] Perhaps :P [17:42:17] 070:19:20 Lousma: That is affirmative. Also, we would like you to know that LOI is now about 11 minutes later than our preflight planning, because we didn't burn midcourse correction 1 and made our translunar trajectory adjustment at midcourse 2 instead. So this puts us 11 minutes behind on LOI and 11 minutes behind throughout all of our lunar orbital activities. I have some additions to make. [17:42:32] I burned MCC-1 though, haha [17:44:54] could just be the optimization of the MCC that is different between our and the actual RTCC [17:45:28] the hybrid trajectory missions can achieve any pericynthion time they like [17:46:45] aaaand back [17:49:52] welcome back [17:52:25] ah, I was only checking the pericynthion time. Our LOI-1 TIG is actually a minute closer to the flight plan than the actual mission [18:53:37] rcflyinghokie, another checklist thing, at 45h GET [18:53:44] "check celestial body option" [18:53:55] John Young looked at Jupiter and Mars there [18:55:31] if we don't have the planet half vectors for Apollo 10 then I am going to generate some [18:56:06] Do we have that capability? [18:56:30] to calculate them? [18:56:41] not yet, but it's similar to what I did with the star vectors [18:56:56] but the crew charts document has them [18:57:11] not super readable, but usable [18:58:12] I have never even tried that option before [18:58:28] hmm, I am fairly sure you have [18:58:41] it's also used with stars that are not in the AGC [18:58:54] pretty sure the nominal LM surface procedures use some of those stars [18:59:12] and you then have to manually input a vector for the star, instead of an ID [19:00:20] Apollo 12 LS Checklist has a handwritten note for one [19:00:25] if you ever flew that one [19:05:47] I probably have just not in a while [19:06:32] it's a quite useful capability [19:06:35] even in Orbiter [19:06:50] we should have way more stars than just the ones the AGC knows about [19:07:02] and planets are also usable of course [19:07:19] but they move a lot, so the G&C Checklist has tables for their position [19:08:03] I'll do a normal P52 and then I'll check if these numbers from the crew charts are any good [19:09:01] Awesome [19:11:54] I am really struggling to make the ECA's not require the CONT breaker to turn on [19:13:59] I see Jupiter through the sextant [19:14:03] and Callisto [19:14:11] and Ganymede [19:14:15] and Europa [19:14:17] Wow [19:14:44] Io must be behind Jupiter or so [19:17:08] bool LEMBatterySwitch::SwitchTo is driving me crazy [19:19:33] but even without markers, I clearly see 3 Jupiter moons [19:19:35] at 60x [19:19:50] seems about right, I remember the Moons from my fathers telescope, about 100x [19:19:57] I'll help you shortly :D [19:24:58] there is Mars [19:25:04] can't see any of its moons [19:25:06] too small I guess [19:25:18] if the AGC is anything then it's a great celestial navigation machine [19:26:30] ok, LEMBatterySwitch [19:26:54] it can have two types [19:27:00] for the descent and ascent ECAs [19:27:11] that's the "afl" variable [19:28:46] Yeah I see thand and the condition to check the ECA CONT [19:28:55] that and [19:29:05] I just cannot figure out to make the switching on conditionless [19:29:17] Or just needing ECA power [19:31:41] maybe move the control code to case THREEPOSSWITCH_DOWN: [19:32:29] so those "check for control power lines" [19:32:33] power" lines [19:32:48] I tried [19:33:36] Maybe I did it incorrectly [19:35:36] maybe [19:36:07] basically, I would think, you just have to move the lines below "Check for control power" to case THREEPOSSWITCH_DOWN: [19:36:10] and that's it [19:36:44] That was the first thing I tried [19:36:58] what's the issue with that? [19:37:17] I remember something didn't work this was a while ago I am going to try it again [19:37:31] maybe you were still under CSM power [19:38:19] Could be [19:40:52] Moving it there I can switch them on and off with the breaker in or out [19:41:55] Unless I did it wrong [19:42:05] ok [19:42:10] I'll try it as well [19:42:47] I'd like to move this to ECA code anyway, which will require a bit more complicated coding, so I can take care of it [19:42:54] but this solution should really work [19:44:00] I thought so too [19:46:46] well, you did it wrong I think, haha [19:46:49] it works right for me [19:47:01] can you take a screenshot of your code? [19:47:25] Yeah I probably messed up something [19:47:43] should be simple enough [19:47:52] not many ways to mess this up [19:49:52] https://www.dropbox.com/s/btl0vod6n95wfme/Screenshot%202018-03-06%2014.49.25.png?dl=0 [19:53:58] well, that's not right [19:54:13] you moved it just above the "case THREEPOSSWITCH_DOWN:" [19:54:21] it has to be just below it [19:54:52] that's how the switch - case stuff works [19:55:03] Ah [19:55:16] I don't know the case stuff that well yet [19:55:33] I sort of understand, but the syntax I am still not great with interpreting [19:55:59] switch (state) evaluates the variable state [19:56:15] and then it will jump to the appropiate line with case [19:56:28] Oh [19:56:36] What about switch (srcno) [19:56:43] that's a separate switch [19:56:45] Is that a separare case logic within a case [19:56:49] separate [19:56:53] for LV/HV [19:57:05] so that this LEMBatterySwitch class can be used for that as well [19:57:10] Ah I see [19:57:13] srcno determines LV or HV [19:57:27] and "afl" DES vs. ASC [19:57:50] While this probably wont fix the save load thing, its another step in the right direction with proper procedure and function [19:58:00] yes [19:58:04] I will fix the checklists as well [19:58:15] I can remove that extra ASC ECA CONT step [19:58:44] And when I PR that we can close my git issue on it [19:59:10] And I think the power transfer one as well [19:59:20] I might have already just found the issue with the LM creation [19:59:25] Oh? [19:59:51] the function PostLoadSetup() is only called when the LM is loaded [19:59:53] not when created [20:00:06] and in there is stuff like [20:00:07] DES_LMPs28VBusA.WireTo(&ECA_1a); [20:00:10] Ah [20:00:14] that might be it [20:00:19] That sounds like the smoking gun [20:01:15] Which file is this in? [20:02:07] LEM.cpp [20:02:15] I'll fix that [20:03:21] Sounds good [20:03:26] I'll be back [20:11:23] let's see if simply calling that function causes a CTD [20:13:57] nope [20:14:09] and I have voltage and current in the LM [20:18:15] update pushed [20:40:12] Great [20:42:21] I am working on the ECA CONT in the checklists now making sure I take out the ones not in the actual procedures [20:43:39] procedure wise we should be good now, right? [20:43:52] except for the time when the LM is not existing yet of course [20:48:14] As far as I can recall yes [20:48:28] I dont think I had to work around anything else [21:00:17] The only thing I am unsure with is when apollo 9 activates the ascent batteries all I have to go with is "connect asc batts" [21:00:48] yeah, we are lacking a lot of Apollo 9 procedures [21:00:52] I think they would stay open though to prevent inadvertent shutoff [21:11:49] up to MCC-3 now, which has different execution criteria than Apollo 8 [21:14:00] Which is? [21:14:24] for Apollo 8 it was a DV threshold [21:14:38] but for Apollo 10 it is basically "can LOI-1 be properly targeted" [21:15:16] one fixed number is the pericynthion altitude at least [21:15:23] has to be between 50 and 70NM [21:15:52] node also has altitude constraints [21:16:10] so I probably have to calculate LOI-1 just for the MCC-3 execution decision [21:16:58] in the real RTCC they would be running some sort of calculation nonstop anyway [21:18:20] pericynthion altitude right now is 60.5NM [21:18:23] that is quite good [21:18:28] only executed MCC-1 [21:24:38] Was this the same for 11? [21:24:54] the criteria? [21:25:57] it's even less concrete for 11 [21:26:07] MCC-2 and 4 are preferred execution points [21:26:28] "if cost is not prohibitive" "when feasible", thanks, so precise [21:26:42] Haha I guess they really wanted little reason for an abort [21:26:58] With 10 a landing was not happening giving mission wiggle room I suppose [21:27:20] Ok PR is up [21:27:27] I also have the lunar battery commented out [21:27:48] looks good [21:28:00] yeah, I had done that in my local copy, but hadn't commited it yet [21:28:15] Also the two power issues I have on git should be resolved [21:28:27] And I was just handed a grocery list...so I must be off [21:28:53] If I dont see you have a good night! [21:31:20] yeah, good night! [21:37:23] 60.5NM pericynthion, 63.8NM the node. Definitiely a scrub for MCC-3 [21:41:51] the short burn logic being in the erasable memory from Apollo 10 on really helps with precise MCCs [21:44:30] anyway, good night [23:01:37] .tell indy91 so one thing we forgot with staging is to tell the LM it doesn't have a landing radar, its heater and temperature gauge seem to still work after staging? [14:07:18] morning [14:09:01] hey [14:09:57] working on all the pre-LOI Maneuver PADs and uplink for the Apollo 10 MCC right now [14:10:04] uplinks* [14:12:07] awesome [14:20:51] hmm, were the abbreviated Maneuver PADs they used from Apollo 10 on a separate form? [14:20:52] Looks like most LM EPS issues are solved, even the Ascent battery activation... [14:21:03] or did they just not fill in most of the data [14:21:37] hmm, good question [14:23:14] probably the whole thing [14:23:50] should I only display the partial one with the MCC? [14:24:20] for LOI? [14:24:20] it's not 100% consistent what they read up with the abbreviated ones [14:25:04] where are the abbreviated ones found anyway? [14:26:03] you mean when they were used? [14:26:31] most abort PADs (PC+2, TEI etc) are the abbreviated version [14:27:07] preliminary LOI PAD says TIG is 12 seconds earlier than the historical LOI TIG. not bad [14:29:04] like where are the pad forms found? (abbreviated) [14:29:06] nice! [14:29:45] or do they use the same form for the abbreviated versions? [14:30:44] that was my question [14:30:55] but I think they used the same form [14:30:58] oh haha [14:31:08] let me get more coffee [14:31:24] the CSM Updates book will have them [14:32:03] this one [14:32:04] https://historical.ha.com/itm/transportation/space-exploration/apollo-10-flown-csm-updates-checklist-directly-from-the-personal-collection-of-mission-command-module-pilot-john-y/a/6037-41079.s [14:35:26] uh, oh [14:35:39] I broke something with the thruster parameter change [14:36:50] bummer [14:38:02] luckily a quick fix [14:39:35] but my REFSMMAT is also wrong [14:39:45] always lots of things to fix along the way with the MCC [14:42:55] thruster parameter change for not reading the default thruster? [14:42:55] Good morning [14:42:59] hey [14:43:30] hey Ryan [14:43:45] AlexB_88, yeah, when I did that change, but the issue was just a small typo [14:44:18] it would always use the DPS parameters for LOI-1 right now [14:44:49] haha [14:44:58] so the TIG isn't right either [14:45:46] when I get to the preliminary LOI-1 calculation again I'll push my current state [14:46:03] rcflyinghokie, I found another checklist issue [14:46:38] Apollo 10, Flightplan, line 173 [14:46:40] Fire away [14:46:44] time is 19800 there [14:46:48] should probably be 198000? [14:47:05] Good catch [14:47:28] haha, easy catch, 19800 is 5:30h GET. Slightly out of place at 55h GET. [14:47:35] 55h would be 198000 [14:48:01] Yep :) [14:48:05] Appreciate it [14:48:16] I'll let you know when I found more [14:48:38] one thing you might have to check is the PROs in V49 [14:48:46] sometimes it's just one PRO, not two [14:48:57] but I can't really tell you specific occurances [14:50:08] Sure [14:50:46] That area in the Apollo 10 checklist is slightly incorrect anyways actually haha a few copy paste errors from what i can see so i will fix those as well [14:51:18] what I had to implement new for the MCC that I found in your checklist is uplinks even when a maneuver was scrubbed [14:51:37] they definitiely did those state vector updates at the times when MCC-3 and 4 were supposed to happen [14:51:40] but were scrubbed [14:52:12] Ah yeah [14:54:55] I only had to do MCC-1 [14:55:07] pericynthion state is basically perfect [14:57:19] I also didn't have to chase residuals, that helped [14:57:35] Nice [15:02:11] these abbreviated Maneuver PADs are so abbreviated that they don't even have the reentry data [15:02:16] PC+2 and the TEI PADs [15:02:31] but they will all be targeting 165°W, I am sure [15:03:00] oh, another thing missing in the checklist [15:03:05] at about 71:15 [15:03:18] copy preliminary LOI-1 PAD, TEI-1 and TEI-4 PADs [15:09:40] Ok [15:12:41] Added [15:12:44] great [15:12:52] LOI-1 calculation is indeed fixed [15:13:20] good HA and HP and the REFSMMAT is also right, 1° within each PYR angle [15:13:29] compared to the historical LOI-1 Maneuver PAD [15:13:44] that is with the new method of calculating the LS REFSMMAT before LOI-1 [15:13:59] using the approach azimuth as a parameter [15:14:14] Awesome :) [15:14:34] make the calculation a bit easier [15:14:36] great [15:14:43] Oh I think I fixed Alex's FC rad temp low on Apollo 17 [15:14:48] in RTCC MFD, too? [15:17:11] yes [15:20:01] And now I am going to look into this landing radar [15:21:33] I guess that would mean that the "MCC" options on LS REFFSMAT page, and the "LS during TLC" REFSMMAT page will no longer be needed [15:22:08] The "LS during TLC" option is still different [15:22:16] it's using the planned approach azimuth [15:22:28] while the normal LS method uses the actual orbit of the CSM [15:23:21] rcflyinghokie, LR doesn't do any timesteps without the descent stage [15:23:28] so it's just the handling of heaters etc. [15:23:58] Right [15:24:13] CSM uses a bunch of WireTo(NULL) for this [15:24:39] so you just have to add a bunch of things to CheckDescentStageSystems() [15:24:44] I would also need the heater display to, I assume, not get any signal [15:24:53] yes [15:25:04] probably has to be done in the specific switch code [15:25:35] rcflyinghokie, thanks for getting the ascent battery activation working right! [15:26:08] Well I had it almost there, just one line too high, so thank Nik [15:27:06] you learned something about C++ at least :D [15:27:31] I did indeed [15:27:58] I guess the LM EPS is in a pretty good state now [15:28:18] Well I am sure it still needs a fine tooth comb [15:28:25] But procedurally it is working [15:28:44] Including the CSM/LM power transfer [15:29:12] The XLUNAR bus code they had in there messed a lot up [15:29:12] yeah [15:29:28] Now everything appears to work right [15:29:39] I noticed one weird thing, but it didn't happen again [15:29:52] the voltage on the meter in the LM was pegged under CSM power [15:30:06] reloaded the scenario and it was the expected 28.8V [15:30:19] that wasn't even just after the LM was created [15:30:30] just he first time I loaded a scenario with the EPS changes [15:30:32] the* [15:32:11] oh and I noticed something the other day... Our Saturn.dll is just a bit over 160 MB now [15:32:46] the weird thing is, last October, it was only maybe 90 MB [15:33:13] but I cant seem to understand what we added to it the made it grow so much [15:33:28] indy91 I never noticed that mine looked fine [15:35:06] AlexB_88, must be on your end, the Github releases haven't increased that much [15:35:17] 174MB right now total [15:35:24] vs. 154MB or so for the 7.0 release [15:35:31] probably your mesh and texture work mainly [15:35:53] hmm [15:35:55] although [15:36:03] hmm, but I committed most of that [15:36:09] my Saturn IB and V dlls are both about 118MB [15:36:21] AlexB_88, no, I meant the 20MB increase [15:36:30] from release to current alpha [15:36:37] ah right [15:36:38] might just be a Visual Studio thing [15:36:46] we are manually building the modules a lot [15:36:58] in my copy, they are 160 MB [15:37:04] which is very odd [15:37:31] there is a cleanup option [15:37:37] with the build/rebuild options [15:37:43] I run clean often [15:37:47] let's see if that changes the size of them [15:37:51] what does it do? [15:38:31] Just removes previously built code [15:38:40] ok, trying that] [15:38:58] I've not been getting great performance lately [15:39:02] maybe that even helps with that [15:39:25] yep. me neither [15:40:37] same dll sizes as before [15:41:12] I'll check their size in the alpha release [15:41:25] but it could just be all that Saturn code I added since 7.0 [15:44:51] the Github modules are about the same size as my local ones [15:45:17] interestingly, the packed zip versions are muuuuch smaller than the actual file sizes [15:45:59] 122MB vs 15MB packed [15:48:09] and your local saturn5.dll is how big? [15:48:48] 119MB [15:49:04] interesting [15:49:21] did you locally change the project settings for debugging? [15:49:40] hmm its in release mode [15:50:45] MCC update pushed [15:51:07] oh its my UHD panel changes I think [15:51:27] I have modified CSM panels to fit my UHD screen, in my copy [15:53:43] ah [15:53:47] yeah, that could be [15:53:52] bitmaps are in the modules I think [15:56:18] Haha if I do a CM/SM sep attached to the SIVB the umbilical does not unclamp [15:56:51] And the optics covers are gone [15:57:50] yeah, I think the optics cover is never on with the CM [15:57:54] that probably could be fixed [15:58:04] umbilical is weird [15:59:43] the umbilical is easy to explain... the new Sat5Abort3 SIVB+SM model is created, with the SM with the umbilical in the clamped position, its just the 3d model thats like that [16:00:01] I can probably easily make it unclamped in that model [16:00:53] should probably always be unclamped [16:01:01] yeah [16:01:12] is that a separate mesh entirely? [16:01:15] or just the umbilical [16:01:24] its just part of the SM model [16:02:13] ok [16:02:22] Ok back to the LR, how do I get a pointer in checkdescentstagesystems() there to wire the boiler to null [16:03:02] Ah I think i got it [16:03:25] Boiler *lrheater = (Boiler *)Panelsdk.GetPointerByString("ELECTRIC:LEM-LR-Antenna-Heater"); [16:03:26] lrheater->WireTo(NULL); [16:04:45] Now how do I tell it to send no signal to the heater display [16:08:02] example from the CSM [16:08:07] fuel cell indications [16:08:14] the display class calls GetFuelCellStatus() [16:08:29] and GetFuelCellStatus() returns 0 for everything if the stages is CM [16:08:31] stage* [16:09:55] Would i do that in checkdescentstagesystems or in the tempmonitorind [16:11:13] Or even a condition in GetAntennaTemp() [16:12:40] a condition in GetAntennaTemp might be the best [16:13:10] so directly at the source of the temp data [16:13:23] Thats what I was thinking [16:13:23] is that a reading going through the SCEA? [16:13:28] Not sure [16:13:50] Doesn't appear to be [16:14:00] not in our code at least [16:14:06] but it's not complete yet [16:14:10] Looks like the temp monitors all get them direct right now [16:14:45] the SCEA would be calling the GetAntennaTemp() function, so for that the stage condition would have to be there anyway [16:15:00] Now how do i check for staging here [16:15:46] stage < 2 [16:15:54] or lem->stage [16:16:45] it's going through the SCEA actually [16:16:51] just haven't implemented that yet [16:17:15] So what should I return if staged? [16:17:22] I want the equivilant of no signal [16:17:39] NULL? [16:18:16] 0K maybe [16:18:24] if (lem->stage < 2) { [16:18:25] return NULL; [16:18:25] } [16:18:26] else { [16:18:26] return KelvinToFahrenheit(antenna->GetTemp()); [16:18:27] } [16:18:27] } [16:18:40] no, NULL is bad there [16:18:46] Ok [16:19:01] that would be 0°F and using NULL in place of a number works, but isn't good [16:19:01] I'll just use 0 then [16:19:15] return KelvinToFahrenheit(0); [16:19:37] But I dont want 0F [16:19:54] Kelvin to Fahrenheit [16:20:00] converts Kelvin to Fahrenheit [16:20:04] so input is K [16:20:17] Oh i see [16:20:23] the function itself returns Fahrenheit [16:20:35] Right [16:20:38] I misread [16:20:55] I was thinking the other way for some reason [16:22:04] easy to get confused [16:22:18] I think we have a bunch of other instances where we need a stage condition [16:22:26] just looking at the stuff in the SCEA [16:22:33] Descent oxygen tank pressure [16:23:10] but some of those conditions should be a bit more universal [16:23:30] like, the whole DPSPropellant class shouldn't run with the descent stage gone [16:24:23] Yeah [16:24:33] Hmm it doesn't like my pointers it seems [16:24:56] Boiler *lrheater = (Boiler *)Panelsdk.GetPointerByString("ELECTRIC:LEM-LR-Antenna-Heater"); [16:24:57] *lrheater->SetPumpOff; [16:24:57] *lrheater->WireTo(NULL); [16:26:37] operand of * must be a pointer [16:26:38] what's the * for in the last two lines [16:26:56] you just need lrheater there [16:27:00] Oh oops [16:27:09] copy paste [16:27:10] copy pasted from the first line? [16:27:11] haha [16:27:40] Now I dont think I need the setpumpoff but its just in case [16:28:01] also SetPumpOff() [16:28:05] don't forget the () [16:28:09] Ah thanks [16:28:29] I need to start using those dropdowns more [16:28:32] for the removed heat exchangers in the SM the CSM code also sets the length to 0 [16:28:41] do we have any heat exchangers in the descent stage? [16:28:55] I don't thinks so only radiators [16:29:19] And actually, only this radiator [16:29:37] The LR [16:30:02] right [16:30:42] Think anything needs to be done to is? [16:30:44] it? [16:30:54] Ugh I can't wait to have my fingers back [16:31:23] Still too tender to leave unwrapped and use [16:32:26] no, the radiator will probably still do its normal timesteps, but it's not connected to anything useful [16:32:33] same setup as in the CSM [16:33:10] Ok [16:36:32] I also need to figure out why I get an o2 quantity light even on the ascent stage [16:42:11] same issue I would guess [16:42:39] the o2 tank is emptied on staging, right? [16:43:13] but I am sure that is also CWEA code related [16:44:06] Ah it isn't based on which is selected [16:47:24] Haha it checks descent oxygen after being staged [16:47:31] if(lem->stage < 2 && (lem->ecs.DescentOxyTankPressurePSI() < 135)){ LightStatus[1][7] = 1; } [16:47:44] I would imagine that is wrong [16:49:40] what is wrong about it? [16:49:49] if first checks the stage [16:50:10] and if the stage is 2, then it won't light the light [16:50:56] hmm [16:51:01] one of those checks there is wrong [16:51:10] Isnt light status 1 on? [16:51:30] yes [16:51:50] if it's the descent stage AND the pressure is low, then the light is on [16:52:00] but I think the line above is wrong [16:52:13] hmm [16:52:15] or maybe not [16:52:47] no real pointin working on the CWEA right now [16:52:50] Nah [16:52:59] And I read Stage < 2 as staged for some reason [16:53:14] stage 0 is unstaged, gear not deployed [16:53:18] stage 1 is gear deplyed [16:53:21] stage 2 is ascen stage [16:53:24] ascent* [16:53:38] Last line is wrong though I believe [16:53:57] should be ascent 2 not descent [16:54:59] if(lem->stage < 2 && (lem->ecs.AscentOxyTank1PressurePSI() < 99.6 || lem->ecs.AscentOxyTank2PressurePSI() < 99.6)){ LightStatus[1][7] = 1; } [16:54:59] if(lem->stage < 2 && (lem->ecs.DescentOxyTankPressurePSI() < 135)){ LightStatus[1][7] = 1; } [16:55:00] if(lem->ecs.AscentOxyTank1PressurePSI() < 99.6 || lem->ecs.AscentOxyTank2PressurePSI() < 99.6){ LightStatus[1][7] = 1; } [16:55:23] No reason to check the descent stage o2 when staged [16:55:52] yeah, those last two lines are weird [16:56:07] I changed it to the above code [16:57:02] Unless it needs a stage 2 [16:57:10] don't think so [16:57:21] but isn't the very first line now redundant? [16:57:28] I was just about to say that [16:57:35] It is [16:57:40] It should always check the ascent o2 [16:57:41] just look in the Systems Handbook for the right behavior [16:57:45] it has all the detail [16:57:46] Will do [17:00:06] Hmm weird [17:00:36] "des o2 press, asc 1 o2 press (< 684 PSIA), and asc 2 o2 press inputs are disabled at staging [17:01:10] Oh I understand [17:01:25] When unstaged, it has a different pressure switch for the ascent tanks [17:01:33] Basically would indicate a leak [17:01:43] right [17:01:59] When staged it only has a pressure switch for asc o2 1 [17:02:15] Doesn't look at the descent stage or ascent 2 [17:04:23] if(lem->stage < 2 && (lem->ecs.AscentOxyTank1PressurePSI() < 681.6 || lem->ecs.AscentOxyTank2PressurePSI() < 682.4)){ LightStatus[1][7] = 1; } [17:04:24] if(lem->stage < 2 && (lem->ecs.DescentOxyTankPressurePSI() < 135)){ LightStatus[1][7] = 1; } [17:04:25] if(lem->ecs.AscentOxyTank1PressurePSI() < 99.6){ LightStatus[1][7] = 1; } [17:04:37] That should be right based on the sys handbook [17:06:21] Why they have slightly different pressure switches I have no clue but that is per the logic in the handbook [17:09:33] did you change if from 99.6 to 680? [17:09:36] is that right? [17:10:30] Yes when unstaged [17:10:46] It basically gives the crew an alert if the tanks are leaking [17:10:57] And then once staged it comes on for a low quantity [17:11:31] LM 8 handbook pdf pg 113 [17:15:11] Hmm I am all of a sudden getting like 10 fps [17:15:37] On a fresh launch scn [17:15:44] Maybe its my computer [17:17:27] well, I am not having as much success getting the Saturn 1B abort stage to stay on the pad after a pre-launch abort, it just disappears... [17:19:03] Used the same method I did with the Saturn V, so don't understand what's the issue right now [17:22:27] there is some code deleting abandoned stages [17:22:49] have to check that [17:23:16] do you know where, exactly? [17:24:20] Saturn::KillDist in saturn.cpp [17:24:27] but it's called from elsewhere [17:24:42] actually [17:24:43] KillAlt [17:24:45] just below it [17:24:47] one of those [17:24:53] thanks [17:26:09] maybe I can put a check on it to not delete an aborted prelaunch stage [17:27:17] Saturn::DestroyStages [17:38:37] found it, there is another check for habort and it deletes abort vessels that fall below 100m [17:38:58] I'll add a check to that to avoid it on prelaunch stages [17:40:07] yeah, but it won't be a prelaunch stage anymore with the jettisoned CM, I would think [17:40:25] Not to dive into the SCERA much but the comment for the glycol temp seems to want the temp from the wrong place [17:40:34] //Water sublimator coolant outlet temperature (GF9998) [17:40:35] SA10.SetOutput(1, scale_data(lem->ecs.GetSelectedGlycolTempF(), 20.0, 120.0)); [17:40:52] The path is right but the comment is wrong it should be at the accumulator [17:41:02] At least thats where the temp sensor I see is [17:41:13] not sure if the accumulator tank existed when I implemented that [17:41:23] if you know how fix it, please do :) [17:41:32] Sure [17:42:17] the function calls oapiGetAltitude, but thats from the mean radius [17:42:57] The pointer is correct so just a wrong comment [17:44:09] what do you mean wrong comment [17:44:14] that is directly from the AOH [17:44:25] not my words [17:44:27] Really? [17:44:51] Well there is a temperature sent via telemetry I believe for the water boiler [17:45:04] But it is different from the glycol temp c/w [17:45:21] maybe we need two separate measurements then [17:46:17] Possibly let me look [17:46:32] "GF9998U GLY TEMP" in the Systems Handbook [17:47:17] Yeah that sensor is by the accumulator [17:47:45] Well the sensor that feeds it [17:47:50] doesn't have the U in the AOH, but that's where I took the name from [17:47:53] GF2681T [17:48:16] Goes to SC1 [17:48:22] Then GF9998U [17:48:25] which one is that? [17:48:38] First one is the sensor itself [17:48:42] ah, I see [17:50:25] So the water boiler has its own sensors [17:50:48] GF2531T and GF2581T [17:51:14] GF9998 is what is relevant for the Glycol caution light at least [17:51:19] Those are not displayable in the cabin [17:51:22] same SCERA output at least [17:51:22] Correct [17:51:35] Which is odd that the comment was from the AOH about the boiler [17:52:02] Just caught my eye, but it appears to be right otherwise [17:55:15] I see [18:02:42] morning! [18:04:21] hey [18:21:10] I also made some additions to the glycol C/W light nothing major just it will function properly now [18:21:25] The only thing the sensor doesn't read is quantity [18:22:01] But it will start the glycol light off and disable it if the switch is in SEC [18:22:08] And turn it on if the temp is above 50F [18:24:28] good [18:25:59] Do you have a glycol low level sensor in the scera? [18:28:12] I didn't see one I am just double checking [18:29:20] no, net yet [18:29:27] that would be SCERA2 [18:29:39] SA3 [18:29:43] channel 3 [18:30:04] and it's connected to both prim and sec glycol [18:32:01] Ok [18:32:12] I am making the functions to get the masses [18:34:26] alright, got the S1B pad abort working [18:35:06] rcflyinghokie, you can already add the measurement for the CWEA [18:35:18] I will [18:35:20] that SCERA subassembly type has two outputs [18:35:30] a voltage 0-5V and a sold state switch [18:35:40] the solid state switch already outputs to telemetry [18:35:47] so the CWEA must get the voltage [18:35:53] but that is basically like a switch as well [18:36:05] 0V is logic 0, 5V is logic 1 [18:36:14] so I have usually used "lem->scera2.GetVoltage(3, 3) > 2.5" [18:36:23] that would be for the right measurement [18:36:25] Looks like both LLS share the same output [18:36:26] just not added yet [18:37:32] Interesting that the glycol caution light is disabled in SEC, yet the LLS from the secondary loop goes to that light [18:37:46] I guess it will indicate a low level in either [18:37:52] actually, I spoke nonsense [18:37:56] While the switch is in pump 1 or 2 [18:38:02] that subassembly does not have the solid state switches [18:38:08] so you can only check the voltage [18:40:03] so just like a wrote above [18:40:15] I* [18:41:59] Ok [18:43:33] Let me check my current CWEA and make sure it's right then I will add the scera stuff [18:59:14] ah right, now I remember why I never implemented the map update for Apollo 8 [18:59:28] I never worked out the calculation for the hyberbolic trajectory [18:59:34] so LOS before LOI-1 [19:05:07] Hmm this LLS will be difficult since we dont have real accumulators [19:05:25] They arent very representative of the whole loop [19:06:04] I could just take the mass of the whole system [19:06:16] That would, in essence, be the same thing [19:08:11] Or I could make it read when the accumulator is 10% of its normal operating mass [19:08:17] indy91, to make the pad abort work, I lowered the altitude which the abort stages are deleted from 100m, down to 30m [19:09:23] that should be good for stages that are falling from the sky [19:09:42] and not delete the S-I standing straight up on the pad [19:10:21] exactly [19:11:55] I've tested it and it works well, if you abort just after launch, say 5m and upwards, the aborted stage will gall back and start tipping over and once it falls through 30m it gets deleted [19:12:25] but if you abort before that, it does not tip over, and stays upright on the pad [19:12:50] good enough [19:15:03] I had to reduce the stance of the touchdown points on both abort vehicles (S1B and SV) to make that work like I wanted [19:30:05] Ok glycol C/W works right, now what about this scera [19:30:53] what about it [19:32:42] Is it separate from the CWEA? [19:32:55] I mean is it connected to it [19:33:38] some outputs go from the SCEA to the CWEA, yes [19:34:03] Ok so i am adding the low level sensors [19:34:11] yes [19:34:19] SCERA-2, subassembly 3, channel 3 [19:34:23] I have the comments ready in SCERA2 SA3 [19:34:46] SA3.SetOutput(3, lem->ecs.GetGlycolLowLevel()); [19:34:48] basically [19:35:04] just below suit fan 1 failure [19:36:00] Now I need to make the functions for get low level [19:37:00] right [19:37:12] I guess that would be the mass of some tank [19:37:14] or all of them [19:38:13] I just did a simple 10% of the accumulator when it is running normally [19:38:30] Ideally the accumulator level would be representative of the total system mass [19:39:06] I could take the whole system mass though, it would be more accurate data wise but not sensor wise if that makes sense [19:42:06] Actually I will take the system mass for now and we can make it into an accumulator if we ever make a working one [19:49:00] ah right, the accumulator needed a variable volume or something like that [19:49:17] so basically a pressure dependant volume [19:51:45] Yeah [19:52:05] I just made the quantity functions return the total system mass [19:52:15] We can make one for the accumulator if we get one working [19:52:37] But this will work just fine for now [19:53:43] yeah [19:55:37] Hmm I cannot add pointers [19:55:45] I have to make a variable name for each tank? [19:56:11] indy91, PR sent [19:57:17] Oh parenthesis issue [20:01:10] Or not [20:01:57] I cannot add two pointer values according to VS [20:04:54] Guess naming each one it is haha [20:12:53] rcflyinghokie, not sure what you tried to do [20:13:17] Secondary_Glycol_Mass = (((double*)sdk.GetPointerByString("HYDRAULIC:SECGLYCOLACCUMULATOR:MASS")) + ((double*)sdk.GetPointerByString("HYDRAULIC:SECGLYCOLPUMPFANMANIFOLD:MASS")) [20:13:19] etc [20:13:34] ouch [20:13:37] hmm [20:13:51] I am giving each one a name [20:13:54] well, you are indeed trying to add two double pointers [20:14:00] instead of two doubles [20:14:01] So I can just add those [20:14:29] you can dereference them [20:14:40] hmm [20:14:47] *(double*) [20:14:49] like that [20:14:55] Is that safe? [20:15:15] safe enough [20:15:25] Ok [20:15:36] Dam I already made all my doubles too [20:15:59] But dereferencing takes a lot less code [20:17:29] Now my equals sign is red [20:17:40] value of double cannot be assigned to entity double [20:17:45] of course the code would be much cleaner if you make a line for each mass [20:18:07] Thats what i was in the middle of actually [20:18:35] I have 2 in each line [20:21:33] Ok no errors [20:22:44] But it gives me a nullptr [20:26:17] https://www.dropbox.com/s/we798s0mcsrfq9o/Screenshot%202018-03-07%2015.26.00.png?dl=0 [20:26:56] I took off the * on Primary_Glycol_Mass = to get rid of the error on the = but that results in a nullptr [20:27:42] I can't read this code properly. Just do it mass by mass and add it in the end [20:28:52] Ok [20:29:10] I still see the red equals sign [20:29:19] but it properly built? [20:30:03] If I make that a pointer [20:30:15] I think the parentheses aren't right [20:30:27] adding pointers isn't really helpful :D [20:30:41] then you just add the addresses of the masses, not the masses [20:30:50] I am going to do each to its own and add them in the end [20:30:59] yeah [20:31:24] No problem I was almost done with it anyways [20:31:48] we aren't coding AGC assembly, I think we can afford to add more lines than necessary for better code readibility, haha [20:34:29] No problem [20:34:44] Now, what is the if statement in those functions actually doing? [20:35:00] if (!Secondary_Glycol_Mass) { etc [20:35:44] the pointers are persistent, in the LEM_ECS class [20:36:24] So i need one for each pointer [20:36:25] so, only during the first call of the function will the pointer be assigned to whatever it is pointint to [20:36:39] !Secondary_Glycol_Mass is basically the same as [20:36:47] Secondary_Glycol_Mass != NULL [20:37:00] so it just checks if the pointer was already assigned to the e.g. glycol mass [20:37:21] Ok [20:37:22] so on subsequent calls of the function all it has to do is dereference the pointer and return the actual mass [20:37:44] that means GetPointerByString is only called once in that function [20:37:52] just a bit more efficient [20:37:55] Makes sense [20:38:02] I shouldnt have an issue with this now [20:38:19] You might wake up to a full PR though [20:38:42] sure [20:39:15] For the SCERA: [20:39:16] //Primary Glycol LLS (GF2041X) [20:39:16] SA3.SetOutput(3, lem->ecs.GetPrimGlycolLowLevel()); [20:39:17] //Secondary Glycol LLS (GF2042X) [20:39:17] SA3.SetOutput(3, lem->ecs.GetSecGlycolLowLevel()); [20:39:29] And those return true based on the low level conditions [20:40:03] no, that isn't right [20:40:21] you just overwrite the channel with the sec glycol low level [20:40:31] but the input is actually prim low level OR sec low level [20:40:53] SA3.SetOutput(3, lem->ecs.GetPrimGlycolLowLevel() || lem->ecs.GetSecGlycolLowLevel()); [20:41:01] and just once of course [20:41:17] Ok, and the comment will contain both 2041 and 2042 I guess [20:41:25] yeah [20:41:52] Ok [20:41:59] Makes sense [20:43:18] Time to take my dog out and then come back and do these one by one haha [20:47:20] aborting from the pad, and viewing from ground observer mode is quite awesome [20:50:33] haha, yeah [20:50:56] implementing the pad abort tests would be fun [21:15:05] map update for the hyberbolic trajectory works [21:15:18] so LOS time should be accurate [21:15:21] I'll see :D [21:17:06] yep, looks good at least. All times are 4 minutes later than the historical update on Apollo 10 [21:17:15] just like LOI is 4 minutes later [21:18:37] night [22:41:01] Ugh this has been a pain to add up all the glycol masses [22:47:28] But I think I have the glycol and heater and o2 quantity c/w working properly [22:53:22] nice! [22:58:45] Thats 3 less persistent lights [23:01:02] :D [23:31:10] .tell indy91 One thing to look at with the LM is I can no longer deadface the des bats using the switch [23:33:14] Thats a big PR haha [23:33:35] Well big from my normal additions [23:34:17] Time to make dinner [23:37:45] So I guess the CWEA will be shaping up now [00:53:48] Yeah there is a lot to do for it still though [00:54:16] But the logic is starting to shape up, you can fly a mission with the entire right CW panel extinguished haha [01:03:59] hehe about time we took down the Christmas tree [01:04:06] or half of it [01:18:15] night! [12:51:35] hey [12:51:49] hey Niklas [12:52:05] MCC has guided Apollo 10 into lunar orbit [12:52:12] haha you seem to be getting lots of those [12:52:25] yes [12:53:16] I thought about the schedule in lunar orbit. We already have a revolution counter, which gets incremented at 180° longitude [12:53:45] so the way I will time MCC updates in lunar orbit is revolution number plus a time into the current rev [12:54:13] sounds reasonable [12:54:27] when things are getting closer to DOI and PDI then a lot of timing will be relative to those [12:55:07] but until then scheduling updates per revolution should give the most accurate results [12:59:21] it was interesting how early Apollo 10 entered the shadow of the Moon before LOI-1 [12:59:45] like 3 hours before LOI-1, at quite the distance to the Moon still [13:00:07] and I guess LOI-1 itself was in daylight [13:00:42] oh yes [13:00:53] already for an hour in daylight again at LOI-1 [13:03:44] next up LOI-2 and TEI-5 PADs [13:04:13] and the next new MCC feature will be landmark tracking PADs [13:04:26] the RTCC MFD of course already has that, mostly [13:07:05] and LOS on time [13:07:12] map update works very well [13:07:34] the LOS time is calculated with the center of the Earth [13:07:49] but the MCC displays LOS times for specific tracking stations [13:08:02] so the LOS time was right in between LOS Goldstone and LOS Madrid :D [13:32:12] the addforce at launch is only initiated from LVDC.cpp, correct? [13:33:29] I am trying to figure out why it affects the CM when aborting during the period it is active. When the CM aborts, isn't the LVDC immediately deleted? [14:27:32] hello friends~ [14:27:48] despite my best efforts, I am still alive [14:27:52] how goes things? [14:28:22] and did whoever it was that wanted something to do with the wiki ever get sorted out or are they still waiting on me to do something? [14:29:47] hey [14:30:00] good to see you alive [14:30:35] I'm not sure about the wiki [14:30:38] Thymo would know [14:31:01] I only vaguely remember having supposed to be doing something [14:31:20] I have been following the change traffic and builds though [14:31:23] yeah, I think there is a problem with new users [14:31:32] for the wiki [14:31:36] I figured as long as things kept moving along everything was okay [14:31:58] Oh right, I remember this now [14:32:08] yeah, I think there is some good progress with development [14:32:10] Sourceforge turned off email from webspace, so it can’t email anyone anymore [14:32:45] because we are talking here so much and there are new commits basically every day, BuildBot is doing a lot of lonely talking on the forum [14:33:23] I’m honestly surprised the forum is still there and working. [14:33:32] I approved someone a couple days ago [14:33:33] it's barely working, haha [14:33:48] They had been waiting since September or something stupid like that [14:33:50] it's not working properly quite often [14:34:11] I thought we were going to get a subforum on orbiter-forums at one point [14:34:13] sounds like my experience with getting approved on the forum [14:34:37] yeah, I think that is still the idea, especially lately with the forum being so unreliable [14:34:54] we've just been waiting for the moment where it gets even worse [14:35:03] I’d just have to wrangle buildbot into being able to post there [14:35:12] It basically exploits a bug in SMF to be able to post [14:35:19] haha, awesome [14:35:37] for BuildBot, it's posting a bit too much I feel [14:35:48] maybe daily builds would be better [14:36:13] some days there are a lot of commits, and then sometimes no commits for a few days [14:36:17] Yeah, there’s actually a limit to how many builds in a day it can do [14:36:21] I forget what it is though [14:36:31] 10 or something like that [14:40:12] some days we are getting close to that. But right now, on those days, the BuildBot forum posts get a bit too much I feel. And if we move to the Orbiter Forum I am not sure they would like one post for every commit either. [14:41:36] did you hear anything new from MIT? Swatch hasn't been here in a while, so I figured there was no news about that. [14:42:30] No, nothing [14:43:05] Last update I got about anything was the supposed copy of LVDC software at the rocket center didn’t exist [14:43:15] It turned out to be FCC stuff [14:43:18] yeah, that was disappointing [14:43:57] at least I've been implementing a bunch of new LVDC++ features [14:44:06] it can do slingshot maneuvers now [14:44:33] I saw there’s been a bunch of LM stuff [14:44:42] Kinda annoyed I missed the party on that :< [14:45:02] yeah, especially rcflyinghokie is spending a lot of time on the LM ECS [14:45:18] Has there been any progress in exorcizing all the old staging mess? [14:45:27] (however that’s spelled) [14:46:30] LM staging? [14:46:33] or in general [14:46:37] In general [14:46:51] I've done some experiments with docked stages [14:47:06] got a docked S-IB and S-IVB into orbit [14:47:15] there are a bunch of issues to work out with that [14:47:16] We were supposed to be able to do proper staging in the new Orbiter, instead of the whole mesh translating and subclassing mess [14:47:21] yeah [14:47:27] I think it works, in general [14:47:50] I don’t remember if it was via attachments or docking but it was supposed to suck less [14:47:51] adds a few new complexities, but removes waaaaay more of the old ones [14:47:59] the only thing I was unclear on was interstage communication [14:48:23] main change in Orbiter2016 that is relevant for this was that it allows docked vessels while landed [14:48:24] if there was going to be a provided method or if we’d have to roll our own [14:49:35] I think I mostly did it on my own, in my tests [14:49:51] just used the Orbiter API function to access the docked vessel [14:50:02] and then just a check on the vessel type etc. [14:50:41] anyway, a whole lot of changes will be necessary for reworking our stages, so my idea was to postpone that until the next major release [14:50:49] 8.0 for the LM as the new big feature [14:51:00] and 9.0 can be the new staging and support for a few more missions [14:51:52] I assume the landing has happened by now? [14:52:22] oh, we've been doing lunar landings with the Virtual AGC for a while now [14:53:29] Nice [14:54:18] I've tested all the landing missions, and they all work quite well [14:55:05] I figured it was just a matter of time once MCC was able to feed it the targets and such [14:55:26] Did it end up even needing the variable CG stuff? [14:55:57] I am working on the MCC for Apollo 10 right now, but the lunar landing calculations can already be done with the RTCC MFD [14:56:03] just have to be done manually [14:56:08] We also now have LVDC presettings for all the missions thanks to Niklas's recent work [14:56:42] about the variable CG, Orbiter actually calculated the moments of inertia of docked vehicles wrong [14:57:07] I got Dr. Schweiger to fix that and that made docked DPS burns controlled from the LM possible [14:57:32] so, at least to be able to control the vessels docked or undocked, we don't need variable CoG [14:57:39] Oh, was that the thing that required use of the beta orbiter or whatever it was? [14:57:43] yep [14:57:57] current NASSP alpha releases need the latest Orbiter Beta versions for that [14:58:24] when we implement docked stages, I would also like docked ascent and descent stages for the LM [14:58:37] that will solve 99% of the control issues that the DAP is having [14:58:55] mostly at PDI ignition [14:59:03] needs a bunch of RCS to keep steady [14:59:24] because with full propellant the CoG of the LM is in a very different location than with empty tanks [15:00:16] docked ascent and descent stages would basically be a two point mass approximation of the CoG [15:00:26] and that is sufficient [15:00:36] but even right now, there are no big controllability issues [15:03:38] Oh, that was what the variable CG stuff in the LM was supposed to solve [15:04:26] yeah. I thought that would also be necessary to solve docked DPS burns [15:04:28] The last thing I did was to add a callback that allowed the LM to change its CG depending on how much propellant it had, but someone had to write the code that actually determined what the CG was supposed to be and set it accordingly [15:04:32] but that was mainly an Orbiter issue [15:05:07] for now we don't need variable CoG, but variable moments of inertia would still be good [15:05:18] I had done some tests with that [15:05:43] Well, the function just gets called if the mass changes by a fixed amount, so you should be able to use it for anything that requires a change over mass. [15:05:49] yeah [15:05:54] Orbiter uses the mass normalized PMI, but that is a bit off for empty or full propellant in the CSM [15:06:37] the CSM close to the end of the Apollo 7 mission for example isn't controlled super good by the DAP [15:07:05] that can be improved with the variable PMI [15:07:20] but CoG is not necessary for now, I think [15:07:25] variable CoG* [15:07:34] Eh, just copy the stuff from the LM into the CSM and have it change the PMI instead then [15:12:53] yeah [15:12:56] that is no problem [15:13:17] and as I said, just to make the DAP control it a little better [15:14:06] it was Orbiters fault all along that we even would have needed that [15:16:44] Good morning [15:17:24] hey Ryan [15:18:20] What's up [15:18:49] we have a rare visitor looking how things are going [15:19:23] Oh? [15:19:27] Appveyor doesn’t have an easy way to build once a day on changes, it either builds every day at a set time or on a push [15:19:34] that or I missed it [15:20:22] And that means it’d be building 7.0 once a day and such [15:21:02] hmm, not really a better solution [15:21:29] can you exlude pull requests from the auto builds? [15:22:13] if I merge them then they create a new auto build anyway [15:22:23] so not really necessary to have two builds for that [15:23:39] Oh, it shouldn’t be doing them on pull, just push [15:24:59] That’s github’s doing [15:25:01] hang on [15:25:26] OK, that should be fixed [15:25:28] indy91. I may have found a bug in the orbital guidance of the IU. If in EPO during timebase 5, you switch to CMC and fly the SIVB using the RHC for a bit, then switch back to IU, sometimes the SIVB will yaw all the way to 60 degrees yaw, then come back to 0 yaw for some reason [15:25:30] great [15:25:38] It should trigger a build only on push [15:26:03] that should already cut down on a lot of unneeded auto builds and forum posts [15:26:31] I probably forgot to uncheck pull when I set up CI [15:26:35] AlexB_89, interesting, will have to try that myself [15:26:52] Hmm I am getting a debug line on the laptop build when I create the LM, DX8JS: No joysticks found [15:27:24] that is from the function I added to the LM creation, to make the EPS work correctly [15:27:26] That’s another thing that surprises me, that the joystick stuff still works [15:27:49] lvlog? [15:28:08] I haven't touched that part of the joystick code at least. I would have no idea what I am doing anyway [15:28:15] AlexB_89, I'll test it myself [15:28:34] my Apollo 10 scenarios are quite recent [15:28:40] It’s not that hard, but I expected microsoft to have done away with DX8 by now [15:29:12] and Orbiter hasn't done away with DX9 yet, haha [15:29:21] well [15:29:22] Basically, you ask for a list of what devices are present, it gives that to you, and the axes are just a number from 0-64K [15:29:31] the inline graphics client is still DX7 actually [15:29:41] but the only external client under active development is DX9 [15:30:07] you scale those to something appropriate for your purpose and then use it or stuff it in the AGC [15:30:12] right [15:30:27] I've done a bunch with the processed axis data in the LM [15:30:36] The only annoying part is there’s very little standardization for which axis is what outside of the X and Y [15:30:39] separate ACA and TTCA classes, because those are a bit special [15:30:55] Z is a throttle sometimes, a rudder sometimes, something else entirely other times, etc [15:30:59] right [15:31:12] and it might be 0-64K or 64K-0 [15:31:13] there is a bit of code trying to deal with that [15:31:22] which I again haven't messed with [15:31:22] Yeah, someone put it in the configurator [15:31:27] You used to have to edit text files [15:31:32] ouch [15:31:41] I wrote it before the configurator was a thing [15:31:52] That was one of the first things I did [15:32:00] because I wanted separate translate/rotate joysticks [15:32:04] because I am a huge nerd [15:32:25] Join the club :) [15:32:27] That and someone told me it was impossible to do because orbiter didn’t support it [15:32:37] I mean, there even is a procedure using two RHCs in the CSM! [15:32:44] so totally relevant to be able to do that [15:32:55] Really? What requires that? [15:33:10] CM RCS translational burn [15:33:27] for a hybrid deorbit, partially done with the SM RCS, rest with the CM RCS [15:33:55] I don’t think it supports multiple joysticks of the same time, unless someone added that [15:34:01] *same type [15:34:35] hmm, right, not sure. Maybe joystick + numpad. But I haven't really tried it myself [15:34:49] I think all you really do is command pitch and down at the same time [15:34:50] It wouldn’t be all that hard to add it though [15:35:05] which would be possible with the numpad [15:35:12] Wait, do you mean using the RHC and THC at the same time? [15:35:12] pitch up and down* [15:35:21] no, the two RHCs in the CSM [15:35:38] OK [15:35:42] the CM RCS doesn't really support translational burns [15:35:43] I was gonna say... [15:35:59] so you have to command pitch up and down at the same time to get a translation effect [15:36:04] Anyway, making it work wouldn’t be all that hard, since it’s just lighting discretes in the CM [15:36:21] You’d just have to make sure that one joystick doesn’t clobber the other [15:36:37] should also work with the SCS [15:37:16] IIRC the only assumption I made in joystick stuff in the CM (and LM) is that joystick travel is linear. [15:37:40] (So if you have/make a joystick that has the same physical throws as the original THC/RHC, things happen at the right angles) [15:39:31] indy91, at 1st it was hard for me to re-create the issue, but I think I found what caused it: If you are in saturn takeover mode, and yaw right with the RHC (yaw towards 355 degrees and less) then switch back to IU, it then yaws left back though 0 degrees all the way left to about 45-50, then does weird stuff and slowly come back to 0. It does not happen if I stay near 0 in the 1st place and don't yaw right. [15:45:31] Hmm so why do I get that debug line on the laptop and not the desktop I wonder [15:47:58] Does your laptop have a joystick? [15:48:10] No [15:48:28] In the orbiter configurator, nassp section, turn off the stuff about joysticks [15:48:47] The configurator says you have one but since you don’t, the code can’t find it [15:48:58] It is all disabled [15:49:02] Thats why i am confused [15:49:31] In that case, the text file that the configurator makes got out of sync with what you actually have [15:49:50] Ah that could make sense as I copied the install over to it [15:52:23] I forget its name, I can look it up, but it should be obvious [15:52:30] It will be in the orbiter directory [15:52:52] Yeah I have it [15:53:03] Just deleted it to let orbiter make a new one [15:54:31] Awesomesauce [15:54:51] it's certainly caused by the function LEM::PostLoadSetup() [15:55:01] Yeah I found the line itself [15:55:04] that wasn't called during LM creation previously [15:56:56] Well damn I am getting a CTD on LM creation now [15:57:08] Its in my mass code [15:58:10] access violation reading a location upon LM creation [15:58:26] can cofirm [15:58:52] Secondary_Glycol_Accu [15:59:00] you didn't null that in the init [15:59:08] it's just "Secondary_Glycol_Accu;" [15:59:10] Yep I just found that [15:59:13] instead of Secondary_Glycol_Accu = 0; [15:59:16] that should do it [15:59:48] sounds like a good opportunity for an auto build test. :D [16:00:05] Hey I learned VS well enough to find that issue quickly :) [16:00:16] very well done [16:00:25] it shouldn't do an auto build for PRs now [16:00:33] just when I merge it [16:00:39] Oh good that got a bit out of control [16:00:54] Especially with my previously daily checklist PR's :P [16:00:55] especially when you added commits [16:01:04] to your PR [16:01:07] Ah yeah [16:01:10] Yeah, I forgot to uncheck that when I set up CI [16:01:12] My bad [16:01:12] and suddenly it had to build 3+ times [16:01:24] I honestly didn't know those added to the PR until we were on the ECS branch [16:01:42] I am not sure I like that. [16:01:49] maybe a git or github setting? [16:01:52] Might be a git setting to change it? [16:02:35] better to have at last one active step to add commits to a PR [16:02:38] least* [16:03:23] True [16:03:43] I have been more observant about that when making commits during an active PR [16:05:04] Ok ready for a test? [16:06:11] always [16:06:36] and BuildBot as well [16:06:41] PR up [16:06:41] It’s a github setting [16:06:46] ah [16:06:53] I changed it earlier [16:07:10] yep, it didn't try to do a build [16:07:17] Github sends a trigger to appveyor, appveyor does the build, and the completion of the build sends a trigger to cirno [16:07:26] merged [16:07:32] And it didnt try to build [16:07:34] Awesome [16:07:35] buildbot is just a php script on cirno that gets the trigger from appveyor and makes a forum post [16:07:41] right [16:07:45] The trigger now fires only on push [16:08:20] and it's building the merged pull request now [16:08:24] so all working as intended [16:09:04] Great [16:09:08] Well, wait [16:09:19] Did you want it to build on the merge commit? [16:09:47] Doesn't it need to in order for a file to be created for download? [16:10:09] The merge commit counts as a push, so that started a build (it’s ongoing now) [16:10:24] yeah, that's how I wanted it. [16:10:27] OK [16:10:38] It’s still cloning git [16:10:57] I just didn't want it to do 2 basically identical builds [16:11:06] with the only difference being the merge commit [16:11:09] Right [16:11:14] I just wanted to make sure [16:11:25] sure [16:11:45] I haven’t been paying attention to the actual hang time on these [16:13:00] clone just finished [16:13:07] Here’s the actual build [16:13:16] about 5 minutes just for the clone [16:13:41] So much cleaner than when we started [16:15:01] since switching to Visual Studio 2017 the builds itself take longer than before I have noticed [16:19:20] Still going [16:19:51] At least it’s not spewing a ton of warnings like it used to [16:22:17] nah, those have all been fixed [16:22:29] some time before the 7.0 release I think [16:22:50] Build is done, it’s packaging now [16:23:22] Uploading to github [16:23:53] All done [16:23:57] 15 minutes 58 seconds [16:23:59] Not too bad [16:24:04] (60 minutes is the limit) [16:24:33] Ah its nice to have a laptop than can run orbiter :) [16:24:38] And maxed out on graphics [16:25:04] haha nice [16:25:28] And I will be adding an M.2 SSD today when it arrives [16:26:02] Hmm so what damage can I do to NASSP today [16:30:20] How far along is the LM now? [16:30:27] I understand the ECS exists [16:31:42] yeah, the ECS is already quite advanced. [16:31:53] and the interface between CSM and LM work [16:32:05] so you can pressurize the LM from the CSM [16:32:47] mostly detail work with the ECS now, I would say. But there are lots of details to consider. [16:32:59] the system that needs the most work right now is probably the CWEA [16:33:40] Yeah [16:33:49] and there are a lot of small construction sites all over the LM [16:34:38] I also get a large temperature increase in the LM cabin/suits during time accel [16:35:09] must be a side effect of time dilation :D [16:38:38] Haha [16:40:49] I am just testing another TLC with it, but it also happened in LPO just using 30x [16:44:34] yes, I notice that too, 10x is fine, but 30x gives weird behavior [16:44:56] but then up to 50x and it was fine again?? [16:46:27] I still got increasing temps a 50x [16:47:16] Hmm I might have to lower the temps of some of these LM systems when it spawns, I might have raised them too much so you get no indicated current 30 minutes after LM press [16:47:26] Or I need to reduce the isolation of the radiators [16:48:50] indy91, did you notice the weird yaw in the SIVB yet? [16:49:07] working on the MCC right now [16:50:04] right, no rush needed of course [16:51:12] only people like me who find the weirdest ways to fly the saturn will run into that bug right now anyway :D [16:51:18] haha, yeah [16:53:49] gotta go, later all! [16:53:53] See ya [16:54:05] I think I am going to try to get RCS heaters working in the LM [16:55:58] I actually had someone arguing with me about that a few days ago [16:56:49] They claimed the AGC did all the work because they “actually read the source” [16:57:06] and tried to use yaagc as a reference [16:57:34] Uhh [16:57:51] something something the missions only succeeded because margaret hamilton got out and physically pushed the lm to the goddamn moon etc [16:58:03] Haha that would make a great meme [16:58:20] no way [16:58:35] I wouldn’t touch that with a 45 foot pole made for touching things you wouldn’t touch with a 20 foot pole [16:58:58] :D [16:59:31] Ok lets see how the CSM handles the rcs heaters [16:59:37] for the 50th anniversary of Apollo 5 I made that mission work. And in that case the AGC (Sunburst) actually could do all the work. [16:59:44] through the LM Programer [17:00:09] ? [17:00:12] Oh, I mean the LVDC [17:00:26] works similarly actually. [17:00:30] They claimed the loss of the LVDC software was not a factor because the AGC did all the work of flying the Saturn [17:00:41] The LVDC sends a lot of commands to the stages via coded messages [17:00:50] so similar to Sunburst and the programer [17:02:13] yeah, the CMC never had the IGM implemented [17:02:22] I think MIT would have liked to do that at one point [17:02:31] but quickly ran out of memory [17:02:50] starting with Apollo 10 the CMC can at least fly the S-IC [17:06:26] one thing I did with the LVDC++ is try to move all of the code that is not actually LVDC functions out of that class [17:06:43] I started that when there was hope to get actual LVDC software [17:06:58] so in anticipation of having to implement a LVDC emulator that needs to be connected [17:07:30] Well, worst comes to worst we have the hardware description and such, we could just roll our own LVDC software [17:07:31] so I implemented a separate FCC class, separate systems for each stage and its engines etc. [17:07:52] It would be a fun project once everything else is squared away [17:08:22] for someone, yes. I am not going to start coding in assembly, nope [17:10:22] we recently found something that is close to LVDC software [17:10:35] At least it’d be not another microcode project [17:10:50] oh? [17:10:53] an attempt to port LVDC code into several programming language [17:11:08] higher programming languages* [17:11:31] it's only partial, but it was done with the actual software of Apollo 17 or so [17:11:39] Oh, the mythical fortran program? [17:12:16] https://www.ntrs.nasa.gov/search.jsp?R=19720013551 [17:12:56] first it has a bunch of program flows, which should be derived directly from LVDC code [17:13:54] and then it has a bunch of translated LVDC code in SPL, CLASP, HAL and CMS-2 [17:14:10] That’s neat [17:14:24] yeah [17:14:37] could help to make the program flow of our LVDC++ better [17:15:06] especially the orbital flight sequence is quite wrong as we have it right now [17:15:34] the major loop doesn't play a role during orbital flight, all relevant tasks are controlled and scheduled through the minor loop [17:15:42] and we just run the minor loop every timestep [17:16:04] instead of 50x per second during powered and 10x per second during coasting flight [17:19:56] but all of that requires a lot of changes for little gain in accurate simulation of the LVDC [17:20:10] so not exactly a priority [17:21:30] indy91, the SM controls the heaters by pointing directly to the boilers in saturnpanel, do we want the LM RCS heaters in lempanel? or lm_rcs? [17:23:35] can be done in lempanel [17:23:43] lm_rcs mostly has the propellant resource code [17:25:07] ok [17:26:09] morning! [17:27:35] Good morning [17:27:39] hey [17:27:42] what's up? [17:28:05] hey you [17:28:52] coasting around in lunar orbit with Apollo 10 working on the MCC [17:28:53] oh hey! [17:29:34] how's it going Suzuran[mobile]? [17:30:02] I’m somewhere with reasonable innertubes today so I thought I’d drop by [17:30:16] hehehe [17:31:13] Gotta put in an appearance now and then so I can still claim I contribute and keep a straight face [17:31:36] based on forum activity I'd say you do 99% of the work [18:09:30] indy91 where should I make a function to return the quad temperature? [18:09:56] lemsystems maybe [18:10:15] Thats what I was thinking [18:10:57] Before I go further how does this look... [18:10:59] https://github.com/rcflyinghokie/NASSP/commit/b9494f90748f714619a0c239365c022ccc77a46e [18:11:35] Other than a switch position mistake [18:15:31] that will work, but you can make that more efficient [18:15:42] look at PanelSwitchToggled in saturnpanel [18:16:00] there you have a function like "CryoTankHeaterSwitchToggled", that handles one type of switch [18:16:10] Ah I was wondering about that [18:16:13] so you don't have to basically add the same switch code 4 times [18:16:21] I knew there was a way to not have to do those repeated [18:16:42] RCSHeaterSwitchToggled or so [18:17:32] I think you can copy that whole function really [18:17:35] logic is the same [18:17:44] up is auto, down is manual on, center is off [18:18:10] CryoTankHeaterSwitchToggled I mean [18:19:35] I will give it a try [18:23:23] I’m back [18:26:02] Ok now for making a function for getting the temperature, I cannot just put a double in lemsystems can I [18:27:26] I guess I can [18:30:27] thewonderidiot: BTW, on the connector having less pins than the bus - You wouldn’t have to duplicate pins common to the connectors - grounds, etc [18:30:43] or pins not needed by the other end: voltage, etc [18:31:10] rcflyinghokie, you already have the pointer to RCSHtr1Quad1 and so, just need to return its temperature [18:32:12] Those pointers are to the boilers [18:32:15] and I'm not sure about your wiring [18:32:16] Not the radiators [18:32:19] yeah, I need to work out exactly what pins are totally unique [18:32:19] ah, right [18:32:29] But what can i fix with the wiring [18:33:00] you wired the switches to the CBs [18:33:15] Yeah they are supposed to be [18:33:35] Remember 2 sets of heaters [18:33:49] One on just cb's and the other cb's to switches [18:34:18] yes, but that won't work for us. You should wire the heaters directly to the CBs [18:34:31] and with the switch they are set to auto,on,off [18:34:35] Ohh I see [18:34:44] wiring the switch to the CB disables the switch [18:35:05] so the SwitchToggled function wouldn't be called anymore [18:35:10] if the switch has no power [18:35:26] different kind of wiring [18:36:10] So just duplicate what I did with htr 1 [18:37:33] Or can I do this: [18:37:40] ((Boiler *)Panelsdk.GetPointerByString("ELECTRIC:QUAD1HTRSYS1"))->WireTo(&RCS_QUAD_1_CDR_HTR_CB); [18:38:04] yes [18:38:06] Ok [18:38:08] no [18:38:19] make a proper pointer [18:38:25] and then use pointer->WireTo [18:38:27] that is cleaner [18:38:33] Ah like I did before [18:38:53] the only different with those heaters is that they are only set on and off with the CBs [18:39:05] I think we already figured out the part in the config for that [18:39:13] because I remember us talking about these heaters [18:39:53] Yeah the config has been ready for the code for a while [18:40:49] Ok done [18:40:56] Now back to this temperature [18:41:46] What is the best way to do this so I do not need a function for each quad [18:44:22] Those functions are in csmrcs on the csm side [18:44:26] to get the temperature? [18:44:45] Package temperature [18:45:06] in the CSM you have 1 package = 1 quad. [18:45:10] fairly self contained [18:45:28] in the LM you have two RCS propellant resources that supply 4 quads, so it's a bit different [18:45:36] hmm [18:45:51] So what is the best course here [18:48:14] maybe something like Saturn::GetRCSStatus in the CSM [18:51:02] Again thats what i was thinking :) [18:51:39] Lets see if I can make it work [18:51:57] that function is slightly advanced programming, haha [18:52:06] Which is why I was hesitant [18:52:16] But I saw how it works I "think" [18:53:40] I wound need definitions for the quads [18:54:19] And i suppose it could be expanded for more RCS info later [18:56:21] Hey [18:56:30] Roughly reading through the backlog. [18:56:58] Suzuran[mobile]: Could a backup of the forum be made? It's been quite unreliable lately. [18:57:29] Also I left a message for you in Guenter a long time ago, you just need to change your name to Suzuran and speak here. [18:57:42] Backup in which sense? Another forum to replace it if it dies, or a dump of the data? [18:57:56] At least the latter. [18:58:06] . [18:58:26] Ah. Yes. I ran across the license on the wiki a long time ago. [18:58:44] haha, September [18:58:57] I'm not sure what I thought needed to be updated? Copyright year maybe? [18:59:01] I don't quite remember. [18:59:52] On the subject on BuildBot posting volume. I know a lot of Gentoo projects have an IRC bot that posts in the channel on build results. That might be a solution for us instead of forum spam. [19:00:48] I'm pretty sure you can set that up just in github repository settings [19:00:52] I think they support it "natively" [19:01:47] That would work for commits but not builds [19:01:57] github doesn’t do the builds, appveyor does [19:02:36] right [19:02:48] derp [19:04:57] Ideally one implies the other so the difference is about 15 minutes but w/e [19:09:23] But would buildbot work for IRC? Or is there some API? [19:09:51] It’s just a php script. I can in theory make it do anything. [19:12:21] Buildbot is just a php script that gets called by appveyor when a build finishes. It gets a few parameters that specify what happened, it formats them into a message, then exploits a bug in MSC’s old version of SMF to post the message. [19:14:05] Hmm, I should be able to let Guenter support that in some way. [19:14:22] And that just shows again how insecure the forum really is... [19:14:42] It doesn't even have HTTPS (hello sending passwords over plain text). [19:19:32] It really has an immortal cookie, not a password [19:19:39] Same idea though [19:20:07] Can't we do an update? [19:20:20] Or at least put a certificate on? [19:22:12] I can’t. We’d have to dig up rob [19:25:54] According to the forums he last logged in mid-December of 2015 [19:30:24] During the licensing scare [19:35:45] Ouch [19:48:43] indy91 I think I have done this mostly right, but I am stuck on some of the code in lm_rcs [19:48:56] Of course I may be totally wrong haha let me show you what I have done... [19:50:27] ok [19:50:28] https://github.com/rcflyinghokie/NASSP/commit/6c09af41d5ef702870a6e914d7b19ebef302dac4 [19:50:48] Of course I may have really screwed up trying to copy that code [19:51:06] you did [19:51:11] Hahaha [19:51:17] you just added 4 new propellant resources [19:51:54] the LM really only has 2 :D [19:52:01] and not located in the quads [19:52:11] I was trying to just make indicators for them [19:52:29] Not more propellant resources [19:54:31] Ok back to the drawing board [19:54:39] all of the code in lm_rcs is wrong unfortunately [19:54:51] No worries at all [19:55:08] I just need something to point to different radiators to get the temperature [19:55:44] you already did that with the radiator pointers you added [19:56:03] those are the ones you should be using [19:56:34] and you named those identically to the new propellant sources you added [19:56:59] remove the "RCSPropellantSource LMQuad1RCS;" lines in the LEM header [19:57:07] an all of the changes in both lm_rcs files [19:57:11] that should mostly fix it [19:58:03] rs.QuadTempF = quad->GetQuadTempF(); [19:58:11] I think with this line you just have to do [19:58:15] quad->GetTemp() [19:58:22] so directly the radiator temperature [20:01:18] Whoever asked earlier - I can’t update the sourceforge webspace right now. Their shell service is “temporarily” disabled. As I understand it this has been the case since last month and there is no ETA [20:01:53] That also means I can’t do anything with the wiki, but I can screw up its database using the web interface [20:02:01] better than nothing [20:03:06] indy91 ok I still need to know what to do with RCSPropellantSource in my getrcsstatus [20:03:23] nothing [20:03:38] RCSPropellantSource *quad = 0; [20:03:43] make that h_Radiator [20:04:02] the LM quads are only represented by radiators [20:04:13] Right [20:04:44] h_Radiator *quad =0;? [20:04:50] I think so [20:04:57] still doesnt like the quad [20:05:22] in each case [20:05:34] ah [20:05:41] a value of type h_radiator cannot be assigned to entity h_radiator [20:05:42] LMQaud1RCS etc. are already pointers [20:05:59] in the CSM code they are RCSPropellantSource, not pointers to it [20:06:04] so just remove the & from each line [20:06:05] Ok [20:06:19] I think that worked [20:06:29] &X means the address of X [20:06:35] quad is a pointer [20:06:46] so if LMQuad1RCS is a pointer, you can directly assign it [20:07:03] if it was h_Radiator, and not a pointer to it, then the & would be necessary [20:07:20] Ah that makes sense [20:08:21] So how do I get this to return the temperature based on the quad selected [20:09:12] lem->GetRCSStatus [20:09:27] And I dont fully understand the values in the () [20:10:03] the index [20:10:25] 0-3 for quads 1-4, if you defined them like that [20:10:29] That is the quad [20:10:31] Yes [20:10:37] And the next part? [20:11:41] which () [20:12:11] Do i need the LMRCSStatus &rs [20:12:44] hmm [20:13:00] so in the CSM that function seems to be only used by the telemetry code [20:13:18] So I don't need it for the LM [20:14:09] you could also just make it a function that directly returns the temperature [20:14:13] instead of a status struct [20:15:20] Is there anything else you might need for telemetry that would be read from individual quads? [20:16:40] not general quad parameters I think [20:16:46] only for individual thrusters [20:16:59] Ok so this should just be simply to return temperature [20:18:06] it can be, yes [20:18:15] there is no right or wrong solution there [20:19:27] So how do I make that a function to directly return the temperature [20:19:33] We may want individual quad temps later for failure simulation purposes (lower temperature = increased chance of failure) [20:20:26] oh we have individual quad temps, just not multiple temp measurements [20:20:44] Unless you mean individual thrusters [20:20:58] in the CSM we have helium and package temperature [20:21:12] but that doesn't rally apply to the LM with its 2 propellant sources [20:21:15] really* [20:21:23] rc [20:21:26] oops [20:21:42] rcflyinghokie, a function that returns the temp of any of those quad temps as a double [20:21:57] you don't have to make it a new function, but it should probably be renamed [20:22:14] Instead of get status, yeah [20:22:14] and then just return the temp [20:22:19] Ok [20:22:35] and it still needs to be convert to °F [20:23:16] do i need to change from void to double [20:23:54] yes [20:24:20] it might have been faster if I had just done this myself, haha [20:24:47] If you did, I wouldn't have learned [20:24:52] true [20:24:58] Which i did a lot here [20:25:06] good [20:25:18] I would still suggest to learn a bit more C++ aside from NASSP work [20:25:48] just some simple tutorials [20:26:07] Yeah i need to [20:26:58] I am not super good myself, I often notice my lack of theoretical knowledge [20:27:05] So the quad heaters are not connected to c/w? [20:27:23] At least not to the heater c/w [20:28:37] just quad and antenna temperatures [20:28:45] so in our case, radiators [20:29:10] Its weird I see the c/w wiring with limits and switches [20:29:15] but all are "cut and capped" [20:30:12] oh, there [20:30:13] hmm [20:30:22] maybe that's just an Apollo 14 thing [20:31:12] They still go to SCERA [20:31:19] But not to the c/w light [20:32:08] The LM 10 handbook doesnt mention anything about illuminating the c/w light for them either [20:32:30] yeah [20:32:49] so just for display and telemetry, not CWEA [20:32:52] Right [20:33:03] Which I guess makes sense for longer missions [20:34:29] Now here is something I am unclear about, there are two sets of thermostat switches, are those just redundant in both systems or does one heater system have one set of temperature limits than the other? [20:35:28] I knew the answer to that question at some point [20:36:24] Systems Handbook [20:36:25] 12.1.4 [20:36:37] note 1 [20:36:41] Thats where I have been [20:37:20] I see that note but it doesnt tell me if each system uses two or if one is primary and the other is secondary [20:38:00] not sure [20:38:33] Yeah I mean I would think that the switched ones are primary if that is indeed the case, otherwise why have redundant switches at different temperatures in the same system [20:39:35] Also they calculated each heater at 17.5W at 24V [20:39:51] Thats 70W per quad [20:40:01] The breaker diagram is 95W at 27V [20:43:31] I am going to keep 95 since we usually run higher than 24V [20:50:23] good night! [20:52:17] Ah and I had another C++ question! [20:52:24] Shoot [20:52:30] I’m still here [20:52:35] Excellent [20:52:45] Not very awake, but here [20:52:49] I am trying to satisfy a warning that not all control paths return a value [20:53:06] Still not totally used to the structures I have explored today [20:53:25] Here is the code in question: [20:53:32] Probably means you declared the function as returning something, but there’s a conditional/unconditional return somewhere that doesn’t return anything [20:53:47] https://www.dropbox.com/s/l8aupv4um13qb93/Screenshot%202018-03-08%2015.53.33.png?dl=0 [20:53:49] This includes the implicit return at the end of the function [20:53:55] Or the function just ends without returning anything. [20:54:01] Suzuran: Exactly that. [20:54:18] The return is inside the if [20:54:19] So do I just need another return at the end? [20:54:27] Oh [20:55:07] You want another return outside of the if() that returns 0 or -1 or something [20:55:16] because it means you were passed an invalid quad number [20:55:51] I totally missed that I deleted it earlier to change it but forgot to add it back [20:57:07] You really could do the whole thing with just the switch and drop the if entirely (use default: to catch the exception) [20:57:13] but that’s cosmetic [20:57:24] True [20:57:27] (unless the VC++ compiler is even dumber than I think it is) [20:57:39] Might be better seeing is I dont intend to expand it any further [20:58:02] But lets see what happens as is [20:58:16] Warning is gone [20:58:31] Lets see if it works [21:00:05] It does [21:00:15] Now I need to figure out how to scale it to display properly [21:01:27] But that will be after I take my dog out, back in a bit [21:29:26] Alright. I've got everything packed. Leaving at 5:30 tomorrow to go skiing at Willingen for 2 days. I'll be back Saturday evening. :) [21:29:50] Enjoy! [21:30:08] I have a new snowboard I still havent had time or enough snow to break in :( [21:30:42] Just like I have a new mountainbike that's waiting for the weather to get pretty enough. :) [21:30:56] Have fun, don’t break any legs [21:31:36] Haha, thanks. I'm sure we'll enjoy ourselves! [21:33:35] Hmm what is a good example of a display that is rescaled when different data is selected [21:35:59] I was going to say the ammeter in the LM but it appears it is not scaled like it is supposed to be [21:37:38] Oh never mind you divide it by two when reading it [22:37:41] And the quad heater displays are scaled successfully through the scera :) [22:40:22] Or not... [22:50:16] I thought the gauge class did the scaling [22:50:23] it’s been a long time since I had to look at it [22:50:43] but I seem to remember I had to specify the measurement range in the registration [22:51:45] Well it does yeah, but we have actually implemented the sce in the LM so it can scale based on voltages [22:52:02] I forgot about that until a little bit ago [22:52:16] So I am adding more to it and seeing if I can get a proper display [23:02:43] Time to pack up [23:02:46] Have fun kids [23:02:52] Take care [14:01:48] Good morning [14:04:40] hey [14:10:06] So we have quad heaters now [14:10:25] However I cannot figure out where to find scaling information for the scera [14:11:12] nice [14:24:09] I see that Niklas has a bunch of scale factors to get voltage to the right displayed value, but I do not know where he got the information [15:36:58] I am wondering if he just generated a scale factor [15:42:07] yeah, no idea unfortunately [15:43:02] Well I calculated one that works, hopefully it passes his inspection :P [15:43:37] I am assuming though that other LM's had the other scale placarded on the heater temp display for the quads [15:46:29] Interesting, LM 10 closeout photos show actual warnign bands on the temp meter [15:46:35] https://www.hq.nasa.gov/alsj/a15/lm10-co8.jpg [15:47:10] Also the quad scaling was changed from 20-200 to -60 to 260 [15:47:51] Looks like our LM started those see the placards around our temp meter, RR LR SBD? [15:47:55] hmm interesting [15:48:56] The quad scaling I knew about, LM 8 used the 20-200 and LM 10 AOH had -60 to 260 [15:49:06] But looks like our panel needs those bands :P [15:49:18] LM-10 is witch mission again? [15:49:23] which* [15:49:33] 14 [15:49:36] sorry 16 [15:49:39] 8 is 14 [15:50:00] so I guess we should make it like LM-8 for now [15:50:13] Wait [15:50:37] LM 10 is apollo 15 [15:51:00] Thats right they changed to J missions [15:51:25] Are the markings ok now as it stands for our panels, or do they need some more? [15:51:31] LM 9 is at kennedy never flew [15:51:57] They are fine I am sure, though those "LR RR SBD" are pointless by the display without the bands below them [15:54:48] Of course the systems handbook doesnt have those added placards [15:56:15] right [16:04:40] I am trying to get some pictures of LM 8's panel in flight but having a hard time [16:07:51] https://history.nasa.gov/alsj/a13/AS13-59-8484HR.jpg LM-7 [16:07:56] Barely visible [16:08:12] You can see the quad scale on the left, not right [16:10:11] The LM simulator had it on the right [16:28:32] Now lets see if I can get the CO2 light working [16:30:37] How is that done, making a light turn on [16:30:45] It would be the same as the no track light [16:30:56] graphic wise [16:37:05] yeah, sounds like it should be simple enough [16:37:40] but that usually means it ends up being stupidly complicated :D [16:37:49] Well I have no idea how to do any of that sort of thing [16:38:24] lempanel I presume [16:38:35] Ah I see [16:38:53] I guess it would be similar to the CWEA light you got working [16:39:21] No that lighting code was already there [16:39:29] I just had to turn it on or off [16:40:29] Looks like it needs a loadbmp [16:43:32] I can use the same bmp but how to I know where to put it on the panel [16:53:55] And how do I tell it to use the bmp in question [17:07:06] Ok figured that out [17:07:17] Now to figure out how to draw it over the right spot [17:14:42] Any idea how to find the right location to draw this? [17:36:36] hmm, you mean where to super impose it on the main panel nmp? [17:36:39] bmp* [17:38:13] Yeah [17:38:31] I have it all set up but the coordinates are still over the no track light [17:38:56] oapiRegisterPanelArea (AID_RR_NOTRACK, _R(1000, 1300, 1034, 1334), PANEL_REDRAW_ALWAYS, PANEL_MOUSE_IGNORE, PANEL_MAP_BACKGROUND); [17:39:03] I am assuming it's those 4 numbers? [17:39:47] Yes it is [17:40:29] Now how do I figure out what corresponds with a location I want [17:49:25] morning! [17:49:43] ScrX, ScrY, ScrX + 245, ScrY + 245 [17:49:49] Thats what the 4 numbers are [17:49:53] Hey Mike [17:50:32] what's up? [17:50:32] Ah never mind that is FDAI specific [17:50:52] Trying to figure out how to determine coordinates for placing something on the panel [17:51:09] oh boy [17:51:21] OAPIFUNC void oapiRegisterPanelArea (int id, const RECT &pos, int draw_event = PANEL_REDRAW_NEVER, [17:51:21] int mouse_event = PANEL_MOUSE_IGNORE, int bkmode = PANEL_MAP_NONE); [17:51:47] const RECT &pos is what I need [17:52:10] I try to change the numbers to see if it moves but it either vanishes or doesnt move it seems so trial and error has not worked [17:53:59] So I haven't a clue [17:55:21] let me open up VS and see what I can find [17:55:37] I appreciate it [17:55:47] I am working in lempanel [17:56:01] your're basing it off the no track light, correct? [17:56:06] I have the light and the conditions I just need to move it to the right spot [17:56:10] Yes [17:56:30] oapiRegisterPanelArea(AID_CO2_LIGHT, _R(1706, 926, 1790, 1130), PANEL_REDRAW_ALWAYS, PANEL_MOUSE_IGNORE, PANEL_MAP_BACKGROUND); [17:56:37] That is my line which works [17:56:41] But the position is incorrect [17:57:00] That position is the one from the original track light location [17:57:21] I have tried other positions they work as well moving it around but I cannot determine what to change to move where I want if that makes sense [17:57:55] so the 1st 2 numbers (1000, 1300) are the top left coordinates [17:58:28] or 1706,926 in your case is top left [17:58:47] and 1790,1130 is bottom right [17:58:50] Oh [17:58:52] I see [17:59:07] Any good way for figuring out the coordinates I want? [17:59:15] I use the panel bmp [17:59:55] I opened it but have no idea how to see the coordinates [18:00:03] see where on the panel bmp which pixel corresponds to the top left/bottom right of the light bmp [18:00:24] what are you using for image editor? [18:00:36] I just have paint in here [18:01:43] Oh paint shows them, paint 3d was the default [18:01:48] I think I have them [18:01:49] very easy with paint, just use rectangle select and then what ever pixel you're over will show [18:02:18] Yeah i see that [18:02:25] you can see in the code what pixel the no track light used on the panel [18:02:53] and then use the same corresponding pixels on the CO2 light, if the light is identical [18:03:37] They are [18:03:57] What do you mean use the same corresponding pixels? [18:05:56] Oh never mind [18:06:30] well say the not tack light top left is 1000,1300 in the code. I then look for that pixel on the bitmap and then zoom in on it and then I can see the exact pixel it is on the no track light. So since the CO2 light is the same, I know what pixel to use on it for top-left [18:07:27] But I have to guess where to start the top left for the co2 light [18:08:49] well if you zoomed enough to note the pixel from the no-track light you can note the patern of the pixels around it too, and can then easily spot the same pixel on the CO2 light [18:09:40] I still don't follow [18:09:52] That pixel is just gray panel [18:09:56] hmm, I see [18:12:36] I think I figured out a way [18:12:36] What I do then is make a black tick on the pixel 1000,1300 and with rectangle select, measure the distance from it to a certain pixel on the light itself [18:12:57] Well I know the total size [18:13:04] I just need to figure out where to start the top left [18:13:09] its 34x34 [18:13:10] yes [18:13:31] but thats the way to find the top left location, on the new CO2 light [18:13:37] Right [18:13:40] I did that [18:14:05] Lets see what it looks like [18:14:21] If this works then I can get those other bulbs in the LM working [18:16:38] Works, thank you! [18:16:47] no problem [18:17:11] what was your coordinates finally? [18:17:51] Well i realized I did the wrong light haha [18:18:02] But they worked for the suit fan light :) [18:18:14] haha [18:18:19] So i will use those for when I make that code [18:18:30] (1822, 1072, 1856, 1106) for the suit fan [18:18:46] But now I know how to find those corners thank you for that [18:19:12] I have to run out, but I hopefully can get more of those coded tonight :) [18:19:15] Later! [18:19:41] cya [18:46:56] hey [18:50:18] morning! [18:52:35] hey [18:53:16] Ryan has been getting more lights working (CO2, suit fan) [18:53:23] very nice [18:59:52] I've got lights working today as well. In a car with the help of a battery jumper cable. [19:02:30] hahaha [19:03:37] I can't help but picture you with one of the LM panels, having decided that the best way to try to turn it on is to stick it in your car and wire it into your car battery [19:04:37] been there before, :D I always keep jumper cables in my car now... [19:04:53] yeah, we had to go to the next gas station [19:05:47] so I guess you forgot to hit LM PWR - CSM? [19:06:37] more like, we forgot to switch the Main Bus ties off [19:06:50] haha [19:13:53] nice to see buildbot not do anything about today's PR, I think that was a good change [19:15:35] yeah [19:17:16] and now forum visitors will truly thing the project is dead :D [19:17:39] *think [19:18:56] a lot of people still think it is haha [19:19:17] I don't blame 'em if they can barely get a forum account [19:24:33] for that alone we should have more of a presence in the Orbiter Forum [19:32:53] yeah definitely [19:41:14] Apollo 10 landmark tracking PAD has more numbers on it than the Apollo 11 one. So I'll take the lazy approach a just implement the Apollo 11 one for now. [19:41:20] That's also what the RTCC MFD does anyway [19:41:58] sounds good [19:51:07] I got a jump pack for my car it has already paid for itself being my car or others cars, even got me a free haircut for jumping one of the barbers cars that died [19:51:22] http://boltpowerusa.com/product-category/auto-jump-starter/ [19:51:27] They are great [19:52:18] don't even need another car that way! [19:52:50] I saw your PR [19:52:55] I have some change requests [19:52:59] Sure [19:53:11] I wasnt quite sure about the scera handling [19:54:13] how are you assembling commits? I'm usually checking and commiting it with Git GUI, because there you can look at the actual changes [19:55:03] because then you would have noticed that you still have "h_Radiator *quad;" in the lem_rcs header [19:55:16] I am also staging each file manually in Git GUI [19:55:24] Thats what i am using and how I do it [19:55:28] ok [19:56:05] with staging each file manually it's a good last check that I am actually commiting only the changes I want [19:56:25] Yeah I need to check that a bit more thoroughly [19:56:44] and when I did some testing changes and I have files that only have e.g. an empty line added or removed then I usually revert that file and don't commit it [19:56:53] just to not have useless changes in my commits [19:57:44] reverting a file can also be done with the GUI [19:57:51] I was going to ask how to do that [19:57:59] carefully [19:58:04] Haha [19:58:16] I've almost reverted the wrong files sometimes [19:58:27] I am cautious with git I have messed up my local repo more than once [19:58:47] anyway, I noticed that quad line in lem_rcs and in the LEM header there was still the LMRCSStatus struct [19:59:03] which I don't has any use right now [19:59:05] don't think* [19:59:47] so if those two things could be removed, then I'll happily merge the PR [20:00:31] also saw a commented debug line in the SCEA code, but I don't mind having that there [20:00:44] Ah yeah [20:00:59] Could be useful to repurpose later I suppose [20:01:12] SCEA changes look all right [20:01:29] it can be annoying having to work with the 0-5V for a gauge [20:01:54] but at least it's scaled correctly for telemetry and it's realistic [20:02:09] Also the scaling of the quad temps is different than the rest on that display [20:02:15] Thats what threw me off for a bit [20:02:37] I wonder if that is accounted for with the scaling the SCEA does [20:03:17] LM 8 quads are also scaled differently than LM 10 and later [20:03:22] quad temps* [20:03:27] annoying [20:03:57] Even the little placard is different [20:04:52] But based on LM 8 data, they are scaled properly and displayed properly [20:05:26] And we have working quad heaters [20:05:39] awesome [20:06:01] I just copied the coordinates from the CSM so they actually heat and cool based on being in the sun or not like the CSM [20:06:23] I just hope I have the right quad in the right corner :P [20:06:34] LM coordinate system is also different [20:06:45] so I would expect that not to be correct right now [20:06:58] Yeah that will all need to be corrected at some point [20:07:31] can be easily verified with a debug string in the thermal code [20:07:48] Now to get the rest of these light bulbs installed ;) [20:07:52] and then just point the quad to the sun and look if the radiation is maxed [20:08:04] Ah I can try that [20:08:25] I removed the pointer and the structure definition in the PR [20:12:42] merged [20:14:08] Also I noticed our LM is missing the color bands on the temperature display [20:14:21] We have the labels for the headers of them but not the bands [20:14:37] https://www.hq.nasa.gov/alsj/a15/lm10-co8.jpg [20:17:17] did every mission have those? [20:17:40] Not sure, the lm simulator from apollo 11 doesn't appear to [20:17:48] I am trying to find a better picture [20:17:51] https://history.nasa.gov/alsj/a13/AS13-59-8484HR.jpg [20:18:10] You can see the quad label on the left on 13, but I cannot tell if there are color bands [20:18:36] https://www.hq.nasa.gov/alsj/a12/LM6-co27.jpg [20:18:42] Apollo 12 had them [20:18:58] even better here: https://www.hq.nasa.gov/alsj/a12/LM6-co28.jpg [20:20:08] Ah yeah [20:20:22] so yes, we should add them [20:20:32] Agreed [20:23:39] should be easy to add that to the main panel bmp [20:28:36] Just have to make it look right [20:28:56] Ok I have all these light bulb coordinates, now to figure out the logic [20:32:11] all those ECS lights? [20:32:53] Yes the co2, h20 sep, glycol, and suit fan lights I believe they are [20:33:54] do some of them use SCEA discretes? [20:34:02] I don't remember [20:34:08] I will be researching them one by one though [20:34:12] right [20:34:20] I just wanted to get the positions of the lights right [20:34:26] Then all that's left is logic [20:34:51] I have to stop using "direction" words in my phrasing haha [20:35:13] yeah, that's not the right way to write [20:35:41] hurray, landmark tracking PAD worked on the first try. Just one revolution too early because I used the wrong inputs for the calculation. [20:36:20] haha very nice [20:36:23] the flight plan has times one rev too early, but that is not the actual tracking, but just a landmark familiarization [20:36:46] I guess I can locate the dc bus fault and bus fault lights for now and leave them off just needing logic while I am doing this [20:37:04] I also have to make them light up on the LMP window panel [20:37:32] just one more set of coordinates to figure out on the window panel [20:37:39] Yeah not hard [20:38:19] just a bit tricky sometimes to locate it on the right pixel [20:40:56] Yeah Alex helped me getting that down [20:41:17] And thankfully these are easy to line up [20:46:20] so, how do we do landmark tracking in Orbiter 2016... [20:49:19] in the past the marker have been really helpful [20:50:40] Dont we have a marker file? [20:50:48] I remember adding landmarks to it [20:54:27] yeah, but now the surface has elevation changes [20:55:00] hmm [20:55:11] none of the markers are appearing when I enable them [20:55:18] I wonder if that is an Orbiter Beta issue [20:55:21] or change rather [20:56:32] can you see the markers? [20:57:16] there indeed was a change, in rev 68 [20:57:28] deleted the marker folder [20:57:32] I kinda remember that coming up in here at one point [20:57:37] cant see any surface markers either [20:57:39] I don't remember if it was Thymo or Alex [20:57:40] and added a new label file [20:57:50] I guess Thymo, heh [20:58:19] Haha [20:58:20] oh no, [20:58:28] (08:20:25 AM) rcflyinghokie: [08:02:59] So it looks like markers for the beta are all screwed up [20:58:29] (08:20:25 AM) rcflyinghokie: [08:03:08] Not the stars but the terrestrial ones [20:58:29] (08:20:25 AM) rcflyinghokie: [08:03:21] They changed the layout and configuration it looks like [20:58:30] (08:20:25 AM) rcflyinghokie: [08:03:30] It doesnt match the manual anymore [20:58:57] Ah we changed it for 2016 [20:59:01] But the beta messed it up [21:00:01] seems like it [21:00:11] It was something about how the file layout was written [21:00:22] the file Doc/PlanetTextures.pdf explain the new setup [21:00:22] Different from before and didn't read our cfg [21:03:31] ah, I screwed it up [21:03:46] with my blind change for the Orbiter Beta [21:03:58] "LabelFormat = 2" in the planet and moon configs [21:04:11] without that the legacy label format is used [21:04:20] of course the new one supports elevation [21:04:24] so that might be better [21:06:46] I have to install new cable boxes so I will be off for a bit [21:06:57] I'll try to get those lights "installed" tonight [21:07:02] Back a bit later [21:07:34] http://orbit.medphys.ucl.ac.uk/mirrors/orbiter_radio/tex_mirror.html [21:07:44] Label.tree files there [21:07:48] those are fairly new [21:08:00] they should have the new default labels [21:09:31] haha, 100MB just for Earth labels? wow [21:11:00] ah, there they are [21:11:03] look very nice [21:11:15] just need to figure out how to create our own labels for it [21:26:02] I should create labels for all the landing sites [21:27:56] those should be part of the default labels [21:28:52] AlexB_88, did you do the elevation fixes at KSC with tileedit? [21:29:34] no with treeman [21:29:52] what's that? [21:30:19] in any case, this .tree file format has to be unpacked somehow [21:30:21] https://www.orbiter-forum.com/showthread.php?t=37452 [21:30:31] then it might be possible to edit the labels in text [21:30:54] the file for the Moon is only 100KB [21:31:00] so we could include a modified version [21:31:16] not the 100MB file for the Earth though [21:32:04] ah great, the most recent version of treeman supports label editing, it looks like [21:32:11] great [21:34:17] brb [21:34:50] good night [22:15:20] Ok all lights are installed on all panels [22:15:30] Now we just need logic [22:17:45] I did find an issue with the panel though, ascent helium switches when accessed from the cdr window panel [22:17:56] reg 1 switches work reg 2 dont [22:20:28] Ah they arent coded to be [22:26:51] yeah [22:28:02] I can fix that [22:29:46] Also the ECS gauges need to be added to the S.E view (LMP) [22:30:05] Yeah There a few things on either side that need to be added [23:23:44] Woo co2 light is working right [23:40:50] great [23:44:10] And all the other lights work as well, they just need some control logic [23:51:19] Does the water quantity light some on whenever you load the LM? [23:51:24] come on* [23:54:08] hmm, sometimes it might of [23:54:22] I can't remember though [23:54:59] I think it might be a load order or timestep [23:55:09] I do know I have seen some random ECS lights come on on the CWEA for sure, just can't remember if it was that one [23:55:17] Because you can clear it with the cwea reset and it stays off [23:57:52] right [00:00:28] I need to figure out why that happens [00:01:05] Niklas might know off the bad with his familiarity with the timesteps/saving/loading order [00:01:10] bat* [00:23:39] Hmm what is a good way to tell it to draw power every timestep while the bulb is lit without just rewriting the conditions in a timestep? [00:25:27] I'll ponder over dinner [00:28:33] good question [00:28:46] anyway I'm off to bed, cya! [15:39:52] @rcflyinghokie hey i was just wondering if apollo 7 and 8 would work in v8 in the orbiter 2016 beta [15:40:04] They should [15:40:25] yeah cause i cant do apollo 11 because of those ctd's [15:40:50] Which ctds? That .dll file? [15:40:59] yeah [15:41:47] Now does the creation/use of the LM cause those? [15:42:04] happens always after lem ejection [15:42:23] i have been trying some apollo 7 and 8 scenarios and i never get the ctd [15:43:11] i tried the pdi demo scenario and no ctd for that either [15:44:19] Hmm interesting [15:44:40] What is funny though is that .dll file is a windows file and not a file created by NASSP [15:44:58] yeah i read it could be the program that causes it but i dont know [15:44:59] What are your computer specs if I may ask? [15:45:26] windows 7 ultimate 64 bit with 4g ram [15:46:28] What about graphics? [15:48:12] NVIDIA GeForce 210 [15:48:39] have you ever gotten a ctd when switching views? [15:48:59] We get those occasionally in the LM, can never pin them down [15:49:22] You are using orbiter with the dxd9 client? [15:49:26] yes [15:49:29] the ng one [15:49:34] And running the exe orbiter_ng [15:49:40] Ok [15:50:20] The reason I am asking is my old windows 7 laptop gets a very similar ctd to yours, but its in the dxd9 client and always with the LM [15:50:27] I am wondering if its a windows 7 issue [15:50:33] maybe [15:50:42] i dont think anyone on here is using windows 7 [15:50:52] I don't either [15:51:04] I would put my money on that potentially being the issue to be honest [15:51:09] yeah [15:51:28] How did you do your orbiter install? [15:51:34] the msi file [15:51:51] for the beta i used some svn thing i dont remember what it was called [15:52:48] Ah yeah [15:53:01] And you have that in a separate folder from the orbiter msi install? [15:53:43] the beta folder is separate from the regular 2016 version [15:54:34] Ok good [15:54:51] And I assume you just downloaded the NASSP zip and copied it in there? [15:55:16] and about apollo 8 in the before sivb seperation scenario the sivb never maneuvers do you think that will be fixed eventually? [15:55:19] yes i did [15:55:38] Actually it does [15:55:57] It maneuvers to orbital rate and then to sep attitude [15:56:07] not in v8 i dont think [15:56:32] i know it does in v7 with orbiter 2010 [15:56:38] It does in V8 [15:57:57] did you guys do some changes to the lvdc lately? [15:58:25] Yeah there are a lot [15:58:33] for apollo 8 too? [15:58:49] Probably [15:58:59] I do know it has been working though even before those changes [16:01:22] that is strange because it doesnt seem to be working for me i just tried it [16:02:30] From a fresh launch? [16:02:48] no if i clikd on the before sivb seperation scenario [16:02:54] click* [16:03:17] Oh those probably dont have the lvdc stuff in them [16:03:34] yeah it only works if i use a before launch scenario [16:03:44] Which is correct [16:04:31] would that be an easy fix do you thing? [16:04:34] think* [16:05:37] Well all the scenarios need to be fixed/replaced [16:05:47] We have made a lot of changes that arent present in those files [16:06:06] But that won't happen until we are closer to a release [16:07:12] do you think we will see v8 released this year you guys seem to be making alot of progress [16:07:23] It's hard to say [16:07:27] I would like to say yes [16:07:51] It would have to fully support up to Apollo 11 [16:09:32] yeah and i think i will focus on apollo 7 and 8 right now [16:11:24] well i am gonna go start apollo 7 now so i will talk to you later [16:15:43] Have fun [16:48:31] morning! [16:58:18] Good morning [17:16:10] hey [17:18:43] Hey there [17:19:57] everything was great with the MCC, but then the map update for rev 4 calculated times that were all wrong, haha [17:20:19] this is the first one after LOI-2, I wonder if the very much circular orbit is an issue [17:21:21] Interesting [17:21:37] You would think the circular orbit would make things simpler? [17:21:48] it does, yeah [17:22:00] but the definition of the true anomaly because a bit problematic [17:22:08] usually 0° true anomaly is at periapsis [17:22:40] but if periapsis is not very well defined, due to circular orbit, then some calculations need to account for that [17:22:45] maybe that is the case, not sure yet [17:23:16] *definition of the true anomaly makes this a bit problematic, is what I wanted to so [17:23:47] https://en.wikipedia.org/wiki/True_anomaly [17:24:14] it has some info on that, basically alternative definitions for a circular orbit and a circular orbit with zero inclinationn [17:24:40] I never thought about that [17:24:58] haha, yeah, it's my department to think about that :D [17:25:22] Would potentially make periapsis bounce around [17:25:39] I actually see that in KSP with a very circular orbit [17:25:47] and it certainly will with nonspherical gravity [17:26:13] changes the periapsis with any maneuvering or perturbations in gravity [17:26:44] Well I had some success last night getting all those bulbs in place [17:26:59] And the CO2 logic works [17:27:35] I am currently working on logic with the others, working on glycol now [17:27:46] Thankfully you have those relays already in place making life easier [17:30:12] yeah, it always helps when you can rely on a system being implemented without shortcuts [17:31:36] And I can use the scera voltages for these as well [17:35:02] Oh, I want to add a power draw to these bulbs while I am here, I think they draw like 1 watt (based on the co2 sensor cb max power) [17:35:31] Where is a good place for those drawpowers [17:36:23] And can I base it on if the bulb is "lit" rather than duplicating the conditions in each case that draws the bulb lit bmp over the panel [17:37:09] might be good to implement a class for those type of lights [17:38:39] Would the logic for lighting them go there too? [17:39:09] Or would that stay in the cases [17:40:02] I suppose the logic could go in that class for each bulb and the cases for drawing could return from those [17:43:21] yeah, most of it can go into the class [17:43:29] I think I can manage that [17:43:42] I will get the logic and the lights working and then migrate them [17:44:03] Oh, how do i return the state of a boolean in a debug string? [17:44:23] %b? [17:45:06] %d should also work [17:45:15] Ok [17:53:44] oh, the AOS and LOS calculations weren't wrong [17:53:49] it just confused AOS and LOS [17:53:54] hopefully easier to fix then [17:55:47] Mixed them up? [17:56:09] I think I remember SR and SS calculations used to be mixed up as well [17:56:14] yeah [17:56:24] it had the AOS time as the LOS and vice versa [17:56:32] I remember fixing some things about that [17:56:35] maybe not enouggh [17:56:37] enough [17:57:54] Did you see this? [17:57:55] https://www.ebay.com/itm/132530400523?ssPageName=STRK:MESELX:IT&_trksid=p3984.m1555.l2649 [17:58:20] Haven't looked at it yet but caught my eye [18:02:50] very nice, exactly the kind of document I am usually looking for. But in this case, Apollo 10, I already have all the flight events [18:03:09] prelaunch could be potentially interesting, I am still lacking some good data on that [18:04:13] and being from November 1st, 1968 it could be slightly outdated [18:05:01] "You can read through the countdown" [18:05:06] sounds promising at least [18:06:45] I am messaging him on reddit (where I saw the ad first) to see if he will snap some pictures of the prelaunch events to see if they can be of use [18:07:05] Anything in particular you would be looking for to see if it is useful? [18:07:55] the 6th picture, with the header "flight mission event list" [18:08:04] that is taken from Timebase 6 [18:08:22] if there is something like that list for prelaunch, then it could be really useful for me [18:09:02] I shot him a message [18:09:03] 7th picture are the events just after liftoff [18:09:06] thanks! [18:09:07] Yeah we have those [18:09:24] yeah, maybe in the pages before that are the prelaunch events [18:09:36] We shall see what happens [18:09:47] on of the Apollo 10 document we have actually has a list of a few S-IVB prelaunch events [18:09:51] but that's about it [18:10:00] Question about the auto transfer code in the glycol pumps [18:10:12] The pump fail relay is kind of baffling me [18:11:13] The conditions that make GlycolPumpFailRelay = true seem to be always on [18:12:33] Hmm maybe it was a transient [18:12:38] Now it is behaving normally [18:12:55] maybe you did an auto transfer? [18:14:29] It did [18:14:33] GlycolAutoTransferRelay is a latching relay [18:14:36] has to be reset [18:15:09] Hmm [18:15:22] So are 3 conditions able to turn on the glycol light? [18:15:34] the dp switch, 7k8, and 7k9? [18:17:25] 7K9 is weird [18:17:36] is that actually getting a signal from the SCEA? [18:18:01] it looks like it does [18:18:31] no, the other way around [18:18:32] in the wiring that sc2 box is a little oddly placed [18:18:43] that relay is what is causing the signal in the SCEA [18:18:44] 7k9 signals scera [18:18:51] and the signal in the SCEA is required for the light [18:18:51] and scera turns the light on? [18:19:00] Yeah I have that logic in place [18:19:18] note 6 [18:19:30] I am trying to see if the dP switch and 7k8 being latched both independently turn the light on [18:19:30] on 6.3 [18:19:52] and it's the solid state switch from the SCEA [18:19:56] not the voltage this time [18:20:53] Ah [18:20:57] Is that implemented? [18:22:02] yes [18:22:12] all the RCS TBs are using it [18:22:27] Oh duh thats what i already am using [18:22:51] I have if that voltage is >0 [18:22:58] that's wrong [18:23:17] that's not the solid state switch [18:23:22] what do I use to get that switch [18:23:36] //Cooling pump no. 1 failure (GF2936) [18:23:37] SA12.SetOutput(2, lem->PrimGlycolPumpController.GetGlycolPumpFailRelay()); [18:23:41] That is the switch [18:24:19] so I would be using something other than getvoltage [18:24:26] ah getswitch [18:24:28] yes, I'm checking [18:24:34] I have it (I think) [18:24:38] getswitch gives you a pointer to the switch [18:24:47] but then you can access its state [18:25:08] lem->scera1.GetSwitch(12, 2)->IsClosed() [18:25:43] got it [18:25:49] scera2 in this case [18:26:19] ah, right [18:26:47] Ok I get that now am I right about the dp switch and 7k8 both being conditions for the light to turn on? [18:27:06] 7K9 only indirectly [18:27:19] the SCERA solid state switch OR the DP [18:27:30] 7k8 only indirectly* [18:28:32] ah good, there already is a GetPressureSwitch() function [18:28:45] Yep [18:29:03] I think I need to add one for 7k8 though [18:29:37] one what? [18:29:52] Well a light is supposed to come on if auto transfer has been done [18:30:03] And then extinguish if you switch to the working pump [18:31:09] The actual pump transfer is done but the light does not extinguish until you switch to the working pump in order to make the crew aware [18:33:37] yes, but that should already all be accounted for with the current logic [18:34:07] There is no current logic for the light [18:34:22] Oh message from the seller : [18:34:24] I'll take some pics. Any idea of how many seconds before liftoff you want? There are many pages. I'll look for 'mission event list'. [18:34:37] Any idea what you want as a sample? [18:34:43] the logic for the light just needs to be: SCERA solid state switch OR the dP switch [18:35:08] and the right behavior should then already happen due to the logic in the LEMPrimGlycolPumpController class [18:35:40] 7K9 is the auto transfer latching relay [18:35:46] that stays energized until reset [18:36:00] 7k8 [18:36:05] ah, yes [18:36:17] And thats what I mean, the light is on when that is latched [18:36:34] yeah [18:36:56] 7K9 is energized when 7K8 is energized [18:37:11] and the SCERA switch is closed when 7K9 is energized [18:37:16] so that should all work correctly [18:38:05] 7k8 energizes 7k9? [18:38:18] yes [18:38:33] 7K8 closes a contact [18:38:47] and that energizes 7K9 through the glycol pump 1 CB [18:39:06] with the switch setting glycol pump 1 [18:39:32] GlycolAutoTransferRelay && glycolRotary->GetState() == 1 && glycolPump1CB->IsPowered() [18:39:38] logic for the fail relay [18:40:31] Right I have those up [18:40:55] So pulling the pump 1 cb is not a good way to test this [18:40:57] about the countdown, I am especially interested in the last 3 minutes before liftoff [18:41:06] Ok I will ask [18:41:27] 187 seconds really, haha, that is when the terminal countdown sequencer is in control [18:41:58] there is an auto transfer test during LM activation [18:43:14] Yeah I am going to try that [18:43:23] I asked for the page with 187 seconds before liftoff [18:43:30] thanks [18:43:37] I think I've tested the glycol pump check [18:43:46] of course I never really tested the logic for the failure relay [18:43:52] no SCEA or light to use it before [18:44:33] Yeah I remember mechanically everything worked [18:44:49] ah, I think it makes sense. I'm looking at 104:40 in the Apollo 12 LM Activation [18:45:00] that starts with pulling the pump 1 breaker [18:45:02] Thats what i have open [18:45:13] that should cause an auto transfer [18:45:18] The ecs light turns on then off as the transfer is completed [18:45:28] ah [18:45:29] hmm [18:45:32] And the comp light should stay on until pump 2 is selected [18:45:34] no, that could work right [18:45:42] the pressure will not drop instantly [18:46:07] yeah, but the comp light will not be on until the pump 1 breaker is closed again [18:46:22] before closing that, the auto transfer latching relay is already set [18:46:29] but 7K9 not, due to no pump 1 CB power [18:46:36] and pump 2 has taken over [18:46:41] Ah thats what my comfusion was [18:46:48] so no dP issues [18:46:49] confusion [18:47:07] How do I return if the switch is closed or not in a debug string [18:47:13] For lem->scera2.GetSwitch(12,2) [18:48:19] ->IsClosed() [18:48:42] That will return a 0 or 1? [18:49:23] true or false, returns a bool [18:50:34] GetSwitch returns a pointer to the switch itself [18:51:11] Ah ok [18:51:18] I set it up this way because it works well with the talkback class [18:51:45] so you give a pointer to the solid state switch to a SCEATalkback class [18:51:58] and then the talkback code just needs to do [18:51:59] ssswitch->IsClosed [18:52:01] ssswitch->IsClosed() [18:53:33] The only think I couldnt get right with the glycol loops was the pressure when the pumps were off [18:54:17] So pump off pressure is the bottom of the green band until I work on that again, but increasing the loop volume or decreasing the mass just reduced the flow [18:54:28] But the dp sensor works right even with this problem [18:56:16] So everything works right but the comp light coming on momentarily when pump 2 is selected [18:58:03] Maybe the unlatching of 7k8 isnt instant? [19:02:17] Otherwise I cannot find a reason why the light would be on momentarily [19:02:53] And he is going to snap a pic of that pg with 187 seconds on it today for me [19:20:24] awesome [19:21:35] the light is on because of the dP pressure switch [19:21:43] not the solid state switch [19:22:45] Ah [19:23:46] Why would that switch be closed [19:23:54] momentarily [19:24:01] just before the auto transfer [19:24:19] The auto transfer is already complete by then [19:24:30] or did you mean transfering manually to pump 2 [19:24:34] the switch I mean [19:25:33] ah I see, the light should be on momentarily when you switch to pump 2 [19:25:36] but it isn't? [19:30:19] Nope [19:33:33] Pump two is already running from the auto transfer at that point isnt it? [19:33:48] Therefore the pressure switch shouldnt be closed [19:33:50] yeah [19:35:03] hmm [19:35:18] wouldn't both pumps be off in the INST (SEC) setting? [19:35:38] that is done just before setting the switch to pump 2 [19:36:07] so the light should be on due to low dP [19:37:18] well, when you switch to pump 2 at least [19:37:21] then the dP should rise [19:37:29] and everything is good [19:38:17] maybe the dP didn't drop enough? [19:38:34] due to your high pressure with the pumps off [19:41:22] hmm, no [19:41:26] pump 2 stays on [19:41:32] because of auto transfer [19:43:59] so the light has to be on due to 7K9 [19:44:36] Why would 7k9 still be on [19:44:51] yeah, can't be [19:44:56] switch is in pump 2 [19:46:24] weird [19:51:13] Yeah [19:51:39] I cant really make sense of why the light would be on momentarily [19:51:58] "Maybe the unlatching of 7k8 isnt instant?" could be this [19:52:03] no other idea at this point [19:52:11] but that should require it taking quite long [19:52:21] long enough for the pressure to drop [19:55:37] I'm looing at the page from the elementary schematics [19:55:45] maybe that has additional information [19:57:39] not really [19:58:17] Would something to do with switching to SEC to pump two do it? [19:58:44] Like does it "remember" being on and then is turned off? [20:02:06] how about this [20:02:21] when you switch from SEC to pump 2, you have to go through pump 1 [20:02:42] and if you are setting it to pump 1 momentarily, the light should be on [20:03:02] so maybe it's just momentarily on in the process of switching from sec to pump 2 [20:04:02] that would really just be an issue with switch code [20:04:20] so nothing we can or should fix in the glycol control code [20:11:18] Oh thats right [20:11:29] That makes perfect sense [20:11:44] And pump 1 would light the light [20:12:15] yeah, auto transfer is still on at that point [20:12:46] In that case I think the glycol light is working properly [20:15:35] great [20:31:45] Hmm what are we better set up for, suit fan or water sep [20:36:36] for the light you mean? [20:37:05] Yeah looks like suit fan would be easy [20:37:15] on if K12 is closed [20:39:23] SuitFanFailRelay [20:39:37] and there already is a function to get it [20:39:39] GetSuitFanFail() [20:39:43] Yep [20:39:46] Easy [20:41:16] the h2o sep might get interesting [20:42:49] Oh that reminds me, any idea why the water quantity light comes on after each load of the LM? [20:42:50] probably a function of flow through the separator? [20:43:03] And yeah thats what I am thinking for the sep [20:43:31] I think the CWEA doesn't save or load anything yet [20:43:58] and we already have the WaterWarningDisabled flip flop [20:44:02] but it's not saved [20:44:27] Ah [20:44:48] And suit fan light works [20:46:02] I guess I need to add the glycol and suit fan logic to the c/w lights as well while I am here [20:54:10] It looks like k12 closes the switches for ecs caution and suit fan lights as well as the comp light? [20:54:58] And if that is energized and suit fan 2 is selected the suit fan warning light comes on [20:55:43] And if it is energized and fan 1 is selected, the ecs light comes on [20:56:44] sounds about right [20:56:56] and I think you again mostly have to access the SCEA [20:57:43] for the CWEA at least [20:58:44] I already added functions in LEM_ECS [20:58:46] GetSuitFan1Failure [20:58:49] and GetSuitFan2Failure [20:59:12] and the SCEA is reading those [20:59:48] but that is not the SCERA subassembly type with the solid state switches [20:59:54] so a voltage check it is [21:00:00] "> 2.5" I guess [21:00:30] the type is 504-3 [21:00:36] "12 dual channels" [21:00:43] I think what that measn is that is has two outputs [21:00:56] in this case one for telemetry and one for the CWEA [21:02:13] I think they are switches? [21:02:37] //Suit fan 1 fail (GF1083X) [21:02:37] SA3.SetOutput(2, lem->ecs.GetSuitFan1Failure()); [21:02:38] //Suit fan 2 fail (GF1084X) [21:02:39] SA3.SetOutput(6, lem->ecs.GetSuitFan2Failure()); [21:03:46] "1" when fail [21:04:21] there are a bunch of SCERA subassembly types that are discrete buffers, but only one type has solid state switches [21:05:02] and type 504-3, like others, is conditioning a closed contact (so logic 1) as 5V [21:05:14] and open contact, logic 0, as 0V [21:06:09] the voltage can vary [21:06:26] the AOH says you should expect 0 to 0.5V for off (logic 0) [21:06:32] and 4 to 6V for logic 1 [21:06:50] so the check "> 2.5" should also be correct [21:07:02] always* [21:08:33] Ah I see [21:10:03] lem->scera2.GetVoltage(3, 6) > 2.5 [21:10:45] yes [21:11:19] Ok lets try this [21:13:50] Question, why do some of these CWEA lights have an else to make the light turn off and some have the light off as the first line? [21:14:06] Is that just the same thing written different ways? [21:15:12] basically the same [21:15:47] for cases where there are a bunch of different conditions to have the light on, it can be easier to just set the light off by default [21:15:57] and then only have the logic for the on state below [21:16:23] if the "if" condition is only one line you can just make it a "if - else" [21:16:36] Makes sense [21:16:45] the difference is mostly subjective, clarity of code, maybe fewer lines of code required etc. [21:19:15] I think I have figured out why the AOS and LOS (and sunrise/sunset) times are switched sometimes [21:19:44] because I like analytical solutions (because I am stubborn) I am solving a quartic equation for that [21:20:01] and usually that quartic only has two real roots [21:20:27] but for nearly circular orbits (I think) this quartic can have 4 real roots, which is not a case I am properly processing [21:24:56] Yikes [21:27:41] I think the dp switch for the suit fan was a bit off [21:27:55] should be close at 6 INH2O and open at 8 INH2O [21:29:44] probably just a bad guess, considering "inch H2O" is not PSI :D [21:29:57] feel free to change those numbers [21:31:17] Haha ok just making sure I didn't miss another piece of information elsewhere [21:31:34] Would also explain why even with a high dP the light stayed on :P [21:31:44] I can't really remember why it's 1 and 1.33 PSI [21:32:00] No idea [21:32:04] but I think it just was a guess with the pressures we had in the loop at the time [21:32:24] We never really used that data for anything until now anyways [21:46:05] Ah that change made the difference [21:48:35] Now for the CW light [21:59:15] Success [22:00:20] I see you have some water sep flow rpm code [22:11:00] Guess we have to make some arbitrary calculations regarding RPM [22:12:19] And figure out if 0.85 is the appropriate max flow [22:24:08] yeah, pretty much [22:24:11] good night! [09:27:40] . [12:27:31] hey [12:28:44] hello [12:28:49] @indy91 just wondering is apollo 7 a difficult mission to fly? [12:29:16] good question [12:29:52] Apollo 7 has a rendezvous with its S-IVB in the flight plan [12:30:23] and the rendezvous procedures are very challenging [12:30:31] there is a lot to do in a very short time [12:31:05] so all in all Apollo 8 is probably a bit easier than Apollo 7 [12:31:16] probably [12:31:36] starting with Apollo 9 you have to know two spacecraft very well, CSM and LM [12:31:47] so 9 and later are never going to be easier than 7 or 8 [12:32:24] yeah i know where most of the switches are in the cm with the panel numbers [12:33:14] I think by flying Apollo 7 you can learn more than flying Apollo 8 [12:33:31] and if you make it through the rendezvous then Apollo 7 becomes quite managable [12:34:09] and i am guessing it should work in v8 in 2016 right? [12:34:44] yes, although it hasn't been tested too much [12:35:27] right now there is no real advantage of flying Apollo 7 with Orbiter 2016 and NASSP 8.0, just the potential for issues [12:36:20] just that the graphics of the earth and moon are better [12:36:55] indeed. The improvements for the Earth aren't that major though [12:37:10] the difference of the Moon between 2010 and 2016 is stunning [12:37:30] jut for the visuals I would say that flying a mission to the Moon should be done in 2016 [12:37:33] just* [12:38:58] and for me the time acceleration is less laggy then in 2010 for some reason [12:39:20] interesting [12:39:59] I get a worse frame rate in 2016, but I never noticed anything worse or better about time acceleration [12:41:05] and just wondering are we allowed to post youtube videos of nassp? i know you guys do that but is anyone allowed? [12:41:46] yes, very much allowed [12:41:56] there should be no licence issues with that [13:36:46] There aren't. GPL doesn't cover video content or any other production in any way. [13:37:03] GPL is just for software distribution and modification. [15:07:05] Good morning [17:57:16] morning [17:57:18] DST is the worst [18:05:02] I know, right?. [18:05:13] At least I didn't have to get up early [18:05:36] yeah [18:05:39] will tomorrow though :( [18:07:03] Yeah certainly takes more than a day to adjust [18:08:10] By the way [18:08:11] https://www.ebay.com/itm/132530400523?ssPageName=STRK:MESELX:IT&_trksid=p3984.m1555.l2649 [18:08:47] The seller is going to take a picture or two of the prelaunch sequence for me and then we can see if it any use to Niklas [18:10:29] nice! [18:18:12] I hope Thymo doesn't mind that I have started diffing into and working on the CWEA [18:18:17] digging* [18:24:30] is the CWEA the last big thing in the LM? [18:26:57] EPS needs some work too, especially assigning the right power draw and heat to all systems [18:27:14] CWEA is actually well on it's way with the scera in place [18:27:29] I got the ECS comp lights up yesterday [18:27:43] awesome [18:27:49] A few CWEA logic switches things like that [18:35:40] sounds like we are well on our way to NASSP 8 :D [18:37:22] I hope so! [18:39:38] I've been working on designing a USB debugging board/cable for the AGC, in the event that we actually get to power one up [18:40:18] I'm hoping to be able to use it as a sort of real-time logic analyzer thing :) [18:40:25] Way outta my league :) [18:40:57] haha [18:43:30] C++ question... [18:43:43] What is the difference between... [18:43:46] !pressRegulatorASwitch->GetState() == 0 [18:43:55] And pressRegulatorASwitch->GetState() != 0 [18:45:25] as far as idiomatic programming goes, I would never do the first one [18:45:45] but also, I think it is not correct [18:46:02] in C++, I am pretty sure the ! operator returns a boolean [18:46:08] Thats how Niklas did a pressure switch I am working with [18:46:16] so you end up comparing a boolean and 0 [18:46:20] which I guess might work [18:46:25] but it's weird [18:46:29] Niklas is weird :P [18:46:33] Haha [18:47:56] I have been writing my state checks with the latter of the two's syntax [18:49:16] yeah, that is definitely the preferable way [18:53:52] true is 1? [18:55:15] yeah [18:55:28] but any non-zero value will also evaluate as true [18:56:44] I just mean if I return that bool using %d it will be 0 or 1 [18:56:48] In a debug string [18:57:20] yeah in that case, false = 0 and true = 1 [18:58:24] Ok great [19:09:27] He is going to see these changes and be like what did you do? [19:15:48] hahaha [19:42:23] I have an NAND gate here [19:42:40] I am trying to make sure I have the logic correct [19:44:10] Let me take a shot of the logic for you [19:51:15] https://www.dropbox.com/s/g0v67pzucejvop9/Screenshot%202018-03-11%2015.50.54.png?dl=0 [19:51:54] The non filled in circle is on the bottom, I am used to that being on the right side of the gate not the left [19:54:56] If both conditions are "1" is the light on or off? [20:16:28] hey [20:17:10] rcflyinghokie, I have a few topics for you [20:17:22] Hey no problem [20:17:39] first, SA5.SetOutput(3, scale_data(lem->ecs.GetWaterSeparatorRPM(), 0.0, 3600.0)); [20:17:45] you changed that from 500 to 0 [20:18:07] the lower end of the scaling [20:18:17] Yes per the systems handbook [20:18:22] ah, interesting [20:18:25] AOH said 500 [20:18:26] hmm [20:18:32] Which LM? [20:19:21] 10, maybe [20:19:29] AOH Volume 1, PDF page 479 [20:19:40] "Basic Date 1 February 1970" [20:20:20] lm 8 handbook pdf pg 138 [20:21:11] hmm [20:21:50] I mean either is fine, I just have to change the comp light scaling [20:22:05] right [20:22:11] But I have been trying to stick with the LM 8 handbook as best I can for consistency [20:22:15] we even have a revision page for it in the Systems Handbook [20:22:22] LM-8 revision B [20:22:25] page 287 [20:22:27] also 0 there [20:23:01] Yep [20:23:25] I would think LM-8 Systems Handbook is earlier [20:23:44] and we probably should use LM-5 as the reference, whenever possible [20:23:49] so using 0 RPM is fine by me [20:23:52] Ok [20:24:11] PR merged [20:24:19] Other than the delay from spin up/spin down that sep light works well [20:24:25] then, Apollo 10 comm tests [20:24:34] they did a steerable antenna test [20:24:38] which requires AC power [20:24:45] and they did indeed activate the inverters [20:24:48] No inverter on at that point in my checklist [20:24:54] I can fix it [20:24:54] 084:45:58 Cernan: Okay. My AC bus voltage was on the high side of the Green for inverter number 2. [20:25:01] yeah, Apollo 12 didn't do that [20:25:13] so that should be added [20:25:24] because the steerable didn't move during the test, haha [20:25:49] Ah I remember that [20:26:01] so at least inverter activation and the S-Band antenna AC CB [20:26:21] and then of course both deactivated after the comm test [20:26:29] Do you know which procedures they followed for the eps powerup before that? Since I assume it wasnt the full one [20:27:20] I need more LM activation checklists haha [20:27:56] two for Apollo 9 even [20:28:30] EPS Activation from PDI Day of Apollo 12 should be good [20:28:36] Ok [20:28:37] so on ACT-18 [20:28:44] I think I have that as a group [20:28:45] to 20 [20:28:49] yeah [20:28:55] Just need to add the cb [20:29:17] and then during comm deactivation, inverted off, rest as per CB chart, just like now [20:29:29] inverter* [20:29:36] Sure [20:30:06] So I have been digging a lot into the pressure switches and logic for cabin repress and cw light for it [20:30:31] We don't have a separate cabin pressure switch, it is kind of a hybrid with the repress open relay [20:31:44] yeah, I think it hadn't been fully implemented [20:31:54] it should repress for both cabin and suit pressure, right? [20:32:03] wiring is a bit weird [20:32:18] Yeah I have been trying to make sense of it [20:32:30] I can take a look again [20:32:56] I understand how to change it more or less I just need to make sure my logic reading everything is correct [20:33:27] ok [20:33:29] And the suit pressure switch doesnt involve the cabin at all [20:33:30] let's see [20:34:57] Before that, I have a few more observations with the checklist. CSM Power switch needed the SetDelayTime, or else it can't use reset. I have fixed that in my local copy, will be included with the next push. [20:35:30] Ah great [20:35:44] and during the LM comm test your focus was very much the LM, haha, you didn't add the landmark tracking in the CSM. [20:36:03] I quickly did all the procedure up to the steerable test, because that involved a specific attitude [20:36:08] then I did the landmark tracking [20:36:13] and then the steerable test [20:36:27] but doing the job of 3 astronauts at the same time is tricky [20:37:08] I hadn't done a proper landmark tracking in Orbiter2016, I was surprised how well I could do it. I switched to the sextant, was able to see some crater close to the targeted site and do marks on it [20:37:30] Yeah it was hard to balance things, but in the end I focused on the LM as it had the "busier" tasks [20:37:35] right [20:37:45] it would be nice if there was a higher resolution at the zoom factor 60x [20:37:54] Yeah its grainy [20:37:56] yep [20:38:07] but otherwise, quite possible to do, even without markers [20:38:21] just have to pick out a specific landmark [20:38:51] and then just an observation. having to do the LM represses and hatch openings adds sooo much to the immersion [20:38:55] I quite like that [20:40:03] Yeah and the timing isnt too bad if I do say so myself :) [20:40:14] you put a lot of work into it [20:40:29] We just need to hook up the unbilicals before charging the LM :) [20:40:37] umbilicals [20:40:56] saving with the hatches open is a bit adventurous though [20:41:19] Very large valves and timesteps oh my [20:41:26] yeah [20:41:28] it's not too bad [20:41:44] I first thought it was really bad, because the dP gauge was at -1 PSI [20:41:46] I noticed in the LM on panel switching sometimes I get a glycol comp light transient [20:41:48] but I had the gauge in off [20:41:50] Haha [20:42:15] I think there are a lot of possible improvements with the panel code [20:42:28] I still need to get back in there and get the lm press and tunnel vent timings down, I really never messed with those [20:42:29] it needs a good overhaul, for Orbiter 2016 and also 2010 features [20:42:35] Oh I am sure [20:43:07] the current standard for Orbiter isn't using bitmaps at all [20:43:10] but 2D meshes or so [20:43:20] which would be much more performant [20:43:22] eventually... [20:43:35] That would improve a lot visually as well I bet [20:44:27] Oh I did have to change some of the cabin repress logic as well [20:44:38] And that will be changed further with these switches [20:44:44] Should they be their own classes? [20:45:22] the pressure switches? [20:45:32] Yes [20:45:54] Or just logic within another [20:46:08] why not in LEMCabinRepressValve as it is right now? [20:46:53] Thats where i have started putting mine [20:47:42] Then the repress relay would be dependent on that switch [20:47:47] was there really that much to add? [20:47:55] I thought I had it 90% figured out [20:48:00] No it would be wasy [20:48:04] Yeah its almost there haha [20:48:24] rcflyinghokie: I'm back [20:48:31] I just need to make sure I am reading the wiring right, because putting this switch in would mean changing conditions for say the suit gas diverter solenoid etc [20:48:45] the white circle on the logic gate input means that input is inverted before going into the logic gate [20:48:54] Ah thats what it means [20:48:58] hey Mike [20:48:59] That makes total sense now [20:49:07] afternoon! [20:49:22] Thats how I was understanding the logic but was unfamiliar with the drawing itself [20:49:25] oh, Ryan, did hear back about the countdown pictures? [20:49:33] Yes, he is posting it tomorrow [20:49:37] great [20:50:14] I don't know if he is taking all of them but if the one he takes looks like something you want, maybe I can ask nicely if I can get those pictures before it sells [20:51:43] so, how do you understand the repress logic we don't have yet? [20:51:50] what's with the diverter valve there [20:54:53] Ok [20:55:16] The diverter valve pops out if the cabin pressure switch trips [20:55:45] ah, so that is you thought making it a separate class [20:55:54] because it is used in two different systems [20:55:59] Yes [20:55:59] makes sense for that [20:56:06] I didnt know if you could just call the relay [20:56:13] Like some of the others [20:56:18] *switch not relay [20:56:42] you can add a class that does the timestep to determine if the pressure switch(es) are open or closed [20:56:47] But I think just a pressure switch class that contains logic for both switches? [20:56:57] Suit and cabin microswitches [20:57:00] and then just add a funtion to that class that returns the switch state [20:57:06] Yeah [20:57:09] one class [20:57:15] and two instances of it [20:57:23] one is given a pointer to the tank [20:57:29] cabin tank [20:57:42] other one some suit circuit tank [20:58:55] I think I can manage that [20:59:08] class init would have the tank pointer, lower and upper limit [20:59:22] Then we just have to go back through the ecs systems and use those switch states rather than independent pressure conditions [21:00:55] yeah, but that shouldn't be too difficult [21:01:59] Nah easy [21:02:37] I changed some other CWEA stuff to use scera instead of a direct function per the handbook as well [21:02:45] awesome [21:03:04] and I think I have fixed this map update issue for good [21:03:21] Other than the water quantity light always being on when we load the LM, the caution panel can all be off while flying [21:03:52] I am using the correct derivative function of the correct equation now [21:04:18] The only 3 I have not checked are c/w power ed relays and rcs, the other 6 work properly [21:04:19] needs more testing, but I am confident that it is solved [21:04:22] Oh great [21:04:31] For RTCC and MCC? [21:04:33] right, RCS [21:04:58] yeah, I moved the function into the RTCC class [21:05:04] where it gets used by both MCC and RTCC MFD [21:05:17] Great [21:06:01] the choice LOS vs. AOS was just more obvious for elliptical orbits, mathematically speaking [21:06:51] circular orbit is a border case, that was unreliable when using the slightly wrong function for the LOS vs. AOS decision [21:07:11] LOS/AOS and sunset/sunrise are the same calculation [21:07:16] True anomaly issues right? [21:07:18] for lunar orbit at least [21:07:31] just one uses a vector to the Earth, other calculation to the Sun [21:08:13] indirectly with the true anomaly. Just the quartic equation for this becomes one with 4 real roots, two of them being identical [21:10:14] couldn't find the right picture, but basically case B here: https://bam.files.bbci.co.uk/bam/live/content/zqcvcdm/small [21:10:29] just with a quartic, not a quadratic [21:11:29] so this was mostly a maths issue, not really orbital mechanics [21:11:41] Haha one in the same most of the time [21:11:56] I have little to no experience with quartic [21:12:05] I know quadratics well enough [21:12:40] just a few more calculations to do [21:13:53] the calculation of the roots worked super good, no issues there. It's just always been figuring out which root is a LOS and which is a AOS. [21:14:25] in the real RTCC documents it always just refers to the "Work Schedule Processor" [21:14:46] which seems to output a lot of the numbers like AOS, sunrise etc. [21:16:06] so not really a specialized tool for the map update but more of a byproduct [21:16:36] I suppose that makes sense to prevent redundant calculations [21:16:59] No need to calculate it by itself when another calculation's output can be used for it as well [21:17:54] right [21:18:06] although there was a lot redundancy in the RTCC and RTACF [21:18:21] the old Gemini stuff was transferred to the RTACF [21:18:48] then there was development for the major maneuvers like LOI etc. that were first tested in that "old" RTACF [21:18:53] before being used in the RTCC [21:19:54] so for e.g. translunar MCCs the RTCC was able to calculate them, the RTACF was able to calculate them and during the first missions the RTACF also had an alternative way of calculating it, which if proved to be working, was then transferred to the RTCC as the new method [21:20:55] so the RTACF was both proving ground and backup [21:22:32] Interesting I did not know that [21:23:57] the RTCC was literally in the basement of mission control [21:24:01] not sure about the RTACF [21:24:15] https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19720017573.pdf [21:24:29] RTACF development experience report [21:24:31] interesting read [21:24:40] evolved from Mercury apparently [21:25:23] I actually just had that up after googling it [21:25:47] Ok for this switch code, you said the logic goes in the init? [21:26:41] the class should have variables for switch closing and opening pressures [21:26:50] which are initialized in the init [21:26:58] and a pointer to the tank I guess [21:27:03] Oh I see [21:27:37] I have a pointer to each tank in my init right now [21:28:29] each? [21:28:47] it needs one pointer [21:29:39] What determines which tank to look at then [21:29:58] it should be a generic pressure switch class [21:30:05] and we will use two instances of it [21:30:18] one for the cabin pressure switch, one for the suit loop [21:30:35] class name LEMECSPressureSwitch maybe [21:30:49] Yeah I have it LEMPressureSwitch [21:31:03] and the LEM will have two of them [21:31:14] it looks to me like the two pressure switches are working the same way [21:31:19] just with different pressures [21:31:23] Yeah just different limits [21:31:27] And of course different tanks [21:31:30] yep [21:32:31] Ok I guess I dont totally understand how this is going to work haha [21:32:44] What goes in the init in lemsystems if I only have one pointer [21:33:29] the LEM class will have two LEMPressureSwitch instances [21:33:33] so there will be two inits [21:33:58] same function, just different inputs [21:35:32] Oh I see [21:37:41] haha, in your C++ education we have been doing too many classes that only are used once [21:37:54] but this is what they are really useful for [21:38:12] Yeah I am not used to this [21:40:05] Do you know of a good example off hand of a condition like this? [21:40:11] 2 inits in one class [21:41:04] no, the class only has one init [21:41:21] but there are two instances of the class [21:41:26] which both need to call the init [21:41:34] with the inputs pointer to tank, max and min pressure [21:42:11] for one instance the input will be the pointer to the cabin tank, and for the other somewhere in the suit loop [21:42:55] just look at the CircuitBrakerSwitch class [21:43:00] we have 100s of them [21:43:01] Ok [21:43:07] and each call the init [21:43:36] oh, much better example [21:43:40] LEMSuitCircuitPressureRegulator [21:43:50] in LEM.h [21:43:51] LEMSuitCircuitPressureRegulator SuitCircuitPressureRegulatorA; [21:43:51] LEMSuitCircuitPressureRegulator SuitCircuitPressureRegulatorB; [21:44:21] and then look at those two (A and B) in lemsystems [21:44:59] going through a C++ tutorial would help so much with this, NASSP work alone just isn't a good tutorial [21:45:31] http://www.cplusplus.com/doc/tutorial/classes/ [21:46:07] I will give all of those a look thanks for bearing with me! [21:48:36] no problem [21:49:21] can confirm those tutorials are helpful, I went through them... something like a decade ago now... [21:49:48] back when I was dead set on making a big 3D game in C++, lol [21:50:34] haha [21:50:39] I had a uni course in C++ [21:50:58] very classical approach, just a text editor and compiler [21:51:03] nice [21:51:04] starting with apples and oranges [21:51:29] although I think my "peak C++" was at the end of that semester [21:51:50] I have learned OOP using Java this year. Same concepts apply. [21:52:04] since then I forgot a lot [21:52:26] even NASSP development doesn't keep one proficient in every aspect of C++ [21:52:32] as I said, not the best tutorial [21:52:32] true, but you've also probably learned a lot more for practical use [21:52:42] probably, yeah [21:53:00] on a higher level probably [21:53:11] Visual Studio, complex include structures [21:53:14] that kind of stuff [21:53:31] yeah, that sort of thing is hard to learn through a class [21:53:50] Put that into contrast with "Class Cow extends Animal". :P [21:54:26] haha, yes [21:56:05] great, I fixed the map update and the next one isn't until after the sleep period [21:56:08] so much for testing it [21:56:39] guess I'll do one with the MFD each rev [21:57:06] This is making much more sense now [21:57:42] After going through the tutorial? [21:59:27] Some of it yeah [21:59:41] I totally understand this now, I was overcomplicating it in my head [21:59:50] At least this particular case I get [22:00:46] Tbh I should probably go through some cpp stuff again. I've been influenced by Java quite a bit. [22:00:51] yeah, it's not that complicated, but it's easy to make it complicated [22:02:59] Are these switches powered at all? [22:03:13] Or are they mechanical [22:03:23] I think the latter [22:04:28] mechanical, yeah [22:06:43] and there is the signal strength on the steerable [22:06:55] too bad auto tracking doesn't work yet [22:08:47] Wouldn't it be similar to the CSM/RR? [22:08:51] Just usign earth? [22:08:54] using* [22:09:17] And then that would be the same for the csm hi gain tracking as well [22:09:56] On these inits, do I put the max and min values for each just in the init for each? [22:10:55] the HGA in the CSM uses the same tracking method as the RR, but it has 3 axis which I haven't figured out yet. [22:11:14] And for the steerable antenna in the LM, I understand the axis and geometry, but the tracking method not yet [22:11:26] the init function should have min and max as an input [22:11:41] Where are they input [22:11:53] the actual values for each [22:11:56] same as all the other Inits. [22:12:06] CabinPressureSwitch.Init((h_Tank *)Panelsdk.GetPointerByString("HYDRAULIC:CABIN"), 4.70/PSI, 4.07/PSI); [22:12:13] yeah, like that [22:12:16] Ok cool [22:12:30] Then all that is left is to return if they are open or closed [22:12:54] yeah, so just a public function returning a bool [22:13:20] like the function return relay states for the SCEA [22:13:23] functions* [22:13:29] returning* [22:15:25] ah, I remember, the steerable antenna uses conical scanning https://en.wikipedia.org/wiki/Conical_scanning [22:15:35] just have to figure out the best way to implement that [22:16:31] Do i again use just one function to return it? Or do i need one for each switch [22:17:00] I did a generic one and returned like you did in other classes [22:17:01] bool GetPressureSwitch() { return PressureSwitch; } [22:17:06] yes, like that [22:17:15] the function won't have two bools to return anyway [22:17:19] the class* [22:17:19] Right [22:20:24] And last part how do I return the pressure switch state for the particular switch I want [22:21:03] CabinPressureSwitch.GetPressureSwitch() [22:21:17] and maybe a "lem->" in front of that, depending from where you call it [22:21:53] Hmm [22:22:05] doesn't like the lem-> [22:22:11] or by itself [22:22:13] where do you call it from [22:22:23] repress code I guess [22:22:27] Yeah [22:22:35] Unless I missed a definition somewhere [22:23:07] no, it's just that that class doesn't have a LEM pointer yet [22:23:27] look at LEMOverheadHatch how to add that [22:23:33] Ah ok [22:23:35] "LEM *l" in the init [22:24:36] And that has to add to the repress init [22:27:43] yep [22:27:46] Ok [22:28:28] There we go [22:30:27] Or not [22:30:55] says the line in LEM.h is inaccessible now [22:31:01] What little thing did I forget [22:32:52] hmm [22:33:00] making it a friend class! [22:33:21] Thats what I was just looking for [22:33:34] very bottom of LEM header [22:33:50] Yep [22:34:00] friend classes are allowed to access private members of a class [22:34:16] so if the repress class is the friend of the LEM class, then it is allowed to access its pressure switches [22:34:33] I had issues with friend classes before (rather remembering to add it) [22:35:09] Why isnt the overhead hatch in here though [22:36:26] even though it uses lem-> [22:36:32] right [22:36:40] that class only calls functions of the LEM class [22:36:44] public functions [22:37:09] so it doesn't need to be a friend [22:37:31] Oh I see [22:37:43] the alternative way we could do this is to give the repress class a pointer to the pressure switch [22:37:46] instead of LEM [22:38:04] Does which we choose become a style preference? [22:38:05] then no friend class would be needed [22:38:08] yep [22:38:21] Ok lets see if the repress stuff works [22:38:51] Then I might have a PR for you to look through [22:38:56] hey [22:39:32] Good evening [22:43:26] hey Alex [22:44:48] I see some nice CWEA progress [22:47:17] About to be some more (if this works) [22:48:10] I still dont understand that water quantity light [22:49:06] it needs saving/loading, I think [22:49:30] the other lights seem to work properly on startup [22:49:34] Its only that one [22:50:51] I guess the CO2/H2O SEP/SUIT FAN/GLYCOL lights need to also be tied up to the lamp/tone test circuits [22:51:44] Yeah that should be easy now [22:53:16] Hmm switch closes properly but doesn't open back up, time to investigate [22:56:09] indy91: https://imgur.com/a/q3zLB [22:56:21] scroll down a bit for the prelaunch pics [22:57:19] the whole automatic sequence [22:57:25] exactly what I was looking for [22:57:53] thanks a lot! [22:58:09] Did he get pics of everything pertinent to that? [22:59:31] yes [22:59:38] Wow even better [22:59:47] I have other documents for the manual steps done by people in the LCC [22:59:57] but I didn't have the auto sequence commands [23:00:00] now I have [23:00:14] Well great [23:00:23] I guess we dont need to bid on it now [23:00:57] yes, we got all I had in my "need" category [23:01:24] Excellent [23:02:14] Ok now why won't my switches open [23:02:51] https://www.dropbox.com/s/8zxb8yazymoodlt/Screenshot%202018-03-11%2019.02.27.png?dl=0 [23:04:28] Logic issue somewhere [23:04:45] didn't you already do the "/PSI" in the call of the init? [23:04:56] so you shouldn't need it in the timestep anymore [23:04:57] Yes [23:05:03] I was just looking at that [23:05:08] I think thats why [23:05:18] space.Press returns Pa [23:05:20] Yep [23:05:26] and the scaling in the init call also does that [23:06:21] Yeah that was very likely it, pressure was never above the max because of bad conversion [23:09:55] suit switch worked I assume the cabin is about to as well [23:10:52] Success [23:20:09] I will PR my current state then start seeing what else can use those switches [23:20:25] Or better yet, I'd like to verify my cabin warn logic [23:20:50] sure [23:21:17] I'm close to the sleep period with Apollo 10. The checklist just has "Initiate PTC roll" [23:21:23] but that is not what they did [23:22:13] Which timeframe [23:23:04] end of LOI day [23:23:13] 84:45 [23:23:32] "G&N Att Hold +/- 10°DB, two adjacent quad control" [23:23:47] there is a special procedure to use 10°DB I think [23:25:29] Ah yeah I see what you mean [23:25:40] PTC roll is wrong for LPO [23:25:52] They usually kept a fixed attitude [23:25:56] yeah [23:26:01] with large deadband [23:26:27] you manually have to change some erasable to get 10°DB [23:26:32] I'm trying to find the procedure [23:27:46] And was that a 2 quad through dap or auto rcs select switches [23:30:00] Auto RCS I think [23:30:09] 085:16:07 Engle: And Charlie Brown, we'd like for you to disable B and C, and use B and D rolls in DAP, please. [23:30:19] so B and C disabled manually with Auto RCS [23:30:25] and then B/D roll selected in V48 [23:30:53] AOH Volume II, part 1, PDF page 303 [23:30:59] CSM that is of course [23:31:19] I'm just confirming that EMEM3255 is the right address [23:32:25] Ok [23:32:34] Let me start getting this into the checklist [23:32:58] yes it is [23:33:21] so you do a V48, with B/D roll selected as well as 5.0°DB [23:33:43] and then you manually load 10°DB by changing the relevant erasable [23:35:15] Ok [23:37:03] I have a few things about this commit [23:37:05] PR* [23:37:15] Sure fire away [23:37:41] EmergencyCabinRepressRelay [23:38:01] the logic for it was correct, I think [23:38:17] now there are some states where the state is not determined [23:38:24] some cases* [23:38:42] like the else [23:39:17] Right [23:39:35] Which logic change are your referring to? [23:40:09] you removed the relay being set false above "//MANUAL" [23:40:19] Yeah it was not working properly [23:40:42] I am reverting it right now as I don't remember the exact bad behavior [23:40:48] hmm [23:41:38] you are right [23:42:04] I think it wasn't staying on [23:42:05] your solution can't be right either though [23:42:18] The repress valve opened [23:42:19] yeah, where it was set to true only gets called once [23:42:22] and stayed open [23:42:28] but the relay reset [23:42:46] And the relay controls the cabin warning light [23:43:01] The way I have it has the correct behavior in the sim [23:43:08] At least from the tests I have tried [23:43:53] the if-else logic doesn't check out. [23:44:03] your solution is better than mine though, haha [23:44:54] Yeah I thought mine was a little weird but it delivers the right behavior of the relay from what I could see [23:45:14] Which reminds me, can you check my logic for the cabin warning light [23:45:21] but in all cases, can't be [23:45:25] not* [23:45:31] if you pull the repress CB [23:45:36] it would stay energized [23:46:05] Ah yeah [23:46:19] or anything with the pressure regulators [23:47:06] ok, better solution [23:47:09] should the false be in the else [23:47:13] no [23:47:18] have the false where it was [23:47:49] at the top? [23:48:09] where it was [23:48:16] and then [23:48:17] if (cabinRepressValve->in->open) [23:48:18] { [23:48:18] EmergencyCabinRepressRelay = true; [23:48:19] } [23:48:28] below the else if [23:48:40] else if (lem->CabinPressureSwitch.GetPressureSwitch() == 0 && cabinRepressValve->in->open == 1) [23:48:42] this one [23:48:47] so below the "}" of it [23:49:13] Ah I see [23:49:19] that sets the relay to true if the valve is open due to auto repress [23:49:24] which should be the correct behavior [23:50:11] and remove them from the if and else if in between [23:50:31] yes [23:50:44] Ok let me try that [23:51:16] night! [23:51:20] Goodnight! [23:51:59] cabin warning light logic is not quite right [23:52:09] Yeah thats what I needed help with [23:52:12] the repress switch state also goes through the SCEA it seems [23:52:19] SC1 it says [23:52:20] Oh does it [23:52:42] yep I see that [23:53:50] now where in sc1 [23:57:46] And for the 10 changes, was it B and C quads or B and C roll jets disabled in auto rcs [23:59:50] quads [00:01:07] Ok [00:02:09] Did you look for the repress switch state in sc1 by chance? I could not find it [00:04:11] still looking [00:04:19] might be not used for telemetry [00:04:26] so hidden somewhere [00:05:42] oh [00:05:50] might not even be going through the SCERA [00:05:51] maybe [00:06:49] hmm, no [00:06:58] SC1 referes specifically to SCERA-1 [00:07:32] Right [00:07:40] But I cannot find anything in there for that haha [00:08:19] doesn't even have a measurement number on the CWEA schematic [00:08:28] so let's just keep it as it is right now [00:08:40] Ok thats why i did that in the first place couldn't find it anywhere [00:08:52] maxpress = NULL; [00:08:55] minpress = NULL; [00:09:06] I am not sure using NULL at all [00:09:13] it seems to be used for pointers usually [00:09:23] but not actual numbers [00:09:31] so better use maxpress = 0; etc. [00:09:55] Ah no problem [00:10:14] Can you take a look at the ecs schematic where the cabin repress valve is? [00:10:16] anything you had about the cabin light? [00:10:28] Yeah thats what I am about to ask [00:10:43] It says on there <4.3 psi inhibit when valve in manual [00:11:01] yet the logic on the warning schematic makes no mention of this, only that the light is disabled in manual [00:11:10] Am I missing a pressure condition somewhere? [00:12:13] hmm [00:12:25] it looks like there are two separate relays actually [00:12:35] 7K6 is the one relevant for the CWEA [00:12:47] but another one opens the repress valve [00:13:22] it's getting way too late, I'll look at this tomorrow [00:13:33] so just like my Apollo 10 flight, I now have a sleep period [00:13:35] good night! [00:13:36] No problem [00:13:37] Night! [00:15:20] well, I just finished designing the dumbest PCB I have ever made [00:15:20] lol [00:15:42] Dumbest? [00:16:09] https://i.imgur.com/U2hjM4q.png [00:16:17] no traces at all [00:16:41] just through-holes to be used as soldering points for putting together a cable that will plug nicely into the AGC test connector :D [00:17:19] the AGC used 0.125" spacing between its pins everywhere, which is remarkably non-standard and basically doesn't commercially exist [00:17:25] so unfortunately all cables and connectors are very DIY [00:18:27] Haha [00:18:29] simple [00:18:33] :P [00:20:21] Im trying to figure out if the no track light is considered a component light [00:27:49] Yep found a list finally [00:53:19] .tell AlexB_88 if you could make me some start and stop buttons that are red instead of white I can add them in as those are lit red [01:24:27] .tell indy91 so the water quantity is due to the tanks not being full, looks like the "100%" quantity measurement was adjusted after they were filled on the pad to compensate [01:38:17] .tell indy91 also those changes to the cabin repress do not work, the relay stays closed [12:53:27] morning [12:57:02] hey [12:57:24] yes, because you didn't do it like I told you, Ryan :D [12:58:01] I've started with the DOI day events for the Apollo 10 MCC [12:58:36] lots of new LM stuff coming up [13:00:04] oh nice [13:02:58] things are progressing quickly for Apollo 10 MCC [13:03:58] not that quickly, had to fix a lot of things along the way [13:04:02] map update for example [13:05:06] and I am not leaving any MCC update from the flight plan out [13:05:27] I skipped a few things for Apollo 8, like the map update [13:05:57] I'll have to go through 7 and 8 again for the MCC at some point [13:06:40] I guess once 10 is done, the 11 will be mostly a copy/paste? [13:07:17] a lot of it, yes [13:07:44] but they still updated a lot of procedures from 10 to 11 due to the flight experience [13:07:57] right [13:21:11] "start and stop buttons that are red"... does he mean they are backlit red? [13:22:05] they are indeed [13:22:23] but they would only be if the backlighting was on right? [13:22:27] yep [13:22:53] so just making it red might not be correct as when the power is off, it would still be red [13:24:26] maybe we could make a separate red over-lay and then control its opacity depending on the level of backlighting [13:26:18] or just a separate bitmap for each state of the button? [13:26:27] well, all in one bitmap [13:27:29] right [13:28:10] So I just have to look up which part of that button is red [13:52:42] I think I'll first only implement the nominal Apollo 10 MCC updates [13:53:11] there is no other mission for which I have as many information about alternative flight plans, aborts etc. as Apollo 10 [13:53:25] so there is a lot I could do [13:54:45] yeah makes sense [13:57:30] I had implemented some limited abort support with the Apollo 8 MCC [13:57:41] early TEIs, flyby and so on [14:00:27] I wonder if Apollo 10 TEI will have the issue with the high out-of-plane DV component I have been noticing on some missions [14:00:53] not the early ones at least [14:00:59] so far they were really small [14:01:01] Mostly the later missions, but I think even 11 had quite a bit more DVY then nominal [14:01:02] just like the real ones [14:01:34] but I will see how it is in 2 days [14:02:26] even the historical TEI-31 PAD has small DVYs [14:02:43] so, at least for Apollo 10, it looks good [14:03:12] great [14:04:22] for Apollo 11, not so much unfortunately. My TEI dvY was +1435.7, historical +681.8 [14:05:16] yeah, then I'll have to improve the TEI targeting [14:38:30] LVDC_T_LO, is that always set to the nominal launch time? [14:41:19] GMT time of nominal GRR [15:07:30] So I found a procedure to know what launch azimuth to input into V78 in the case of a delayed launch. Pretty easy actually: 1. Take a launch scenario, place its MJD to say the delayed launch time minus 60s, make MISSNTIME -60 and run the scenario until ignition. 2. Close the sim, open lvlog and note the new launch azimuth and then revert the changes you made in the scenario (MISSNTIME back to -14400 and set the MJD to the new [15:07:30] launch time minus 4 hours) [15:08:29] Of course only on missions with the full presettings (8,11,14) [15:08:58] and 17 [15:09:07] ah right [15:11:14] Theres a really handy tool I use "Orbiter Date Converter" [15:11:44] really easy to convert from GMT to MJD and vice-versa [15:12:31] the tool in the folder Utils? [15:12:55] I'm using that a lot [15:13:07] oh thats where I got it from lol [15:13:38] I had moved it out of that folder a while ago I guess and forgot it came from there...thought I had downloaded it or something [15:14:50] haha [15:18:23] So I created a very delayed Apollo 11 launch scenario of 17:46 GMT (8 minutes before the end of the launch window) [15:18:45] fun [15:18:47] Azimuth = 106.545471 [15:19:57] I'm certainly planning to make the MCC compatible with that [15:20:33] I had tested Apollo 8 with it and it looked like it had no problems with it already [15:20:47] Apollo 8 with a launch delay that is [15:21:01] yeah, I never tested it, but I was thinking about it when I implemented the MCC [15:21:09] The only issue would arise I guess if I were to delay to 2nd opportunity [15:21:40] yeah, that wasn't supported by default [15:21:53] what you could do though is the debug option "reset state" [15:22:09] after the LVDC has switched to the second opportunity [15:22:21] yeah I think that had worked when I did that [15:22:34] but I'll try to support the 2nd opportunity with that [15:22:38] without* [15:23:05] also maybe in the RTCC MFD, have an option to input a new launch time and then get a new launch azimuth from it [15:23:26] calculated from the LVDC parameters [15:23:57] that would just give you 72° for the unsupported missions for now, so should be safe [15:24:11] right [15:25:15] I guess at GRR, the LVDC uses the current time to caclualte the azimuth, so I guess a time in the future could be fed to it to get a predicted azimuth? [15:25:50] I'll just let the RTCC MFD do the same calculation as the LVDC [15:25:58] right makes sense [15:27:29] Good morning [15:27:39] hey [15:30:51] hey Ryan [15:31:17] I realized sometime after going to bed that I forgot a power condition with the comp light test [15:32:23] rcflyinghokie, I'll look into the start/stop switches soon [15:32:33] Awesome [15:32:37] rcflyinghokie, look on Github [15:32:46] No rush just something I thought about when looking at the wiring [15:32:50] Ok [15:35:42] Ok I missed the last line of where you asked them to go [15:36:01] I see that in rereading [15:37:02] yeah, it needs a check on the valve state [15:37:11] later guys! [15:37:13] or else the relay is always energized in auto state [15:37:27] Yeah I saw that behavior last night [15:38:37] and I am seeing some new lights in the LM! [15:38:47] doing Apollo 10 LM Activation right now [15:39:01] Yep! [15:40:09] glycol temp was high initially, but quickly normalized [15:40:25] I will fix this and test it then add the proper power condition to the comp light test, the way I have it (guess I was tired) was just based on the switch not if the breaker was powered haha [15:40:36] Yeah TLC left the glycol high for me as well [15:40:59] I think it is partially due to time accel [15:41:20] I get the same behavior in the lm atmosphere tanks as well [15:41:53] But the heat exchanger cooling cant/doesnt bring them down as fast [15:42:05] But they eventually come doen [15:42:06] down [15:42:58] Ok so that if statement goes below the last else if in the repress code [15:43:16] it just needs to be in the auto repress case [15:43:23] Ok [15:43:24] where you put it [15:43:34] just missing the if condition [15:43:46] Yeah I see that I totally misread [15:44:09] And the reverting to false is taken care of by the top of the timestep? [15:44:55] yes [15:45:19] that way you don't need to put the false in multiple places [15:46:18] Got it [15:49:47] Quick wiring question before going back to cabin warning logic [15:50:07] The contact light bulbs are powered by the atca breaker [15:50:23] As in the power for the bulbs themselves [15:50:33] Is that correct? [15:50:49] I think so [15:50:56] the logic for those is already implemented [15:51:01] Yeah it is [15:51:08] I am just verifying [15:51:11] in one of the control assemblies [15:51:58] Until we have a true lighting control assembly I am just putting the comp light conditions for the test switch with the lighting conditions themselves [15:52:20] power is not from the ATCA breaker [15:52:50] panel 1 light power is from the panel 11 eng cont CB [15:53:18] panel 3 light is from the panel 16 ATCA breaker [15:53:20] so that one is [15:53:28] Ah ok [15:53:38] but that is just for the actual contact [15:53:43] not during a light test [15:53:57] hmm [15:54:01] not sure [15:54:07] Me either [15:54:07] might be also its power source during a test [15:54:14] Thats what I was thinking [15:54:27] Let me look at the light test in the activation and see if those breakers are in at the time [15:54:45] If so then they probably get their power from those breakers for the test as well [15:55:08] I am on handbook pdf 48 if it helps [15:55:38] me too [15:55:51] I think the test switch just provides an alternative ground [15:55:56] no power source [15:56:10] Ok in the activation checklist those breakers are closed right before the lamp test [15:56:17] So that looks like the answer [15:56:43] yeah [15:56:50] which means the current logic is already correct [15:57:04] SCS_ENG_CONT_CB.IsPowered() && (scca3.GetContactLightLogic() || LampToneTestRotary.GetState() == 6) [15:57:15] Yep [15:57:42] Now here is where I am a little confused, do both comp ltg breakers have to be in [15:58:00] for what? [15:58:07] the comp lights [15:58:11] it looks like just panel 11 [15:58:55] Yeah just panel 11 powers those from what I can tell [16:00:04] both are going into the lighting control assembly [16:00:43] Yeah [16:00:50] I think we should have a separate class for that one [16:00:55] It will need it [16:01:10] But for now It appears the panel 11 breaker feeds the comp lights [16:01:20] through the controller [16:03:43] Ok that all works now for this cabin warning logic [16:05:17] didn't we already figure that one out? [16:06:02] except for the weird SC1 [16:07:02] Yeah you said something didn't look right though didn't you [16:07:36] it had no measurement ID [16:07:56] so I would say, let's keep it a direct signal [16:08:00] not through the SCEA [16:08:04] So it works right just not through the CERA [16:08:08] SCERA [16:08:10] Ok [16:08:18] Behavior in the sim is right [16:08:32] And I assume you saw my water quantity message [16:09:46] yeah [16:09:50] not sure how to solve that one [16:10:04] are we always using the same initial water quantity right now? [16:10:30] if yes, just adjust the 100% for the low level sensor [16:10:50] Well I filled it to one of the mission levels by default [16:11:02] But never thought about the sensors comparing to the actual tank max [16:11:15] So I just put them to max for the time being [16:11:37] I would say the solution is to change the fill for each missions and adjust the max as well [16:11:46] But for now, full tanks works [16:12:25] Last thing before asking you to review/merge, the seq light bulbs, what powers them? [16:12:26] I don't follow [16:12:32] It appears the same breaker [16:12:39] I'll explain better in a moment :P [16:13:00] at one point you made the water quanitity lower, because they never filled it to 100% anyway for a mission [16:13:43] Yes [16:13:56] And that quantity was made to be the new max quantity in the sensors [16:14:16] Even though it wasnt the tanks actual design capacity [16:14:43] So I could leave them all full for now, or adjust the nassp def to the 76% full max for the time being [16:15:10] Functionally it makes little difference at this point as that value varied mission to mission [16:16:11] so your plan is to increase the water quantity to 100% again? [16:16:48] Well that was my test to eliminate the light [16:17:11] See here is what I was unclear of: [16:17:14] is the value in nassp defs used for the gauge? [16:17:20] Yes [16:17:35] and would that show percent of max or percent of sensor adjusted 100%? [16:17:55] Thats what I do not know [16:18:28] I think % of max where the sensor for the c/w was adjusted, I recall some missions starting with 76% water on the gauge I believe [16:18:40] yeah [16:18:44] Yet the c/w light wasn't on to start [16:18:47] so that nassp defs value needs to stay as it is [16:18:55] And the c/w logic changed [16:19:07] and a different value needs to be used as the sensor 100% [16:19:59] the ED lights are powered by the same thing as the other component caution lights [16:20:57] Ok [16:21:03] Then I did that correctly [16:21:12] I will change this water logic now [16:21:35] Probably needs to be added to scera anyways [16:22:03] when the PR is commited, then you have a to stop for a moment [16:22:10] I want to move the CWEA into its own files [16:22:13] and a few other things [16:22:30] Sure [16:22:43] just to not cause any merge nightmares for either of us [16:23:04] Absolutely [16:23:30] Ok the scera uses that get quantity function right now [16:23:57] Hm [16:24:11] If I am reading this right the same scaling is used for the display and sc1 [16:24:47] lets see if that is what is used for c/w as well [16:25:06] Yep [16:26:11] can I merge? [16:26:33] Haha sorry, yes [16:26:56] Forgot to say I was done [16:36:15] "**INITIAL WATER LOADING MAY VARY BETWEEN 155 LBS AND 333 LBS FOR THE [16:36:15] DESCENT TANK, ANO BETWEEN 19.8 LBS AND 42.5 LBS FOR THE ASCENT TANKS. [16:36:16] WITHIN THESE LIMITS THE MEASURING DEVICE MAY BE ADJUSTED TO INDICATE 100%" [16:36:31] So maybe they did adjust to 100% [16:37:02] I am trying to find my reference for the 76% or so on the gauge [16:37:38] Unless the measuring device on the ascent tanks was adjusted not the descent tank [16:37:48] That would keep the c/w light off [16:42:51] hmm [16:42:56] I wanted to move something else [16:43:00] Hey guys [16:43:15] anyway, update pushed, including all the new MCC stuff [16:43:18] hey Thymo [16:43:42] What's up? [16:44:01] MCC and CWEA work, I guess [16:44:33] or lights in the LM in general [16:44:48] Yeah the comp lights [16:45:06] The battery and bus fault comp lights work on the test but otherwise we have no metrics to turn them on yet [16:56:19] Oh those yellow circle things? [16:57:52] Yes [16:58:03] aka component lighting [17:17:28] morning! [17:19:26] Hey there [17:25:25] what's up? [17:30:19] Working on switching cwea logic to use the scera instead of a direct function [17:34:24] SCEA = Signal-Conditioning Electronics Assembly [17:34:36] the SCEA needs to convert different types of signals [17:34:57] so it can have different "modules" that can be changed depending on the LM [17:35:09] these modules are combined in two SCERAs [17:35:16] so the SCEA has two SCERAs [17:35:35] SCERA = Signal Conditioning Electronic Replacable Assembly [17:36:10] each SCERA or ERA has up to 22 plug-in subassemblies [17:36:38] which can be of differing type, buffers for discrete inputs, AC voltage, DC voltage etc. [17:36:45] just as a general explanation :D [17:36:50] Interesting [17:36:56] I was thinking they were one in the same [17:37:00] nope [17:38:35] The more you know haha [17:38:43] or it's probably more precise to say, the two ERAs make up the SCEA [17:38:54] I don't think the SCEA has anything else [17:40:46] also, hey Mike :D [17:43:52] o/ [17:46:21] oh neat [17:46:40] that IBM SLCC programming manual and possibly other things is out for delivery [17:49:49] possibly other things? [17:50:08] Hi Mike [17:50:46] it was not entirely clear what all was in this repurposed binder from the listing lol [17:50:59] ah, right [18:19:06] so, one step I was trying to figure out with my Saturn countdown research is the switching on of the LV engine lights [18:19:18] at T-4 minutes 10 seconds [18:19:43] but I have still not really been able to find how that was done [18:19:55] from EDS schematics I know there there are inhibit relays [18:20:02] that there* [18:20:35] that time is before the terminal countdown, so I think it would have been done manually in the LCC [18:20:40] but I am still not sure [18:21:01] the code for that is just bad right now, so I was trying to improve it [18:22:23] howdy [18:22:37] I had a quick question, I'm running the Orbiter 2016 alpha [18:22:38] hello [18:23:25] I'm going through the Apollo 11 mission and I'm at T+1:49:00 and I haven't gotten my 'ready for uplink' message or my maneuver pad; the flight plan called for a state vector update at 1:40:00 [18:23:51] right [18:23:56] is there any way to know when the uplink will be ready? [18:24:17] the mission control feature that would be showing the PAD and doing the uplinks hasn't been implemented yet for Apollo 11 [18:24:29] I am actually working on it for Apollo 10 right now [18:24:32] ah [18:24:35] Apollo 11 will be fairly soon [18:24:37] what should I do [18:24:44] I guess the checklist already is ready for it, haha [18:25:02] you have to calculate the PAD and do the uplinks manually [18:25:05] with the RTCC MFD [18:25:52] where do I bring that page up [18:25:59] gotta confess I've never really used that before [18:26:04] no problem [18:26:59] there is a manual for it under Doc/Programmers Notes, but it's fairly outdated. It hasn't been updated since the NASSP 7.0 release and the MFD has changed a lot. [18:27:14] I can teach you how to do state vector uplinks though [18:27:30] those are on the MFD under Utility [18:28:48] and there, MOD button changes the time for the state vector, "Now" is fine [18:28:51] and to add, the checklists are ready for the MCC, sorry for the confusion [18:29:01] yeah [18:29:41] how do I pull up the utility section [18:29:58] you open the RTCC MFD first [18:30:05] yeah how do I do that lol [18:30:23] is that just the "Project Apollo" tab in the normal MFD? [18:31:56] first close Orbiter [18:32:02] RTCC might not be enabled in the launchpad [18:32:07] yep [18:32:19] in the Orbiter Launchpad under Modules [18:32:33] there should be a "ApolloRTCCMFD" entry [18:32:53] I already enabled that [18:33:28] ok [18:33:42] then it might be on the second page of MFDs [18:34:18] press SEL multiple times when you have the "MODE SELECT" page open [18:34:50] where you can choose which MFD to open [18:34:54] I have no arrived somehow at "MFD MENU" [18:34:57] *now [18:35:04] and there's an option for "State Vector Update" [18:35:08] is that it? [18:36:06] hmm, it doesn't say "update" on the RTCC MFD [18:36:14] do you have the Project Apollo MFD open? [18:37:01] there are 3 MFDs coming with NASSP. Project Apollo MFD, Checklist MFD, RTCC MFD [18:37:14] <_Uncooked> whoops my internet died [18:37:23] <_Uncooked> I clicked state vector update and it seems to have worked [18:37:57] which MFD though? The RTCC MFD or the Project Apollo MFD? [18:38:20] <_Uncooked> Project Apollo it looks like [18:38:57] yeah, that one can do state vector updates as well, because it existed before the RTCC MFD. But those state vectors are not quite correct for Apollo 10 and later [18:39:02] so it would be better to use the RTCC MFD [18:39:04] <_Uncooked> ah [18:39:11] <_Uncooked> how do I bring up the RTCC MFD then lol [18:39:22] when you have the PAMFD open, press SEL [18:39:31] there you should see the list of MFDs, right? [18:39:44] shows 12 for me [18:39:53] <_Uncooked> yeah [18:40:01] does it also say page 1? [18:40:05] <_Uncooked> it does [18:40:10] press SEL again [18:40:17] that should get you the second page of MFDs [18:40:19] <_Uncooked> aha [18:40:26] <_Uncooked> I'm in the RTCC MFD now [18:40:29] great [18:40:33] now Utility [18:40:43] and State Vector [18:40:53] <_Uncooked> aight [18:41:01] then press TGT once so that is says Columbia [18:41:13] because you want to uplink a state vector of that vessel [18:41:19] <_Uncooked> yeah [18:41:31] that should be all the settings, no press CLC [18:41:33] now* [18:42:01] did it update the numbers shown on that page? [18:42:06] <_Uncooked> is that supposed to start the uplink? [18:42:10] <_Uncooked> it did [18:42:20] CLC only calculates the state vector [18:42:27] UPL starts the uplink [18:42:30] <_Uncooked> ah [18:42:37] <_Uncooked> started the uplink [18:42:48] great [18:43:14] then you would also get three updates to write down, but two of them are for post-TLI aborts [18:43:17] so not really necessary [18:43:42] the last update is the TLI PAD, with relevant information for TLI [18:43:57] so click BCK a few times to go back to the main menu [18:44:01] where it said Utility [18:44:12] <_Uncooked> and then I hit PAD [18:44:15] <_Uncooked> ? [18:44:16] yep [18:44:22] then Maneuver PAD [18:44:38] and then OPT twice [18:44:51] to cycle through the different kinds of PADs for a maneuver [18:44:55] in this case, the TLI PAD [18:45:10] if you see TLI PAD, press CLC [18:45:27] <_Uncooked> got it [18:45:31] great [18:45:41] <_Uncooked> thanks! [18:45:42] what all those numbers mean is explained in the flight plan [18:45:49] <_Uncooked> yah [18:47:12] the RTCC MFD is not super user friendly, but it's a quite powerful tool [18:47:38] but with it you need to play mission control as well as astronaut [18:47:45] <_Uncooked> that's fine with me lol [18:47:50] great [18:47:52] <_Uncooked> it helps me understand it better [18:48:11] feel free to ask more questions about the MFD [18:48:25] whenever they may come up [18:48:40] <_Uncooked> sure [18:51:17] probably will happen once you want to do midcourse corrections :D [19:01:59] indy91 I think the unbalance equation in the cwea for the asc water tanks is incorrect [19:03:11] no idea who implemented that [19:03:19] could be wrong, sure [19:03:31] Haha ok [19:03:41] yeah they just took the absolute value of the tank difference [19:03:46] I think I fixed it [19:03:58] To a percentage difference calculation [19:04:48] <_Uncooked> the real question is can I turn *back* time [19:05:04] Only if you saved [19:05:06] <_Uncooked> cause I may have screwed up and missed my TB6 time by 9 seconds [19:05:40] _Uncooked, do you mean TB6 started 9 seconds late? [19:05:55] <_Uncooked> no I didn't start it [19:06:03] it starts on its own [19:06:10] <_Uncooked> TB6 was at 2:35:18 and I came out of timewarp at 2:35:27 [19:06:15] <_Uncooked> what about the DET [19:06:19] oh, I see [19:06:34] DET has to be manually started [19:06:44] what timewarp did you use? [19:07:00] <_Uncooked> 10x [19:07:05] that's fine [19:07:33] there currently is an issue that causes bad things when doing more than 50x before TLI [19:07:33] anyway [19:07:54] so your issue is that you started the DET a bit late? [19:08:09] <_Uncooked> I paused it right away but now I'm trying to find my quicksave lol [19:08:13] haha [19:08:21] you could try to sync the DET later on [19:08:25] <_Uncooked> hmm does it only save 4 quicksaves [19:08:57] nah, you can save unlimited numbers of quicksaves [19:09:07] Woo the equation works haha [19:09:51] <_Uncooked> hmm looks like I screwed up [19:10:18] Also indy91, did you make a typo on the des and asc h2o quantity scaling in the scea? [19:10:31] scale 0-1 [19:10:34] possible [19:10:38] Shouldnt it be 0-100 [19:10:42] <_Uncooked> my latest save was at 0:34:00 [19:10:44] percentage [19:10:45] <_Uncooked> rip [19:10:50] oh nooo [19:10:56] are you still paused? [19:11:13] <_Uncooked> I mean I have plenty of time now lol [19:11:17] you could just continue [19:11:23] <_Uncooked> yeah I'm just gonna continue [19:11:32] <_Uncooked> gives me the opportunity to not screw up some of the things I screwed up [19:12:21] There is a steep learning curve, so that happens often :) [19:12:23] rcflyinghokie, those don't return % [19:12:34] they return total/ max total [19:12:34] No? [19:12:40] so they will be range 0 to 1 [19:13:02] Should they return %? [19:13:19] The scale page from the handbook says 0-100 PCT [19:13:28] So those functions might need a *100 [19:14:13] that is just a definition thing [19:14:17] % is not a real unit [19:14:47] a bit like using degrees and radian [19:15:06] Interesting analogy [19:15:33] So I can keep it 0-1 [19:15:37] And adjust accordingly [19:15:42] ok [19:19:16] Slowly but surely these are getting SCEA data and not the direct function [19:19:58] I have to run out, hopefully I will have all the ECS stuff converted tonight [19:20:24] _Uncooked, have fun with Apollo 11! And welcome to the IRC channel [19:20:58] cya Ryan [19:33:09] <_Uncooked> thanks! [19:38:06] afternoon [19:38:21] hey [19:44:59] hey Alex [20:13:29] <_Uncooked> this isn't really related to NASSP but I figured you guys would know if anyone [20:13:42] <_Uncooked> the CM mission clock only goes up to 3 digits in the hours section [20:14:01] <_Uncooked> but missions with the Apollo CM went up into the thousands of hours (Skylab) [20:14:05] <_Uncooked> how'd they deal with that? [20:14:57] good question [20:15:11] the CSM was mostly powered down while docked to Skylab [20:15:24] so I am sure they used some new reference time as zero for the mission timer [20:15:47] all lunar missions only lasted up to 300 hours, so those are no problem [20:16:29] <_Uncooked> huh [20:24:54] they might have used GMT on deorbit day actually [20:30:18] indy91, I have been using the debug line to watch the issue with orbital guidance in TB5 [20:31:46] _Uncooked, I found a source. They defined the time of the deorbut maneuver as 20h PET, phase elabsed time [20:31:52] deorbit* [20:32:15] so from a completely powered down CSM they started activating systems on the day before deorbit [20:32:26] I guess at around 0h phase elapsed time [20:32:45] so their time reference was the deorbit maneuver [20:32:57] <_Uncooked> huh that's really cool [20:33:00] <_Uncooked> where'd you find it? [20:33:16] when in saturn takeover, you manually yaw right and the CMD goes from 0 to 359 and less. Then switch back to IU, the CMD yaw then counts back up to 360, but then instead of going to 0 and up, it counts up from 360, and on to 400 [20:33:47] http://www.jamesoberg.com/skylab_rendezvous_profile.pdf [20:33:49] PDF page 11 [20:34:07] AlexB_88, very interesting [20:34:28] must be a bug in the rate limiting function [20:34:40] which isn't right anyway [20:35:49] like its as if its trying to get back to 0, but doesnt understand that after 359, it should go to 0, and not continue above 360... [20:36:41] yeah, I'll have a look at that. Now I already know what specfically to look at [20:39:13] probably just needs a check if the angle is greater than 360° [20:39:23] and then set it to X-360° [20:42:32] I can probably fix that. Just that this part of the code is still not quite right and I'd just make code that is wrong anyway work better, but even more wrong. [20:47:29] nah, I think this is all too wrong. The fix might have to wait until the rate limiting is done properly [21:44:43] I'm still in the Earth SOI at T+31 minutes after the burn right