[17:53:45] NASSP Logging has been started by thewonderidiot [17:55:28] indy91, 433 km [17:55:58] read from the docking HUD [17:56:40] thanks! [17:57:03] tracking the ascent stage? [17:58:27] ah but its inconsistent [17:58:56] hmm [17:59:11] for some reason I tried the test again and the light, and just changing views away and back for a sec made it disappear at 415 km [17:59:22] can you post your line of code for this again? [17:59:32] sure [17:59:49] oh in my test I am using the Descent legs extended [18:00:01] ok, so size 7 [18:01:03] SetVisibilityLimit(1e-3, 5.4135e-4); [18:02:56] "If the vessel is to be visible beyond its geometric size (e.g. due to light beacons etc.) then the spotlimit value can be used to define the limiting distance due to the vessel's geometry, while vislimit defines the total visibility range including all enhancing factors such as beacons. " [18:03:06] isn't this sentence confusing spotlimit and vislimit? [18:04:44] "vislimit defines the total visibility range" shouldnt that be spotlight? [18:05:22] yeah I think it is [18:07:42] so yeah after 3 tests if I dont change views and stay in sextant, it disappears by itself at 433 km [18:10:25] changing views might change the FoV [18:10:42] yes [18:10:49] it goes back to 60 [18:11:15] but then goes back to 2 when you re-enter the sextant [18:11:18] does pressing z and x work for inboard views? [18:11:29] that might mess with it as well [18:11:53] so this is with the descent stage (size 7) and 5.4135e-4, right? [18:11:57] distance 433km [18:13:06] if I mess with X/Z in the sextant, the FOV pops back to 10 and yeah it disappears at that instant [18:13:21] yes [18:17:12] another thing I found, if you mess with the FOV, then it disappears and you cannot get it visible again even when switching back to sextant and FOV 2, unless you save and reload [18:17:30] but in all cases, its gone after 433 km [18:19:53] is there any parameter of the beacon that might influence this? [18:21:27] trackLight.falloff [18:22:26] hmm but I dont think that will change much [18:22:56] because its not just the light that is disappearing, but the vessl marker as well [18:23:20] falloff detemines how the render size of the beacon changes with distance. The value should be between 0 and 1, where 0 means that the apparent size of the beacon is proportional to 1/distance, and 1 means that the apparent size doesn't change at all with distance. The higher the value, the further away the beacon will remain visible. (but note that visibility is limited to the range defined by SetVisibilityLimit). [18:24:37] I think the vessel marker is only visible, if the vessel itself is deemed visible. And that might be influence by a beacon. [18:24:48] oh [18:24:51] maybe the behavior changes with that falloff parameter [18:24:57] guess it doesn't hurt to try [18:25:15] yes its making a difference [18:25:45] I set trackLight.falloff = 1.0 for testing and im past 433 km and its still showing [18:28:24] never mind actually it did disappear at 433km [18:28:50] for some stupid reason my mind read 423 as 433 [18:34:06] just don't confuse that with the DEDA [18:34:10] 423: DESIRED ALT RATE [18:34:17] 433: LM TOTAL VELOCITY [18:34:31] lol [18:36:47] Ill question myself about that next time I notice a 5000 fps descent rate :D [18:37:03] yeah, sounds unhealthy [18:38:16] ok, time to continue this rendezvous [18:38:58] for now I guess 433 km is not too bad to see the light [18:39:43] Ill get to work on the docking lights [18:40:52] yeah, I think 400NM is the maximum you would ever expect [18:42:10] 433km is 233 nm. Are there any CSM rescue situations that have you take sextant marks above 233 nm? [18:47:52] Apollo 7 starts at about 80NM [18:57:42] ugh [18:57:53] it is going to take a lot of self-control to not spend all of my time making a Block I hardware sim over the next year [19:00:34] haha [19:02:00] I really can't wait to see what the Block I circuits look like... and how similar it was to Block II [19:03:00] it's like having had Luminary 99 all this time, and then getting Aurora 12 and seeing for the first time what older versions looked like [19:03:12] all over again :D [19:04:48] yeah, even for me messing aroun with Aurora was fun [19:04:57] because so much was working in the LM cockpit [19:05:10] X-Pointers etc. [19:05:43] yeah I still really want to explore more of Aurora [19:05:53] I haven't used much outside of the LGC self-test [19:16:45] PGNS and RTCC agree within 0.2 ft/s about CSI, very nice [19:19:50] what I don't like is the CDH DV [19:20:05] AlexB_88, maybe the Lambert targeting offset is not working properly? [19:20:18] maybe it doesn't properly follow the shape of the orbit [19:20:42] I used 14.7NM for the DH, but the CDH DV suggests I'll be in a fairly elliptical orbit after CSI [19:21:57] hmm [19:22:04] I think CSI won't be at apolune [19:22:07] that would explain it [19:33:54] maybe I have to think about the insertion maneuver targeting a bit more [20:14:18] hmm I havent really used lambert targeting recently [20:14:30] but cant remember having issues with it [20:16:08] yeah, I am pretty sure it's ok after checking the code [20:25:41] hmm [20:26:06] I think this perilune at insertion is too low [20:29:45] although compared with the flight plan it's ok [20:40:18] I have a question on the vector 3 to define RGB colour [20:40:40] static VECTOR3 beaconCol = _V(1, 1, 1); so the 1 means 100% of 255, correct? [20:42:40] uhh, maybe? [20:43:10] I think so [20:51:50] ok 1st test of the docking lights [20:55:17] and they work [20:56:21] great [20:58:15] now I need to position them and tweak the parameters [21:04:18] night! [21:43:31] Had to throw in an extra rebooted. Mounted the fan the wrong way around. :p [21:43:46] nice [21:43:53] All is working again, fan speeds are also better regulated. [21:44:22] They used to stay idle even when temperatures went to 65C+ [21:53:49] dont want old Guenter to get too hot [21:56:17] brb [22:13:49] AlexB_88: On that vector. Usually it will either be scaled 0-255 or 0.0-1.0. [22:56:12] Thymo, thanks [10:43:02] hey indy [10:43:10] time for loi day [10:45:03] hey [10:52:13] not sure if you remember this but on my apollo 11 mission on windows 7 i couldn't even make it to loi 2 without a ctd [10:54:30] I'm sure it will work this time [10:54:37] unless you discover a new MCC bug, haha [11:02:54] i am fairly optimistic about this mission [11:15:09] and also i don't know if this is intentional but your mcc updates were a bit late [11:15:28] no, you are late [11:15:31] literally [11:15:41] what do you mean [11:15:44] haha [11:15:50] you'll arrive at the Moon later than in the flight plan [11:15:56] ah [11:16:13] and you should take a good look at the flight plan vs. your LOI TIG [11:16:28] because most of your lunar orbit activites will have the same time difference [11:16:40] the real Apollo 10 mission was about 12 minutes late throughout lunar orbit [11:16:49] on my current Apollo 10 flight it's about 15 minutes [11:16:52] its about 75:45 in the flight plan [11:17:16] you'll see when you get the LOI-1 Maneuver PAD [11:18:53] the MCC updates during translunar coast are all scheduled relative to TLI and LOI [11:19:05] so you are probably now in the phase where they are relative to LOI [11:19:13] they were on average 20 minutes late [11:19:13] and if LOI is late, MCC updates will be late [11:20:17] well i am 5 minutes to 74 hours so i am going to do loi [11:20:23] this is apollo 10 signing off [11:21:36] haha, I hope all goes well [12:41:45] i am burning loi 1 right now about 4 minutes to go [12:41:56] it's a long burn [12:42:20] 6 minutes and 21 seconds [13:04:28] hey [13:04:50] hey Alex [13:04:58] hi alex [13:05:23] @AlexB_88 snoopy and charlie brown are now in lunar orbit [13:06:32] and my Snoopy and Charlie Brown are getting quite close to each other again [13:06:36] good to hear [13:06:41] I decided to move the CSI TIG to apolune [13:07:13] much better results with the rendezvous. 14.5NM DH, PGNS and RTCC agreed within 0.2 ft/s about CSI, LM orbit was more circular than CSM orbit after CSI [13:07:20] CDH was 8.5 ft/s [13:07:25] approaching TPI now [13:09:02] in the rendezvous planning calculating the time between insertion and CSI actually gets adjusted so that CSI happens at apolune. But that is with the planned trajectory and is a bit off when using Lambert targeting for insertion [13:11:03] and I think this was done during the actual mission as well. The CSI time on the CSI PAD was 30 seconds different than on previous PADs. [13:12:14] interesting [13:12:45] dont forget to turn on the docking lights ;) [13:14:02] ah right [13:14:28] I actually wasn't able to see the tracking light until about 100NM [13:14:36] it seems that is quite random [13:15:15] hmm I hadn't really tested with the ascent stage [13:15:20] not the distance itself [13:15:28] but if you can see it or not [13:15:36] beyond the calculated distance it never appears [13:16:08] were you switching views back and forth from the sextant? [13:17:13] I think so [13:18:49] I only included the SetVisibilityLimit on my PR from last night, did you get that? [13:19:05] yes [13:19:14] or else I wouldn't see this very obvious light [13:20:50] my RCS is also getting quite low [13:20:56] 32% or so [13:21:58] I've been in attitude hold most of the time [13:22:08] and the LGC doesn't do that very efficiently [13:26:00] Kind of weird considering you dont even fly PDI on 10 [13:27:33] yeah, but 10 spends a long time coasting around with the descent stage [13:27:55] and due to the CoG issues, the DAP is not very good at controlling a heavy descent stage [13:29:26] so it might be because of that [13:31:06] right [13:45:47] MCC-1 is 0.3 ft/s [13:45:55] haha, I think that means it's skipped [13:47:34] bug report: MCC is too accurate [13:47:53] nah, all the PGNS [13:48:06] normally the crew only gets a CSI PAD [13:48:15] and only CDH or TPI PADs on request or so [13:48:27] maybe I should get in with all the fun and fly Apollo 10 [13:48:49] and find more bugs, yes [13:49:10] lotisully86 on the forum already found a bug [13:49:15] ill try my best [13:49:19] the LGC activation uplink string was too long [13:49:19] yeah I saw that [13:49:36] every DSKY key for the uplink is 3 chars [13:49:48] so there were more than 1024/3 keys in the string, haha [13:53:06] hey rcflyinghokie [13:53:13] Hey good morning [13:53:18] I have a lot of things for you :D [13:53:31] hey Ryan got the docking lights up [13:53:33] checklist, EPS, ECS [13:53:46] Nice Alex [13:53:50] And ok fire away [13:53:59] first, a small but significant checklist error. [13:54:01] Apollo 10 LM [13:54:05] rendezvous [13:54:52] line 129 [13:55:00] in the description it says V80E [13:55:07] but what it actually does is V81 [13:55:09] Ah i see it [13:55:11] I think V80 is correct [13:55:28] Yeah it is [13:55:42] I remember changing those from Apollo 9 which I believe used V81's [13:56:03] then a bunch of oberservations while doing this rendezvous [13:56:30] it would be good to add yellow comments on when to proceed in rendezvous programs [13:56:53] I think that is ET - 12 minutes for CSI/CDH/TPI [13:57:16] and 3 minutes for the MCCs. In the case of these that actually fixes the TIG in the AGC [13:57:24] ah wait [13:57:29] You mean for the final pass? [13:57:32] for the MCCs the time since TPI is relevant [13:57:34] yes, final pass [13:57:57] Sure I can do that [13:57:59] proceed at TPI+12 minutes for MCC-1, TPI+27 minutes for MCC-2 [13:58:08] and that should still be on the event timer anyway [13:59:16] then, a lot of times the checklist has the flight plans times for the rendezvous maneuvers as the inputs for P3X [13:59:52] Right [13:59:53] using the MCC and auto checklist I always had to skip these, because my maneuvers are all 12 minutes late [14:00:00] which is right [14:00:10] the fixed time is TPI, which depends on lighting conditions [14:00:17] I can change those to input the MCC times [14:00:38] it already has the flight plans times as a yellow text there [14:00:44] Yeah [14:00:56] those can stay, you could simply remove the part where it wants to input these on the DSKY [14:03:41] Sure [14:03:55] ok, next [14:03:57] ECS [14:04:03] suit and cabin are at 100°F [14:04:04] help [14:04:05] what do [14:05:42] I already have that [14:05:49] *that fixed [14:05:50] Locally [14:05:58] Its the suit fan [14:06:01] ah [14:06:06] I had to increade the heat exchangers [14:06:08] increase [14:06:10] and I use an old state of the ECS anyway [14:06:23] Oh [14:06:33] I launched quite a while ago [14:06:34] Did you use time acceleration? [14:06:39] For TLC [14:06:42] a bit [14:06:48] That seems to be the reason [14:06:54] i just have a question does the orb rate have to be exactly on the local horizon? [14:06:55] can't be [14:07:06] temp was good earlier [14:07:15] just was slowly increasing all the time during the rendezvous [14:07:20] Oh then yeah thats the suit fans [14:07:43] Without compensating witht he heat exchangers they really push the temp up [14:07:43] sounds like it [14:08:04] glycol temp seems ok [14:08:09] I think I have it stabilized locally I wanted to fly the LM for an extended period of time to make sure before comitting it [14:08:36] The temp is actually correct based on the ECS schematic though [14:08:46] At least the temp of the suit fan exhaust [14:08:52] ok [14:08:59] so it's getting fixed eventually [14:09:03] I think the heat exchanger cant keep up haha [14:09:04] Yeah [14:09:11] It should be in my next PR [14:09:13] i am getting it close but not exact [14:09:22] Just open a window for now ;) [14:09:36] ah, one more checklist thing. For the CSI burn they used the APS interconnect. So they opened those valves and closed the SOVs and only burned with APS propellant [14:09:45] astronauthen96__, no problem [14:10:00] it's only used as an orientation for the astronauts [14:10:04] Yes I omitted those in the LM because when you close the SOV the RCS didnt work before [14:10:05] doesn't have to be super precise [14:10:06] or do i even need to do the orb rate? [14:11:17] rcflyinghokie, that still seems to be a bit buggy. I had some red flags during the CSI burn. But it worked 95% of the burn, so quite strange. [14:11:35] astronauthen96__, if it's in the flight plan then it should be done. [14:11:41] Yeah i get red flags on lunar liftoff about half the time [14:11:45] what was your LOI TIG compared to the flight plan? [14:12:07] 75:59 and i think 12 seconds [14:12:26] so about 15 minutes late. [14:12:46] i am kind of confused about the flight plan delays [14:13:02] in that case I would suggest doing all the flight plan activites 15 minutes late as well. The crew got this suggestion during the actual mission as well. [14:13:05] when it asks to maneuver to an attitude should it do it at that time? [14:13:08] okay [14:14:19] rcflyinghokie, are glycol press/temps more stable now? seems like I can go 30x without it hitting the pressure switches like before [14:14:56] however at 30x I get a intermittent suit fan warning light (suit pressure fluctuates a bit) [14:15:03] I havent changed anything in glycol actually [14:15:06] Not in a while [14:15:20] Not since the big valve size change [14:15:25] right [14:15:42] Yeah my next extended project is to look at the oxygen and see if I can stabilize it a bit [14:16:09] Then I need to figure out how to make glycol pressure lower when pumps are off, its a static pressure in the system right now [14:16:35] indy91, the 10 rendezvous checklist has TPI+3 and TPI+18 for the MCC's [14:17:40] One thing I noticed was that I was testing LM activation right after LM ejection very early in the mission. Glycol was fluctuating a lot with 30x at that point. Now on my Apollo 12 lunar orbit scenario, at 100 hours or so, they are much more stable. I wonder if glycol press/quantity changes over the course of the mission [14:19:29] I guess what I am saying is maybe the erratic glycol behavior at 30 x was due to my very early LM activation and that it doesn't happen when you activate the LM at the normal time, in lunar orbit [14:19:40] TPI+3 and 18 for what? [14:21:39] AlexB_88 yeah the glycol has time to settle out into the tanks and flow evenly if you wait [14:21:49] indy91 for MCC1 and MCC2 on Apollo 10 [14:22:00] The TPM [14:24:40] oh [14:24:50] that's when P35 is started each time [14:24:53] that's not so important [14:25:05] the relevant time is when you press PRO on the 16 45 [14:25:18] that's done at TPI+12 and 27 [14:25:48] and with the padloaded 3 minute delay, TPM-1 is then at TPI+15 and TPM-2 at TPI+30 [14:26:57] Ah gotcha [14:27:58] And in this case, ENTER on the 16 45 I believe [14:28:46] No never mind it is pro [14:31:58] Was thinking a different part [14:32:09] yeah, the PRO on the 16 45 is what determines the TPM TIG [14:32:18] Right [14:32:55] Is all the APS interconnect stuff working properly? [14:33:43] well, as I said, I had some issues with it during CSI [14:33:55] so it is all implemented, but probably buggy [14:34:57] Where did you find that it was used for CSI [14:35:38] transcript [14:35:44] Ah [14:35:46] and mission report [14:35:58] I believe the rendezvous procedures document is not the complete checklist [14:36:05] Probably not no [14:36:08] it only has the relevant steps for the guidance systems [14:36:28] https://i.imgur.com/elgdhlC.png [14:36:45] So I am not entirely familiar with the RCS/APS and their connections [14:36:52] Ah Snoopy is back from his walk [14:38:00] indy91, any comments on the visuals aspect of the LM so far, the new textures, staging effects, lights, etc? [14:38:43] I like it [14:39:11] great, let me know if theres anything I can improve guys [14:40:16] track and docking lights all worked as advertised [14:41:28] Slap a landing radar on the descent stage? [14:41:32] :P [14:42:32] indy91, how does the APS interconnect work/ [14:42:32] ? [14:44:24] there are 8 valves, 4 in each system [14:44:43] and in each system there is a primary and a secondary valve for oxid and fuel each [14:45:08] the with the 4 switches on the panel you are always opening or closing oxid/fuel together [14:45:24] the talkbacks however show the combined state of the prim and sec valves [14:45:35] so they will be bp until you open both feed 1 and 2 [14:45:43] feed 1 and 2 are the primary and secondary valves [14:46:12] that's why the switches and the talkbacks can be confusing [14:46:22] Yeah I was wondering about that [14:46:41] That makes sense [14:46:48] but essentially, you open the interconnect and whichever system has the higher pressure (RCS or APS) supplies the propellant [14:46:59] if you close the SOV of the system the APS always should win [14:47:23] So you would open both A and B and close SOV for this CSI [14:47:41] yeah, I think they did that with both systems [14:47:57] so those 4 interconnect switches to open, the two SOVs to close [14:48:00] in that order :D [14:48:02] And that works? [14:48:17] apparently a bit buggy, but yes, it's fully implemented [14:48:30] even the tricky situation with all valves open [14:48:34] including crossfeed [14:48:40] it's checking the APS system pressure [14:48:57] so if the APS hasn't been pressurized yet, then the prop resource will stay the RCS supply [14:49:16] I think I'll have to do a CSI or ascent with a debug string though [14:49:23] something isn't working 100% there yet [14:49:28] hence the red flags [14:49:36] During the ascent the SOV's are opened and ASC feeds closed [14:49:41] oh [14:49:59] I thought they used APS propellant for that [14:50:20] Well here is the flow: [14:50:21] ah wait [14:50:24] DURING the ascent [14:50:26] Yes [14:50:33] with 200fps remaining [14:50:34] so normal config at 200fps before shutdown [14:51:27] yeah, there might still be a logic issue [14:51:40] For liftoff the SOVS are closed [14:51:43] during CSI I momentarily had a lack of propellant supply it seems [14:52:34] probably what happens to you as well during the ascent [14:52:57] Looks like it is happy with the SOV's closed now [14:53:03] I will change that for the 11 FP [14:53:08] I had to leave them open before [14:53:28] yeah, in general that should be working [14:53:37] oh, I forgot the EPS item I had. The descent battery talkbacks don't go barberpople at staging. [14:53:46] have to check where that signal comes from [14:54:33] ECA [14:54:35] Yeah [14:55:10] but through the SCEA [14:55:52] so I can add a stage condition to those measurements [14:56:21] should be easy, we already have a SCEA talkback class [14:56:32] Ok [14:56:54] Also, where was the switchover done for the APS interconnect for 10 [14:57:08] are all talkbacks in the LM going through SCEA? [14:57:26] I dont think they all are yet [14:57:35] Some stragglers likely [15:00:54] or I mean in the real LM? Are all talkbacks supposed to go through SCEA [15:01:24] many seem to be going through the SCEA, not sure about all [15:01:40] all the RCS ones on panel 2 are [15:02:40] none of the DPS ones go through the SCEA [15:03:04] ah ok [15:03:06] APS on the other hand, through the SCEA [15:03:15] APS helium regulators [15:03:25] indy91, do the Apollo 9 rendezvous times need to be treated the same way (removing the automatic inputs) [15:05:27] probably. TPI will be based on lighting [15:05:56] and if the orbit in the hours before is a bit different, then all the rendezvous times will be different as well [15:06:14] I'll compare flight plan and mission report [15:07:09] I'll still just make them the same as 10 where they can use the MCC values [15:07:15] That way there is no confusion [15:07:42] yeah, so a suggested time, but not the part where they are would be automatically inputted [15:08:53] flight plan TPI TIG: 98:00:15 [15:09:35] mission report: 97:57:59 [15:09:37] not bad [15:09:41] only 2 minutes off [15:09:47] Sounds good I will remove the auto inputs [15:12:17] so indy91, are you to shoot snoopy in solar orbit now? [15:12:27] that's the plan [15:13:38] have to add the calculation for that [15:16:38] impulsive TIG is at 180° longitude [15:16:49] and the attitude is 0,0,0 LVLH [15:18:58] sounds like not to hard a thing to calculate [15:19:20] yeah [15:19:29] rcflyinghokie, im working on the backlit start/stop buttons now [15:19:43] any pictures of them with the backlighting? [15:19:56] I can look [15:20:11] I haven't found any myself yet [15:21:10] The AOH has a description [15:21:17] page? [15:21:32] vol 1 pdf 557 [15:22:29] thanks [15:24:26] It looks like they are backlit with EL when not engaged [15:24:54] Which would be the same as the panels [15:25:09] And then the red comes on when pushed [15:28:50] EL? [15:34:54] electroluminescent [15:35:08] Same type as the panel backlighting [15:35:13] Which we dont have yet anyways [15:35:23] So they can stay as they are when off [15:35:34] And just need red backlighting when pushed/powered [15:38:44] hey again. so is it really necessary to follow the flight plan 15 minutes late? [15:44:39] So something like this? [15:44:40] https://www.dropbox.com/s/aj2q0c3rxe60bt6/Screenshot%202018-03-28%2011.43.59.png?dl=0 [15:45:11] That looks reasonable to me [15:45:22] astronauthen96__ not sure what you mean [15:45:40] indy91, what was the procedure to close the interconnects for 10, I found the part in the transcript [15:45:46] indy knows [15:47:23] Oh its during the burn [15:48:01] looks like 9 did the same so I have the procedure [15:49:46] astronauthen96__, roughly, yes. Just do all the steps in the flight plan, but 10-15 minutes later. [15:50:21] rcflyinghokie, both SOVs to open, all 4 ASC feed switches to close [15:50:23] will i have to do that with the rendezvous as well? [15:51:05] yes. But you will also get lots of Maneuver PADs with the updated times [15:51:23] and during the rendezvous you aren't looking much at the flight plan anyway [16:07:33] ok I have the bitmap ready [16:08:28] https://www.dropbox.com/s/89b9r73tduywj17/Screenshot%202018-03-28%2012.08.23.png?dl=0 [16:08:35] Thats from Apollo 9, bottom right [16:09:32] ah, ok. [16:09:35] so for the start/stop switches, I guess the plan is to have the bitmap we already have to be called when it is unpowered, and then have the new bitmap which is the same as the original (but with the pushed side red) display when it is powered [16:09:36] feed 1 is open at launch [16:09:43] so I guess it stays open [16:09:52] and only feed 2 valves are opened/closed [16:13:25] seems to be the same for ascent [16:13:36] so I guess you can use that procedure for Apollo 10 CSI as well [16:13:39] Ok [16:16:40] Just saw the docking lights [16:16:45] Very nice [16:17:23] We just will need them switched off via the LCA/CSM PWR latches [16:20:32] so I am adding the code right now to have the start/stop switches show correctly [16:21:34] I am thinking of making a second version of the switch (powered and unpowered) with the only difference being the bmp itself [16:22:46] sorry I mean the second version of the switch is powered and the current unchanged version is unpowered [16:24:07] and when I register the switch on the panel with oapiRegisterPanelArea, I can put a check to see if the switch is powered or not [16:24:58] hmm [16:25:08] I think it's better to do this in the code for the switch [16:28:25] overloading DoDrawSwitch function [16:28:47] are the buttons only lit when pushed in? [16:29:33] yeah [16:29:46] and bitmap-wise, just add the lit version on the same bitmap with the pushed in/not versions [16:29:55] ok [16:30:05] to the righ or to the left^ [16:30:22] right [16:30:28] ok [16:34:33] DoDrawSwitch, where do you find this? [16:35:43] the engine start and stop classes are derived classes from ToggleSwitch [16:35:55] they have no own DoDrawSwitch function, so they use the ToggleSwitch one [16:35:56] ToggleSwitch::DoDrawSwitch [16:36:27] so what we have to do is overload this function in the start/stop button classes [16:36:39] have you found the function? [16:36:54] it just has two states, "up" and "down" [16:37:21] yes, found it [16:37:22] in the "up" state it draws the left half of the bitmap [16:37:27] "down" state the right half [16:37:41] only difference is the "xOffset + width" [16:37:47] what you need is a 3rd state [16:37:55] which would simply use "xOffset + width + width" [16:38:14] right [16:38:45] so I overload it with the offset? [16:39:45] yeah, just add a "void DoDrawSwitch(SURFHANDLE DrawSurface)" function to the two classes [16:40:04] and in the code add a 3rd condition [16:40:09] so if/else if/else [16:40:39] the state "down" is "pushed in" for the buttons I think [16:41:04] so the logic is "IsDown() && Powered()" for the lit version [16:41:17] that will also need an added e_system to the class [16:41:28] hmm [16:41:40] or something like that [16:41:46] to determine if it has power or not [16:41:59] ok [16:42:26] Buttons are also lit in a lamp tone test [16:42:41] oh [16:42:48] ENG PB- C/W 2 [16:43:04] Lamp tone test rotary pos 3 [16:43:13] then in that case it would also light with the button out [16:43:23] Thats how I found out when it was lit to begin with [16:43:25] Yes [16:44:06] ok I will add that all to the same bmp as well [16:46:46] AlexB_88, you could also just give the button classes a LEM pointer [16:47:01] then you can use any logic with LEM systems you want to determine the lit state [16:47:12] ok [16:47:37] I will do that and maybe tie it to something simple for now [16:47:41] the the logic is basically: IsPowered() && (testswitch || IsDown()) [16:47:45] then let you guys re-wire it [16:47:54] ok [16:55:52] so the logic goes in the EngineStopButton::CheckMouseClick part? [16:56:51] no, in EngineStopButton:DoDrawSwitch [17:00:01] which you have to create [17:00:06] from ToggleSwitch::DoDrawSwitch [17:02:25] ok got it [17:03:53] morning! [17:09:43] hey mike [17:10:54] I am trying to get the LEM pointer in like it is done with abort stage switch without much success [17:12:05] what complains? [17:12:26] https://www.dropbox.com/s/sqv56mn3eayhuzy/Screenshot%202018-03-28%2013.12.02.png?dl=0 [17:12:47] says expected a ) after the LEM *1 [17:14:26] is that a 1 or a l [17:14:37] one or el [17:14:38] :D [17:16:00] ahhh lol [17:16:05] thanks [17:21:39] oh, hey Mike, didn't see you there [17:22:05] Luminary069 has done a good job getting me back to Charlie Brown [17:22:15] nice! [17:22:45] I guess missing the R2 lunar gravity model doesn't affect you much :P [17:22:58] next I'll send Snoopy hyperbolic [17:23:12] yeah, not supported by Orbiter [17:23:27] so the parameters are set to 0 in the padload [17:24:32] I think I loaded the parameters from the transcript [17:25:05] Hmm my O2 quantity FF wont reset when the switch is in reset [17:25:13] Maybe another nested if issue? [17:25:54] which parameters? [17:26:07] did they change the gravity parameters? [17:26:34] Sorry the burn dv's [17:26:50] oh, right [17:27:02] I read parameters and thought dv's/tig [17:27:17] gravity parameters from the transcript wouldn't work, though, because they changed out the whole gravity model for Luminary 69 Rev 2 :P [17:27:44] indy91, hows this for a start? [17:27:45] https://www.dropbox.com/s/b3rcpa0boe0e26b/Screenshot%202018-03-28%2013.27.22.png?dl=0 [17:27:45] yeah, but they still might have wanted to change the padloads for it... for whatever reason [17:28:01] sure, but we only have 69 so they wouldn't be applicable to use even if they did [17:28:10] right [17:28:19] testswitch isnt defined yet, so thats why its red [17:28:50] indy91 true, I just meant I never had a way to calculate it :P [17:28:54] hmm, we only need 3 conditions [17:29:19] rcflyinghokie, I'll just use the 4600 ft/s total DV from the transcript and the only calculation is ignition at 0° longitude [17:29:43] That should get it close [17:29:54] Its not like it has to be perfect [17:30:01] yeah, my mission is just 2-3 minutes off the real mission [17:30:06] and about 15 from the flight plan [17:30:21] indy91, you sure? now the bitmap has 4 settings [17:30:32] uhh [17:30:45] pushed in, pushed in lit, pushed out and...? [17:30:51] because we need to have the red come on in test [17:30:59] ah of course [17:31:00] and in test the button can be out [17:31:09] so the case of not pushed in, but lit exists [17:31:12] right [17:31:50] are you doing the 4 next to each other? [17:32:07] yeah [17:32:40] hmm, then your logic still needs some work [17:32:50] because for the first case it now checks both IsUp and isDown [17:33:59] I have a PR up with the ECS and checklist changes, but dont merge it yet, I want to fix this O2 caution FF first [17:34:04] I'd suggest adding the lit versions below the unlit bitmaps [17:34:24] because then you can simply use width and height [17:34:31] ok [17:34:32] and don't have to do width + width + width [17:35:10] how about this for logic, just: if (IsPowered() || testswitch) { [17:35:50] rcflyinghokie, might be the nested if [17:36:01] Yeah i am checking now [17:36:03] not good for FFs [17:36:15] And if that is the case I am going to change that in other FF conditions [17:36:36] actually disregard what I just put we still need the isDown [17:37:53] so the logic was good, but I just have to put the red buttons underneath and add an offset to the height in the 1st condition [17:38:09] in the 1st if/else that is [17:39:23] something like that, yeah [17:39:34] or height+height [17:39:53] First time here! Nice to be here [17:39:54] no, I think you just need width and height [17:39:57] and combinations of it [17:40:02] welcome Mikael_! [17:40:09] Thanks! [17:40:41] hey welcome! [17:41:56] So this is where the NASSP activity is these days. Nice! [17:43:10] yeah, it just naturally over time moved here, for the most part [17:43:23] just more efficient to talk to each other directly, haha [17:44:07] oh man I can imagine that the ECS and CWEA would have taken waaaaaaay longer without you guys talking in here [17:44:07] but of course that has left out the outside world a bit [17:45:00] is IsUp() the pushed-in state? [17:45:01] Hmm still no resetting FF [17:45:02] we do try to keep logging active, so you can read most of the chat history here: https://vanbeersweb.nl/irclogs/%23nassp/ [17:45:07] Time to debug [17:45:11] (at least, since we started logging) [17:45:11] Yes , that is probably the case when you are in the development. [17:46:35] AlexB_88, uhh, not sure right now, I might have confused it [17:48:09] IsUp() checks if the state is 1 [17:48:15] and I think pushed in is 1 [17:48:55] so the logic should be if (IsPowered() && (testswitch || IsUp())) { [17:49:58] for lit and pushed in [17:50:05] uhh [17:50:07] no [17:50:24] interesting, even when in CWEA Reset the FF will not reset [17:50:54] Oh its being held on by the cwea logic ok [17:50:55] rcflyinghokie, I think you need if/else if logic [17:51:02] the reset code is first [17:51:08] so it might be set to 0 [17:51:10] Then else ifs for the set [17:51:16] but then it checks if they should be set [17:51:21] which is probably still the case [17:52:01] best way to implement FFs is no nested ifs and if/else if logic. Trust me, I have lots of experience implementing latching relays :D [17:52:36] and you can also do if/else if for each of the 3 FFs [17:52:48] that takes more lines of code, but is more clear usually [17:55:43] AlexB_88, you could do an if on IsPowered() and that would then be the 2 out of 4 cases where the button is not lit, in any case [17:56:10] so the IsPowered() should in any case distinguish between the lit and unlit states [17:56:34] indy91 no problem [17:57:13] ok, let's see if I got these battery TBs through the SCEA right [17:57:40] lol, not at all [18:00:46] ah, much better [18:02:37] hmm, if these TBs go through the SCEA [18:02:47] then you probably can't see in which state the batteries are [18:02:58] before full LM activation I mean [18:03:01] so during TLC maybe [18:03:24] That sounds right [18:04:02] ah [18:04:15] the SIG CONDR CBs are closed for the initial LM check [18:04:21] so all good [18:06:04] done. that takes care of a full new SCEA subassembly [18:11:39] and I've of course taken care of the stage check on the descent ECAs [18:11:48] which was the whole reason I have changed this [18:12:03] Awesome [18:12:16] I have fixed all CWEA FF's to have if/else if logic [18:12:43] and does it fix the issue with them not resetting? [18:12:47] Yep [18:12:53] great [18:12:59] I have only tested the O2 case [18:13:05] But the behavior looks correct [18:13:17] I am going to test a few more before adding it to the PR [18:13:36] ok [18:16:11] I tried a few they are working [18:16:43] Some of the lightlogic still have nested if's but I dont think that is a problem [18:18:04] it can create issue, but it doesn't always [18:18:44] as long as the logic is clear to you, you can use as many nested ifs as you want, haha [18:20:18] Yeah the logic is very clear for those and follows more or less the cwea logic flow [18:23:57] Ok you should be albe to check the PR now [18:23:59] able* [18:26:01] I am experimenting with using the target temp at the evap out instead of the accumulator [18:26:15] That should lead to slightly higher glycol temps when all powered up [18:26:22] Which is normal [18:27:26] And the evap was controlled by heat load and a thickening/thinning layer of ice in the sublimator itself [18:27:32] So I think this is more realistic [18:27:42] if (lem->SCS_ATCA_CB.Voltage() < 24.0) { CESACWarnFF = 1; } [18:27:46] else if (lem->SCS_ATCA_CB.Voltage() < 24.0) { CESACWarnFF = 1; } [18:27:52] Ah [18:27:55] lol [18:27:58] Good catch that was right originally [18:28:01] nice else if [18:30:18] Those should be ok as they originally were right? [18:30:55] And not need an else if? [18:32:05] sure [18:32:26] when you have two ifs, then the order is important for which state is dominant [18:32:30] set or reset [18:32:44] with if/else if the if is always dominant over the "else if" of course [18:33:04] and with "if/else if" it also doesn't do a double check [18:33:15] so if the "if" was already true, it doesn't check the "else if" condition [18:33:46] So AGS shouldnt need the else if either [18:34:26] uhm [18:34:28] I am dumb [18:34:38] And RCS failure? [18:34:42] I thought you only added the else if line [18:34:45] indy91, I think I have it down for the start/stop switches [18:35:02] I thought you had the CESACWarnFF lines in there twice, once with if, once with else if [18:35:12] so, the PR as it is is good [18:35:14] I think [18:35:35] but you deleted the if (lem->SCS_ATCA_CB.Voltage() < 24.0) { CESACWarnFF = 1; } line [18:35:44] and added the else if (lem->SCS_ATCA_CB.Voltage() < 24.0) { CESACWarnFF = 1; } line [18:35:48] Github confused me [18:35:48] https://www.dropbox.com/s/dwzhd68pib95xpc/Screenshot%202018-03-28%2014.34.59.png?dl=0 [18:36:13] so disregard everything I said [18:36:23] else if is preferable [18:36:30] for the reasons I said above [18:36:33] so it looks all good [18:37:05] rcflyinghokie, any objections to merging the PR as it is? [18:37:26] Oh i thought you meant the else if was unnecessary [18:37:39] no, I thought you had this in your code [18:37:43] if (lem->SCS_ATCA_CB.Voltage() < 24.0) { CESACWarnFF = 1; } [18:37:44] else if (lem->SCS_ATCA_CB.Voltage() < 24.0) { CESACWarnFF = 1; } [18:37:47] Ohh [18:37:54] bout the first line was a deletion [18:37:56] I thought you meant that was unnecessary [18:37:57] but* [18:38:19] basically the opposite is the case. I prefer your else if verison [18:38:21] version [18:38:24] If they look right then all of those FF's use else if's with the reset being dominant [18:38:29] I just thought it was another copy&past error [18:38:38] Well I wouldn't put it past myself.... [18:38:53] you can't copy&paste and I can't read [18:38:55] a dream team [18:39:10] reset being dominant is right? [18:39:49] oh, I think I found at least one issue [18:39:55] debug line is not commented out [18:40:19] Ah [18:40:45] Reset should be dominant yes [18:41:14] I mean that makes sense otherwise things don't reset like my o2 case [18:41:35] And as soon as the reset condition is release they can set again if the condition persists [18:41:42] yep, sounds right [18:41:47] so just fix the debug line and I'll merge [18:41:51] There also is a mention somewhere about not leaving the cwea reset in cwea reset fo that reason [18:42:23] I am so glad that build with each push is gone [18:42:39] AlexB_88, looks good, just needs the test switch condition [18:42:50] Should be all set now [18:43:16] yeah I brought the initial if logic down just for testing [18:43:29] now it would be IsPowered() && (testswitch || IsDown()) [18:43:31] sorry [18:43:40] if (IsPowered() && (testswitch || IsUp())){ [18:44:10] merged [18:44:54] but I am having issues with those: IsPowered() does not seem to do anything [18:44:55] so in the IsPowered() case [18:45:07] well yeah, that was just an example [18:45:15] and test switch is obviously nothing, what can I put in its place? [18:45:21] right [18:45:47] the powered condition would be the CB [18:45:52] and for the test logic [18:45:57] in the IsPowered() case [18:46:12] if (IsUp() || test) [18:46:28] hmm [18:46:30] no [18:46:37] getting confused now [18:47:55] too much logic implementation at once, need to take a break from that for a bit, haha [18:48:18] haha [18:48:31] I can put something simple in the interim though [18:49:39] I cant seem to call anything into that line from anywhere, like I tried to wire it to the docking switch (lol) just for testing... but it cant access it [18:49:56] docking light switch* [18:50:28] needs to be a friend class [18:50:49] you can avoid that by giving the class the connect systems directly [18:50:56] like the lighting CB [18:51:29] but the slightly lazy way is giving it a LEM pointer, making it a friend class and just do with the lem pointer whatever you want [18:51:34] I've done that many times [18:51:42] right [18:52:05] im trying to figure out how to make it a friend class [18:53:44] the friend class list in LEM.h you mean? [18:54:04] yeah [18:54:32] What class are you trying to access functions from [18:54:35] friend class ClassName; [18:58:36] I am trying to just simply wire it to the docking lights for testing [18:58:52] friend class LEM_DockLights; is already in LM.h [18:59:28] so I tried using if LEM_DockLights.IsPowered() [18:59:58] but that doesnt seem to work, it gives a red line under the . and says expected a ) [19:02:16] Oh [19:02:22] lem-> [19:03:20] lem->DockLights.IsPowered() [19:03:47] Try that AlexB_88 [19:04:07] says member docklights is inaccessible [19:04:30] member LEM::DockLights is inaccessible [19:04:47] Where are you putting this? [19:04:56] EngineStopButton::DoDrawSwitch(SURFHANDLE DrawSurface) { [19:05:08] what file is that in [19:05:35] lemswitches? [19:05:38] yeah [19:07:00] the init needs a pointer tot he LM [19:07:02] to the* [19:07:29] it has one [19:07:34] actually I fixed this [19:08:01] I added a friend class EngineStopButton; itself [19:08:16] Ah yeah [19:08:40] start and stop need to be friends [19:09:38] rcflyinghokie, I have all the logic in for getting the switches to light up. Now can you tell me what is best to wire it up to to tell it it 1. It is powered and 2. The signal from the test switch [19:11:06] Let me see where it gets its power, but I assume its the dock/comp breakers [19:11:38] ok [19:11:49] Yeah it comes through the LCA [19:11:55] So for now we can use those breakers [19:12:25] (CDRDockCB->Voltage() > SP_MIN_DCVOLTAGE || LMPDockCB->Voltage() > SP_MIN_DCVOLTAGE) [19:12:36] That can be IsPowered() [19:12:44] ok thanks [19:12:53] Then to turn it on it will need to either be pressed, or the lamp test switch in CW2 [19:13:15] I assume there are different bmps for pressed and lit and not pressed and lit? [19:13:28] One thing with those breakers [19:13:30] I had pointers [19:13:52] yeah [19:13:54] You can add pointers to them or use lem-> [19:14:54] (lem->CDR_LTG_ANUN_DOCK_COMPNT_CB.Voltage() > SP_MIN_DCVOLTAGE || lem->LTG_ANUN_DOCK_COMPNT_CB.Voltage() > SP_MIN_DCVOLTAGE) [19:15:11] That should work without adding pointers to the class itself [19:16:08] So pressed and powered should draw the lit pressed bmmp [19:16:25] pressed and not powered should draw the original pressed bmp [19:17:00] And the lamp tone test and powered should draw them lit and not pressed or lit and pressed depending on, well, if they are pressed [19:17:15] That should cover all the possible conditions I think [19:17:54] yep thats all working like that now [19:18:02] Perfect [19:18:08] thanks your power thing is working btw [19:18:15] Great [19:18:30] just the testmeter left [19:19:11] Should that be witht he start stop buttons or in CWEA [19:19:30] with the, this keyboard is weird to get used to on my laptop haha [19:20:27] You can probably put it in the current classes you are working with if its easier, and just fix the comments in the CWEA [19:21:46] sorry I meant, the engine PB backlighting are also activated by the LAMP/TONE TEST in - ENG PB C/W 2 [19:22:26] Yeah you can do that in the current classes you are working on if it is easier [19:22:34] I will change the comments in the CWEA [19:22:52] ah ok I see [19:22:54] / ENG PB lights are lit in the EngineStopButton & EngineStartButton code [19:23:00] I will add that to the CWEA code [19:23:11] We do the same witht he comp lights [19:23:50] so I guess ill use lem->LampToneTestRotary.GetState() == 3 [19:24:12] Yep [19:24:43] ok I put in in the switch class [19:24:58] so I guess yeah the CWEA code comments can be updated [19:25:31] I have a small push with that [19:26:15] I am trying to figure out how the dock lights turn off when CSM power is applied [19:27:23] Also could you exit the visibility of the dock lights to a certain range like the track light? [19:27:28] edit not exit [19:28:29] thanks for your help indy91 and rcflyinghokie the PB are working as advertised :) [19:28:44] Nicely done [19:29:23] I can see what I can do for the docking lights range vis [19:30:31] rcflyinghokie, relays [19:30:36] Were you using stats from the lm 8 handbook or lm 10 aoh? [19:30:56] indy91, yeah I assumed that was the case I am just trying to find the connections [19:30:57] Systems Handbook page 47, L8 [19:31:04] Ah well thank you [19:31:14] Oh no [19:31:23] "from command module power through LO voltage taps" [19:31:24] That isnt the relay that turns them off with CSM pwr [19:31:35] Oh that relay [19:31:38] Wow I am blind [19:31:48] I was looking at it and not seeing it [19:32:02] I was the blind one, you just can't copy&paste. Already forgot? [19:32:15] Haha [19:32:30] Are those relays in your CSM pwr code? [19:32:37] good question [19:32:49] might be relays just for the purpose of turning off the lights [19:32:56] I'll check in the schematics relay list [19:33:02] Yeah it disconnects power from that breaker to the LCA [19:33:13] Which would also explain why we have lights on when entering the LM [19:33:23] They should be off because of that [19:34:23] as promised, the LCA will come soon [19:35:11] So those two relays kill power to the mated deploy relay which interrupts the breaker power to the LCA? [19:37:06] they are the indeed the same relays as used to enable CM power in general [19:37:12] -the [19:37:33] so, the way we have it implemented, cm_power_latch or however it is called [19:38:04] csm_power_latch [19:38:35] so there just has to be a check on that somewhere [19:46:05] PR sent for the start/stop switch backlighting [19:46:08] The check would interrupt power from the breaker to the LCA [19:46:48] And my PR just has comments in the CWEA :P [19:47:39] I think this is best saved to do through the LCA [19:47:50] Otherwise all lighting on that breaker would need that check [19:53:00] there probably will be a DC bus or something to get voltage and current output from the LCA [19:53:07] that's how I plan it [19:53:25] two PRs in the same minute [19:53:36] NASSP is really making quick progress :P [19:53:41] Haha [19:54:02] Sorry my PR is so big [19:54:18] both merged [19:54:29] and while I'm in the process... [19:55:35] my update is up [19:55:51] battery TBs through the SCEA, Apollo 10 MCC flown and tested through docking [19:56:20] let's see how BuildBot handles this :D [19:56:21] Nice [19:56:34] One at a time hopefully :P [19:56:54] be back in a bit [20:01:54] Guess its doing all 3 at the same time [20:04:04] it's a race! [20:21:46] Yours is last :P [20:22:26] haha, it's still working on it [20:23:35] Oh thats the one with everything all together [20:31:58] hello again [20:32:16] hey [20:32:28] just wondering what would happen if i flew the flight plan right on time, would it cause problems? [20:33:10] If it conflicts with MCC instructions it could [20:33:35] i was thinking of starting apollo 11 and doing 10 at the same time [20:33:54] Apollo 11 doesn't have MCC updates yet [20:34:03] i know i can use the rtcc [20:34:10] like i did last time [20:34:17] but without ctd's of course [20:34:35] well yes, it would cause issues [20:34:42] probably not too many big issues, but many small ones [20:35:11] when the flight plan says to be in a certain attitude by a certain time, then that will be too early [20:35:30] You know I always thought the abort/abort stage buttons lit when pressed [20:35:35] Thanks FTETTM [20:35:46] i guess i can set the det for 14 minutes when an event in the flight plan comes up [20:35:50] I guess they don't and just stay lit white [20:37:02] @rcflyinghokie are you talking about from the earth to the moon [20:37:11] Yeah [20:37:17] i have it on dvd [20:37:24] As you should! [20:37:44] is that apollo 14 abort thing simulated? [20:38:13] It is certainly simulate-able, but we arent at 14 yet :P [20:38:33] will that be for nassp 9 [20:38:36] There is a part where they press the abort buttons and they light red [20:38:43] But it looks like they actually do not [20:39:14] astronauthen96__, it rarely has to be super accurate. I like getting ahead of the flight plan a bit. And my Apollo 10 mission is about 15 minutes late as well. So I just am doing everything roughly 10 minutes late. [20:39:15] easy to do [20:39:47] so the entire lunar orbit period has to be late? [20:39:57] it will stay about the same, yes [20:40:03] I am at 107:00 right now [20:40:08] still everything 15 minutes late [20:40:23] should be easy if i use the det [20:41:48] ah, so you want to set the DET so that it counts the minutes in flight plan time? [20:41:50] so with a delay [20:42:09] when a flight plan item comes up i will set it for 10 minutes [20:42:29] or i guess i could just look at the GET [20:42:37] and add 10 minutes [20:42:47] yeah, flight plan times are rarely something you need to do on the second [20:42:57] only the times you get on PADs are super important [20:43:25] I've had no problems with just roughly adding 10 minutes to the GET [20:43:25] did you do the landmark tracking? [20:43:27] yes [20:43:52] Oh that reminds me was the marker file solution found? [20:44:02] that's a bit tricky [20:44:29] can be done in Orbiter 2016 even without markers though. I just looked where the sextant was pointing automatically and I just tracked the crater that was closest nearby [20:45:08] The Apollo 14 abort switch issue isn't simulated, but thanks to the Virtual AGC we can of course do the correct procedures [20:45:12] do you have to manually maneuver the spacecraft for the tracking? like in apollo 7 [20:45:14] I've even made a video about that [20:45:38] you will get landmark tracking PADs [20:45:52] and the times on there will tell you when to pitch down [20:46:08] do you have a scenario before landmark tracking? [20:46:12] so all you have to do is wait for that time, initiate a 0.3°/s pitch down maneuver manually and then go to the sextant and do the tracking [20:46:24] all while in P22 of course [20:46:26] I wonder if Alex is willing to make a utility lighting panel for the LM [20:46:36] with a bit of practice that is quite simple [20:47:23] so do you have one indy? [20:47:30] a what? [20:47:42] a before landmark tracking scenario? [20:47:48] uhh [20:48:28] yes, but I've been using a slightly outdated launch scenario. [20:48:34] LM ECS was outdated [20:48:52] and didn't you just do LOI-1 today? It's only a few hours until the landmark tracking [20:49:04] yeah i guess i could [20:49:51] .tell AlexB_88 think you could manage a utility lighting panel in the LM? https://www.hq.nasa.gov/alsj/a15/lm10-co19.jpg [20:51:20] Also indy91, any idea why some of the cb's are white? [20:51:21] https://www.hq.nasa.gov/alsj/a15/lm10-co14.jpg [20:51:38] in vs. out [20:51:45] i tried the apollo 11 vr at a friends house yesterday and were the panels backlit in real life? [20:51:59] Are you sure? [20:52:12] no [20:52:13] :D [20:52:40] Looks like most are out (closeout, afterall) and I cannot find an order to which are white and which are black [20:52:42] bit it makes sense [20:52:48] but [20:52:55] the white ones are pulled out [20:53:02] some testing config [20:53:07] not cabin closeout [20:53:18] ASC ECA CONT is out for example [20:53:24] pretty usual [20:53:33] GLYCOL PUMP SEC [20:53:46] all of STAB/CONT except ASA for the heaters [20:54:03] well im gonna leave you guys alone and do some more apollo 10 [20:54:07] have fun! [20:54:08] Have fun :) [20:54:13] i will [20:54:15] not sure it's the same in the CSM, but this could simply be done by a bitmap change [20:54:16] bye [20:54:22] Yeah probably stickers for testing that makes sense [20:54:29] And I was thinking it could as well [20:54:34] We have almost all the pieces for it [20:54:40] Just need to splice it together haha [20:55:00] stickers? [20:55:24] I was thinking this is what it looks like during flight as well [20:55:27] white and black [20:55:57] Oh [20:56:08] I was thinking they were stickers placed on the ends of the cb's [20:56:29] But I can see they are part of the cb itself [20:57:36] https://www.flickr.com/photos/projectapolloarchive/21475970170/in/album-72157656682617854/ [20:57:58] Wonder if this was for all LM's or just J missions [20:58:26] https://www.hq.nasa.gov/alsj/a12/LM6-co08.jpg [20:58:45] Looks like we have another bmp change :P [20:58:57] haha, yeah [20:59:16] I still am trying to figure out why some were white and some not, had to be some sort of flow [21:00:52] I am comparing it to cb diagrams [21:00:55] See if one matches [21:01:05] Some contingency ones are close [21:01:25] yeah, some displays, SCEA etc. online for ground testing [21:01:46] Also the signal str on the sband is up [21:02:17] back [21:03:37] https://www.hq.nasa.gov/alsj/a12/LM6-co25.jpg [21:03:58] Also that pic :) [21:07:18] Ill see what I can do [21:07:29] Looks like you can steal some stuff from the CM [21:08:00] im thinking not a whole new view for the sake of just 2 switches though, maybe integrate it in with the overhead window or AOT view? [21:10:00] Yeah it should not be its own,I was thinking the docking hatch, actually [21:11:11] ah right because its quite close to the docking hatch [21:11:31] Yeah its basically between the hatch and the AOT [21:11:33] night! [21:19:40] Looks like you can steal UTILITY from the CM [21:21:13] And "LIGHTS" as well haha [21:22:44] right [21:23:15] just noticed cycling through the LAMP/TONE test rotary, the ASC PRESS light illuminates [21:23:27] maybe thats intended [21:30:10] At what part? [21:30:47] It should light with CW1 [21:30:52] right [21:31:01] Along with the rest of that bank [21:31:30] yes [21:31:45] Hmm [21:31:46] the ASC PRESS light then stays latched [21:31:53] Somethings wrong with the tone test [21:32:02] until you open/close the CWEA cb [21:32:51] I think niklas did that wrong when he changed the cwea lighting [21:33:33] Or not [21:33:50] Let me check this patch [21:33:52] latch [21:34:29] Oh there is no latch [21:34:41] It should be lit if the aps is not pressurized [21:35:31] A least I am pretty sure [21:36:19] Unless that was a fixed value [21:36:23] In which case something is bad [21:38:14] well the A12 activation checklist says that light is on "trough the descent" whatever the heck that means [21:39:16] also another thing, when going LM PWR - CSM, the C/W PWR in the LM should go out [21:39:21] according to the checklist [21:39:23] Yes [21:39:35] That is the relay I was talking about earlier [21:39:39] ah [21:39:58] Instead of making that condition on every light, I am waiting for the LCA [21:40:18] yeah makes sense [21:40:19] Because the relay basically cuts power from the breaker to the LCA [21:40:42] Which would make all those lights as you enter off [21:40:51] is the LCA responsible for the ENG PB lights, too? [21:41:22] Yes [21:41:40] Basically all lights other than the tracking lights and the utility lights [21:41:51] The power for everything else runs through the LCA [21:41:52] so maybe some of the code I put in should be replaced with the LCA code I guess [21:41:56] Yes [21:41:59] And my code as well [21:42:15] I am honestly thinking Niklas should make the LCA it's own class [21:42:21] Or file rather [21:42:29] right [21:42:40] Or just a lm_lighting or something [21:42:42] I like how organised this is becoming [21:42:51] a file for all the separate subsystems [21:43:01] Then the TLE can be moved there along with the dock lights component lights etc [21:43:13] Yeah it makes it easier to find [21:43:21] And work on without breaking other things haha [21:43:33] yeah [21:43:38] I think the nested if was the cause of the ASC PRESS light [21:43:48] You can change it to if (lem->stage < 2 && (lem->GetAPSPropellant()->GetAscentHelium1PressPSI() < 2772.8 || lem->GetAPSPropellant()->GetAscentHelium2PressPSI() < 2773.0)) { [21:43:49] SetLight(1, 0, 1); [21:43:49] } [21:43:50] else [21:43:51] SetLight(1, 0, 0); [21:45:01] thanks [21:45:08] Its on my current repo as well [21:45:08] ill wait for a PR though [21:45:20] I need to check for other stuck lights [21:45:24] its not that important for me to get it now [21:46:09] Ohhh these eng pbs look so good! [21:46:18] haha thanks [21:47:46] No other lights seem to stick, but I might have to clean other nested if's if we see any other issues [21:50:57] so the ASC light should be on before ascent pressurization? [21:54:39] Based on the logic, no [21:54:53] Oh you mean in the real LM [21:55:04] well both [21:55:05] That I am unsure of [21:55:10] We have a static pressure [21:55:14] Its always 3020 [21:55:16] right [21:55:22] Even before pressurizing the APS [21:55:41] I am not sure if that helium pressure is normally that high or lower before pressurizing [21:55:57] I dont know the propellant workings as well as the ECS [21:57:16] They should have the high pressure [21:57:21] So the light should not be on [21:57:32] yeah that makes sense [21:59:29] I dont know why the 12 checklist has that [22:02:17] Even in TB verification it has the light out [22:04:02] Damn the 15 lm activation is missing that page [22:06:18] 14 isnt [22:06:36] and the light is not on, on the Apollo 14 activation check [22:07:07] and isnt our logic based on A14 LM? (LM-8) [22:07:31] so that may be the answer [22:08:25] Yeah [22:08:32] Thats what i was thinking [22:08:59] maybe there was some change from previous LM's in the CWEA [22:09:56] Well LM 1 uses fuel and ox pressure [22:10:03] Those are cut and capped on LM-6 [22:10:07] LM-8* [22:10:26] oh [22:10:27] So if LM-6 used that logic, then it would be on through descent [22:10:39] may very well be [22:10:39] At least I think [22:11:17] Also LM-1 used 3000 psi as the logic switch pressure [22:11:29] I guess we dont have anything between LM-1 and 8 to go by [22:11:31] LM 8 uses 2772.8 [22:11:44] Let me see whats in the excerpts in between [22:12:25] No CW [22:13:00] So probably different logic [22:13:14] I think it's safe to assume what we ave for LM-8 is correct [22:13:17] have* [22:13:31] yeah [22:13:38] I agree [22:15:47] man I'm happy we now have LM-8 and later documentation to go by... Don't know what you guys would have done if we only still had LM-1... [22:16:04] Man what a handicap that would have been [22:16:11] This handbook is just gold [22:17:28] ok might as well through some lights onto the SIVB now [22:17:34] throw* [22:18:51] and Ill do that utility panel in the coming days for sure [22:19:06] So where are the lights on the SIVB [22:19:24] sorry meant on the LM in the SIVB [22:19:35] Oh haha [22:19:42] Are there any on the SIVB? [22:19:49] dont know [22:19:57] I would think 7's SIVB had one [22:20:41] yeah [22:26:01] Ok time to get the tunnel vent and lm press valves working [22:26:38] Or sized right rather [22:51:21] 10 hours for LM Press through the LM PRESS valve [22:55:22] ouch [23:02:13] Takes a while to test even at 50x [23:22:25] and the SIVB is lit [23:23:30] so do I want to make the lights appear with the creation of the new SIVB stage right after CSM SEP, or wait until the SLA panels are ejected? (a few seconds later) [23:32:06] I keep saying SIVB but I mean LEM in the SIVB is lit [01:01:35] Sorry I was watching a movie with the girlfriend haha [01:01:42] While letting LM PRESS happen over 10 hours [01:01:57] Make them appear with the SLA panel ejection [01:02:04] Thats what hits the switch to turn them on [01:02:17] They are off while the SLA panels are attached [01:02:23] And with that goodnight! [12:23:10] morning [12:31:47] hey [12:32:03] Snoopy is doing a long burn right now [12:34:56] hmm [12:34:59] something isn't right [12:35:03] too much APS propellant [12:35:27] oh lol [12:35:47] oh no [12:35:55] it doesn't use the launch scenario masses [12:37:24] hard-coded? [12:37:58] they are already wrong in the very first scenario I saved, at T-20 minutes [12:38:05] maybe saving loading is broken [12:38:29] just the ASC, or DSC as well? [12:40:08] all the LM parameters [12:40:14] bummer [12:40:43] btw I added the docking lights to the SIVB project, so they display with the LM sitting in the SIVB [12:44:54] and I have a small question about that when you have a second [12:47:02] sure [12:48:22] I am trying to make the lights appear the instant the SLA panels are jettisoned from the SIVB, which is a few seconds after CSM SEP itself. I am curious about what I could use as a condition for the lights to activate at that point [12:49:12] probably the SLA animation state [12:49:49] and also I need them to disappear when the CSM+LM is jettisoned (disappear from the SIVB project) as the lights are now on the LM project (or there are 2 sets of lights if I dont do that) [12:50:14] panelProc [12:50:23] from 0 to 1 [12:50:34] so SLA animation state for the 1st, and the 2nd, maybe the ejection pyros? [12:51:17] use a check [12:51:21] PayloadType == PAYLOAD_LEM [12:51:31] that will be set to PAYLOAD_NONE or so when the LM is jettisoned [12:51:40] aah right [12:51:42] ok [12:51:46] Ill try those [12:51:47] and that check will also make sure only the LM has the docking light, not any other payload [12:52:24] right [12:52:37] so I can put the code in prestep? [12:52:53] all the other code seems to be there [12:53:34] yes [12:57:21] it doesn't even load the LM parameters from the scenario... [13:01:21] hey [13:01:41] i am starting a new mission [13:02:21] Indy91 well i am about to tli with apollo 11 i will talk to you guys later [13:03:07] good luck [13:03:22] AlexB_88, all Ryans fault, he used the wrong variable name in the launch scenario [13:03:32] LMASCFUEL vs. ASCFUEL [13:03:41] haha [13:04:15] hows this btw [13:04:17] if (panelProc == 1){ [13:04:17] for (int i = 0; i < 5; i++) dockingLights[i].active = true; [13:04:18] } [13:04:18] else if (PayloadType == PAYLOAD_LEM){ [13:04:19] for (int i = 0; i < 5; i++) dockingLights[i].active = false; [13:04:19] } [13:04:21] else { [13:04:23] for (int i = 0; i < 5; i++) dockingLights[i].active = false; [13:04:25] } [13:04:33] PayloadType == PAYLOAD_LEM should be NONE [13:06:46] wait I dont think that will work from looking it over again [13:07:16] if (panelProc == 0.1 && PayloadType == PAYLOAD_LEM) { on } else { off } [13:07:22] if (panelProc >= 0.1 && PayloadType == PAYLOAD_LEM) { on } else { off } [13:08:32] I was over thinking this [13:09:02] thanks ill put that in [13:10:02] I think the 0.1 condition should be right [13:10:23] the LM/SLA pressure switch probably opens already when the SLA is just deployed [13:10:30] and not fully [13:10:51] ok [13:11:34] or at least it doesn't have to check if the animation state is 1 [13:11:46] smaller number is sufficient [13:13:48] it worked [13:14:01] but with panelProc > 0.1 [13:14:28] sure, shouldn't make a difference to >= [13:14:41] oh I see on the 2nd line you had the >= :D [13:14:48] I had copied over the 1st line [13:14:56] ok Ill make it >= [13:14:58] yeah, that's why I posted it again [13:15:01] == is bad [13:15:29] yeah saw the lights in a very quick flash :D [13:15:44] haha [13:16:03] scenarios are fixed. Snoop went some place... much further than planned [13:16:21] explains some Maneuver PAD differences at least [13:16:33] 17 vs. 20 seconds for the insertion maneuver [13:17:19] ok, it's only half Ryans fault. Because the variable names he used are indeed used in the LEM. [13:17:32] but not in the Saturn, where it stores the LEM parameters until CSM sep [13:19:04] right [13:19:23] ok lights are working as advertised, ill make a PR shortly [13:19:41] great [13:19:53] as promised I've started work on the LCA [13:20:00] nice [13:20:13] I think all the elements are in place to be used by the LCA [13:20:43] im also slightly increasing the docking lights strength in my PR [13:23:29] PR sent [13:26:23] looks simple enough [13:26:28] merged [13:28:47] thanks [13:33:55] looks like AppVeyor is having trouble this morning [13:35:20] yeah [13:44:30] will the LCA be its own file? Like lm_lca.cpp [13:47:01] no, it's in the EPS file [13:47:24] in the schematics the lighting stuff is in the EPS category, so I've put it there as well [13:50:32] makes sense [13:51:45] Apollo 10 DOI day is done [13:52:02] next up landmark tracking day, but I don't think that is too difficult from a MCC perspective [13:52:25] I have to figure out how to calculate these photography PADs though [13:56:07] oh god, so much landmark tracking [13:56:16] no wonder they called it landmark tracking day [14:03:47] I need to add a check for my lights to not display when inside the LM [14:04:57] because when you open the LEM forward hatch, they are right in front of you, lol [14:10:56] hmm maybe a better way to do that is to just actually lower the view from the forward hatch to the correct height, below those lights [14:15:37] yeah [14:50:35] another PR sent, with the fix above [14:51:02] ok AppVeyor, this is your chance to shine [14:51:09] haha, was thinking the same [14:51:42] wow that was a fast merge [14:53:21] I was just looking at chat when you posted "another PR sent" [14:55:08] I guess it helps that it doesnt build at each PR too [14:55:58] yeah [14:56:06] previously I always waited for it to finish building [15:06:53] good job AppVeyor! [15:44:33] so is the Apollo 11 timeline book excerpts we now have, usable for Apollo 10^ [15:44:37] ? [15:57:28] back in a bit [16:11:46] Good afternoon [16:25:00] hey again [16:26:56] i might have an idea for nassp in the future [16:27:58] @indy91 the onboard heat flow experiment ttps://archive.org/download/as17-162-24063/as17-162-24063.jpg [16:28:14] https://archive.org/details/as17-162-24063 [16:29:56] AlexB_88, some of it may be usable, from undocking to DOI at least. Not sure about that LR flag change, after all Luminary 069 and 099 will be different in some ways. [16:30:02] hey Ryan [16:30:12] Hey [16:30:28] astronauthen96__, support for any special panels will come with about NASSP 10.0, for the J-Missions. [16:30:38] Tunnel vents in about 10 minutes, and LM PRESS takes a little over 10 hours now [16:30:44] rcflyinghokie, unfortunately you did a bad [16:30:47] Uhh [16:30:52] *hides* [16:30:57] you are only partially to blame [16:31:06] LM mass parameters in the launch scenario [16:31:18] you used the variable name as it is used in the LM [16:31:29] but the names are different when still saved in the Saturn class [16:32:08] I fixed it: https://github.com/dseagrav/NASSP/commit/f6a60018870e723eed5661de91eb664d0389060e [16:32:29] but unfortunately my Apollo 10 flight was completely with default masses [16:32:38] I only noticed during the APS burn to depletion [16:32:45] it just kept burning and burning :D [16:33:02] will my scenario need to be updated for that, i started a fresh launch last night [16:33:25] Haha I thought those were the variables you gave me to use [16:33:47] maybe I gave you the wrong ones, very possible [16:33:59] astronauthen96__, for Apollo 11 the difference is not so significant [16:34:26] i doesnt take long for my lem to pressurize [16:34:29] Yeah at the time I wouldn't have been able to come up with those on my own [16:36:22] in any case, my Snoopy is gone into solar orbit. Maybe with right masses next time I fly Apollo 10 :D [16:41:10] working on the LCA now [16:41:23] I already have code to generate the right output voltage [16:41:32] voltages I should say [16:41:36] there are a few outputs [16:43:28] Yeah there are haha [16:43:46] I'm thinking about how systems should use the LCA [16:43:58] we already have a bunch of different solutions for lighting [16:44:14] DSKY init has the CB and the rotational switch [16:44:27] which of course gets used in CSM and LM, so changing that is not so easy [16:44:47] I would honestly suggest all lighting systems we have be integrated into the LCA somehow so it isnt all over the place [16:44:56] Ah yeah that could be challenging [16:44:57] yeah [16:45:13] All other lighting save for utility lighting and the track light goes through it though [16:45:15] and a new class for lights, that has the right interface [16:45:27] for e.g. power drawing [16:45:50] but first I am just interest in getting voltage to lights in the best way [16:46:23] Yeah its basically the conduit between the lighting cb's and the lights in its most simple form [16:46:37] Even though it is far from simple [16:46:48] I have 4 output functions right now [16:46:53] GetAnnunVoltage() etc. [16:47:17] which return 0 if unpowered and otherwise a voltage depending on rotary and override switch [16:47:37] we only have on and off states for lights right now, but that might change at some point [16:47:48] and it's not difficult to calculate the right output voltage [16:48:06] for all the component lights this solution is already sufficient [16:48:13] the panel code just needs to call those functions [16:49:00] Right [16:49:29] Oh the MA is also not on the LCA :P [16:50:00] One less connection I suppose haha [16:50:01] morning! [16:50:13] hey [16:51:13] Also there are 2 LCA's it seems, not sure if it is one unit or two separate ones [16:51:21] I would think its all one [16:53:19] But the schematic has one unit specifically for the INTGL LTG control and the other on everything else [16:53:52] Oh flood lights also arent on the LCA [16:56:25] AOH only shows one LCA [16:56:47] so I bet it just was separated for the purposes of the Systems Handbook page [16:56:59] and actually it's one unit [16:59:11] Makes sense [16:59:30] I was honestly thinking all the lighting should be in its own file [16:59:39] Instead of scattered about [16:59:41] lots of nested ifs again with these component lights. I'm fixing it. [16:59:49] all in the EPS file [16:59:53] Great [17:16:13] I think, even though we dont have a "powered" coas, that I will add the power draw to it for more realism [17:18:06] And do the same with utility lights once we have a panel for it [17:19:25] ah, DSKY uses the ANNUN/NUM rotational switch, but not the LCA [17:19:45] so nothing has to be changed for it [17:20:38] at least for the brightness of the display [17:20:53] DSKY lights is gonig through the LCA [17:20:57] It just gets power from the LCA [17:21:09] The rheostat I mean [17:21:14] it gets power from the DSKY power supply [17:21:17] for the registers [17:21:35] Oh I see [17:21:40] DSKY lights is annunciator voltage from LCA [17:21:41] And just "borrows" the rheostat [17:22:25] and the push button lights are yet another power source, integral lighting [17:22:30] the DSKY's power supply has inputs for a potentiometer to control the brightness of the electroluminescents [17:22:47] yes, that is the ANUN/NUM rotational switch [17:22:50] in both CSM and LM [17:24:11] but the power is coming from the DSKY power supply [17:24:15] not the lighting power [17:24:16] yep [17:24:41] that's only true for the EL, though, the keyboard and caution/status lights are supplied externally [17:25:50] yeah, it's 3 separate power sources [17:28:25] are the caution lights and info lights on the alarm panel powered by separate sources or connected to the same thing? [17:28:35] they're on separate power nets internal to the DSKY [17:28:50] but I could very easily see them just tying those pins together [17:31:25] caution and info lights are all from the annunciator power source [17:31:57] keyboard is integral lighting [17:32:49] And they share the same rheostat? [17:33:48] looks like there are 3 different potentiometers [17:33:57] one for the DSKY EL [17:34:12] one for the CW DC dimming cirucit [17:34:31] which also supplies the DSKY caution and info lights [17:34:37] and DEDA OPR ERR light [17:34:52] and the 3rd is for the AC dimmer [17:35:07] DEDA numerics [17:35:26] timers, digital propulsion display etc. [17:44:45] I guess each light being on will generate its own power load, question is how to do the LCA heat load, just adding them up? [17:47:37] yeah, maybe the LCA needs to collect the power load from connected lights [17:48:10] for that a special light class is necessary and then it would use WireTo the LCA [17:50:16] is the LCA relevant for heat load in the grand scheme of things? [17:51:16] Yes [17:51:22] It is cooled by glycol [17:51:42] So I would consider that relevant [17:54:32] right [17:57:57] Potentially more than 50 heat watts just using the circuit breaker loads [18:10:56] one other system that needs to be implemented is the ascent engine arming assembly that was flown on Apollo 9 and 10. It would have been used for the burns to depletion. [18:11:11] for the easy remote control of them [18:11:53] does anyone know if the panels in the lem and csm were backlit in real life i tried the apollo 11 vr at a friends house yesterday and they were all backlit [18:12:54] You mean the lettering? [18:13:18] everything [18:13:24] indy91, all other LM's were deorbited with RCS, correct? [18:13:31] Well the lettering is lit [18:13:34] yeah, I think so [18:13:34] The displays are lit [18:13:57] There are utility and flood lights in the cabin to provide splash lighting [18:14:31] all the panels seem to have "EL patches" [18:14:53] controlled with the integral lighting [18:15:29] Yep [18:15:30] but I don't really know about fully backlit [18:16:39] No it isnt [18:17:39] Just the EL on the panel itself [18:19:36] astronauthen96__ there is a whole description of what is lit in the AOH [18:20:02] http://www.ibiblio.org/apollo/Documents/LMA790-3-LM10-ApolloOperationsHandbookLunarModuleLM10AndSubsequent-Volume1-SubsystemsData.pdf [18:20:16] pdf page 556 if you wish to see [18:25:32] back [18:39:36] Once the LCA is merged I will start adding the COAS and utility lights to the eps project file [18:40:27] I would like to learn how to change the rotational switches so they dont just choose the position you click [18:49:06] yeah that would be great [18:51:57] thewonderidiot, any good documentation on the Apollo uplink format? In the CMC for example there seems to be some code that determines if the uplink is for the CMC or a real-time command for e.g. the abort light. [18:52:34] I'm mostly interested in how the DUA in the LM decides that an uplink should be routed to the LGC or somewhere else [18:52:56] In the CSM for example* [18:53:35] 0 for TEST, 3 for CMC-UPDATE, 4 for CTE-UPDATE, 6 for RTC-COMMAND [18:53:40] no idea what that is based on [18:54:55] must be sent shortly after the vehicle code or so [18:55:07] which is 3 for LM and 4 for CSM I think [18:59:15] indy91, is changing the rotational switch easy? Right now it looks like it calculates best position based on click [18:59:46] probably not easy [19:00:20] it registers a switch position based on angle [19:00:40] so the class keeps track of the angle, which is useful for e.g. the ORDEAL altitude knob [19:01:16] But even the ordeal knob you have to scroll it to a position rather than just clicking [19:01:19] but what you are planning basically needs a commanded switch position vs. the actual one [19:01:47] Is there a better way? [19:03:33] I'm just saying that the "best position based on click" feature won't help you [19:04:09] the rotational switch would need to be in each state between where it was and where you clicked for at least one timestep [19:05:04] the simpler solution is to only allow it to change one position per click [19:05:32] That was what I wanted to do [19:06:33] only allow to change one position per click? [19:08:00] yeah, so that say for the glycol switch, if you want to go from INST to PUMP 2, you have to go through PUMP 1 [19:08:52] yeah, I know it's mostly for that, but I thought you both said you didn't like this solution for it. Only one position change per click. [19:10:24] indy91: I didn't know anything was ever uplinked to the CMC other than DSKY keycodes [19:11:31] no, not to the CMC [19:11:55] some option code for the uplink equipment that sends it either to the AGC or somewhere else [19:12:10] in the CMC there are some real-time commands the ground can send [19:12:14] switching antennas etc. [19:12:29] for the LGC we currently only have LGC or test there [19:12:53] but there was a decide receiving uplink commands on at least Apollo 5, 9 and 10 [19:12:56] device* [19:13:47] https://github.com/dseagrav/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_csm/csm_telecom.cpp#L4103 [19:13:52] this is what I am refering to [19:14:49] indy91 no haha I just was referring to the current way its set up and asking could it easily be changed to be one position per click [19:14:52] maybe at the point where an uplink reaches the AGC this has already been decoded, so you've never seen anything like it [19:15:20] rcflyinghokie, one position per click shouldn't be super difficult [19:15:27] hmm [19:15:28] although [19:15:38] you actually can register switch positions out of sequence [19:15:56] so you can register the switch positions and angles in a random order [19:16:03] that probably makes it more difficult [19:18:33] why not just base it off 3-pos toggle switch and just add more positions based on the amount needed [19:18:58] toggle switches only move 1 position per click [19:21:20] ah but then we would have to change all rotational switches to toggle switches and that would be quite a mess, maybe not then [19:21:31] or we implement a new class [19:21:50] of rotational switches that can only have discrete switch positions [19:24:23] That might be better, that way you can keep things like the high gain and s band or ordeal as they are for now [19:24:33] Those would eb annoying to multiple click for a position [19:24:36] *be [19:27:39] have to go, cya! [19:57:31] .tell indy91 sorry for the slow reply. I only know what gets routed to the AGC -- I don't think I've seen anything about the overall uplink format, but I've also never looked for it [20:21:11] I think the only thing the AGC gets is keycodes in INLINK. Any other uplink stuff is handled by other systems. [20:28:47] right, but it's the uplink format to that other system that Niklas was asking about [20:41:55] AlexB_88 I have some utility lighting code ready for you [20:42:01] Just need a panel ;) [21:07:44] sorry I was away [21:08:08] sure Ill see about doing that tonight/tomorrow [21:08:33] the LCA should be ready soon I guess? [21:09:37] I guess so Nik said he was getting through it [21:09:47] I have COAS and UTL lighting code [21:09:58] I dont know if we have a lit COAS bmp though [21:10:12] Its basically for power draw purposes [21:12:54] we have a COAS that is permanently lit I think [21:14:24] Yeah [21:46:34] Ok COAS switch will draw power now [21:46:38] So dont leave it on ;) [21:47:02] And once utility lighting has switches, they will easily draw power [22:02:55] Hmm why is it nullptr [22:05:12] Oh duh [22:05:18] No switches for it yet L:P [22:18:41] And now we have some floodlight controls [22:18:54] How is the hatch handled, is it a switch? [22:21:10] Ah this will work nicely: lem->OverheadHatch.IsOpen() [22:27:14] nice stuff [22:38:13] I guess I just have to figure out power draw through the rheostats [22:38:25] But those are the lighting components not in the LCA [22:40:24] .tell indy91 I have code for all the lighting not in the LCA locally, but I didn't want to PR it just in case it conflicts with the LCA, but I have power code for the utility, flood, and coas lights as well as heat they potentially release into the cabin [11:09:46] . [11:30:25] good morning indy [11:30:26] so about the joystick thing i simply exited orbiter and went back to the current state and the joystick thing went away and it also made my framerates go way up [11:32:02] hey [11:32:04] interesting [13:27:28] Good morning [13:28:27] hey Ryan [13:29:17] I see an LCA addition [13:29:22] affirmative [13:29:44] CW power light now goes on when switching to LM power, which is fun [13:29:54] Perfect [13:30:03] and the override switches now work [13:30:25] and, as before, all the displays are off, with the rotation switch in full dim [13:30:58] Very nice [13:30:58] but there is a different voltage for each step, so at one point we can actually support dimmable displays [13:31:13] Thats what I wanted to add to my flood lights as well [13:31:36] I just need to merge yours and mine haha [13:31:55] yeah, I saw your message [13:31:59] Time to fix conflicts yay [13:32:05] Shouldnt be bad though [13:32:14] by not doing a PR you took that job of fixing conflicts, haha [13:32:22] Yeah it's good practice [13:33:05] and I've flown the rest period on Apollo 10. Adding a lot of landmark tracking PADs now. [13:33:12] occasionally I checked Snoopy [13:33:19] it's now completely out of power [13:33:32] well [13:33:47] below 20V, but still a small current [13:34:05] I wonder what system that is [13:34:25] might actually be the inverter [13:34:30] works down to 10V [13:34:40] at least in our implementation right now [13:36:10] all the normal DC equipment will have gone offline at 20V [13:37:32] Right the minimum voltage def [13:40:37] yeah [13:40:47] most systems probably should have a different voltage for it [13:41:01] or else you get this weird behavior of everything switching on and off every other timestep [13:44:07] Yeah, the nasspdef is useful, but realistically each system as you said should have a voltage at which it stops or degrades etc [13:44:14] yeah [13:44:34] Ah those conflicts were easy [13:46:29] I also added a pointer to LCA heat in the LCA that we can use [13:47:08] yeah [13:47:42] that will be a whole different development step for the LCA, adding heat from the lights to it [13:48:09] I suppose it can be a function of power drawn [13:48:20] Well, it will be one [13:49:39] I am going to steal your get voltage for the flood light class I implemened [13:54:38] And I have code for the utility lights that is commented out until we have a panel for it [13:59:45] Were your voltages generic for now? [14:01:32] morning [14:01:59] Hey Alex [14:12:02] hey [14:12:08] rcflyinghokie, what do you mean generic? [14:12:19] How did you compute them [14:15:50] just trying out the LCA, 1st test was watching the LM POWER - CSM turn off the docking lights, nice! [14:17:07] Also turns off the CW light :) [14:17:42] yeah [14:19:53] so I notice ANUN/NUM dimmer dims the annunciator panel, does it dot dim the compartment lights as well? [14:20:46] rcflyinghokie, the rotational switch has 9 possible positions [14:20:49] 0 to 8 [14:20:56] and the Systems Handbook has the output voltages [14:21:10] oh I guess not, its not called ANUN/NUM/CMPT dimmer, lol [14:21:25] yeah, those get 5.5 VDC constant [14:21:43] the annun dimming is 2-5VDC [14:21:47] override is 5V [14:21:49] right [14:21:56] and that's how the voltages are computed [14:21:56] do the over rides work yet? [14:22:08] annun and num, yes [14:22:18] I guess the floods and utility get the full 28V [14:22:25] I think so, yes [14:22:38] I computed the power differences for the dimmers on the utility lights [14:22:47] AC for numerics has variable 20-110 VAC output [14:22:50] Thankfully the voltages are displayed on those resistors [14:22:58] integral is 15-75 VAC [14:23:13] yeah, and that's how the GetVoltage functions are calculating them [14:23:17] so I put the ANUN/NUM dimmer to dim then flip up the overrides? [14:23:26] yes, that will work [14:23:46] fully dimmed down probably didn't switch the displays off fully in the real LM [14:23:51] just get e.g. 2V then [14:24:05] but it was our previous implemention that they are off in fully dimmed [14:24:09] so I kept it that way [14:24:27] I implemented that by requiring 2.25V for the lights to be on [14:24:39] hmm so NUM switch seems to not do anything [14:25:11] Hmm I wonder what fully dim on the rheostats is in terms of voltage for floods [14:25:15] ah, I think that's not properly implemented yet with the displays [14:25:22] timers etc. [14:26:11] the problem is also that those classes are partially shared between CSM and LM [14:26:15] so I can't simply change it [14:26:24] and DSKY, or is the DSKY independent from that? [14:26:56] DSKY is controlled with the ANNUN/NUM knob, but has its own power supply [14:26:58] not the LCA [14:27:19] right [14:27:37] numeric override is implemented in the LCA, but just not used by anything right now [14:27:43] I need to step by step change those classes [14:52:17] indy91 can you see if what I have done with floods will work? [14:52:18] https://github.com/dseagrav/NASSP/compare/Orbiter2016...rcflyinghokie:Orbiter2016 [15:04:07] And I can uncomment the utility lighting when there are switches to connect [15:18:15] I just wish I knew how much power each lamp drew so I could make it draw more for all on versus just ovhd/fwd properly [15:19:45] I suppose I could make an estimate [15:33:24] And that is done [15:37:10] looks ok [15:37:31] I need to make some changes though I did a bad [15:37:44] As you so eloquently like to say [15:38:51] I think I've picked that up in an Apollo transcript [15:38:58] Really? [15:39:19] And the fix was minor I think I got it, let me test it and I will make a PR [15:41:43] maybe not, can't really remember [15:46:48] landmark tracking PADs are fun. [15:46:54] even more fun are 4 of them at once [15:46:57] every 2 hours [15:47:00] for a full day [15:47:10] happy landmark tracking day, Charlie Brown! [15:49:10] Haha [15:49:40] Oh Ryan cannot do math [15:49:50] 28+28 != 48 [15:50:05] No wonder the power draw is high [15:58:41] PR is up [15:58:50] Floods draw power [15:59:15] cya later [16:04:30] Guess it will merge later [16:04:39] I am hitting the road to Ohio for the weekend [16:05:30] I'll pop on when I can, I also might have a crude idea for floodlights and making them visible, and let me know when there is a utility panel (no rush the code is ready just commented out) [16:05:32] Later! [16:16:58] morning! [16:39:01] hey Mike [16:39:30] what's up? [16:41:45] nothing much, Niklas and Ryan are busy with LM lighting at the moment [16:42:12] and I think Niklas is drowning in landmark tracking pads as well [17:05:56] haha [18:13:12] I'm back [18:21:29] hey [18:21:53] Im doing some work on the CM MFD's [18:22:03] making them bigger basically [18:22:10] a bit bigger [18:22:25] so we can read your PADs :D [18:23:16] just wait until I can calculate the rest of the lunar entry PAD [18:23:25] haha [18:23:37] anyway I have made them the same size as they are in the LM [18:24:39] sounds good [18:27:43] so to get the 2 CM main panel MFD's bigger, I have to do the same for all the other 7(?) MFDs too in the CM [18:28:05] which is quite a hassle and honestly is any one still using the LEB MFDs? [18:28:16] I am thinking of taking them out [18:29:30] we only really need 2 MFD slots in the CM as of now in my opinion, unless there is another good reason im not seeing? [18:45:31] with the 4 MFDs in the LEB you used to do maneuver planning with IMFD [18:45:39] that often took 3 MFD slots [18:46:09] yeah [18:46:23] And do you propose taking out the LEB MFDs completely or just the 2 additional ones? [18:46:41] completely [18:46:45] because, the Checklist MFD is quite useful in the LEB [18:46:56] when you are working with the DSKY there and the sextant [18:46:58] ah right [18:47:04] so you don't have to scroll up to the main panel [18:47:32] how about I keep 2 [18:48:13] why do you want to remove them? not enough space for 4 MFDs there or...? [18:49:47] actually no, laziness :P. The thing is I want to make them bigger is what I am aiming, but from what I see if I want to make the 2 on the main panel bigger, I must make them all bigger. [18:50:09] so thats what Ill do make them all bigger, and keep them all [18:50:49] yeah, would be great if you can do that [18:51:55] having completed the 2 on the main panel, its quite easy really [18:52:36] also I did end up finding a small difference in the LM handling of MFDs vs. the CM's [18:53:27] the CM seems to have an extra checks in MousePanel_MFDButton [18:53:43] if (event & PANEL_MOUSE_LBDOWN) [18:54:22] thee LM does not have those checks, so I wonder if that could of lead to some CTD's [18:56:52] hmm, maybe [19:28:04] I have two of those weird CTD's in 2 days now [19:28:19] https://www.dropbox.com/s/qkoiw2cbl3l5eqo/Screenshot%202018-03-29%2018.03.25.png?dl=0 [19:28:29] And just now [19:28:30] https://www.dropbox.com/s/ml0k52jav09upj6/Screenshot%202018-03-30%2015.27.34.png?dl=0 [19:29:15] are you guys adding lights now? [19:30:32] More like turning them on [19:30:36] rcflyinghokie, and you get them when you load a scenario? [19:30:43] Yeah [19:30:55] I can usually load again and it loads fine [19:31:11] But those were yesterday and just now. on 2 different computers [19:31:27] same scenario? [19:31:33] should i download the latest build? [19:31:42] Yes [19:31:55] I never thought about the scn being an issue [19:31:59] yes to which question? [19:32:00] :D [19:32:08] Haha to both [19:32:25] well, my guess is that some system we recently implemented is doing scenario saving or loading wrong [19:32:36] so that scenario might have some clue [19:34:03] https://www.dropbox.com/s/xf364yrayn6vkws/LM%20ECS%20Testing.scn?dl=0 [19:34:11] thanks [19:35:23] It is missing a lot of LM stuff though [19:35:29] so outdated [19:35:45] That way it would more or less spawn a new LM each time so a save/load problem could be the case [19:37:16] maybe I changed something so that the saved state in that scenario is not corresponding to the loading code anymore. [19:37:20] but I have no clue what [19:37:25] could even be a fixed [19:37:28] a fix* [19:37:38] so it saved something wrong in the scenario [19:37:44] I'll check in the commit log [19:39:57] Hmm I have that no joystick found error again [19:40:54] Hello guys, when i use version 8 i can not regulate the O2 feed with the o2 direct button. Regardless of which setting, it gives full flow according to the O2 flow indicator. I also get an alarm for high flow. [19:40:55] Wasnt the cause of that mismatched orbiter config and orbiter settings [19:41:04] @rcflyinghokie with the joystick i just exit orbiter then go bavk to the current state and its gone [19:41:55] Mikael_ Yeah unfortunately that will happen right now. We changed the flow rates to the proper rates and since the CSM pluming is very "cheaty" in terms of O2, all settings give max flow on the gauge [19:42:15] That will be fixed at a later date though we are aware of it :) [19:43:08] astronauthen96__ unfortunately that does not solve the issue for me right now [19:43:26] seems like the joystick message is annoying enough and also harmless enough [19:43:30] so I'll comment it out [19:43:33] do you get it after lem creation [19:43:41] Yeah it is LM code [19:43:53] So you only get it when there is a LM [19:44:03] right after lem ejection [19:44:05] It sounds good. I thought you might not know the problem [19:44:21] CSM code has the same message [19:44:43] Ah I only get it with a LM [19:45:10] Mikael_, is the MCC uplink for LGC activation fixed for you? If you were the one asking... [19:46:04] hmm it was not me who asked. but I will check it out myself [19:46:17] ah, ok. [19:46:36] lotisully86 on the forum asked that. [19:47:08] and you joined here the first time when he asked how to join the channel, so I made that connection, haha [19:48:57] I have added power draw for the seq camera [19:49:10] Nothing major just another breaker that does something haha [19:50:01] It's not many times I've been to LM. Still working with Apollo 7. A lot to learn [19:50:24] there always is more to learn [19:50:40] Yeah I am learning more every day for certain [19:50:54] me too [19:51:47] indy91, I am going to add power draw for AOT lamps and heaters shortly, should the AOT just get it's own class in lm_eps? [19:52:20] already has a class of course [19:52:25] LMOptics in LEMcomputer [19:52:27] Oh haha [19:52:29] Duh [19:53:06] you'll enjoy the comments in LMOptics::SystemTimestep [19:54:15] Haha! [19:54:20] As if it was talking to me [20:13:55] Are the AOT Lamp breakers redundant? [20:14:40] They appear to be [20:20:29] yeah, I think so [20:20:39] no additional functionality on either CB [20:23:32] Ok [20:23:48] Now where are the heating elements [20:24:03] On the section in the cabin? [20:26:08] Or the entire assembly [20:26:53] Oh the mirrors [20:27:29] maybe the AOH has something on that [20:28:17] It does [20:30:14] So the aot heaters heat is probably radiated partially into the cabin but mostly into space [20:30:59] Actually the mirror is before the pressurized sealed section so maybe it does radiate into the cabin [20:36:43] AOT PR is up [20:38:19] lem->AOT_LAMP_ACA_CB.Voltage() > SP_MIN_ACVOLTAGE && lem->AOT_LAMP_ACB_CB.Voltage() > SP_MIN_ACVOLTAGE [20:38:24] so much for redundancy [20:38:26] && [20:38:37] lem->AOT_LAMP_ACA_CB.Voltage() > SP_MIN_ACVOLTAGE && lem->AOT_LAMP_ACB_CB.Voltage() < SP_MIN_ACVOLTAGE [20:38:40] both > and < ?? [20:39:11] Well I needed a way to split the power load between the two [20:39:20] If one is closed and the other not [20:39:23] Or both closed [20:39:28] oh [20:39:35] now I see what you did there, haha [20:39:45] Unless there is a cleaner way [20:41:18] well, a little bit [20:41:37] look at LEM_BusFeed::UpdateFlow in lm_eps [20:42:42] but you will need to define 3 variables for that method [20:42:53] Right [20:42:55] dc_source_a != NULL is a check you don't really have to do [20:43:15] but the advantage is that you won't have to use the 9.3 six times [20:43:24] that is considered cleaner [20:43:42] Haha [20:43:43] less of an error source if there is one place where the 9.3 is defined [20:43:55] Ok I will see if I can make that work [20:44:12] you will need int csrc, A_Volts and B_Volts [20:44:48] and for the heat, you can also make a simple check then [20:44:53] csrc > 0 [20:47:03] Should I just keep my lem-> pointers or define the breakers in the init [20:48:44] And should I make separate functions like you did in eps, or do this in systemtimestep [20:49:32] Probably better to do all of the above [20:51:25] use lem pointer because it's already there anywa [20:51:32] not a separate function necessary [20:52:38] Ok [20:53:41] hmm [20:53:50] there is even a much cleaner way [20:54:10] rarely used in the LM, because there rarely this type of redundancy [20:54:15] Fire away [20:54:30] although I first have to ask [20:54:35] is this just separate power [20:54:37] or separate lamsp [20:54:39] lamps [20:54:46] Oh good question [20:55:10] it's mostly a logical difference, not different implementation wise [20:55:20] but we have a powermerge class [20:55:25] PowerMerge [20:55:49] Looks like ten lamps and redundant power [20:56:08] so a power merge could make sense [20:56:15] do we have this in the systems handbook? [20:56:20] didn't find it [20:57:12] anyway, look at FlightBusFeeder in saturn.h and satsystems.cpp [20:57:24] Yeah I just used the description in the AOH [20:57:35] Ok [21:00:55] I think a power merge is just the right thing [21:01:47] Is the AEA redundant breakers doing something similar? [21:02:13] We actually have a few redundant breakers in the LM don [21:02:16] dont we [21:02:41] ECA breakers, AEA, AOT Lamps [21:03:16] AELD [21:03:43] ah, AELD is powering different relays [21:04:26] ECA CONT might be redundant [21:04:27] alright I have all the MFDs done in the CM [21:04:41] they are now the same size as the LM MFDs [21:07:56] AEA seems just redundant [21:08:34] Yeah AEA is [21:09:01] on the Apollo 17 descent power schematic some wiring goes from the DES ECA CONT breakers to ECAs 3 and 4 [21:09:23] so I would off on making those power mergers [21:09:34] They had different ECA wiring I believe than LM 8 [21:09:35] but AEA and AOT lamps would certainly be possible [21:09:51] Yeah AEA and AOT are safe to try that [21:10:01] I don't quite understand how to use it though [21:10:06] I see what it does [21:10:16] But as far as implementing... [21:10:27] you can just draw power from it [21:10:40] So make like AOTBusFeeder? [21:10:47] it's not really a bus [21:10:55] AOTLampFeeder maybe [21:11:17] in the LEM class [21:11:23] wire it correctl in lemsystems [21:11:32] and then either give the LMOptics a pointer to it [21:11:36] Ok [21:11:46] or just use lem->feeder [21:15:18] Use my same 3 conditions still? [21:16:24] indy91, I will make a PR. I also added the additional checks (if (event & PANEL_MOUSE_LBDOWN)) to LEM::MousePanel_MFDButton, to make it like the CM code [21:17:04] rcflyinghokie, no, not at all [21:17:12] that is done in the PowerMerge class already [21:17:22] Yeah, will the breaker being out automatically stop power draw from it? [21:17:22] since the code looks safer with that check [21:17:40] AlexB_88, sounds good [21:17:46] ok [21:17:56] rcflyinghokie, you should check the voltage on the power merger [21:18:04] and if it is there, draw power [21:18:11] same condition for the heat I guess [21:18:29] I see [21:19:03] Got it [21:21:04] PR sent [21:22:22] And might be a silly question, but power merger can handle AC as well as DC correct? [21:23:36] not too silly, no [21:23:39] I'll check [21:24:53] AOT Lamps are AC [21:25:07] SO just being cautious [21:25:20] yeah [21:26:39] should be good [21:27:18] Hmm what did I miss [21:27:31] No appropriate default constructor available [21:28:01] And no default constructor exists for class PowerMerge [21:29:26] ah [21:29:36] the PowerMerge constructor has parameters [21:29:46] that need to be initialized in the LEM constructor [21:29:59] look at FlightBusFeeder again [21:30:03] this time in saturn.cpp [21:30:44] there is such a section in the LEM constuctor as well [21:30:56] needs a line for the new PowerMerge [21:31:05] FlightBusFeeder("Flight-Bus-Feeder",Panelsdk) [21:32:37] I have this in my lem.cpp [21:32:38] AOTLampFeeder("AOT-Lamp-Feeder", Panelsdk) [21:34:28] should be good [21:34:58] I had that when I had the error [21:36:09] Haha wow [21:36:15] forgot the comma after the line above it [21:36:24] Thats why it gave me the error [21:38:10] How does that look [21:39:55] looks good [21:40:06] Much cleaner [21:40:09] Good idea [21:40:17] merged and merged [21:42:24] I will take a look at the AEA and see how it is done now [21:44:15] Looks like it does its own wire to busses [21:45:30] ah [21:45:35] So it takes care of the power splitting I believe internally [21:45:43] looks like the AEA has an internal PowerMerge already [21:45:49] Yeah [21:45:51] DCPower [21:46:30] Thats what we used to draw power so it should be good [21:47:24] yeah, no need for any change there [21:50:14] Now for window heaters [21:56:46] night! [22:03:45] Ok window heaters draw power now [22:03:50] Dont leave them in ;) [22:16:04] haha yeah [22:24:06] What other systems need heat/power draw [22:26:16] Also does the reticle dimmer move on the AOT? [22:28:16] Looks like we need a little switch there [22:39:08] yeah [22:39:47] I should be able to incorporate a switch there into power draw for the AOT lamps [22:40:46] I think the dimmer on the reticle is ok for now being static, as I dont see how we can make a proper dimming reticle for now [22:40:58] Yeah agreed [22:40:59] maybe something that can wait for the 3d cockpit [22:41:22] When there is something that can visibly dim its worth it [22:41:50] But at least it draws power now [22:41:59] great [22:42:16] Now its potentially a problem to have incorrect breakers in [22:42:28] I think every breaker has a function now [22:45:07] I think this weekend I am going to start getting power draw and heat through the LCA [22:45:31] Bulb by bulb [22:55:32] So what was up with the MFDs? [22:56:14] theyre a bit bigger now [22:56:23] in the CM [22:56:32] now they are the same size as in the LM [22:57:04] so its easier to read things like maneuver PADs in RTCC MFD [22:57:55] Oh ok [22:58:03] I guess i never noticed [22:58:23] Though thinking about it the lm was bigger wasnt it? [22:58:26] yeah its not much bigger, just a little [22:58:43] Good idea [22:59:09] I made them the same as the LM [23:00:40] I cant reiterate enough how awesome the dock lights look btw [23:05:53] thanks [23:06:17] just bugs me I cant get that tracking light to display at the correct range [23:06:32] Orbiter limitations? [23:07:26] I hope not [23:08:37] Whats the max range right now? [23:11:00] its not consistent actually, Ive seen it work up to 215 NM [23:11:08] sometimes not even 100 NM [23:11:20] maybe an orbiter bug? [23:11:30] anyways ill be back in a bit [23:11:56] Ah i havent tried it yet [09:35:21] hello [09:35:42] just having problems with the attitude for mcc2 [09:35:49] hey [09:35:53] which mission [09:35:56] 11 [09:36:11] the p40 gives me an entirely different attitude [09:36:18] than the RTCC MFD? [09:36:22] yes [09:36:45] in the rtcc the attitudes are very close to all zeros [09:36:47] on the Maneuver PAD page, what does it say there under REFSMMAT? [09:36:57] launch i think [09:38:12] did you uplink a PTC REFSMMAT with the MFD? [09:38:18] yes [09:38:22] ah, that explains it [09:38:32] on day one [09:38:41] so, the RTCC MFD only saves its state if you have it open when you close Orbiter [09:39:14] the RTCC MFD usually saves the REFSMMAT, but not when it was closed [09:39:19] that's an Orbiter limitation [09:39:39] which probably can be circumvented [09:39:41] but anyway [09:39:57] you need to sync the MFD and the AGC with the state of their REFSMMATs [09:40:07] you do that by going to the REFSMMAT page of the MFD [09:40:37] then you cycle through the options with OPT until you see PTC [09:40:46] and then you press the DWN button [09:40:53] that downlinks the REFSMMAT in the AGC to the MFD [09:41:20] and having the option PTC open at the same time only changes the display on the Maneuver PAD page, which should then say REFSMMAT: PTC again [09:41:42] is that all i do? [09:41:58] then you have the current REFSMMAT in the AGC again. [09:42:04] Then recalculate the Maneuver PAD [09:42:18] and it should give the same attitude at P40 then [09:42:24] and i noticed the mfds are bigger [09:42:29] yeah, Alex changed that [09:42:36] same size as in the LM now [09:42:48] easier to read the rtcc mfd now [09:43:00] yeah, I think that was the main purpose of that change [09:43:15] the Maneuver PAD and Lunar Entry PAD are quite extensive for one MFD page :D [09:44:08] well i am going to try it again now [09:44:21] and by the way my dv was 26.0 [09:44:45] sounds good. And if the Maneuver PAD page ever shows REFSMMAT: Launch again, you now know what to do [09:44:56] downlink [09:45:01] at least on this Apollo 11 mission you will never have the Launch REFSMMAT again [09:45:05] yeah, downlink [09:45:09] 26 ft/s sounds good [09:45:20] for Apollo 11 we actually have the real targeting data for TLI [09:45:48] so for that mission it should be an especially precise TLI [09:45:53] Apollo 8, 11 and 14 [09:46:01] for those missions we have that data [09:47:26] real mission had 20.9 ft/s [10:53:22] so, the attitude in the maneuver pad put me in gimbal lock [11:01:27] @indy91 would mind taking a quick look at my scenario? [11:02:35] https://www.dropbox.com/s/o2ut8dp4ifau8ra/BEFORE%20MCC2.scn?dl=0 [11:11:13] sure [11:14:58] yeah, 77° yaw [11:15:30] maybe the PTC REFSMMAT isn't 100% correct [11:15:53] but even if it is, it's possible that your MCC-2 simply isn't compatible with the PTC REFSMMAT [11:17:22] the normal procedure is to use a onboard calculated (P52 option 1) REFSMMAT for the burn [11:17:33] one that gives you 0/0/0 for your burn angles [11:17:52] and then after the burn you would switch to using the PTC REFSMMAT again [11:20:12] the procedure to get that REFSMMAT is: calculate burn, go through P30, start P40 but just the first display of it. Immediately do a V37E 00E [11:20:20] then P52 option 1, torquing option [11:20:27] no need to do a realignment [11:20:40] so just do an ENTR on the first option code 00014 [11:24:32] okay i will try that [11:24:52] and what about that p30 refsmmat? [11:26:58] yes, that basically is a P30 REFSMMAT [11:27:13] you can alternatively just uplink a P30 REFSMMAT for the burn [11:27:21] will be identical to the onboard calculated one [11:27:31] might be the easier solution for you to just uplink it [11:27:43] would i have to do a realignment [11:27:57] P52 option 1, torque option [11:28:10] with the torque option it sends you to the 00014 display first in P52 [11:28:29] and when you press ENTR there, it will just skip the realignment part of P52 [11:28:40] so it will just have changed the REFSMMAT, nothing else [11:28:53] i ill try that [11:28:58] ok [11:29:01] will* [13:01:06] Good morning [13:03:16] hey Ryan [13:04:08] Lost internet yesterday but I have a PR with the window heaters [13:04:18] More consequences for incorrect breaker configurations :) [13:05:10] looks simple enough [13:05:41] Yeah no switches just breakers [13:06:01] Found it interesting the fwd windows were AC and the dock window was DC [13:06:37] Now I knew all of this based on the breakers and the panel, but I never really internalized it [13:11:27] I guess we have most CBs implemented now in some way [13:12:21] I think they all are in some way now [13:13:12] I am wondering about that joystick message in the LM, could it be from old scns that were saved on a computer with a joystick? [13:13:31] Because I do my LM ejection scn for example, no message until I create the LM [13:14:15] no idea really. I commented the messages out now [13:14:19] in a local commit [13:14:33] will be pushed shortly [13:14:39] I also did a small CWEA change [13:15:04] Yeah I can do that as well, but I wanted to make sure that I didnt have anything wrong with my orbiter configuration or any conflicts since this is just migrated from my desktop [13:15:07] the guidance control switch is used to inhibit the LGC and ISS warnings, if in AGS [13:15:39] but that should go through the SCEA, reading a relay state from a S&C control assembly [13:15:47] Ah yeah [13:15:54] already done and commited [13:15:56] There might be other switch positions that do the same [13:16:10] Route through SCEA rather than directly to the CWEA [13:16:14] yeah [13:16:26] I don't know what causes the joystick messages. I always suspected that it was some USB device being counted [13:16:27] I havent checked, but things like the inverter switch [13:16:48] but then when it checks if it is a joystick it's finding that it's not a joystick [13:16:51] Who knows, it is all disabled in my launchpad, only comes up when I spawn a LM, and there is nothing attached to my laptop [13:16:57] and that's how it ends if at the joystick message [13:17:16] right, that's why that can't be the whole story [13:17:38] Yeah which is why it is worth an investigation I would think, even though it is harmless enough as you said, something isnt right [13:18:31] I really don't understand our joystick code [13:19:40] Well then we are screwed :P [13:20:54] if I am the best programmer around then we don't have very high standards [13:21:32] dseagrav would know [13:21:57] I get the no joysticks found error [13:22:36] yes you mentioned that [13:23:04] Sorry I was trying to specify the actual debug line that comes up [13:23:12] Since there are a few that can be called [13:23:31] like cannot acquire etc [13:23:53] right, there are a bunch [13:24:23] I can load a scn where I already have a LM and get nothing [13:25:31] I only have 1 scn before LM ejection though [13:25:38] So nothing to compare [13:28:01] So I want to start adding power draw to the LCA [13:28:22] Is there any way with the way you have it set up to totalize what is on? [13:28:29] I am just going to work with the DC section right now [13:28:41] Or do the lights just check for LCA voltage? [13:29:00] if you want to take on a project that will be difficult even for me, sure, you can do that [13:29:01] :D [13:29:20] I have some ideas, and I understand the system... [13:29:24] So I dont mind [13:29:58] well, first you will need a new class for lights [13:30:05] which would register their power draw with the LCA [13:30:26] and then you have to make the LCA an e_object that properly does power drawing from its CBs [13:31:57] it's really not easy. And if I guide you through it, I will probably have spent more time than just doing it myself. [13:32:31] I think there is enough work to do where the systems knowledge is more important than the programming knowledge [13:32:38] but LCA power drawing is not one of them [13:32:43] Fair enough [13:32:55] Once again I was thinking "this would be simple" [13:33:10] yeah, unfortunately I don't think so [13:33:42] The e_object is a good idea though [13:34:00] yeah, the lights can simply use a WireTo(LCA) then [13:34:12] and how much power they draw would be defined in the init of them [13:34:19] that's something you can certainly mess with [13:34:30] just let me first implement the new lights class and some basics in the LCA [13:34:46] It would also need to take into account how much voltage is given to them via the dimmers [13:35:14] I was thinking just totalize the number of lights on and the voltage given to each or something like that [13:35:18] right, so maybe not a single WireTo, but a WireTo the right LCA output [13:35:57] ok, I think I have an idea about this joystick stuff [13:36:22] it tries to enumerate joysticks, even if you didn't choose the option to use a joystick as RHC or THC in the config menu [13:36:47] So it needs to not do that if those arent selected [13:36:58] yeah [13:37:14] in the config the RHC and THC IDs are -1, when you selected not to use a joystick [13:37:26] so, I will do a check if both of those are 0 or larger [13:37:36] and only let it try to find joysticks in that case [13:38:16] That sounds like a reasonable check [13:39:16] did you say you only get the message at LM ejection? [13:40:52] Yes [13:40:58] And only on my laptop [13:43:41] But my desktop does have a USB joystick plugged in [13:43:49] Even though its disabled in the launchpad [13:44:01] ah [13:44:05] so it is finding a joystick [13:44:13] Yes [13:45:20] May be a needle in a haystack, but do we have a source on power consumption on the individual bulbs in the LM [13:45:46] not sure [13:46:05] might be in the AOH or Systems Handbook or the schematics [13:46:13] Yeah I have been hunting, no luck [13:47:30] I was thinking about doing what i did with the flood lights if we cannot find it, and dividing the max power on the power source by the total number of say incandescent bulbs in a certain power source [13:49:01] I am going to hunt through Apollo 13 docs and see if I turn up anything that might be a good source for that [14:00:39] If not I will just make an estimate for now [14:01:22] yeah [14:01:33] and you can implement the new lights then [14:01:54] so, moving the code out of lempanel [14:02:03] and just call an init with the right power draw [14:02:53] I also need to estimate power for the CW lights [14:03:04] And draw based on number of illuminated lights [14:03:26] The CWEA code can totalize that right? [14:04:39] yeah, makes it simpler [14:04:51] so the CWEA would just be one device to be registered with the LCA [14:04:57] Yeah [14:05:07] and the CWEA can calculate the power draw internally, like the DSKY for example [14:05:24] It just also has to take into account the dimmer [14:05:36] Other than the cw pwr light [14:05:49] Which always gets full power from the LCA [14:07:12] hey [14:07:16] hey Alex [14:07:30] Actually I guess the cwea just needs to keep track of lights and the power can be controlled in the LCA, as long as the cw light is wired direct [14:08:00] Hey morning Alex [14:08:55] I'm not quite sure about the best way for that [14:10:15] but maybe the CWEA will just have a lot of instances of the new light class [14:10:29] and wire to the right LCA output in the CWEA constructor or so [14:10:54] variable power is not something I really had thought about [14:10:58] hmm [14:11:30] It can calculate its max power load and then be reduced in the LCA based on the dimmer [14:11:49] All the lights that are dimmable can do that [14:12:25] Or should do that, and then the power draw can be decided based on the dimmer/override switch positions in the LCA itself which would then draw from the DC breakers [14:13:31] So most lights on the DC side of the LCA are dimmable, with only a few exceptions [14:14:36] Actually of the lights controlled through the LCA, only the CW PWR light is fixed [14:14:54] So all the rest can just send a max power to the LCA, and the LCA can calculate it's draw based on the dimmer [14:14:58] Would that work? [14:15:05] because the CW PWR light has a different source [14:15:15] But it comes through the LCA [14:15:50] yes, it has the same power source as the component lights [14:15:54] 5.5 VDC constant [14:16:06] component lights are dimmable [14:16:23] At least I thought they were [14:16:31] I don't think so [14:16:41] hmm [14:16:42] oh wait [14:17:02] no [14:17:05] not dimmable [14:17:32] in the Systems Handbook, the variable 2-5VDC only go out through the off position of the anun override switch [14:17:32] AOH says they have brightness adjustment [14:17:52] "Continuous" brightness adjustment [14:17:57] Versus "Fixed" [14:18:11] uhh [14:18:20] both outputs go the component lights [14:18:23] that's confusing [14:18:48] Yeah [14:20:52] Maybe its a continuous power source when grounded through the lamp tone test? [14:21:10] yeah, I was thinking that as well [14:21:25] so power comes from the non dimmable circuit when doing the lamp test [14:21:51] And the ground through the dimmer when in normal operation [14:22:28] that certainly doesn't make this easier... [14:22:32] Nope haha [14:22:35] More conditions [14:23:11] Hmm [14:23:38] You mentioned multiple outputs that would wire [14:23:41] From the LCA [14:23:49] Why not have an always on output to wire to [14:24:03] The cwea power light and the lamp tone test power could wire to that [14:24:33] And the logic controls of the lights when not in tone test would wire through the dimmer output [14:24:46] Still not simple, but it can work like that [14:25:32] yeah [14:26:29] I think it is safe to assume that all the incandescent are the same wattage [14:27:01] Or close [14:27:06] yep [14:27:44] Makes calculating the individual power draw easier [14:32:47] Roughly 1.18W per bulb [14:33:10] Unless I missed some [14:33:13] 30 CW lights [14:33:17] 9 COMP lights [14:33:20] 3 ENG PB's [14:52:21] Gotta run, hiding easter eggs, later! [15:18:49] indy91, did you make it through the sea of landmark tracking PADs alive? ;) [15:19:04] of implementing them, yes [15:19:21] just getting starting on actually doing the landmark tracking [15:19:25] started* [15:21:57] only a few updates left to be implemented until TEI [15:22:40] and then there isn't going to be much to do until reentry [15:22:52] maybe different MCC execution criteria [15:23:04] than Apollo 8 [15:23:13] I guess from TEI on, all missions are quite similar MCC-wise [15:24:27] yeah, pretty much [15:29:45] And now I have to wait as the "adult" eggs are hidden haha [15:30:13] sounds fun [15:31:07] did you implement the sleep period 10°DB attitude hold procedure for each sleep period in lunar orbit? [15:31:11] or just the first one [15:32:04] Honestly I do not remember [15:32:09] ok [15:32:12] Oh that one [15:32:14] The recent one [15:32:20] Just one I believe [15:32:23] ok [15:32:47] same is done on the sleep period between DOI and landmark tracking day [15:33:04] at about 109h [15:33:24] Ok I can add that [15:33:32] then again before the short rest period at about 129h [15:34:04] and then it's TEI, so that should be it [15:34:28] PTC uses a different procedure [15:34:36] although it might be similar [15:34:43] "20°DB P&Y" [15:36:37] also, who wrote this flight plan [15:36:53] after a whole landmark tracking day, only 3.5 hours of rest period [15:37:13] then a few more hours of photos and landmark tracking [15:37:19] then TEI [15:37:34] and then the "rest" of the sleep period, 5.5 hours [15:37:46] all messed up sleep schedule [15:38:07] Yikes! [15:41:35] Ok how do we need to change PTC? [15:42:39] I'm not entirely sure how they did it on 10 [15:42:48] but I think they left the CMC in control [15:42:55] with the very large 20°DB [15:42:57] and roll disabled [15:43:00] or something like that [15:43:01] Instead of the SCS [15:43:43] yeah, the 20°DB over a longer period of time can only be done with the CMC, I think [15:47:52] Was that for all PTC on 10? [15:49:11] If so I can just add it to the group [15:51:26] I'll research that some more [15:51:32] Ok [15:51:33] you can leave that as it is for now [15:51:46] The DB changes were added at 109 and 129 rest periods [15:52:32] great [15:53:53] PR up [15:54:28] Can I use your code that lights the MA in CWEA to count the number of lights on? [15:55:56] And return it with a function in the CWEA that can go to the LCA [15:56:16] Or rather a max power for the LCA later [16:01:41] you mean SetLight? [16:02:01] Yeah [16:02:29] I don't think that is a good implementation [16:02:41] the LightStatus array [16:03:17] add a function and let it check each variable in the array, if it is 1 [16:03:24] if it is 1, counter++ [16:03:30] and then return the counter [16:03:34] as simple as that [16:05:37] How do i check each variable in the array [16:07:05] look at SetLightStates [16:07:17] and instead of [16:07:19] LightStatus[i][j] = state; [16:07:45] you do "if (LightStatus[i][j] == 1) counter++;" [16:08:04] and at the top of the function you add you need int counter = 0; of course [16:08:10] and at the end return counter; [16:15:41] Oh ok [16:15:49] I dont have much experience with arrays [16:20:22] they can be tricky in C++ [16:22:53] do i need to redefine i and j in the function? [16:26:23] I will play with that later, take it easy [16:48:53] hello @AlexB_88 [16:49:25] i just burned mcc2 and my hp is about 48 would that be right? [18:05:42] hello rc [18:06:20] @rcflyinghokie so, i just burned mcc2 and my hp is about 48 would that be right? [18:07:01] hp with respect to which body? [18:07:21] it says in the dsky [18:07:25] verb 82 [18:07:34] Which mission? [18:07:54] i think its the earth as the distance is counting upward [18:07:56] 11 [18:08:23] and in the apollo mfd it says hp 47 [18:09:18] Hp is perigee [18:09:36] yes [18:09:55] So I believe (I could be wrong) that it is just perigee with respect to earth [18:10:10] Because you are essentially in a very eccentric orbit around the earth [18:10:19] okay [18:10:31] What did you use for your MCC parameters, which TLCC option [18:12:14] And 47 as an Hp sounds like a nominal free return trajectory [18:23:26] option 2 [18:23:41] with a p30 refsmmat [18:24:54] Why the P30 REFSMMAT? [18:25:09] PTC REFSMMAT too close to middle gimbal? [18:33:20] indy91, I have functions in the CWEA that calculate a max power draw based on number of lights lit, and then that can wire to the LCA and be dimmed [18:51:06] rcflyinghokie, yeah, he loaded some PTC REFSMMAT, maybe with no input GET. In any case, he had 77° MGA, so the PTC REFSMMAT wasn't too great to use. [18:51:38] and, great with the CWEA function [18:56:06] astronauthen96__, and your 48NM perigee would only be relevant if there was no Moon at all. Then you would come back to Earth at some point, with a 48NM perigee. [18:56:20] but I have the feeling the Moons gravity has some other plans [19:04:56] afternoon! [19:05:34] hey Mike [19:06:52] what's up? [19:08:16] not much. just been implementing the MCC calculations for the landmark tracking day of Apollo 10 [19:08:23] haven't flown much of it yet [19:08:40] it's always the 4 same landmarks though [19:08:53] and each is tracked on 4+ consecutive orbits [19:08:59] haven't really figured out... why [19:09:09] hahaha [19:09:46] finding the best landing spot for Apollo 11 maybe [19:11:16] Ah forgot I had an open PR [19:11:17] sounds like a good bet [19:11:25] How are those CWEA changes? [19:11:43] One for the cw pwr which is not dimmable and the other for the rest of the lights as a total [19:12:10] minus the cw pwr light should we ever have it come on with the other cw lights wity a more advanced implementation of power [19:12:54] yeah, your implementation is good [19:13:28] one minor thing [19:13:30] Sure [19:13:31] if (LightStatus[3][6]) [19:13:44] LightStatus is an int array [19:13:54] Ah [19:13:54] so that will be true, whenever it is != 0 [19:14:12] and we have the hacky setup with 2 disabling the display altogether [19:14:20] used for the LR light, right? [19:14:23] Yeah [19:14:33] Basically "pastes" a blank cell over the light [19:14:36] of course that won't be the case for the CW PWR light [19:14:44] it will always be 0 or 1 [19:14:52] so your implementation won't cause issues [19:15:02] and you used LightStatus[i][j] == 1 for the others [19:15:27] you change that to == 1 as well, if you want. It's not really important [19:16:39] you can* [19:16:43] so the cw light lightstatus == 1 for thew returning of power [19:17:26] yeah, it will be 1 when on [19:17:46] you'd just have to change the two instances of [19:17:47] if (LightStatus[3][6]) [19:17:47] to [19:17:49] if (LightStatus[3][6] == 1) [19:17:51] as well [19:18:02] yeah [19:18:49] So the next thing would be moving the component lights? [19:20:25] moving where? [19:22:26] You said moving them out of lempanel [19:23:27] oh right, into a special class for them [19:23:31] Yeah [19:23:45] makes sense because we have a bunch of them [19:23:48] Yeah [19:23:55] and they all should have the same bitmap, right? [19:23:58] Yes [19:25:28] so we won't have as much code in lempanel and adding support for any advanced features like power draw will be easier [19:25:34] Win win [19:26:09] Should they go into a class in eps? [19:26:36] And yeah lempanel looks cluttered with a lot of that stuff [19:26:43] lemswitches [19:27:00] all panel elements are there [19:27:14] Ah yeah less work [19:31:25] Should the whole redraw function be moved? [19:31:30] Or just the component lights [19:34:20] just the component lights [19:34:32] I'm sure there are a bunch of other things there that are not easy to move [19:53:48] Is moving these as simple as duplicating that function? [19:54:57] you are really keen on doing it, right? :D [19:55:28] the tricky thing is probably that they each have different logic for being on [19:56:25] Haha I mean I could try [19:57:50] I suppose they could just use a tracker or counter like CWEA bulbs [19:58:27] what you could first do is check if the logic for all the component lights should be a SCEA solid state switch [20:00:44] because right now they still use various types of logic [20:01:01] Ah yeah [20:01:16] I know I have SCEA in some of them [20:01:48] hmm, they are unfortunately not all through the SCEA [20:01:56] No Track light certainly not [20:02:07] SCEA only gets the same signal [20:04:07] would have been nice to use a common logic for a component light class [20:05:26] Looks like a lot of it will be mix and match as it currently is [20:05:58] I need to check that CWEA breaker power to some of those lights as well [20:07:28] I think that was done because the CWEA contains the logic gates for the light [20:07:38] But I will recheck those all [20:08:02] I will verify all of that logic before attempting to move anything though [20:08:17] Now that I have a better grasp of the CWEA in general [20:08:44] Well I could only hide from the easter party so long, time to be social again :P [20:18:32] I had a good excuse not to go to mine this year, damn head colds... [20:48:00] uh oh CTD with CWEA [20:48:32] https://www.dropbox.com/s/mxwls8dr99fpn45/Screenshot%202018-03-31%2016.48.25.png?dl=0 [20:49:39] ah, my fault [20:52:01] haha, that SCERA subassembly type doesn't even have solid state switches [20:53:05] and also, I now get a joystick not found message [20:54:07] uhh [20:54:20] I was quite sure I actually made those much rarer :D [20:54:46] Ive never had them before, and now it shows up haha [20:55:11] how can that be? all I did was add an additional condition... [20:55:22] for that message to appear [20:55:31] hmm [20:55:48] one thing I hadn't thought about is that CSM and LM might intefer in their joystick loading [20:56:35] hmm [20:56:38] it's "no joysticks found", right? [20:56:50] actually, I think its that may joystick is actually not found [20:57:11] as in not working, even though its plugged in and configured [20:57:18] ah, possible [20:57:23] then that message should still appear [20:57:35] if you selected to use a joystick [20:57:41] but it didn't find one [20:58:37] maybe if I delete my config file for the joystick [21:00:25] I think I'll revert all my changes I did with that [21:00:32] I really didn't know what I was doing [21:00:38] just tried to make that message rarer [21:01:17] I can definetely say that its that update, since my other orbiter 2016 folder, which is a few commits behind, works fine [21:01:37] maybe just remove that message all together? [21:03:05] I can comment it out [21:03:14] and leave the general code there intact [21:03:19] yeah [21:04:56] fixes pushed [21:05:37] thanks [21:06:18] btw I just tried it with the options set for 2 separate joysticks for RHC and THC and that seems to work [21:06:35] do you have 2 separate joysticks by any chance? [21:06:47] not really [21:06:54] I have no joystick connected at the moment [21:07:01] ah ok [21:13:19] all looks to be fixed [21:16:05] I was thinking "that subassembly has two outputs, surely one of them is a solid state switch" [21:16:18] and my current scenario worked fine [21:16:26] with a Snoopy completely void of power [21:17:32] hehe [21:36:35] I think Ill fly an Apollo 13 trip (no-fail) now [21:38:28] and test all the newest LM stuff [21:55:32] sounds good [21:55:34] night! [10:48:20] hey [10:48:49] i have a question about the ptc refsmmat [10:49:08] for the tig is it supposed to be at the time of the realignment or the start of the ptc? [10:51:24] I don't really know actually. I have differing sources. [10:51:39] one source said it should be the time of TLI for the translunar coast [10:51:46] and time of TEI for trans-Earth coast [10:52:22] another source said it should be the average time for the launch window of the nominal TEI [10:52:45] so I think in your case, taking roughly the time of TLI will be sufficient [10:53:00] for the ptc refsmmat in the rtcc? [10:53:04] yes [10:53:13] one of the defining factors of the PTC REFSMMAT is the Earth-Moon line [10:53:22] and that's what the input time is for [10:53:47] i maneuvered to pitch 090 and the verb 49 is a little off [10:53:48] so basically, if you would use a time equal to 28 days, then you would get the same PTC REFSMMAT as if you used 0 hours [10:54:15] because that's how long the Moon takes to orbit the Earth [10:54:23] what do you mean V49 is off? [10:54:39] oh, it didn't get you exactly to 90°? [10:54:46] nope [10:54:46] could be your DAP configuration [10:54:48] it was close [10:54:58] yeah the ptc has a different dap [10:55:00] did it want you to change it to 21111 or so? [10:55:06] the 4th digit is a deadband [10:55:16] yes it did [10:55:28] it is closer to 60 degrees right now [10:55:36] 4th digit, 0 = 0.5° deadband [10:55:40] 1 = 5.0° deadband [10:55:53] so it won't try to get you any closer to 90° than the 5° deadband [10:56:37] 60° before or during the PTC? [10:56:52] right now i am about to start the rest period so after [10:57:45] actually i think its closer to 90 as the numbers are upside down i just saw it wrong [10:57:52] I guess the spacecraft had a bit of a pitch or yaw rate [10:58:10] when initiating the PTC. That can happen [10:58:25] Apollo 10 was the first to try a docked PTC and they had major issues at first [10:58:31] its closer to 90 now just saw the threes are upside down [10:58:37] ok [11:50:24] very excited about my mission [11:55:55] I hope you finally make it to LM activation, haha [12:03:26] yeah without those irritating ntdll ctd's of course last time i couldn't even make it to loi 2 [12:12:57] so, will the lem activation take "three hours by the checklist" like in real life? [12:14:12] yes [12:14:22] if you've done it many times you can probably do it quicker [12:15:00] but I think it's more fun than the 4 hour prelaunch procedures in the CSM [12:15:11] not really much waiting [12:15:54] and you can really see the LM come alive, from completely powered down to a autonomous spacecraft [12:17:00] and i have my lem pressure valve closed should that be open? [12:18:36] I think they had that closed for most of the coasting period [12:18:58] if the LM needs additional pressurization, then that can be done on the morning before LM activation [12:19:34] i am about to start day three which is a lem day [12:21:49] ah, just some LM familiarization [12:22:52] i would the assume the astronauts would already be quite familiar with the lem [12:24:32] well, that's what the flight plan says [12:24:47] and it's always going to be different in zero G [12:33:31] good morning [12:35:48] hey Alex [12:38:29] just about to burn TLI with Apollo 13 [12:40:49] ah, fun [12:41:11] I have a development branch for the LVDC minor loop support routine [12:41:17] the Saturn IB already does it correctly [12:41:22] just the Saturn V not [12:41:37] leading to the behavior you described when returning control to the IU [12:42:34] hey alex [12:43:13] thank you for making the mfd's bigger [12:43:56] astronauthen96__ no problem! [12:44:07] much easier to read now [12:44:25] my first reaction was that I didn't like the change [12:44:31] is that hy you made them bigger? [12:44:44] but by now I can live with it, haha [12:49:28] yeah well as I said I am open and I can always revert if the general consensus wants. I do think they make the small lettering on some MFD pages much easier to read, especially on smaller screens [12:52:01] it's probably a change for the better all in all [12:55:14] or maybe I just need to get glasses :D [13:04:10] so on Apollo 13, I can do "evasive maneuver enable" and then when thats complete, "timebase 8 enable"? [13:10:01] yes [13:10:18] but wait with the evasive maneuver enable until you are clear of the S-IVB with the LM [13:10:34] because it might start maneuvering immediately [13:10:40] ok [13:12:11] and also i managed to see the slingshot maneuver [13:14:09] yea, that's quite impressive [13:14:16] the LOX dump [13:14:45] saw it right from the csm [13:15:48] fairly recent feature, hasn't been added very long ago [13:16:31] it was for apollo 10 couldnt catch it for 11 [13:41:13] Good morning [13:47:09] hey [13:52:38] Hows it going? [13:53:45] hey Ryan [13:55:14] flying Apollo 13 right now (no-fail) [13:55:24] going to test all the new LM stuff [13:56:05] Ill try and keep the bug list to one page :D [13:59:39] Haha find it all! [14:00:16] I am trying to move the component lights into their own class [14:14:14] well, good luck with that, haha [14:14:29] I'm just over here doing my relaxing landmark tracking [14:16:43] Just trying to get everything pointing to the right places [14:17:17] The only part I am not sure how to handle is the part in oapiBlt "srf[SRF_RR_NOTRACK]" for example [14:22:32] Would lem->InitPanel.SRF_RR_NOTRACK work? [14:25:56] InitPanel is a function [14:26:11] functions don't have properties like that [14:26:20] you'll have to give the surface per an init [14:26:54] that's how most panel elements are doing it [14:34:44] I have SURFHANDLE surf in the init, how do I point to the one bmp I need? [14:35:15] look at how all the other panel elements are doing it [14:35:24] rcflyinghokie, btw I did not see that FC caution lights come on during boost/insertion (the FC RAD low thing) [14:35:29] must be fixed now [14:36:13] April fools? [14:39:00] oh forgot it was April 1st... the sim must be messing with me [14:39:53] Haha [14:40:03] Yeah i reduced some fuel cell parameters [14:40:52] Tried it on a few launches especially 17 and seemed to be ok [14:41:51] indy91, MCC-1 4.7 fps [14:43:14] not bad for reverse engineered targeting parameters [14:46:39] of course that also is a DV optimized non-free return MCC [14:47:19] also should mcc 3 and 4 be option 1 if they are necessary? [14:47:19] which doesn't take into account the desired lunar orbit orientation after LOI and any timing constraint [14:47:30] yes [14:47:32] option 1 [14:47:55] if you still have the parameters for option 1 saved from the MCC-1 or MCC-2 calculations [14:48:35] usually i calculate option two then switch to 1 and there are numbers there [14:48:54] from last time [14:49:03] yeah, the option 2 is calculating numbers for option 1 [14:49:30] option 2 calculation has a lot of additional constraints, which are dropped for MCC-3 and 4, because they would need too much DV [14:50:10] so MCC-3 and 4 are simply targeting the point in space that resulted from an iteration in option 2 [14:51:28] so one at least of them should be burned then? [14:52:01] no, doesn't have to be. [14:52:06] Not if the DV is really low [14:52:34] i think mcc was required if more than 3fps [14:53:22] different MCCs and different missions had different constraints [14:53:43] for 11 it was 3 as in the flight plan [14:53:55] oh, does the flight plan mention 3 ft/s? Where? [14:54:36] page 145 in the pdf bottom right [14:55:23] "and if LOI-1 cannot be targeted to correct the TLC dispersions" [14:55:31] but 3 ft/s is a good guideline [14:55:50] I haven't added the proper tools to the RTCC MFD to calculate the constraints for this [14:55:51] indy91, actually for MCC-1 I used opt 6/7 [14:56:10] I think I have confused myself with what all I need to bring over to lempanel haha [14:56:13] AlexB_88, ah, so just as a check how free your return is, haha [14:56:21] yep [14:56:27] free enough [14:56:33] pretty close [14:56:44] rcflyinghokie, over TO lempanel? Not away from lempanel to lemswitches? [14:56:51] is there any other way to check the trajectory other than mcc calculations [14:56:54] the latter, yes haha [14:57:59] I have the redraw event function with the component cases over there [14:58:14] astronauthen96__, I'll add a page to calculate those at some point. One thing you could do is try to find your closest approach to the Moon with P21. [14:58:18] And of course the stuff for the "componentlights" class I made [14:58:40] i think all i need for that is loi tig right? [14:59:18] astronauthen96__, yes, LOI TIG and then add and subtract a few minutes and iterate on the input time until you got the small altitude. [14:59:27] Jim Lovell did this on Apollo 8 as well [14:59:36] rcflyinghokie, componentlights or componentlight? [14:59:42] okay [14:59:52] i have mcc3 coming up anyways [15:00:02] are you adding a generic class for any single light or one class with all the light stuff? [15:01:02] I have all the component lights in this class [15:01:14] But the generic probably is a better way to go [15:01:34] But [15:01:39] yes, there isn't much point to adding a lights class that simply has all the same code as lempanel [15:01:44] Yeah [15:01:53] why CMC, must you always choose a star that is hidden behind the damn RR ?? [15:02:17] if we can implement a class that has 10+ instances, one for each of the lights, that would be a win [15:02:34] because then power draw etc. becomes much easier as well [15:03:33] think i might do apollo 12 after this and use the flight plan [15:04:51] What about the light logic [15:04:57] Handled in the individual instances? [15:06:38] Hmm should this class just handle the components, or any dimmable lights (other than CWEA) [15:06:49] that would be one way, yes. If we have a basic light class and then a derived class for each individual light, then that derived class will mostly have one function which determines the logic [15:06:57] I think other than components the only other dimmable lights are numerics and the DSKY [15:07:02] and maybe a second function to determine the power draw source [15:08:11] I hadn't thought this out much further, but I arrived at the conclusion that it's rather complicated to implement programming-wise [15:08:56] I have an idea of what it should do, just have to weasel through actually doing it [15:10:10] indy91, the P37 PAD seems to have the input GET I put in for L/O + 15 abort (15:00:00) instead of the calculated one (14:54:16) [15:11:44] AlexB_88, if you use 15:00:00 in P37, then P37 will calculate a non-impulsive TIG [15:12:02] so on the P37 PAD it's always the impulsive TIG [15:13:48] Yeah this might be too complicated for me at this juncture [15:14:19] rcflyinghokie, I can probably implement the basic class and one or two derived classes as an example, from there on you should be able to do the rest [15:14:35] P37 even uses the Lambert aimpoint guidance, so it's not a constant attitude burn [15:14:36] Yeah I know what needs dimmed where stuff wires and such haha [15:15:29] ah ok right, I still have to use the preliminary TIG when actually doing a P37 [15:15:44] yep, you use 15:00:00 as the P37 input [15:16:00] and it will output a time close to the 14:54:16, which would be on a P30 Maneuver PAD [15:16:04] I will start experimenting with connecting the CWEA to the LCA and seeing if I can get that dimmer connected [15:16:27] we were thinking about implementing different power sources for lamp test vs. normal logic, right? [15:16:43] how about the case where the light is on due to both? [15:17:31] Oh no the power source remains the same [15:17:41] well [15:17:47] power source as in LCA, yes [15:18:24] Oh you mean making the lamp tone test bypass the dimmer [15:18:27] but it gets complicated, because the lamp test is wired through the non-dimmable circuit [15:18:30] And not be dimmable [15:18:59] as a simplification, we could simply draw the non-dimmable way then [15:19:11] If the lamp tone test switch is on [15:19:29] And for power, it would of course be one or the other, cannot be additive [15:20:01] I can make a lamp tone power function in the CWEA [15:20:16] That way the LCA can call that if the lamp tone test switch is in a test position [15:22:33] hmm [15:22:46] let me experiment with this basic light class first [15:22:49] Sure [15:24:17] For the lamp test, say it is in cw1, the dimmable power could ignore the first cw bank so it could still return dimmable lights [15:25:44] So the rest of the lights could be dimmed and power drawn accordingly, and then the max power of the first bank would also be drawn [15:25:51] about the dimmable thing, I don't think there is much point to implementing the power draw for it, without it being visible on the panel [15:26:13] and I'm not sure that can even be done properly with bitmaps [15:26:34] I see your point but I think having the infrastructure for it in place is important [15:26:47] Hell I have dimmable flood lights [15:26:51] That dont exist yet [15:27:31] the standard Orbiter way for 2D panels nowadays is 2D meshes. I'm not sure we really want that, 3D panel would be better. In each case there would be a significant performance advantage. [15:27:43] And the Deltaglider 3D panel does have dimmable displays [15:27:51] so when we get there we could learn from it [15:27:58] Makes sense [15:28:37] I guess I am just concerned with power consumption should the lights always be at max brightness [15:28:51] I dont think it will make much difference [15:29:03] But still something to think about [15:29:17] yeah, we can implement the basics for it of course [15:46:09] one thing about my planned hybrid maneuver (MCC-2) is that with my PTC REFSMMAT, yaw angle is 64 [15:46:39] still ok I think, but quite high [15:51:56] so, the RTCC MFD calculated PTC REFSMMAT will ensure that the attitude with 90° is aligned to the ecliptic [15:52:25] but I've noticed with Apollo 10, and I think Apollo 12 is the same, that there are more constraints in play for the PTC REFSMMAT [15:52:37] HGA optimized it says [15:52:59] we have an Apollo 12 document with the REFSMMAT they would have used [15:54:54] but I haven't found a way to calculate these [15:57:22] so for the MCC I will probably hardcode it again [15:57:45] maybe I can add an inventory of hardcoded REFSMMATs in the RTCC MFD as well [16:01:15] yeah that would work [16:03:55] for Apollo 13 and later the PTC REFSMMAT can probably be calculated correctly right now [16:04:02] just depends on the GET input [16:06:25] aha! [16:06:33] it can be calculated with the RTCC MFD right now [16:06:39] I'm currently iterating on the GET input [16:06:53] I put in the post-TLI GET [16:07:02] and I am getting really close to the exact REFSMMAT from the operational attitude sequence document [16:09:55] what do you mean by "iterating on the GET"? [16:11:35] I know the exact PTC REFSMMAT from a document [16:11:50] and I can let the RTCC MFD show me the calculated REFSMMAT in a debug string [16:11:59] and I am comparing the two [16:12:05] and change the GET input each time [16:12:21] I tried this with Apollo 10, but it didn't work [16:12:27] it works for the Apollo 12 PTC REFSMMAT though [16:13:23] it seems to be the average TEI time, just like on later missions [16:13:34] average in terms of the daily launch window [16:14:11] for both TLC and TEC? [16:14:27] yeah, I think they used the identical REFSMMAT for those [16:14:34] oh [16:14:40] Apollo 10 as well [16:14:48] not sure about all missions [16:15:01] I did read somewhere that the time of TLI was also used [16:15:05] but not sure which misison [16:15:06] mission [16:15:28] ok, if you want a pretty good estimate of a GET input to get the correct PTC REFSMMAT, use: 183:00:30 [16:15:56] that should make the flight plan angles work [16:16:03] and the PTC anyway [16:17:20] ok, for Apollo 13 as well? [16:17:32] TEI time for Apollo 13 is 167:30:00 [16:18:01] so it's going to be some time a few hours later, just like with Apollo 12 [16:18:23] because it's going to be the average TEI again [16:18:38] maybe the halfway point between 72°/1 and 108°/2? [16:18:40] not sure [16:18:47] ah ok [16:19:10] I'll do the same procedure for 13, if I find the REFSMMAT [16:19:33] that 183:00:30 number is probably one we should remember, haha [16:19:38] 183:00:30 gives me the exact same MCC-2 yaw as the real PAD [16:19:43] 326 [16:20:23] so it should be good for most missions then [16:20:45] I calculated that for Apollo 12 though, you are flying 13, right? [16:20:50] yes [16:21:29] normal Apollo 12 TEI is 172:21:14 [16:21:37] maybe we can add a constant "average TEI time" for PTC refsmmat page to read [16:21:51] thanks [16:21:52] yeah, a default parameter [16:22:00] right [16:22:17] just have to make it not use the normal REFSMMAT page GET [16:22:26] hmm [16:22:41] launch windows is about 4 hours [16:22:58] delay by performing TLI one rev later maybe another 1.5 hours [16:23:25] that doesn't quite add up to 183h [16:23:31] especially not the average [16:23:53] but it will actually not be super sensitive to the input time [16:24:03] the Earth-Moon line is the defining factor [16:24:29] so the REFSMMAT will rotate by 360° in the time it takes the Moon to complete a revolution around the Earth [16:24:42] so 360° equals abotu 28 days [16:25:05] so 1 hour is roughly a rotation of 0.5° [16:26:15] unfortunately I don't have a source on the Apollo 13 PTC REFSMMAT [16:26:46] only had one part of the SCOT, and then only 28 pages of it, just a SCOT revision [16:30:14] ah, it's the average time of the monthly launch window [16:30:16] not daily [16:30:25] average time of TEI in* [16:31:20] I wonder if I can reverse engineer the Apollo 13 PTC REFSMMAT from some flight plan IMU angles [16:32:51] maybe the P23 calibration attitude [16:35:47] there are a few of those in the flight plan [16:35:57] you said the time I gave you already worked well? [16:36:22] it's probably off by 1-2 degrees, but can't be much more than that [16:36:30] good enough for now [16:36:56] and the calibration attitude won't give me anything better than 1° accuracy as well [16:37:04] yeah [16:37:42] although its an MCC so hard to compare to the real PAD due to the varying nature of MCCs [16:37:52] but it was close in yaw at least [16:38:21] pitch was not close at all though [16:39:08] off by close to 180 for pitch [16:39:12] looks like mcc3 not required [16:39:49] AlexB_88, what's your DV vector? [16:40:51] Apollo 13 had "minus 0021.7, minus 0001.7, minus 0008.0" for MCC-2 [16:42:12] -15.7 +2.4 -10.5 [16:43:23] hmm [16:45:06] actually now re-calculated it and its 337 instead of 326 for yaw [16:46:34] but it should not matter because my DV vector is a bit different then in reality anyway [16:46:57] my pitch for MCC-2 is 178 [16:47:14] mine was 1.9 [16:49:50] yeah, the PTC REFSMMATs will almost always be in one plane, for any mission, because the ecliptic is pretty fixed [16:50:03] but then it can be rotated by 360° in any way [16:50:27] so if the REFSMMAT is off by almost 180° it might just be rotated around a little bit [16:51:58] I am just curious why a few hours ago during TEC (less then 20 MET) I use the 183:00:30 time for PTC REFSMMAT and then calculated my MCC-2 with it and gave angles 090,355,326 [16:53:00] and now at 28h MET I recalculated the same PTC REFSMMAT 183:00:30 and my MCC-2 angles are 092,178,337 [16:53:47] you sure one of these calculations didn't your own PTC REFSMMAT? The one where you used TLI as the time? [16:55:03] no I had tried the 183:00:30 time [16:55:39] hmm [16:56:03] found a new Apollo 13 document, maybe it has something [16:57:22] nope [17:00:18] oh haha I am dumb [17:01:05] Were there bulbs behind the blank CW cells? [17:01:09] I was still using the old DV vector from my P37 abort pads for the MCC-2 pad angles I had above [17:05:50] so which angles were the one with the MCC-2 burn? [17:07:12] rcflyinghokie, in the CSM at least there are none [17:07:37] or at least they aren't on during a test [17:07:59] I have been putting dimmable versus non dimmable stuff into the CWEA so it can just send that to the LCA [17:08:23] And I have a counter for each bank, but whenever I put the lamp tone test on it, it counts 10, instead of the number of lights lit [17:08:39] indy91: 092,178,337 [17:09:12] that's quite close to the flown MCC-2 [17:09:17] yep [17:09:34] that with PTC GET 183:00:30 [17:09:45] But that was Apollo 12 [17:09:49] I think its an array issue [17:09:56] https://github.com/dseagrav/NASSP/compare/Orbiter2016...rcflyinghokie:Orbiter2016 [17:10:28] yes, that GET will get you exactly the Apollo 12 one, but the Apollo 13 GET for it should be within a few hours of the same number [17:11:13] I noticed 183:00:30 is just about 10.5 hours after nominal Apollo 12 TEI [17:11:39] maybe if I just add 10.5 to nominal Apollo 13 [17:11:42] TEI [17:11:49] sounds like a procedure, haha [17:12:57] rcflyinghokie, ah, the bitmap doesn't have a lit state for those unused lights [17:12:59] in any event sounds like a good case for a RTCC constant to be made out of it [17:13:27] so the state of the LightStates will be 1 [17:13:35] even if it's an unused light [17:13:53] If there are no bulbs back there I suppose I can just subtract the number of unused lights from each [17:14:15] during a test [17:14:18] Yes [17:14:25] It works properly if not in test [17:21:23] morning! [17:23:08] Ok the CWEA can return a dimmable and non dimmable load for the annunciator lamps [17:23:24] The LCA just needs to call those [17:29:00] hey mike [17:31:21] hey [17:32:35] indy91 does the LCA still need a power merger to draw power through one or both breakers? [17:33:31] no [17:33:37] that wouldn't work anyway [17:33:47] because of the additional relay contact for the CDR CB [17:34:05] Ah yeah [17:34:25] So is there an easy way to draw power from say the cwea lights through the LCA right now? [17:34:31] no [17:36:00] Ok [17:36:01] and I haven't really thought out how that best is accomplished [17:36:10] Yeah I am not sure either [17:36:13] I'm sorry, but this detailed light stuff just isn't high priority for me now [17:36:24] I want to get the Apollo 10 MCC done [17:36:26] Oh I am not trying to force the issue haha [17:36:38] all good [17:36:47] I just keep finding something to add and then open the subsequent can of worms [17:37:22] classic [17:37:26] But the CWEA power calculation works properly for dimmable and non dimmable loads, so its on the backburner ready to go whenever [17:37:50] right. And it might rather be that the CWEA call a DrawPower function of the LCA [17:37:58] and not the LCA calling a CWEA function [17:38:09] Oh that is probably cleaner for the different subsystems [17:38:10] but in both cases the CWEA will need to add up the number of lights on etc. [17:38:18] Already does [17:38:31] At least for annunciator lights [17:38:35] yep, that's most of the work done on the CWEA side then [17:39:41] Awesome [17:39:49] I will PR it then if there are no objections [17:41:10] looks good. Mostly unused functions for now anyway [17:41:20] can't intefer with anything [17:41:47] merged [17:41:55] I would agree that we should not venture too much into detailed lights and dimming as for now this is not possible anyway [17:42:22] or at least I have no ability to do it yet with my graphic abilities :D [17:43:03] hehehe [17:43:46] I think the CWEA and LCA and such are already awesome as it is and up to the same standard as the CSM is (and beyond maybe) [18:09:41] looks like we're only a few hours away from a Tiangong-1 reentry [18:09:44] (probably) [18:10:29] unless it suddenly gets a reboost, indeed [18:10:47] lower than J-Mission EPO altitude [18:12:38] current ESA prediction is 2307 UTC Apr 1 to 0307 UTC Apr 2 [18:13:19] so in 9 hours at the latest Tiangong-1 is history [18:14:19] the ESA prediction has Australia on the possible reentry path [18:14:34] if Australia gets hit by another space station, I'm going to say that space stations have something against them [18:14:34] I am hoping to get a glimpse as well [18:14:37] they always seem to have luck with these [18:15:00] 52°N here, nothing to see for me [18:15:44] where are you right now, rcflyinghokie? it looks like continental US is mostly off of the predicted path now [18:15:53] Oh it changed? [18:16:04] I am in Ohio for the weekend [18:16:31] quickly back to PTC REFSMMATs. Apollo 11 has a different calculation mode it looks like. So what the RTCC MFD calculates should be right for Apollo 12-17 [18:16:34] just got more refined [18:16:35] http://www.satflare.com/track.asp?q=37820#TOP [18:17:37] the closest it could get to us now is central america / cuba [18:18:01] I doubt it's going to stay up that long [18:18:09] the orbit just had it over North America [18:18:27] in 12 hours it would be there again with the ascending node [18:18:57] Wonder if it will make it [18:19:37] it might even hit China [18:19:40] wants to get home [18:19:49] haha [18:20:00] a lot of landmass on the probable last orbit [18:20:10] Fitting end haha [18:20:19] yeah [18:20:25] just wants good video [18:20:42] Yeah [18:20:50] Would be pretty cool [18:22:56] I was excited last week when the viewing area was around here [18:23:08] I havent checked since like thursday though [18:23:41] haha yeah, me too [18:23:49] did it decay faster or slower than previously predicted? [18:23:50] it would have been daytime, but still [18:24:05] hmmm, I'm not sure [18:24:43] http://blogs.esa.int/rocketscience/files/2018/04/timewindow_1-1.png [18:24:45] earlier [18:24:57] so it decayed slower [18:25:15] yeah [18:25:16] http://www.satflare.com/news/n37820/sat_decay.png [18:27:43] rcflyinghokie, I have some LCA changes that make drawing power through it possible. Will test it today and tomorrow a bit, so probably tomorrow you can try to wire things to it. [18:27:55] Sure [18:28:59] you will just have to do the usual voltage check and then call DrawDCPower or DrawACPower [18:29:26] From the CWEA, for example? [18:29:29] yes [18:29:36] do you already have differing power draw due to the dimmer? [18:29:40] Yes [18:29:45] Well npo [18:29:45] good [18:29:46] no [18:29:49] haha [18:29:56] I have a dimmable power [18:30:00] because that logic isn't in the LCA [18:30:02] That simply needs to be scaled [18:30:05] it just outputs a voltage [18:30:46] I can probably take that output and use it to change the power draw in the CWEA [18:30:53] I have some ideas how to do it [18:31:43] you 1.18W is with 5VDC? [18:31:45] your* [18:32:03] No thats 28V [18:32:13] On the breaker [18:32:16] indy91, so you were saying Apollo 12-17 use the average TEI time for the monthly launch window, correct? [18:32:29] I just took the breaker power load at 28VDC and divided it by number of bulbs [18:33:00] So I estimate that given 5VDC it will draw 1.18W [18:33:15] Which seems reasonable for a bulb of that side [18:33:16] size [18:33:30] yeah, now that I think about it, the DrawPower function internally in the LCA will draw from 28V sources as well [18:33:47] shouldn't make a difference [18:33:51] Nah [18:34:04] I think that bulb draw should work pretty well [18:34:15] AlexB_88, yes, I believe they were of the same type, with Apollo 10 and 11 having a slightly different underlying calculation method [18:34:16] Its the AC numerics that I will have to do a little work with later [18:34:32] although the defining time might not be the average TEI time for each mission [18:34:45] but the RTCC MFD is doing the right calculation for the PTC REFSMMAT for Apollo 12-17 [18:37:33] Oh indy91, any more info on the CMC vs SCS PTC? [18:39:37] no, haven't search yet [18:40:32] indy91, I see. Also, I just did the LOI-5 abort PAD with option 8 of TLMCC [18:40:39] works quite well [18:40:46] good to hear [18:40:54] some day I have to add the optimized option 9 [18:40:57] I threw in 40 descending as the flight plan indicates for LOI-5 [18:41:19] then I iterated on the altitude to find the MPL [18:43:07] yeah, that is something they had to do in the actualy RTCC as well with option 8 [18:43:21] one thing though, option 8 solution does not seem to be compatible with getting an entry PAD with "MCC" option [18:43:47] like the other fly-by abort page is [18:44:53] I guess the only reason I want to check that is to be able to pull the RTGO,VI0 and .05G GET out of the option 8 solution, for the maneuver pad [18:46:30] I'm not sure the option 8 is good then [18:47:02] because, in the code there is no difference between the numbers that the normal flyby calculation outputs versus option 8 [18:47:57] well I mean the entry pad cannot seem to read the option 8 solution at all [18:48:25] hmm, does the option 8 solution appear on the Maneuver PAD page? [18:49:00] yes [18:49:19] the Entry PAD page only takes the most recent TIG and DV vector calculation for the midcourse correction option [18:51:18] I calculate the option 8, then go straight to the entry pad page with mcc and when I press CLC, nothing happens [18:56:49] ok, I see some strange code there [18:56:53] Oh that reminds me did the flyby or pc+2 calculation ever become working [18:57:02] Just thinking about 13 [18:57:52] they have worked for years [18:57:54] was there a bug? [18:58:17] Well last time i flew 13 they contunuously calculated wrong [18:58:18] not very DV optimized solutions though [18:58:26] I crashed into the moon [18:59:05] Never tried the pc+2 but i could never get back on a free return without impact [18:59:19] the calculation doesn't take pericynthion altitude into account [18:59:45] also, that is the Return-To Earth Processor flyby and PC+2 calculations [18:59:50] those need improvements [19:00:00] I wanted a docked dps pc+2 video with 13 haha [19:00:22] the TLMCC Processor at least can get you back on a nominal trajectory [19:00:45] and that option 8 that Alex mentioned should be able to do it, with the right inputs [19:01:05] and after that the PC+2 should work [19:01:17] I cannot remember what option i used last time, one of you guys told me but i cannot remember [19:01:34] probably the RTE flyby [19:02:09] AlexB_88, so the problem appears to be that the entry PAD calculation needs splashdown latitude and longitude as an input [19:02:11] Yeah sounds right [19:02:17] but the TLMCC processor doesn't provide those [19:02:25] I recently tried the flyby abort page and it got me on the correct trajectory [19:02:29] it should be able to do that though, I can probably fix it [19:02:51] indy91, I see [19:03:34] I tried the "DWN" option and then of course the entry pad calculated, but with the previously stored splash coordinates in the CMC I guess [19:04:21] And for the fly-by page, I had used it on Apollo 12 and had no issues [19:04:36] rcflyinghokie, that issue you had is really weird [19:05:40] oh but you flew it with the LM, correct? [19:06:25] Yeah [19:06:38] I had with the CSM [19:07:01] Shouldnt have mattered with the calculation though should it? [19:07:03] so maybe the non-impulsive TIG wasnt set right for the LM [19:07:15] possible [19:08:07] actually, I am in the process of moving the finite burntime calculation out of these large "processors" [19:08:29] instead they would return an impulsive TIG and a separate processor would calculate the finite burntime TIG and DV [19:08:36] that's how it worked in the actual RTCC [19:08:45] You also changed the calculation fro the DPS taking the throttling into account didnt you? [19:08:57] you did some calculation, could review the TIG and DV and transfer the solution to the other processor [19:09:23] I don't think I actually changed that yet [19:09:41] it's still to 40% at 5 seconds [19:09:47] Ah [19:11:12] I think every normal dps burn was 10% for 10 seconds and then 40 right? [19:11:26] Orher than pdi and other unique ones [19:11:36] it varied [19:11:40] Other* [19:11:55] I think I got the 40% at 5 seconds from Apollo 9 [19:12:07] that's for docked burns [19:12:13] Right [19:12:18] heavy docked burns [19:12:27] where 10% doesn't really help the DAP find the CoG [19:12:36] not enough thrust [19:13:01] acceleration rather [19:13:06] Yeah [19:14:43] Would putting burn profiles as an option be reasonable? [19:15:11] yes [19:15:30] I would probably add that on the option page somewhere [19:16:02] Other than Apollo 9 docked dps there were only a handful of cases i believe [19:16:33] depended on DV and acceleration [19:16:52] DOI would be bad for residuals when you get 10% and then 100% for a few seconds only [19:17:02] the LGC is really quick to react [19:17:05] but not that quick [19:18:04] DOI never used 100 did it? [19:18:14] It was 10 then 40 [19:19:09] yeah [19:19:33] all 3 of that type of DOI :D [19:19:47] Apollo 13 already would have performed the LOI-2 as DOI [19:22:23] yep [19:30:04] rcflyinghokie, I'll change the CWEA so that the unused lights are never set to 1 as their state [19:32:31] Ok [19:32:58] You can delete the compensation for it in the nondimmable code if you wish [19:33:31] indy91, "I'm not sure the option 8 is good then" I beg to differ haha... My fly-by +210.9 -146.2 -251.3 Real: +212.7 -141.7 -254.8 [19:34:11] no way [19:34:22] that has to confirm that they used this option [19:34:39] and not the RTE Processor [19:35:00] rcflyinghokie, I'm taking care of it. Currently testing the LCA power draw and the unused lights are annoying [19:35:08] actually [19:35:16] how did you compensate for it? [19:36:17] lol almost the same gimbal angles too, so that confirms the PTC REFSMMAT as well [19:36:52] the Return-To-Earth page calculations are mostly made up by me [19:37:09] all the TLMCC stuff is almost 1:1 from RTCC Requirements documents [19:37:16] I really wished I had them for the RTE Processor as well [19:37:52] So i lost all messages recieved after my last, the app crashed :( [19:38:32] I was looking at your compensation for the unused lights [19:38:49] it assumes their state is actually 1 I think [19:39:08] in any case, I'll set it up so that the unused ones never have the state 1 [19:40:04] AlexB_88, what inputs did you use for option 8? [19:40:50] rcflyinghokie, for testing, should I just add GetNonDimmableLoad() and GetDimmableLoad()? [19:41:14] Ok [19:41:32] And yes you use them both [19:41:37] ok [19:42:47] indy91, the LOI-5 TIG 72:25:00, 40 Descending, and I iterated the altitude to 788 NM [19:43:12] use that the next time you try Apollo 13, Ryan [19:43:21] because you missed this [19:43:23] " indy91, "I'm not sure the option 8 is good then" I beg to differ haha... My fly-by +210.9 -146.2 -251.3 Real: +212.7 -141.7 -254.8" [19:43:57] Oh wow [19:44:19] thats option 8 of TLMCC and not the other page (fly-by abort) of course [19:44:58] And for the cwea loads, both calculate max loads and they can be used simultaneously, the dimmable just can be scaled down using the dimmer [19:45:02] yeah, and as I said to Alex, the TLMCC calculations are almost 1:1 from RTCC Requirements documents [19:45:30] its ridiculously easy to use opt 8 and very accurate [19:45:52] I think since i have LM consumables ill try 13 again for some videos, just need 3 in the cabin ;) [19:46:07] the documentation also had a bunch of failure states [19:46:12] well.. I have not actually tested the solution of course, but based on its closeness to historical numbers... [19:46:32] so it won't allow you to input unachievable return inclinations [19:47:17] right [19:47:41] as anything taken directly from RTCC documentation, it might fail often :D [19:47:46] but safely at least [19:48:36] LCA power load seems to work fine [19:50:06] rcflyinghokie, can you test the CWEA lamps when the CWEA breaker is out? [19:55:10] pushed the LCA and CWEA update [19:55:19] could use some more testing probably [19:55:57] AlexB_88, also included is a RTCC MFD fix, that should enable it to calculate the Lunar Entry PAD with TLMCC free return solutions [19:57:45] thanks! [19:57:53] ill test right away [19:59:45] works for me now [19:59:55] I hadn't actually tested it, but I knew what to fix :D [20:00:26] so I guess all TLMCC FR calculated splash coordinates will work [20:00:38] yes, all of them needed this change [20:01:29] in addition to loading the calculated splashdown coordinates in some TLMCC variables, it also stores them in the variables that are used as the input for the Lunar Entry PAD [20:01:34] that was missing [20:02:29] if only I had the documentation from NARA about the RTE processor. Then TEI etc. would work as well as the TLMCC processor :( [20:02:59] yeah [20:03:30] I guess its just the dvY that is not optimized for TEI [20:04:09] yeah, it's using some fairly random orbital plane for the return [20:04:30] so most of the lack of optimization will be in the DVY, yes [20:07:27] yep, the fix works good [20:07:49] crazy how close the pad is to the real one [20:07:59] someone want to sponsor the scanning of box "E157G-13" at NARA? :D [20:08:10] because it's all moon-centered RTE abort logic [20:08:13] Indy91 i think so yes [20:08:24] Testing the lights without cwea power [20:08:25] how much is it^ [20:08:35] ? [20:08:36] thewonderidiot would know, haha [20:08:55] I would be willing if the price is reasonable [20:10:53] ok, the box is not all RTE logic. [20:11:02] also some TLI processor and rendezvous calculations in there [20:11:32] what is nice about the RTE documents in there is that is seems to have the basic document from February 1968 and a bunch of changes through December 1969 [20:12:42] one document randomly taken might not be applicable to all missions, but with 4 change documents it should be pretty good [20:12:53] guess the lem hatch does open after all [20:13:38] just needs a low pressure differential [20:14:15] right after i opened it i got an o2 high light [20:14:56] yeah, it still will do a bit of pressure equalization [20:15:05] and now the potential air flow is very large [20:16:25] so the Hp referenced on the real Apollo 13 fly-by pad seems to be that of the earth at (22NM) [20:17:06] I wonder if an option can be put on the maneuver pad page to "force" it to use the earth referenced Hp instead of the Moon [20:17:07] yeah, they did that on most Maneuver PADs that return to Earth [20:17:46] could be tricky [20:18:11] especially for flybys [20:18:23] for direct return aborts it is easy [20:19:25] I mean its pretty minor detail of course [20:19:51] right, but the HP value was used that way a lot [20:20:18] I'll try to implement it [20:20:29] i can see mike collins from the sextant in the lem [20:21:32] RTE processor is on top of my list from NARA, for sure. I'm going to get it eventually, haha. Either by Mike going there at some point and starting some mass scanning. [20:21:37] or in some other way [20:21:57] by second priority probably is some later TLMCC documentation that will help with the LOI-2 as DOI [20:22:00] my* [20:22:29] Im sure well get that RTE some way or another [20:22:38] RTE docs* [20:23:06] I guess it makes sense too to hold off trying to fix until then [20:23:23] I mean what we have already works... [20:23:44] I can work a bit on fixing our targeting. The one used in the RTCC will be quite different [20:23:45] just a bit inefficient, but still ok [20:23:50] so it's going to be done from scratch [20:24:42] so, i have already asked about the rendezvous but it the landing easy? [20:24:52] is* [20:25:17] I would say its easier then rendezvous [20:25:34] I mean you can let the thing land itself if you want [20:25:58] of course you have to have it set up right, thats the hard part [20:26:43] did you get it right the first time? [20:27:11] no [20:27:21] I don't think the LGC got it right the first time Alex tried it :D [20:27:32] we were still fixing Virtual AGC and NASSP bugs at the time [20:29:46] astronauthen96__ Maybe you can practice with the Apollo 11 PDI demo scenario [20:29:55] i did [20:30:01] how was it? [20:30:19] what i meant was actually before the landing like pre doi [20:30:25] it was easy [20:32:08] oh, interesting, some of the document names are actually available online in a database [20:32:09] like [20:32:10] https://catalog.archives.gov/id/1517807 [20:33:18] there are a bunch of these, but not nearly all [20:33:29] and these ones are from Apollo 14, which are in a different box [20:33:42] thewonderidiot, how much did scanning something from NARA cost? [20:40:53] indy91, also about the fly-by pad I have been calculating, Its not the post accident fly-by pad that was actually flown then I am referring to, but the nominal one read up after MCC-2 [20:41:09] ah, I see [20:41:24] but that probably still confirms that this option was used for that flyby [20:41:33] the real time one might be different [20:41:34] yeah [20:42:18] and I think the flown one targeted the Indian ocean [20:43:17] which can still be done with the TLMCC processor, it's just annoying :D [20:43:30] yeah but not that hard [20:44:14] annoying meaning having to fine tune the altitude, right? [20:44:23] while there is some overlap in functionality, TLMCC flyby is more concerned about the state at pericythion, while RTE usually will take the return condition into account [20:44:25] yes [20:44:56] was the flyby maneuver they actually burned targeted at the Indian Ocean? [20:45:13] I think they considered first burning a maneuver that only gets them back on free return [20:46:26] ah wait a minute, didn't I just today find a document that might help with this question? Apollo 13 Mission Operations Report by the Flight Control Division [20:49:44] "flyby maneuver was executed as a minum fuel burn with a water landing" [20:51:24] "targeting to the Indian Ocean" [20:51:32] very likely the RTE Processor [20:51:38] this was from the RETRO report [20:53:16] I guess either TLMCC or RTE could have been used [20:55:09] yeah, I've been trying to figure out which one for a while [20:55:14] still reading the document [20:55:15] https://scribd.com/document/46576887/Flight-Conrol-Division-Mission-Operations-Report-Apollo-13 [20:55:38] rcflyinghokie, this document has the Apollo 13 CSM powerup procedures in the EECOM report section [20:59:38] too bad you need a membership with that site [21:00:01] ah, yeah [21:00:36] https://history.nasa.gov/afj/ap13fj/pdf/a13-mission-ops-report-19700428.pdf [21:00:39] I have that doc [21:00:45] I forgot the AFJ has the same one [21:00:50] I thought i showed you it :P [21:01:13] thanks [21:01:24] Thats where i got all my 13 info [21:01:46] maybe [21:02:07] Yeah i remember mentioning i found the powerup procedure there [21:02:25] Its much simpler than i thought [21:02:53] But a slow charge at what 7.5 amps max? [21:05:12] hmm [21:05:27] there is a procedure in there called "LM to CSM power transfer" [21:05:51] is that like the reverse of LM PWR - CSM? [21:05:55] yes [21:06:47] is that possible in our sim as of now? [21:06:56] Havent tried it [21:06:59] I don't think so [21:09:35] The real one configured breakers to provide a higher potential on the lm batteries but a lower amp flow of current to stay within cb limits [21:09:59] Not sure if the lm connector can even do reverse flow [21:13:10] so how do i close the lem hatch? [21:13:25] click on it [21:14:14] there is no hatch at all there is a giant hole and i can see the lem outside of it [21:14:37] just click where the handle should be [21:14:54] got it [21:21:52] indy91: depends on what you're scanning [21:21:57] is it paper or aperture cards? [21:22:20] punch card? [21:22:33] uhhh [21:22:46] is that the same thing? [21:23:03] maybe [21:23:05] microfilm? [21:23:09] microfilm is yeah [21:23:18] it's not microfilm [21:23:27] Ron has scanned the first pages of it :D [21:23:30] okay, so it's just paper [21:23:35] yes [21:23:58] so with aperture cards you get the first for free, not sure if that also applies to paper [21:24:10] let me dig up pricing info from my email... [21:26:09] okay so the document I had scanned was 33 pages, and they were going to charge me $24 for it [21:26:27] ouch [21:26:32] yeah, it is very pricey [21:26:44] how many pages is the RTE one? [21:26:48] no idea [21:26:57] more than 33 with the changes for sure [21:27:04] I am pretty sure my planned-for-someday flight out there + hotel + rental car will be at least equivalent to how much they would charge to scan everything I hope to scan while there :P [21:27:08] how much was the TLMCC one? [21:27:12] how many pages [21:27:43] you can have them find the document and tell you how big it is and how much it would cost to scan it [21:28:01] I see [21:28:05] they'll get back to you in a day or two [21:28:06] ftworth.archives@nara.gov [21:28:16] just send an email asking about it and give as much detail about how to find it as you can [21:28:18] there were multiple ones for the TLMCC Processor, the big one was 66 pages [21:28:28] nonfree modes 23 pages [21:28:55] flyby modes 30 pages [21:30:35] hmm so assuming the RTE manuals are not bigger it would be $30-90 per doc [21:31:12] I won't be able to make it to NARA until at least the end of this year, potentially not until next [21:31:53] Id be willing to enquire for sure [21:32:11] inquire* [21:32:39] how are the documents IDed? [21:32:50] I just know it's a bunch of documents in here: https://www.ibiblio.org/apollo/NARASWoverflow/TitlePageScans/E157G-13/ [21:32:56] that box [21:33:18] if you can give them the box, that is more than enough [21:33:22] ok [21:33:58] they are really supportive there -- they would try to find if you only had a report number or something [21:34:04] giving them the box just makes it way easier for them [21:35:15] well it's that box and I want anything with "Return-to-Earth Abort" and "Moon-centered" in it [21:35:26] hehehe [21:36:30] back in a bit [21:38:45] how much to just buy NARA? [21:38:51] might be cheaper with everything I want [21:39:08] this is America, surely you can buy anything [21:40:16] hahaha [21:40:30] yes but it is a branch of the government [21:40:55] so maybe you eventually could but you would die from bureaucracy before you got anywhere [21:40:57] so not that expensive [21:41:20] but lots of paperwork, I understand [21:43:43] any documentation about TEI calculations I found so far are either general algorithms or super specific [21:44:15] or early planning documents for Orion, completely devoid of orbital mechanics understanding [21:44:30] hahahaha, nice [21:45:15] hello mike [21:45:40] and it's not only a goal to calculation efficient TEIs or so, but to get about the same burns as the real Apollo missions [21:45:45] to calculate* [21:45:55] yo [21:46:21] gotta strive for that perfect accuracy :D [21:46:22] gonna do loi day tonight and your agc will come in very handy for that [21:46:36] eh, LOI probably worked before I got involved :) [21:46:50] certainly, even [21:47:02] barely [21:47:25] docked SPS burns weren't working until early 2016 [21:47:56] but no Virtual AGC fix was necessary for it, just padload work [21:48:34] yeah, that's what I thought [21:48:51] if I recall correctly, you were skeptical of several of my AGC changes because the CSM programs were working so well :D [21:49:11] the early DAP changes you did? [21:49:25] for the LM [21:49:53] I don't recall which ones I was skeptical about [21:49:56] but it sounds like me [21:50:04] hahaha [21:50:30] I think the thing you were most skeptical of was the reducing instruction times to fix the original 1202/1201s [21:50:39] oh that [21:50:45] but there were some others too [21:50:56] the P35 calculation time helped convince me [21:51:39] so am i gonna be landing manually or will it be automatic? [21:51:43] and now a year later with better moments of inertia, the faster cycle selection required in the Colossus 237/249 padload [21:51:50] among other things [21:52:53] which I still want to verify, the shorter TVC bandwidth. [21:53:11] Which is why I let Ryan request the Apollo 10 documents from the Smithsonian, haha [21:53:14] among other things [21:53:16] hehehe [21:53:18] astronauthen96__, neither [21:53:32] you have the options to land manually or automatically [21:53:44] but all actual missions used the rate-of-descen mode [21:53:46] descent* [21:53:54] semi-automatically basically [21:54:36] i think i will go with semi automatic [21:54:45] Don says in his book that MIT never expected the actual landings to go automatically, and that that was only in there for testing [21:55:08] other people have suggested that of course the astronauts were going to do it manually, they didn't want a darn computer to do it for them [21:55:22] explains why the automatic mode never was super sophisticated [21:55:28] simpler algorithm than ROD mode [21:55:29] speaking of, Don's book is out properly now, and you all need to read it [21:55:41] donn eisele? [21:55:44] yeah, I should [21:55:49] Eyles [21:55:56] AGC developer at MIT [21:56:02] http://sunburstandluminary.com/SLhome.html [21:56:10] was he the guy that saved apollo 14 [21:56:14] yeah [21:56:15] yep [21:56:25] he and Allan Klumpp were the two responsible for writing the lunar descent code [21:56:32] with Allan doing more of the theorizing and Don doing most of the coding [21:57:30] he also is a wonderful hoarder and worked with us to scan a bunch of AGC program listings in his collection over the past couple of years [21:57:44] he had more listings than every other source combined [21:58:29] so he knows about nassp [21:58:42] he probably has seen a video I made [21:58:46] yeah [21:58:55] the abort one? [21:59:01] about one of the development versions of the LGC software, one that never flew [21:59:02] the Tycho crater one [21:59:06] with some fun features [21:59:23] Niklas was flying Zerlina 56 there, which was Don's personal development rope [21:59:24] i will probably make an loi video tonight [22:00:07] fun [22:00:09] is indy niklas? [22:00:17] yeah [22:00:17] Niklas* [22:00:31] its main features were a variable guidance period servicer (which completely alleviated the problems from the Apollo 11 descent) and a P66 LPD that allowed for suuuuper accurate landings [22:00:38] https://archive.org/details/zerlina00done [22:01:17] i wonder if Margaret Hamilton knows about Nassp [22:01:17] we worked out a probably-mostly-correct padload for that video [22:01:29] she knows about VirtualAGC at least [22:03:28] every mission got a new version for CMC and LGC [22:03:31] until Apollo 15 [22:03:32] if you count all of the in-between and offline versions, thousands [22:03:50] there were programs called things like BATMAN [22:03:57] well you probably understand them better than i do [22:04:03] yeah, but that's like saying every NASSP commit is a separate version [22:04:11] https://virtualagc.github.io/virtualagc/R700-3-Table4-11.jpg [22:04:22] this table shows what versions were flown for all missions with Block II AGCs [22:05:15] add on to that Solarium 55 for AS-501/2, Corona for AS-202, plus Aurora for LM system tests and Sundial for CSM system tests, Newspeak and LaMesh for factory acceptance testing [22:05:42] then you've got Eclipse which is what Apollo 1 was supposed to fly [22:06:13] so am i using comanche 55 right now? [22:06:14] Sunrise and Retread which were the "original" ropes for Block I and II respectively [22:06:28] you're flying 11? [22:06:32] yes [22:06:50] yeah, Comanche 55 is what actually flew on 11, so you're flying the same thing they did [22:06:57] interesting [22:07:10] we don't have the exact right software for all the missions [22:07:23] but for Apollo 11 we have the whole package [22:07:29] CMC, LGC and AGS [22:07:38] we don't have the CMC ropes for Apollo 10, 12, 13, or 14, so you would be using Comanche 55 for all of those too [22:07:44] (or do we use Artemis for 14?) [22:07:57] what about the j missions? [22:08:04] we use a modified Artemis version for Apollo 14 [22:08:11] we have the J-Mission versions [22:08:12] all three J missions used Artemis 072 for the CM, and Luminary 210 for the LM [22:08:14] we have both of those [22:08:41] yeah i was thinking of flying 15 next after this [22:08:50] good choice :D [22:09:09] Apollo 15 has the most spectacular landing site in my opinion [22:09:16] agreed [22:09:17] can't wait until eva's are simulated eventually [22:09:33] as far as completeness goes, Apollo 8, 11, and 15-17 are the missions we have the complete AGC software for [22:09:45] of the manned missions [22:09:48] right [22:10:06] Apollo 4, 5, and 6 we also have full AGC software for [22:10:13] and we have hopes of AS-202 soon too [22:10:35] back [22:10:56] of the rest, we have none of the software for 10, 13, or 14 (although for 10 and 13 we have LM versions that are close) [22:11:11] for Apollo 12 we have the real LM software but not the CSM software [22:14:54] so are eva's gonna be for nassp 9? [22:16:27] we haven't really decided what all will be NASSP 9, but EVA is one candidate [22:16:36] Apollo 12-14 is the main feature of NASSP 9 [22:16:45] and some canister changes maybe [22:16:46] full Apollo 12-14 support* [22:17:17] in the grand scheme CO2 canister changes are a small feature [22:17:33] Plus eva that can be added to 9 and 11 [22:18:21] yeah, Apollo 9 EVA should be fun as well [22:18:22] and what about lem tunnel hardware? [22:20:11] careful with the word "tunnel", you might give rcflyinghokie an aneurysm :P [22:20:47] speaking of eva's is the old code still in there? [22:23:17] there is some old code, yes [22:23:23] have to try reactivate that some time [22:23:26] night! [22:24:50] haha why would that happen [22:24:53] @thewonderidiot [22:25:15] I think the tunnel just caused a lot of ECS grief, heh [22:26:52] @thewonderidiot and i bought a cigar just to celebrate your agc when i splashdown in the pacific [22:29:42] nice [22:30:46] whenever i hear the term agc i think of the dsky are they the same thing? [22:31:14] effectively [22:31:30] but the DSKY is really just the display and keyboard -- it doesn't have any brains in it [22:31:54] https://upload.wikimedia.org/wikipedia/commons/7/79/Agc_view.jpg [22:32:02] the actual AGC is the box on the left there [22:36:06] @thewonderidiot when you fly a mission eventually which one will you do first? [22:36:22] probably 8 I guess? [22:36:31] I dunno [22:36:38] good choice [22:38:20] it won't be for quite a while though [22:48:32] The tunnel connection was the start of the NaN's [22:49:16] poor LM caught NaNpox from the CSM [22:49:35] Well the docking probe didnt look protected... [22:49:53] I believe the LET was jettisoned leaving it exposed [22:51:35] But yeah that was just a nightmare [22:51:46] We did a lot of changes that ended up unnecessary [22:59:54] whoa [23:00:02] fear of tunnels doesn't have a proper "phobia" name [23:00:07] I thought everything did [23:02:26] also we are officially in the Tiangong-1 reentry window [23:02:28] could be any second now [23:02:38] it's currently above South America [23:02:51] heading up toward mid-Africa soon [23:03:25] it couldn't be any further away from us, Ryan :P [23:08:58] And here I had my hopes up [23:09:36] It's incredible the level of uncertainty with that given our level of understanding in orbital mechanics and tracking [23:09:48] drag is a bitch [23:10:04] And no way to give a linear model to it [23:10:09] wait no I messed up [23:10:15] should have said "drag is a drag" [23:10:19] reentry is a drag? [23:10:27] haha yeah that too [23:10:58] Ah I wish i was out here longer in Ohio though, I need to finish the USAFM and visit the Neil Armstrong museum [23:11:52] Hmm looks like I have CWEA power that now gets power through the LCA and the power load dims with the dimmer [23:12:12] yessss USAFM is the best [23:12:16] I know it isnt a super big deal without matching graphics [23:12:20] never been to the Armstrong museum [23:14:24] Hmm what other system can I go in and make complicated now :P [23:14:48] (pick the AGC! my counters pull request is pretty much ready for NASSP integration!) [23:14:49] :P [23:18:01] Oh my I know so little about that [23:18:06] In the grand scheme [23:19:00] hehehehe [23:23:44] I think once Niklas makes a basic light class and we start moving some lights into that I will be able to wire them up, and I also need to start looking at numerics and other AC lighting [23:24:22] Not as simple as DC, but the code should be the same in terms of power and dimming assuming I can come up with a power use figure for them [23:26:50] Once I get home I am going to see if I can fix some displays that arent drawing on other panels, like the ECS needles for example, they display in main panel view but not in the LMP window view [23:30:02] I am trying to think what other systems are needed, or need work in the LM [23:30:23] I could look into the LM->CSM power charge [23:31:28] that would be cool [23:35:51] I need to see how the current power connector actually transfers power [23:36:25] And if it can flow both ways, I need to figure out how to change the potential to force a flow into the CM batteries [23:36:55] Easiest way is to start with low CM batteries and see if the inherent potential would work [23:37:14] Because the CM->LM does not charge batteries [23:37:49] So if the LM potential can be made to be higher than the LM, and the current can back flow, then the esystems should govern a flow [23:42:04] Might be able to cheat using the battery charger code, I think that it routed LM power through the battery charger breakers [23:42:22] The actual CSM charge I mean [23:43:28] oh would it be nice if that can be simulated for Apollo 13 [23:44:30] I think we can make it work [23:44:50] I just need to revisit the actual mechanics of it [23:45:06] And the CM would either share the power connector DC source or have its own [23:45:10] when I saw the LM to CSM power checklist, it made me remember a scene in the movie where they talk about that [23:45:22] Well it was actually not "invented" for 13 [23:45:30] They actually had it filed away [23:46:11] The other problem with doing this in NASSP is how the CSM is wired up [23:46:30] The EPS in the CM actually is very complex and most of it wired correctly [23:46:36] So I have my hopes up [23:47:00] I am actually finally getting around to reading Failure Is Not An Option [23:51:45] Looks like I need to dig into the CM EPS a bit to find the power route [23:53:36] Ah hah it does go to the battery charger through main bus B [23:54:07] Not to the charger itself but the same route the battery charger would charge the batteries through [23:54:58] No never mind [23:55:05] It does use the battery chargers [23:55:12] Making it easier for our sim [23:55:40] So all we need the LM to do is power main B [23:56:14] And the current implementation should take care of the rest [00:01:03] oh man I picked up that book a bit ago [00:01:05] I need to read it [00:02:56] Yeah I knew about it I just didnt have time finishing school [00:03:10] But I got a copy as a valentines day gift [00:03:15] nice! [00:03:44] So I started it on Friday and its really good so far, I can here it in Gene's voice [00:03:51] hear* [00:04:49] heheheh [00:04:53] maybe I'll start reading it tonight [00:05:03] instead of playing megaman or something less productive [00:05:25] Haha [00:06:24] in productive news, though [00:06:36] I haven't solved this many systems of equations in years... managed to identify the diode in this module as a schottky with a 0.15V drop, in series with a 3.46k resistor [00:06:47] there's just one capacitor in here that I don't have pegged down and I'm not sure how to measure [00:07:54] no matter how I measure, I end up with one resistor parallel with it and one resistor in series with both [00:08:03] Other than the obvious ways to measure capacitance in a circuit I dont know how to help haha [00:08:40] Basic RC calculations I learned in physics and when rewiring my guitar with one [00:09:12] https://i.imgur.com/GtHByoK.png [00:09:23] C2 is the only measurement on there I'm not sure of [00:09:44] and I can only measure on numbered pins [00:13:59] if you have a good suggestion for how to do it I'm all ears :D [00:14:46] I am sketching out a simple pin to pin and seeing what I can come up with, no promises! [00:15:05] Yeah R and C parallel with both in series with another R [00:15:14] There has to be a way [00:15:29] yeah, it's just really annoying [00:15:48] I've been able to attack everything so far by being clever with my multimeter, LCR meter, and DC power supply [00:16:00] the one in series + one in parallel breaks all of that :P [00:17:37] Which pins did you use for R3 [00:17:56] To measure it [00:18:18] I measured every permutation of R2, R3, R4, and R6 in pairs, and then solved the resulting system of equations [00:18:45] that was the first step here (other than the obvious pins 8 and 10 for R5) [00:18:59] Yeah that one is simple haha [00:19:36] then for R1 and the D1 voltage drop, I applied +5VDC across pin 1 and pin 4, and then pin 1 and pin 6, and measured the voltage on pin 3 [00:19:48] which gave me a system of 2 equations with 2 unknowns [00:20:23] for C1 I just asked my LCR meter for the capacitance on pins 1 and 2 :P [00:20:52] I am wondering if there is a way to do it from pin 4 to 5 since you know the R3 and R4 [00:21:22] Then you have one parallel component and that in series with a known resistor [00:21:44] so what I am thinking is to charge the capacitor to a known voltage by applying a voltage across 3 and 5, and using 4 to measure what that voltage is [00:21:54] and then disconnecting the power from 3 and watching the decay [00:22:27] yeah we can definitely trust all of the resistances to be correct [00:22:35] no idea what the ESR of the capacitor is or how much that matters [00:24:12] I wonder if my oscilloscope can automatically tell me the time constant [00:24:17] I am a very lazy man [00:25:02] Well if you have t and R you have C haha [00:28:15] Yeah I am functioning on a few beers right now so my RC circuit math is not sharp [00:28:36] I can ask my dad tomorrow, he did that for 20 years in the Navy [00:28:46] come on man RC is your name, this should be your bread and butter :P [00:28:55] I know, right? [00:29:22] Believe me I got that in college too [00:29:39] Chapter on RC circuits [00:29:42] Enough said [00:30:19] I am going to do something less intensive, make a checklist page for the Apollo 13 square one [00:30:29] And then chargine [00:30:31] charging [00:31:21] hahaha [00:32:03] That way I dont have to do it manually every time :P [00:32:57] But yeah, I will ask Niklas tomorrow, but if the CSMLMPower connector can flow both ways, I can make battery charging work with little difficulty [00:33:53] awesome [00:54:24] okay [00:54:28] I think I may have a measurement [00:55:15] I hooked a 5V 1kHz square wave up on pins 4 and 5 [00:55:32] and attached scope probes to pins 4 and 3 [00:56:28] http://i.imgur.com/TiXmhbu.jpg [00:56:52] purple trace is the input square wave [00:57:05] blue is what pin 3 sees [00:57:31] assuming it's kosher to measure the time constant like that, then the cap is something like 69pF [00:57:39] That looks like a nice discharge curve [00:58:34] Such a small capacitance [00:58:40] haha yeah [00:58:53] But they do make those [00:59:01] 68 is a common value I believe [00:59:02] yep [00:59:10] nice, that's probably what this is supposed to be [00:59:33] I knew I have seen that value [00:59:40] Quick google fu confirms it [00:59:59] I think you have a winner [01:00:13] perfect. so that's another fully reverse engineered module [01:00:19] now, how the heck do I use it? :D [01:00:37] Not that a nonstandard capacitor isnt possible, its just more of a sanity check that a crude discharge yielded 69 and a very common value is 68 [01:01:05] 1pF is within the margin of error expected there I am sure [01:01:09] yeah, and that's well within error bands of capacitors [01:01:14] Oh yeah [01:01:17] capacitors are universally garbage [01:01:31] Yet so necessary in electronics [01:01:41] our scottish circuits professor liked to call them crapacitors :D [01:01:53] haha yeah [01:01:54] Haha yeah they are a VERY common point of failure [01:02:21] And believe it or not, it is the number one component to cause a central air system to not function properly [01:02:30] totally believe it [01:02:48] capacitors are the thing I am most scared about with turning on this AGC [01:03:15] The AGC doesnt have any large ones though does it? [01:03:19] they're mostly solid tantalums and could very well have crystallized over the years... and they explode violently [01:03:31] define large [01:03:40] the power supply and memory circuits have some decent sized ones [01:04:03] LArge enough to cause damage when swelling/blowing [01:04:26] unclear [01:04:40] I think the welded cordwood construction actually works in our favor here [01:04:53] because each cap is fit snugly into a metal hole that matches its size [01:04:58] I just don't want to blow any up [01:04:59] My dad always said of its larger than your thumb, wear something to protect yourself [01:05:15] Assuming they are exposed [01:05:26] I did manage to track down one of the types of capacitors that MIT used [01:05:34] it's still made today [01:05:38] https://www.vishay.com/docs/40015/150d.pdf [01:05:58] the Sprague 150D series was one of the parts that held that MIT part number, so the AGC I'm turning on could very well use these [01:06:18] ...I am not sure if this is useful information yet though, haha [01:06:35] Well if you have to replace any... [01:06:55] still going to be a nightmare. everything in the AGC is welded together, there's no solder or anything simple like that [01:07:24] but yes, if I have to replace any I can at least use precisely accurate replacements [01:07:43] What kind of welds? [01:09:42] good question [01:10:22] http://www.jhuapl.edu/techdigest/views/pdfs/V01_N1_1961/V1_N1_1961_Cordwood.pdf [01:12:09] knows practically nothing about welding [01:14:30] Ah [01:14:38] Yeah you arent duplicating that in your garage [01:14:50] Those are very specialized welders [01:15:16] I figure if I have to replace one, I won't actually weld the replacement in [01:15:35] At least now they use laser welding for that [01:15:42] I dont know what was used back then [01:16:47] the goal is to not blow any up, haha [01:16:53] Here is a more "residential" if you will, method [01:16:55] https://www.youtube.com/watch?v=TLOwjMpXOvk [01:16:57] although I don't know if there's anything I can do to prevent it [01:17:14] No, if a capacitor is going to go its going to go [01:19:33] hmmm [01:19:54] that is really unfortunate [01:19:55] Assuming the power is correct, of course [01:20:10] And the way to test a cap? Apply a voltage [01:20:17] and it either blows or doesn't [01:20:22] So damned if you do damned if you dont haha [01:20:24] yeah [01:20:42] so I wonder if it would be better to not risk it and make stand-in modules for the ones with bigger caps [01:21:00] or to risk it and just replace any that go, at the cost of it no longer containing 100% original parts [01:21:13] I guess it really comes down to what the owner thinks [01:21:24] Yeah [01:21:30] Thats gotta be a judgement call [01:22:09] ho hum [01:22:17] guess I shouldn't worry about it until we can discuss in person [01:22:39] in other news... Tiangong-1 is down [01:22:50] as is probable, it came down over the ocean with no real nearby landmasses [01:22:57] Yeah my girlfriend just told me it was off brazil? [01:23:05] https://twitter.com/planet4589/status/980616237406400518 [01:23:11] Atlantic [01:23:51] looks like South Pacific [01:25:45] Oh it was a projection [01:26:14] So it had more drag [01:26:55] Well at least the big "omg its gonna land on someone" is debunked [01:28:56] no good video will come of it though :( [01:30:03] Nope! [01:48:42] night! [01:53:19] A square one checklist is very time consuming [01:53:38] Thankfully its all copy paste but its cherry picking everything [01:53:40] haha I believe it [01:53:58] This will be interesting to try [01:59:57] I also need to ask Niklas if I can make the inboard cut out early on the 13 failure mission :P [02:00:14] I would be curious if the IU can compensate [02:00:25] And how close it would be to the actual [02:02:38] hehehe, yeah that would be cool [02:07:28] Well it was nice to see my weights for the saturn plus his IU implementation yielded almost perfect by the books launch times [02:07:51] So I am hopeful that with the proper weights for 13 it would [02:07:57] :D [02:08:11] Of course 13 is not the scope of this release [02:08:19] But its still fun, and a learning experience [02:08:38] In November, I couldnt write my own class [02:09:10] yeah you've come a really long way! [02:09:21] I mean I am not great by any means [02:09:33] But I am just really grateful for you guys for helping me learn [02:10:06] Woo MDC 1 and 2 done haha, a lot more panels to do for this checklist :/ [02:10:14] hahaha [02:10:30] The square one sets every switch and breaker in the CM [02:17:52] oooof [02:17:55] that is a lot [02:21:18] Yeah [02:21:36] And the LM pwr transfer is just 2 simple pages [02:23:50] I am sure you watch Scott Manley like the rest of us space nerds [02:23:52] https://www.youtube.com/watch?v=Eauxlp1wN8Q [02:23:56] Got a kick out of this one [02:24:12] The chemist in me certainly enjoyed it [02:31:43] oh yes, I saw this but I haven't watched it yet [02:31:45] will do that now [02:36:21] this reminds me, I want to read Ignition! too [02:36:34] I have heard only good things about it [02:38:45] Yeah Manley quotes him in the video [02:39:00] I would love that book [02:39:49] Comes out in May? [02:39:56] yeah it seems right up your alley [02:39:57] what does? [02:40:11] Oh must be a special copy of it on Amazon it says preorder [02:40:21] oh weird [02:40:28] yeah I think it's been out for a while now [02:40:51] Says May 16th on Amazon [02:40:57] haha yeah, published in 1972 [02:41:02] I don't know what Amazon is doing [02:41:43] Oh yeah its a rerelease [02:41:50] The original is much older [02:42:09] 72 I think [02:42:33] gotcha [02:47:36] huh, is it hard to find copies of it? until the rerelease, that is? [02:49:00] I guess our friends at archive.org have it [02:49:26] I am not sure [02:49:33] I will check VT libraries and see [02:49:47] But the rerelease is probably worth it [02:50:06] definitely [02:50:42] preorders [02:50:48] Haha yep I did too [02:50:54] and you should read Don's book if you haven't! [02:51:01] Also on the Amazon list [02:51:11] excellent [02:51:18] I have not yet, I have Kranz's book to finish right now [02:52:00] right on [02:52:40] And then Moon Lander [02:52:48] And then I have Don [02:53:00] *Don's book and also Rocketman [02:53:59] I have been dying to get into Moon Lander with all I have been learning about it [02:54:10] It was written by Tom Kelly [02:54:35] ooooh nice [02:54:42] I'll have to add that to my list too [02:54:55] yeah you have been spending a lot of time in Tom Kelly's head lately :P [02:55:00] No kidding [02:55:07] It has been pretty cool [02:55:19] I know the LM a lot better than I imagined [02:55:29] Its making sense [02:56:12] :D [03:00:40] Ok I am calling it an evening, another beet and a hot tub await haha, take it easy! [03:00:46] goodnight! [03:00:48] beer haha* [03:00:50] Night [03:00:52] hahaha [11:04:07] .tell indy91 so how does dv 84.2 sound for mcc4 [12:35:26] i had to adjust my loi ignition time [14:11:05] Good morning [14:16:03] hey [14:16:43] Hows it going? [14:22:37] just finished LOI on Apollo 13, hopefully make the landing today [14:25:39] Aquarius deserves to touch the surface :) [14:26:04] So the CSM DOI calculations are working right now? [14:26:52] just dont tell Jim Lovell im doing this ;) [14:27:12] yes [14:27:26] Awesome [14:27:47] Last time I did 12 I had to do a normal LOI1 and 2 and then calculate a separate DOI burn [14:27:48] you have to choose "DOI as LOI-2" on Apollo 13 and later [14:28:09] 15 not 12 [14:28:22] And yeah i tried it and it gave me bad numbers [14:28:40] So Niklas suggested just do DOI as a third burn versus a combination LOI2 [14:28:53] right [14:29:01] or you could do 2 DOIs [14:29:40] because the DOI is still valid, but I guess it gave you say 75x8 instead of 60x8, or something like that? [14:29:56] Yeah that sounds right [14:30:33] right, so you burn it, then half an orbit later, you do a 2nd burn to bring 75 down to 60 [14:31:15] thats what I do and works pretty good [14:31:39] Yeah and I cannot imagine it uses much more fuel than the combination burn [14:31:50] The net result is pretty much the same [14:31:57] yeah [14:32:24] I think Niklas said he was going to work on getting that working better soon [14:34:03] oh one thing I found the DOI as LOI-2 work better since he added the optimized MCC+LOI (opt4) [14:34:52] Oh nice [14:36:16] Oh I was going through the LM-->CM power transfer last night, all we need to do is make the LM power a CM bus, and the CM simply routes that to the battery charger to charge the battery [14:36:28] So it is pretty much exactly as it is implemented [14:36:58] Only change that needs to be made (I think) is to compare the bus voltage on either side and direct flow based on that [14:37:18] From there, the CSM is already wired properly to charge batteries from there [14:38:01] Normal LM PWR, the LM bus has a lower potential than the CSM bus feeding it, and thus we get flow into the LM [14:38:21] nice [14:39:20] In 13, the CM main bus is not powered by FC's, but low batteries, so the LM bus has a higher potential than the CM bus [14:41:19] Its remarkably simple actually [14:41:25] Just limited to 15A [14:43:52] I have been trucking through this square one checklist its a pita haha [14:44:28] But I figure its a good thing to have as an auto checklist for the future, same with the powerup procedures [14:45:13] Think I will just make them groups in the default checklists so they are accessible for 13 for now [14:57:37] Have you been in the LM yet? [15:00:15] well nothing beside the LM familiarization during TEC, now I am setting up for DOI [15:00:42] Ah ok [15:00:59] I am curious if the cabin temp came up during TLC, I has an issue with that due to time accel [15:01:05] *had an [15:04:37] in the LM? [15:08:29] Yeah [15:08:58] I kicked on the displays during powerup and found cabin temp off scale high [15:09:09] I didnt power up yet but Ill let you know when I get there [15:09:13] Thanks [15:09:34] Also there have been a few changes to the ECS with heat and cooling I want to make sure it works properly over a mission [15:09:42] I only did a few tests over an hour or so [15:11:30] actually I just checked [15:11:40] it is pegged at the top [15:13:35] Yeah [15:13:40] It does come back down [15:13:48] But its a result of the time accel [15:14:07] No idea what causes it [15:32:07] Gotta run out for lunch [15:36:26] hey guys just wondering is 84.2 dv too high for a mid course correction [15:38:25] @AlexB_88 my original loi was 5 minutes late so i had to go back and adjust my mcc4 loi ignition time and my dv for the burn is 84.2 [15:40:34] what do you mean 5 minutes late? [15:42:23] 5 minutes later then the flight plan? [15:42:27] yes [15:42:38] thats completely normal [15:42:58] does that mean i will have to do the flight plan 5 minutes late too? [15:43:36] I would not worry about that [15:43:49] yeah i don't really feel like doing that honestly [15:43:55] if there is a launch delay with a few hours difference then yes, but not for 5 minutes [15:44:11] good thing i didn't clear my recycle bin [15:44:46] okay [15:44:56] thanks so no need to redo mcc4 then [15:45:53] and also for mcc4 which was 5 fps i did a p30 refsmmat then after burn went to the landing site refsmmat would that be the correct procecure? [15:47:52] after the burn you would do a "Landing site during TLC" REFSMMAT [15:48:11] okay [15:48:32] what mission? [15:48:35] 11 [15:48:47] do you have the flight plan in front of you? [15:49:00] yeah in pdf [15:50:21] ok there should be gimbal angles in that flight plan at LOI [15:50:58] compare those gimbal angles with what you get for your LOI maneuver PAD and if they are very similar, the REFSMMAT is good [15:51:18] k [15:54:21] they match up pretty good [15:54:54] very excited [15:56:16] great [16:18:08] another thing that is different from the activation checklist is that the SYS A&B QUADS TBs are supposed to be gray at initial activation, but they are bp [16:18:32] I wonder if they just need to be initialised open, like the main SOVs are [16:19:57] morning! [16:25:27] AlexB_88 I wonder if they are gray when unpowered? [16:25:31] Morning Mike [16:25:44] If not, you might be right [16:32:18] the checklist says SYS A&B QUADS (8) -tb-gray (vlv open) [16:33:00] so yeah I think they should be open [16:48:14] good evening [16:48:23] good morning! [16:48:37] 84.2 ft/s for MCC-4 sounds not so good [16:57:06] hey Niklas [16:57:28] hey [16:58:07] yeah he was trying to mess with the MCC-4 targeting to get LOI ignition exactly the same as flight plan, because his was 5 minutes off [16:58:42] I told him that 5 minutes is nothing to worry about lol and that just using the pre-mission numbers is fine [17:00:27] yeah, it's quite usual to be off a bit [17:01:12] although for Apollo 10 the reason in the mission report why they arrived 12 minutes late at the Moon was that they skipped MCC-1 and only burned MCC-2 [17:01:14] coming up on LM activation/PDI day for Apollo 13 [17:01:34] on my flight I am 15 minutes late, still am after 2 days in lunar orbit [17:01:42] but I did burn MCC-1 [17:01:51] so I wonder why there is that difference [17:02:52] my LOI was about 2 minutes off [17:03:06] that's not that much, haha [17:03:37] I am adding 2 minutes to all lunar orbit activities ;) [17:04:29] how terrible [17:05:15] for Apollo 14 and later the non-free return maneuver was done so that the timing works out, and not to optimize DV [17:06:01] the real Apollo 11 mission was off by 5 minutes as well [17:06:01] right [17:06:22] LOI-1 TIG from the flight plan: 75:54:28 [17:06:37] actual flight: 75:49:50 [17:13:08] so according the the activation checklist, the 8 SYS A&B QUAD TBs should be gray, valve open upon 1st entry into the LM [17:13:50] I wonder if its another case like the MAIN SOVs that were changed to be initialized to open [17:15:57] which activation checklist? [17:16:24] those valves were removed for the J-Mission flights [17:16:32] A12 [17:17:26] ah, the talkbacks are gray when unpowered [17:17:55] which is why [17:17:55] https://www.hq.nasa.gov/alsj/a12/LM6-co26.jpg [17:18:02] they are already in that state at closeout [17:19:59] and I thought I had implemented them that way, but apparently not [17:21:14] which valves were removed for the J-mission flights? The LGC thrutser pair CMDs? [17:21:49] the thruster isolation valves [17:22:32] so those switches/TB would only indicate jet failures and allow a thruster pair to be disabled in the LGC [17:23:30] ah ok [17:25:06] ah, the DrawSwitch function also checks if a TB should fail open or not [17:26:03] fixed [17:26:31] so it was just an issue with the unpowered state of those TBs [17:27:22] ah thanks [17:27:59] maybe that was the issue with the FUEL VENT & OXID VENT tbs I noted a few days ago [17:28:16] let me check [17:28:21] I dont know if you remember [17:28:26] I remember [17:28:56] they fail closed [17:28:59] so BP [17:29:11] ok [17:31:03] in which mission phase did you have them gray? [17:32:12] ACT-24 of A12 activation check [17:34:34] hmm [17:34:38] same for Apollo 14 [17:34:48] which I also remember checking a few days ago [17:39:54] and the vent valves are shown closed by default [17:40:24] they are in series with explosive valves, so it would be safe to have them open [17:41:26] the venting procedure in the AOH Volume II has the latching valves open before the procedure [17:43:20] I can only assume they were actually launched open [17:43:36] makes sense I guess [17:43:40] but have to find a source on that [17:43:44] right [17:44:16] also, I noticed LS during TLC now has the azimuth parameter [17:44:37] so I used that page to calculate my LS REFSMMAT before LOI [17:44:45] worked pretty good [17:45:50] yeah, I tested it on Apollo 10 as well, seems to work [17:46:06] good enough for the REFSMMAT before LOI [17:46:09] it gets updated anyway [17:46:10] that page used to be the combined MCC-4 and LOI [17:46:15] right [17:46:35] but now I guess you use that page whether you do MCC-4 or not [17:46:58] yeah, it just uses the parameters of the planned lunar orbit [17:47:18] and not with calculated MCC-4 and LOI-1 [17:47:27] so a much easier procedure [17:47:52] but is there a difference with using the LS during TLC, and the landing site page w MCC? [17:48:14] MCC being LOI itself [17:48:57] LS page with MCC will propagate your SV to LOI, simulate the burn and then propagate the trajectory to the planned landing time [17:49:10] right [17:49:12] and then it takes the orbital plane of that state vector for the LS REFSMMAT calculation [17:49:24] because that is all that matters [17:49:36] LS REFSMMAT is defined in-plane of the CSM orbit basically [17:49:44] but just with one axis [17:50:03] and the new LS during TLC option simply calculates that orbital plane from geometrical considerations [17:50:13] LS coordinate plus approach azimuth [17:50:55] the LS with MCC option is probably ever so slightly more accurate [17:51:20] right, because it uses your actual trajectory [17:51:25] yep [17:51:31] or post burn one [17:51:34] yes [17:51:39] but not by any significant amount [17:52:06] in lunar orbit itself the normal LS option should still be used though [17:53:22] right [17:53:35] now that I think about it, did I ever fix the potential issues with the LS REFSMMAT calculation when landed in the LM? [17:53:41] so for the liftoff REFSMMAT? [17:54:04] what issues? [17:59:58] I think the calculation uses the LM state vector for it, and not the CSM one [18:01:07] which, while landed on the Moon, is not identical to the orbital plane of the CSM [18:07:07] I havent noticed any issues with that myself [18:08:21] I'll check it when I get there with the Apollo 11 MCC [18:08:40] I am actually nearly done implementing the Apollo 10 MCC. Just the Entry PAD and then I need to fly and tweak it [18:09:44] nice [18:10:26] Will you do Apollo 11 next, or 9? [18:12:56] maybe 11, not sure yet [18:13:36] what I'd like to achieve with the MCC in NASSP 8 is the ability to support different launch days, at least for all the normal events [18:14:06] when I'm done with the Apollo 11 MCC I'll create a launch scenario for a different launch day to a different landing site [18:14:27] and then I'll try to tweak the MCC to be able to support that [18:14:38] so the MCC would have parameters in the launch scenario [18:14:41] landing site etc. [18:15:39] sounds interesting [18:15:49] what about the presettings? [18:16:04] indy91, I think we can make the LM charge the CM batteries with very little code changes [18:16:20] AlexB_88, we have them from the LVOT [18:16:41] for other launch days/landing sites? [18:16:46] And good afternoon btw [18:17:04] July 15, 16, 18 and 21 [18:17:08] hey Ryan [18:17:26] very little code changes sounds good [18:17:44] We just have to do the same thing that the CSM does to connect to the LM [18:18:15] If connected, it would just compare potential and that would govern what powers what [18:18:39] And from there, the LM simply needs to power a bus in the CM through the LM power breakers, and the CM wiring takes care of it from there [18:18:43] negative power draw should be theoretically possible [18:19:04] All the charge did was let the LM power the CM bus and the bus powered the battery charger [18:19:15] right [18:19:32] So a negative draw based on say potential would be the only change [18:20:48] Assuming CM MNB can take power from the LM PWR breakers [18:20:56] Instead of the other way around [18:21:32] probably not, but the negative power draw might work. Might just need some changes to the DCBus class [18:22:59] the way things are wired together probably prevents doing positive power draw "just the other way around" [18:23:45] but if a DC bus can handle a negative power draw, then this might work [18:24:55] Yeah, a check on potential would be ideal to determine flow, but I dont know if that would mess other things up [18:26:01] implementing potential differences might need a huge overhaul [18:27:03] At the very least if (voltage(source) > voltage(destination)) flow -> [18:27:09] and visa versa [18:27:41] Case by case check could work for the CM to LM interface [18:27:55] But elsewhere yeah I can see it needing work [18:28:48] Which reminds me, not to keep straying off, but do the LM PWR breakers evenly divide the power to allow a total max of 15 amps before popping? [18:30:44] they use a PowerMerge [18:30:50] so yes, they should do that [18:31:30] AlexB_88, I haven't been able to find a source, but looking at the procedures, I am sure the latching vent valves were open at launch [18:32:03] and they were only closed on the lunar surface, once pressure has dropped enough [18:32:33] I also still need to actually implement propellant venting [18:53:45] indy91, do you have the TB fixes ready soon by any chance? [18:54:55] it's up now [18:55:58] great thanks [18:56:24] the vent valves change will only affect a new LM [18:56:43] right [18:58:05] the LGC thruster pair change only an unpowered LM [18:58:16] I checked, they show gray now in a pre activation LM [18:58:26] great [18:59:03] ill be back in a few hours [19:19:35] yeah i had severe issues with the p52 option 1's [19:20:47] @indy91 i cant remember is it the state vector that should be uplinked last or the refsmmat [19:20:54] REFSMMAT [19:21:33] the uplinked REFSMMAT is in a temporary memory location. Uplink anything else after it destroys the uplinked REFSMMAT. [19:21:44] in that case you just need to recalculate and uplink the REFSMMAT [19:22:01] yeah i did the refsmmats last [19:22:33] the option 1 p52's are a real pain [19:23:06] I think you just need to follow the checklist step by step, then you'll get it right [19:23:17] yeah i did [19:23:25] which one? [19:23:47] the new attitudes it gives me are close to gimbal lock the majority of the time [19:24:01] the one in the checklist mfd [19:24:59] yeah, it's possible that the new attitude gets you close to gimbal lock [19:25:16] you might have to maneuver before changing the alignment then [19:25:28] in that case i maneuver away from it slightly then it gives me good results [19:26:40] did you use the pulse torque or coarse alignment option? [19:26:45] coarse [19:27:12] always coarse [19:27:26] ok [19:27:42] and were you just close to gimbal lock or did the computer complain and give you a program alarm? [19:28:45] before the 00013 it gives me a new attitude with VERB 06 NOUN 22 and is that attitude for the alightment? [19:30:36] that is your new attitude after P52 changes you alignment, yes [19:31:06] if you want to maneuver away from gimbal lock, maneuver first, then V32 [19:31:12] then it will calculate a new attitude [19:31:20] but I guess that is what you already did [19:44:04] @indy91 well i am going to do some ctd-less lunar orbit now so i will talk to you later [19:44:17] cya [19:44:20] bye [19:57:00] Time to get on the road and then switch to the hot spot, back in a bit [20:15:17] Gonna be restarting my server's nic. I'm switching over to the new dns from cloudflare. Connection may or may not drop. [20:16:31] Good to go. [20:16:47] My DNS should be ~5x as fast compared to OpenDNS now. :) [20:16:56] just checking :P [20:19:47] I wonder if I can make it autostart somehow. [20:20:25] just autostart it whenever Mike is marked away :D [20:20:45] hahaha [20:31:57] Meeting ended by Thymo, total meeting length 527891 seconds [20:31:57] .endlogging