[10:51:11] NASSP Logging has been started by indy91 [10:51:14] aha! [11:21:38] good morning indy [11:22:53] just one question what would happen if i hit pro for the p23 after a bad mark? [11:24:47] hey [11:24:54] your state vector will be a bit worse [11:25:13] you get new state vectors uplinked regularly [11:25:18] so no big thing [11:25:26] okay [11:25:37] it was just one mark [11:26:05] so i started day two again and i will just skip them [11:26:53] i will try to get to lunar orbit on day four by tonight [11:27:48] yeah, skipping the P23 is no big deal [11:28:04] just don't use more than 50x time acceleration [11:28:13] for getting to day 4 quickly I mean [11:28:31] yeah i used 50x alot with no problems [11:29:56] too bad there is no entry into the lem during tlc [11:31:22] yeah, that was first done on Apollo 11 [11:32:07] i guess i could just go in it as i would like to memorized where the panel numbers are [11:32:17] that didn't take me too long with the cm [11:32:23] sure [11:32:28] and the LM has fewer panels anyway [11:33:24] and do you know yet how the 3d cockpit would work [11:33:44] would it just be you playing one astronaut [11:33:49] well, in a 3D cockpit you can switch between different view points [11:34:14] so there probably would be a preset viewing point for each panel [11:34:20] yeah thats right i forgot [11:34:33] and it will be the same as with 2D panels, you have to do the job of 3 [11:34:58] yeah it is more fun that way there are more things to do [11:35:37] you say that now, before having to do lots of tasks in both CSM and LM [11:35:43] at the same time [11:35:56] for the most part, we are just letting the CSM coast around after undocking [11:36:05] because the more important events are happening in the LM [11:36:36] but prior to undocking you have the maneuver the CSM to different attitudes while at the same time you have to perform the LM activation [11:36:39] can be challenging at times [11:36:50] with V49? [11:37:12] mostly, yes [11:38:01] how long is the lem activation? in apollo 13 he said "three hours by the checklist" [11:38:08] sounds about right [11:38:46] LM activation starts at about 94:30 in the flight plan [11:38:56] undocking at 98:10 [11:41:02] but that is with some time to spare [11:41:26] so 3 hours sounds right when doing it be the checklist, yes [12:23:46] and for some reason my frame rates have gone up suddenly [12:26:30] @indy91 this is not really related to nassp but have you seen this website before? http://apollo17.org/ [12:26:37] I have, yes [12:26:41] it's awesome [12:27:23] maybe you could use some of the audio for apollo 17 in nassp [12:28:40] but i ont know how that would work with time acceleration [12:28:50] don't* [12:29:54] i guess you could just have it in the background and sync the get's [12:30:37] yeah, would be great to use more mission audio [12:31:12] there is quite a bit of apollo 11 audio on the flight journal website [12:31:31] actually, I told you nonsense a few days ago [12:31:40] using mission audio IS supported [12:31:47] we already use that extensively for Apollo 7 [12:31:56] what do you mean? [12:32:06] at least from liftoff to about 3:30h GET [12:32:07] like adding sounds [12:32:09] yep [12:32:25] there is a csmsound.csv file in the Apollo 7 sound folder [12:32:59] and that just needs to be added for more missions, along with more audio files [12:33:28] yeah i wanted to try to add this for the apollo 11 launch starting at -5:10 https://www.honeysucklecreek.net/audio/A11_Network/A11_launch_Network_and_FD_loops_synched.mp3 [12:34:09] it is the flight directors loop on the right channel and network on the left [12:34:18] ah, I see [12:34:31] Sound\ProjectApollo\Apollo11\csmsound.csv [12:34:36] i prefer it to the pao [12:34:38] that's the file controlling what is played when [12:34:49] yeah, the astronauts wouldn't hear the PAO [12:35:17] I don't think mp3 is supported though [12:35:23] yeah i cant find any other flight directors loops for any of the other launches without the pao in it [12:40:03] yeah these sound files are all wav [12:45:12] morning [12:45:14] good morning alex [12:45:28] just adding some sounds for apollo 11 [12:47:30] do you guys have anyone doing sounds right now? [12:47:54] not really [12:48:06] what do you mean by adding sounds? [12:48:54] there is more pre launch audio /PAO/ that isnt in nassp [12:49:29] in the flight journal and i am also going to add the flight directors loop for launch https://www.honeysucklecreek.net/audio/A11_Network/A11_launch_Network_and_FD_loops_synched.mp3 [12:50:03] and some wake up calls as well all from the flight journal website for apollo 11 [12:50:28] hey Alex [12:50:38] just did LM staging and the insertion burn for Apollo 10 [12:50:45] nice [12:50:45] now working on the CSI PAD [12:51:18] astronauthen96__ that is nice stuff [12:51:23] according to an Apollo mission techniques document the ground calculated CSI burn solution is actually the nominal one planned much earlier [12:51:32] before CSM separation even [12:52:39] and i think in nassp you start the gimbal motors at 5:25 but in reality it was at 6 minutes [12:52:43] astronauthen96__ However I think we have enough sounds in the main repo and in my oppinion would interfere with MCC as lots of stuff in MCC are synched to the nominal timeline, and not real-life timeline [12:54:40] in the future sounds could be synced up to the updated landing time [12:54:47] hmm [12:54:48] what do you mean by interfere [12:55:03] although that would only really work with the MCC [12:57:04] MCC sends out things like "mode 1 B" and others like that already [12:59:06] the sounds would have to be dynamic and synced up to MCC or able to cope with aborts and stuff, otherwise they are a nuisance unless you fly exactly as the real timeline, in my opinion [13:09:18] yeah i would probably just add the launch and wakeup calls for my self then in this case [13:09:34] and the go for tli call too [13:10:00] of course [13:10:54] maybe what could be done is a bit like AMSO does and have separate sound packs for those who wish to have all those sounds as well [13:11:15] yeah i remember amso [13:11:46] they had a flight director loop option but of course they didn't have the mcc [13:12:17] one thing to keep in mind is the astronauts cant hear the flight director's loop from inside the spacecraft [13:12:56] but I guess if one wants to hear that, it could be part of the sound pack [13:24:49] @indy91 so if i accepted a bad p23 mark by accident could i just update my state vector with the rtcc? [13:25:54] you could do that. Or wait for the next time the MCC is updating your state vector. [13:26:04] No big deal either way [13:26:21] The next time you really need an accurate state vector is for LOI, and that is some time away [13:26:34] probably tonight [13:26:58] because i dont work today [13:31:49] indy91, I think you told me already but cant remember... What is Docking Initiation Processor (DKI)? [13:32:15] one of the RTCC processors setting up a rendezvous sequence [13:32:50] it calculates a horizontal phasing maneuver setting up a CSI/CDH/TPI sequence with the right DH and the right TPI time [13:33:13] on Apollo 10 it was used to calculate a PDI abort [13:33:15] ah ok [13:35:16] and it would also be used for a bunch of CSM rescue cases [13:35:26] right [13:35:44] is it similar to the rendezvous calculator you spoke of? [13:35:57] or rendezvous profile planner [13:37:17] not really, no. The thing with the RTCC was, it always involved a bunch of manual steps [13:37:39] right [13:38:09] so that rendezvous planner right now only has the Apollo 10 sequence and is necessary to do it automatically [13:38:39] makes sense [13:39:08] the nominal phasing maneuver on Apollo 10 was calculated with the two impulse processor. [13:39:21] basically like the Lambert page of the RTCC MFD with some additional feature [13:39:39] its main task was calculating a NCC/NSR sequence like on Apollo 7 [13:39:47] and that probably would work automatically [13:40:17] that means, it sets up the right DH at the right time to achieve TPI at a desired time [13:40:44] but the additional insertion maneuver and CSI were a bit of a special case for Apollo 10 [13:41:16] I don't think they were able to plan a whole rendezvous with that tool [13:41:34] but they could calculate phasing and insertion as a pair, with input phase and height offsets [13:41:51] and then take the output state vector to calculate a normal rendezvous sequence [13:41:52] right [13:42:07] the manual step in there would be adjusting the TIG of insertion and CSI [13:42:39] that had some support, because those RTCC processor had as the output a range of DHs or arrival times [13:42:40] I love rendezvous talk in the morning :P [13:42:49] haha [13:43:05] Buzz, is that you? [13:43:44] Haha, sadly Dr. rendezvous is not present [13:44:10] so for most rendezvous situations except for the nominal Apollo 10 on there were some tools in the RTCC available that planned it all automatically [13:44:16] one* [13:45:27] what I will probably do is implement the RTCC processors as far as possible and for special cases like Apollo 10 just use a Apollo10RendezvouPlan function that uses a combination of them [13:46:03] but right nows it's all quite ad hoc still [13:46:46] rcflyinghokie, I got a ED RELAYS light at staging [13:48:24] ah I see [13:48:27] the light logic is wrong [13:48:37] for setting the light, you have nested ifs [13:49:11] so the state of the light isn't even determined every timestep in some cases [13:50:30] Hmmm [13:51:08] and what actually inhibits the light is the state of the master arm relay [13:51:55] I asked you about that light at staging actually [13:52:54] "when the master arm switch is on or the abort stage switch depressed, the ed relay caution is disabled" [13:53:04] I remember specifically asking about staging for that [13:53:20] as for the mcc updates hen i add a new build does it add new mcc's as well for my scenario? [13:53:50] rcflyinghokie, there is a staging relay in the ED relay boxes and it is used in the ED internal logic [13:54:02] which is used in the SCEA [13:54:06] and then in the CWEA [13:55:19] because of your nested ifs, the CWEA light is never reset [13:55:22] I know how to fix it [13:56:14] Isnt that how the logic is in the CWEA though [13:57:20] @rcflyinghokie for the apollo 11 launch you have the gimbal motors at 5:25 but in reality they were started at 6 minutes [13:57:42] no, the problem with your code is that if the ED relay box is unarmed, neither light on or light off functions are ever called [13:58:14] Oh I see [13:58:36] So what is the fix, 1 if statement? [13:59:27] basically [13:59:35] and I am researching the actual inhibit [13:59:44] astronauthen96__ we do not have an apollo 11 launch checklist [13:59:46] it's certainly the master arm relays [14:00:00] I just don't if through the SCEA or directly, I'll find out [14:00:19] yeah in the flight directors loop neil says "were go at 6 minutes, starting the gimbal motors" [14:00:27] Well the CWEA has an input for the master arm on and abort stage off positions [14:00:40] astronauthen96__, as long as you don't progress past where I am currently implementing the MCC for Apollo 10 you will not have to change anything about your scenarios [14:00:50] okay [14:00:58] rcflyinghokie, yes, but only indirectly [14:01:22] it says that in the description, but it's actually the master arm relays, that has the exact same conditions [14:01:34] abort stage or the master arm switch up [14:01:39] @indy91 okay [14:01:54] Then what signal is connected to that AND gate [14:02:09] that's what I am trying to find out [14:02:22] probably directly or indirectly the master arm relays of each ED relay box [14:02:53] although, in other cases it is the switches inhibiting something [14:02:57] so not 100% sure yet [14:03:22] Ok [14:03:43] AlexB_88, TLE is ready whenever you can find some way to make a strobe [14:05:18] sure, I'll do that now [14:05:21] And astronauthen96__ I will be adjusting launch timings on all missions soon anyways as there has been a lot done to the LVDC, and some of the current timings are a hybridization between a flight plan and the actual sim events [14:06:14] indy91, rcflyinghokie, I have found something: If you arm the ascent stage, and the master arm is on, staging will happen regardless of the abort stage switch [14:06:23] ah, found it. It's different than I thought. It's actually the master arm switch OR K19 in S&C control assembly 1 [14:06:44] AlexB_88, yes, that is normal [14:06:52] ah ok [14:07:06] firing command to the APS causes staging [14:07:25] right lol of course [14:07:58] So K19 also feeds that AND gate? [14:08:18] yes, K19 is abort staging command [14:08:35] So better to use that than the switch in the logic [14:08:38] yep [14:08:45] I'm changing it [14:08:48] Thanks [14:09:02] As you probably saw I forgot CWEA heat with my initial PR [14:09:12] right [14:09:16] So now we have 2 less systems that need heat implemented [14:09:30] is there a good example of a vessel using the strobe? [14:09:42] Delta glider? [14:09:45] so I can use as a template [14:09:49] does it? [14:09:52] I am pretty sure [14:09:55] ok [14:10:13] the DG is a good example for any Orbiter coding [14:10:18] Not sure if its on the original but its on the version IV [14:10:21] right [14:10:39] some other vessels weren't updated much for Orbiter 2016, but the default DG is usually state of the art [14:11:45] Yeah the default DG has a strobe [14:12:07] And the wingtips are white ones [14:12:34] DG also has nav lights [14:12:39] As does the CSM and LM [14:13:10] I pushed a bunch of scary RTCC updates [14:13:14] could break a lot [14:13:21] especially the MCC [14:13:27] ok next stupid question: How do I turn them on :D [14:13:40] but it has now partial APS support [14:13:46] in the DG Alex? [14:13:58] yeah [14:14:00] no switch [14:14:01] overhead panel [14:14:06] CTRL up [14:14:08] ah [14:14:19] Should be a few switches [14:15:25] Oh indy91, I dont know if it is a big deal but many timesteps use different names, "TimeStep" or Timestep" [14:15:38] Would it be a good idea to choose a convention and stick with it? [14:15:49] yes, I prefer Timestep [14:16:08] I changed a few Systemstimesteps so they are all the same as only 3 were different I believe [14:16:20] I can clean up the timesteps as well [14:16:36] I prefer Timestep as well [14:16:48] the capital just invites issues IMO [14:21:41] no real need to search for all of them [14:22:02] just change it whenever you stumble upon one [14:22:08] Sure [14:29:20] I did some last night I think I have 6 left I am just going to do it haha [14:34:50] Done with all those in lemsystems [14:38:22] PR up with that [14:38:44] Ah hold on [14:38:47] Forgot 2 [14:39:01] merged [14:39:03] too late [14:39:18] Haha I will have the fixed ones up [14:39:56] I only did the LM ones though, not the CM side [14:40:25] Checking for errors then I will PR again [14:41:56] There [14:42:00] Now it should build properly [14:43:19] merged [14:45:06] AlexB_88, any luck with the strobe? [14:48:07] not yet, still analyzing the DG code [15:08:37] i want to confirm, "anyone" can make videos of nassp? [15:09:49] people who don't have NASSP probably can't [15:09:56] but all others can [15:10:00] okay [15:10:09] i am going to go back to mcc1 and maybe record it [15:10:22] sure [15:10:27] and i will post some p23 videos and maybe someone could show me what i am doing wrong [15:11:12] I am sure you aren't doing much wrong. It's just very tricky to figure out. [15:11:36] There actually exists a video of a real micourse correction. Apollo 12: https://www.youtube.com/watch?v=ye2xqpVDyZc [15:11:57] so, they had onboard TV while the MCC was going on [15:12:10] pretty fun to watch the same procedures we have done so many times [15:12:15] i have seen that before [15:12:18] very interesting [15:12:42] they had one for apollo 13 mcc2 [15:13:15] oh speaking of which, did you guys know there is a real-life video of inside a block 1 CSM during launch/boost that is facing the instrument panel? [15:14:08] yeah there was on for the apollo soyuz mission filmed live in the cm for launch [15:15:08] really? did not know that [15:15:31] @indy91 its at 43:45 into this video https://www.youtube.com/watch?v=ezckueX38u8&index=7&list=PLC1yaZz2qeGqg8dvPgwcY9UFVlFMIjDmW [15:16:19] @AlexB_88 here is the video https://www.youtube.com/watch?v=cq12RdNLIA4&t=169s look at one minute [15:16:52] I knew about the ASTP video and the Apollo 6 (or 4?) video [15:18:02] I hadn't seen the Apollo 13 one [15:18:26] the burn is at 43:45 in the video [15:19:03] actually a couple of seconds after that [15:19:32] Apollo 12 video has a better viewpoint. But now I know that there was more than one MCC filmed [15:19:40] indy91, for the inverter code, this line: [15:19:41] dc_input->DrawPower(power_load*2.5); // Add inefficiency [15:19:57] What percentage inefficiency is that adding? [15:20:14] Seems like a lot [15:20:59] I am trying to convert the inefficiency to heat for a heat load [15:21:06] and also on apollo 11 had a little nap at 10:32 https://www.youtube.com/watch?v=g7s-44nt6Js&index=2&list=PLOFH9q50V_sfbbH_qAVtb8bV8H1yEI6FL about 30 seconds in [15:21:21] i guess neil was tired [15:22:49] factor 2.5, that seems really a lot [15:23:03] probably adds 150% inefficiency [15:23:10] Thats what I figured as well [15:23:16] Thats why i thought I was missing something [15:23:37] Could be part of the large power drain on the asc bats as well [15:23:41] @rcflyinghokie i found another hidden delay in your checklists [15:24:37] in the p40 sps checklist for the gimbal test when your turn those dials for the second test there is a delay between each turning of the knob [15:24:40] There are many hidden delays in there [15:24:57] They are supposed to be [15:28:00] the CSM inverter has a quite detailed logic for the inverter inefficiency [15:28:14] I am sure this LM logic is wrong [15:28:17] Yeah I was looking at that [15:28:31] might be another hack done to get the displays during LM activation right [15:28:39] when there weren't so many systems implemented [15:29:00] Now I wonder how similar the two systems inverters are [15:29:24] Could the inverter in esystems be used safely in the LM [15:33:38] no [15:35:04] does the LM AC even have three phases? [15:36:06] no [15:36:09] it's single phase [15:36:24] so we just need to find better numbers for the LM [15:36:27] Yeah [15:36:43] I have operating parameters but no efficiency yet [15:38:09] aha! [15:38:15] LM-1 to the rescue [15:38:23] LM-1 Systems Handbook page 20 [15:39:28] I'll implement that [15:40:05] Wonderful! [15:40:13] I keep forgetting to look in there [15:40:37] yeah, it's quite useful [15:40:51] I'm sure the LM Data Book would have the sam graph [15:40:54] same* [15:42:22] I added the heatloads locally to the INV class [15:42:36] At least the pointers [15:43:41] And that will leave heat needed in only: LGC, CDU, PSA, LCA, DSE, PTA, & ECA [15:43:59] And of course other systems that can potentially put heat into the cabin [15:44:10] But that is down the road a ways [15:51:49] I actually forgot to put a crew in the LM on my Apollo 10 flight [15:51:52] so for the TLE light the function is BEACONLIGHTSPEC I think [15:52:06] maybe the checklist MFD should have a reminder for that? [15:52:28] I can add it to the IVT groups [15:52:38] yeah, probably makes sense [15:52:52] rcflyinghokie, do you have a document that describes the strobe light? [15:53:01] Ad a matter of fact yes [15:53:03] As* [15:53:26] Let me get you some pages [15:53:48] The handbook and AOH differ slightly [15:54:08] But pg 48 of the LM-8 handbook [15:54:26] And pg 551 of LM 10 AOH vol 1 [15:54:42] The AOH says 60 fpm [15:54:54] Handbook says 45 [15:56:17] The AOH also shows locations of the docking lights [15:56:41] good [15:57:03] But between those two sections of those two docs you should have all the info [15:57:13] Including colors of everything and intensities [15:57:29] we just have to decide if we want 60 fpm or 45 fpm [15:57:47] theres just 1 light, right? [16:01:42] Tracking? Yes [16:01:48] The big one right in the front [16:01:59] Looks like a headlight haha [16:02:03] right [16:02:22] max range 400 NM [16:04:27] Through the sextant [16:04:59] 130 I think was visual [16:09:38] yeah [16:09:56] dont know if we can make it like that in the sim [16:10:09] probably going to be 400 NM sextant and visual [16:10:35] unless FOV effects the viewing distance [16:11:31] Yeah that should be ok [16:20:32] morning! [16:21:40] Hey mike [16:22:02] rcflyinghokie, ok 1st step done. Got the light to display in the sim [16:22:37] Awesome [16:23:28] I haven't added it to the TLE Timestep yet, still working on getting it properly positioned, and adjusting all the parameters [16:23:39] Well it is all ready for you [16:23:46] great [16:24:01] if (IsPowered()) { [16:24:09] right [16:24:09] Then whatever is needed to turn it on [16:24:14] very easy then [16:42:07] those 40W idle inverter heat loss are probably why they usually only had one running [16:45:44] Hey [16:46:47] So a friend of mine is at the National Air and Space museum apparently right now. [16:47:53] Ah right down the street from me [16:48:10] The one on the Mall or at Dulles? [16:48:21] The one with Skylab 4. [16:48:30] Trying to convince him to steal the AGC. :p [16:49:02] The mall [16:49:06] hello @Thymo [16:49:16] Hey astronauthen96__ [16:49:31] just having fun with some ctd-less nassp [16:49:57] Yeah Niklas tried to convince me to steal the Apollo 11 checklists when i was there a few weeks ago [16:50:08] Which by the way I have not heard anything back about which is a bummer [16:50:12] did they not let you have it? [16:50:48] Well they have to approve scans of it [16:51:17] indy91 you mean the ones in the CM? [16:51:20] yeah they would be neat to have [16:51:45] in Ron's and my experience, Smithsonian time runs quite a bit slower than real time [16:52:16] I would honestly have been surprised if something already came of that, haha [16:52:48] It sucks because I am so close to it yet so far [16:52:57] yeah [16:53:00] is that where you get your agc stuff from? [16:53:58] we've gotten scans of some things from them, but it is a long process [16:54:29] i know there was an apollo 11 lem timeline on here earlier does anyone have the link to it? [16:55:11] http://www.ibiblio.org/apollo/Documents/Apollo11-LM-TimelineBook-excerpts.pdf [16:55:30] thanks [16:55:37] also speaking of [16:55:40] the Timeline Books all start after undocking [16:55:49] did any of you ever email Debbie about the LM Data Book? [16:55:50] rcflyinghokie, no, I meant the ones in the LM [16:56:14] i guess there is no apollo 10 one or is there? [16:57:08] thewonderidiot, I never did, no [16:57:29] astronauthen96__, that's actually a good question. I am not quite sure which document was used for which phase [16:57:36] there was a LM Rendezvous checklist [16:57:48] which might or might not cover everything from undocking on [16:57:54] indy91 well you can only have one on at a time anyways [16:59:02] that is not correct [16:59:26] inverters->inverter switch->AC buses [16:59:38] the inverters are only switched on and off with the CB [16:59:44] Oh I did not know that [16:59:50] is there a link to the rendezvous checklist , i cant find it in the documents section [17:00:15] we do not have the flown copy of that [17:00:25] there is a good rendezvous procedures document [17:00:34] but that one only starts after the phasing maneuver [17:00:41] so it doesn't have undocking through phasing [17:00:55] We have an older phasing summary for 10 though [17:01:14] http://www.icollector.com/Apollo-10-Complete-LM-Flown-Rendezvous-Checklist_i7871530 [17:01:28] only $35,000 if you can afford it [17:01:33] well, 10 years ago [17:01:46] Wish we could find the current owner [17:02:42] there have to be more copies of it [17:02:48] unfortunately there never were many of these [17:04:10] i know there are csm and lm rendezvous procedures for apollo 10 but i can't find the differences between them [17:05:33] the LM rendezvous procedures document has mostly the nominal LM timeline for rendezvous [17:05:42] okay [17:05:44] the CSM one has the CSM timeline and a lot of rescue and abort cases [17:06:06] you will find that the CSM document is much more extensive than the LM one [17:06:41] so yeah, the LM rendezvous procedures document is a great resource and I think it was for the Checklist MFD procedures a lot [17:06:48] it just doesn't cover everything [17:07:14] yeah it would be great to study during my trans lunar coast [17:07:48] so if i get the hang of the apollo 10 rendezvous i guess apollo 11 wouldn't be much different? [17:08:00] 11 is probably easier [17:08:09] 10 had extra maneuvers [17:08:25] In order to simulate the position the LM would be in a nominal liftoff from the surface [17:08:37] And fuel remaining etc [17:09:58] will there be some marks with the sextant? [17:10:39] The way the sim is set up, you will be flying the LM for almost the entire time [17:11:48] indy91, any luck with the inverter? [17:13:00] astronauthen96__, you will be mostly busy in the LM. The CSM would have taken some marks and also used VHF ranging for automatic marks, but that isn't implemented yet [17:13:35] rcflyinghokie, luck isn't a factor, just takes a bit. I've taken 19 data points from the graph and will now implement that for the heat loss. [17:14:09] I'm adding a heatloss variable, just as an intermediate variable. that can be used to call the heatload function then [17:14:28] Oh I see [17:15:17] Now who is adding complexity :P I approve! [17:16:44] and is there a document to record systems data in? [17:16:46] the CSM inverter uses 30 data points! Clearly this is a step down [17:19:03] Haha [17:19:33] I am curious to see what effect this has on the power consumption [17:19:51] yeah, should be interesting [17:20:05] a fully powered up LM will probably consume less power [17:20:20] Which is good considering how many new systems draw power now [17:20:30] Maybe we wont get those DC BUS lights [17:21:42] the cutoff wattage is about 30W [17:22:01] in the previous implementation, 30W or less AC bus demand would have consumed less power [17:22:13] but anything beyond that would have consumed a lot more [17:22:18] which probably is the case [17:22:31] never mind i found it [17:22:41] what have you found? [17:22:58] a page to record systems data [17:23:05] having a hard time getting the light so stay visible from long ranges [17:23:16] for the systems checks [17:25:14] where did you find that? [17:25:53] in the docs folder Apollo 8 Flightplan vAGC [17:26:14] it is under flight data [17:26:47] ah [17:26:58] I thought you meant one specifically for 10 [17:27:13] is there one? [17:27:45] I'm not even sure most missions actually wrote down systems data [17:29:15] Probably just 7 and 8 for consumables analysis [17:29:36] But most of that data was TM'd and recorded [17:30:05] Or just voiced down when asked for by MCCH [17:31:02] and in some cases MCC-H could assemble better estimates for consumables from telemetry readings [17:31:44] than were available onboard [17:31:54] Very true [17:32:07] They had a lot more data points than the crew had to display [17:36:30] I have 47W AC power output in my Apollo 10 scenario, ascent stage [17:36:39] 85W with the descent stage [17:36:49] so there definitely will be less power consumption [17:37:06] for the 85W it was 212.5W [17:37:18] and now is 134W [17:37:41] quite the difference [17:37:44] Yeah [17:38:12] I think that in itself will prevent the DC BUS light [17:38:20] I agree [17:38:36] that and the battery voltage change we did should fix most of the LM power issues [17:38:42] good find! [17:38:51] I never really looked at the inverter code before [17:39:11] I started adding heat for more systems last night and stumbled upon it [17:39:23] I was like power*2.5, wow [17:40:03] I have the heat load pointers added locally, will that conflict with your additions? [17:40:22] that 2.5 factor is exactly right for 16W [17:40:32] it probably will, yes [17:40:37] Ok [17:40:48] but, not very difficult conflicts [17:40:52] Nah [17:40:56] have you solved git conflicts before? [17:41:05] I have using VS [17:41:18] In the team explorer [17:42:51] ok [17:42:55] shouldn't be too bad [17:43:10] I just added some new variables and functions to the inverter class [17:43:34] I should be able to handle it and make a PR with the changes plus the checklist additions with some ECS reminders [17:46:35] update pushed [17:49:57] I was looking at your latest commit [17:50:09] and got confused where the old inverter init call went [17:50:24] but apparently that function was never called before [17:52:00] Nope [17:52:04] oh, these look fun: [17:52:05] http://www.collectspace.com/review/orion_em1_trajectorychart01-lg.jpg [17:52:10] http://www.collectspace.com/review/orion_em2_trajectorychart01-lg.jpg [17:53:47] Hmm its not doing what i want in VS [17:53:52] I have the conflict open [17:54:01] I have a section of code I can check on both files [17:54:59] Oh its working never mind [17:55:12] lol [17:55:42] I wonder if some day in 50 years a small group of fans will be working on a NASSP equivalent for Orion [17:55:49] searching for LVOT's for the EM-1 SLS [17:56:14] assuming it ever flies, of course :P [17:59:24] So heatloss is the heat in watts? [17:59:41] ik I have my preliminary track light ready [17:59:45] ok* [18:00:03] and its called by the TLE Timestep [18:00:54] still haven't figured out how to get it to be visible at long range, but everything else should be good [18:01:28] All fine tuning from here [18:01:53] Now, what about dock lights :P [18:02:04] The nav lights on the delta glider should be a good representation [18:03:34] sure, I'll do all of them [18:03:52] indy91, assuming "heatloss" is the proper heat generated for the inverters in watts, it is all ready to PR [18:03:59] and there is one on the SIVB on Apollo 7, isn't there^ [18:04:41] I am not sure [18:06:01] I have learned a lot about the lights and how they work in conjunction with the SLA [18:06:06] For the LM [18:07:50] For example the docking target and docking lights come on when the SLA panels are jettisoned [18:08:59] And when on CSM power, the lights turn back off [18:09:04] Via relays [18:09:13] I guess that should all be possible [18:09:53] oh, but that would be in the SIVB vessel [18:09:55] For the current set up, you would make the SIVB/LM mesh with docking lights on [18:10:05] yeah [18:10:24] And since we cannot power the LM anyways until ejection, the docking lights would start on [18:10:47] I have a PR ready in a sec [18:10:51] for the main repo [18:10:52] And turn off using the CSM PWR and the appropriate relays which shouldnt be hard [18:11:03] Mine is up as well with the inverter heat [18:11:22] Back in a few [18:22:17] PR sent [18:22:17] indy91, I sent the track light PR to the main repo, just noticed Ryan and a PR after the fact. We are both modifying LM.h and lemsystems.cpp. Will that cause any issues? [18:22:30] Ryan had a PR* [18:27:24] holy wow [18:27:26] https://i.imgur.com/wneopka.jpg [18:27:44] I might be able to actually get some pinout information for intertray connector A62 from that picture [18:29:05] pretty neat [18:32:54] hahaha, he has one other picture [18:32:56] https://i.imgur.com/BOCmgXQ.jpg [18:33:17] I wonder if I can use my database to identify where in the AGC this is [18:34:03] @thewonderidiot i was actually thinking about that for orion [18:36:03] I'll merge Ryan's PR first [18:37:50] seems like the one from Alex is mergable [18:38:55] hmm [18:39:43] I'm not sure your code is good for staging, AlexB_88 [18:40:23] Ive tested it and works through staging [18:42:21] you sure it doesn't display two beacons after staging? [18:42:49] ClearBeacons() [18:43:16] it might be better to add this at the same place as the ClearMeshes() function [18:43:28] ok [18:43:31] so a few times in lemmeshes [18:43:35] right [18:43:51] something strange is happening i am getting bad results with my p52's [18:45:03] is this your first P52 since the PTC REFSMMAT was uplinked? [18:45:15] I also have a better way of handling the different versions of the light for ascent/descent stage [18:45:47] like instead of having SetTrackLight(); and SetTrackLightAscent(); I have added a stage check in SetTrackLight(); [18:46:00] @indy91 first one of the second day [18:46:15] AlexB_88, sounds good [18:46:16] if (stage == 2) { [18:46:16] beaconPos = _V(0.053, -0.41, 2.576); [18:46:17] } [18:46:17] else { [18:46:18] beaconPos = _V(0.05, 1.44, 2.58); [18:46:18] } [18:46:25] ah wait [18:46:29] that variable is static [18:47:07] could still work well [18:47:16] I tested it and does [18:47:37] how is the variable defined in your code? [18:47:49] I initialized it to static VECTOR3 beaconPos = _V(0, 0, 0); at the beginning of the function [18:47:49] it probably has to be static VECTOR3 in both if and else [18:47:53] hmm [18:47:56] i must have done something wrong [18:49:07] AlexB_88, I don't think this all will work [18:49:22] static variables are tricky [18:49:28] especially if defined in a function [18:49:37] can I make it another type then? [18:49:40] nope [18:50:03] I ran into really bad issues with this when I implemented the LEM launch on a Saturn [18:50:13] an animation that is also defined like that [18:50:37] ok Ill stick with the original plan for now and just have the 2 functions SetTrackLight(); and SetTrackLightAscent(); [18:51:08] and add the ClearMeshes() [18:51:18] ClearBeacons()* [18:54:17] the DG has it easier, it never changes its "shape". So it can simply define the beacons in clbkSetClassCaps [18:55:01] Back [18:55:32] is the way I have it in the PR ok for now? with the separate functions? [18:57:04] or maybe I could use another static variable for the ascent stage like static VECTOR3 beaconPosAsc [18:57:28] hmm, actually [18:57:34] no static variables at all [18:57:41] static VECTOR3 beaconPos = _V(0.05, 1.44, 2.58); [18:57:47] trackLight.pos = &beaconPos; [18:58:00] instead do [18:58:01] trackLight.pos = _V(0.05, 1.44, 2.58); [18:58:04] does that work? [18:58:23] if yes, then you can use a single function as well [18:58:45] and then just add the ClearBeacons() [18:59:13] nope but trackLight.pos = &_V(0.05, 1.44, 2.58); works [18:59:20] with the & [18:59:38] hmm [18:59:54] no, then it needs to be static variables [19:00:08] or else it gives no suitable conversion from VECTOR3 to VECTOR3 exits [19:00:47] right [19:02:12] but how about this [19:02:12] static VECTOR3 beaconPos = _V(0.05, 1.44, 2.58); [19:02:13] static VECTOR3 beaconPosAsc = _V(0.053, -0.41, 2.576); [19:02:14] static VECTOR3 beaconCol = _V(1, 1, 1); [19:02:14] trackLight.shape = BEACONSHAPE_STAR; [19:02:15] if (stage == 2) { [19:02:15] trackLight.pos = &beaconPosAsc; [19:02:18] } [19:02:20] else { [19:02:22] trackLight.pos = &beaconPos; [19:02:24] } [19:02:43] yes, that probably will work [19:03:06] Ill test it with all the stage configs and with staging [19:03:20] see, I don't know very much about static variables. All I know is that we have to be careful, because it has caused me major headaches before. [19:03:32] Just trying to prevent adding code that give random CTDs or so [19:03:58] right, better be safe then sorry [19:08:52] ok seems to work well [19:09:26] now, I need to amend my PR [19:09:48] I've done a bit of reading on static variables in a function, and I think that should be safe to do [19:09:55] but 1st I guess I have to merge Ryan's change into my repo [19:11:24] And resolve conflict if any exist [19:12:19] there weren't any, luckily [19:12:30] at least Github told I could simply merge the 2nd PR [19:12:34] told me* [19:12:55] ill amend it in a sec [19:13:34] Nice [19:14:30] I still need to fix the inverter class. Right now it doesn't calculate or have a heat load, when the inverter is on, but not connected [19:15:30] Oh Alex, in your TLE addition, you should just need if (IsPowered()) since that function is contained in the class [19:15:42] You wont need LEM_TLE::ISPowered() [19:16:38] do you know what might be causing my bad p52 results? [19:17:02] how exactly are they bad? [19:17:07] large star angle difference? [19:17:16] the numbers are pretty high [19:17:41] did you ever do the P52 option 1 after the PTC REFSMMAT uplink? [19:17:42] Are you using the sextant or the telescope? [19:17:52] yes [19:18:12] yeah i did once @indy91 [19:18:19] the sextant [19:18:26] ok PR is amended [19:18:32] I remember you had issues with it the first time [19:18:40] but i had to change one star because the lem was in the way [19:18:52] Yeah that happens [19:18:55] rcflyinghokie, ok [19:19:31] the first option 1 was good [19:19:55] the option 1 will have changed your REFSMMAT. Followed by a normal realignment like in option 3. [19:20:11] If something interrupts the REFSMMAT change then it could have broken your P52s [19:20:24] ah, i meant the first option 3 after the ptc refsmat was good [19:21:01] what about the option 1? It never changes the REFSMMAT if you don't complete a P52 option 1. [19:21:15] and PR re-re-Amended [19:21:16] option one was good [19:21:20] ok [19:21:31] i will time accelerate to it again and then try it [19:21:32] exit out of P52, zero your optics and try again [19:22:02] PR merged [19:22:08] thanks [19:23:13] I got in the first little boards for this project! ^_^ [19:23:29] https://i.imgur.com/YB4mpd7.png [19:23:42] indy91, so static VECTOR3 beaconPos can be defined again in future separate functions that will define other lights (ie docking lights) correct? [19:24:15] I won't have to find a separate name for that variable, if its in a different function^ [19:25:32] If it's defined class wide you can use it in any function within that class. [19:25:46] it's not defined class wide [19:26:24] Very nice track light! [19:26:26] if you define a static variable in a method (function of a class) then the function owns that variable. Not the instance of the function, but the function itself, which will only exist once, even if you define instances of the class multiple times [19:26:30] thanks [19:26:46] its 60/min right now [19:26:52] and it's also safe to call the function which defines the static multiple times [19:27:08] so in memory the variable will only exist once [19:27:13] thewonderidiot: Nice! What laptop is that by the way? Looks like Thinkpad Edge E*? [19:27:28] P50 [19:27:37] ok so I can use the same names of that variable for future functions [19:27:38] I'm not looking forward to soldering a pin into each of these holes lol [19:28:06] @thewonderidiot are you building a dsky? [19:28:09] I am not sure if the docking lights should have their own class or be part of the LCA, I am thinking the latter though [19:28:36] that is one of the things, yeah, but that's not what these are for ;) [19:28:44] thewonderidiot: Ah. I have an E550, keyboards look very similair. [19:29:27] I have a E130. Unfortunately it has fallen apart fairly quickly, but it's still usable, haha [19:29:36] Looking forward to hear if that AGC is still operable Mike. :) [19:30:12] haha, me too. it's still a ways out [19:30:21] My E550 is working great. Fingerprint reader is practically useless though. [19:30:40] @indy91 and what does pressing the E key do, it gives me a prog light [19:30:54] astronauthen96__, with that you can reject a mark you just did [19:31:13] basically for the situation where you did a mark, but weren't actually happy with it [19:31:27] thewonderidiot: When I have some time I might have a fun little project. [19:31:40] it only works if the AGC has stored recent mark data, so usually pressing that will give you a program alarm [19:31:48] Thymo: oh yeah? [19:31:49] I've got one of these from college for a PR project I'm helping with. https://en.wikipedia.org/wiki/Sphero [19:32:10] ah, I've seen one of those [19:32:21] It's basically an IMU/Segway toy. [19:32:35] You can get the raw IMU angles using the API. [19:32:43] Might be fun to hook that up to yaAGC. [19:32:59] go for it [19:33:42] I do need to get the Python API running though. I even had to port it from py2.7 [19:33:51] It's still facing some connection issues. [19:34:53] The Android API does work though, but that won't be useful for yaAGC. At least not until I finish my other project I'm working on. [19:41:51] @indy91 this is my second refsmat after the ptc one, i will try the option 3 one again [19:42:37] near the first rest period it asked to press pro if the ptc refsmat had not been uplinked si i pressed pro by accident [19:42:38] what do you mean with second REFSMMAT? [19:43:16] next step for the track light: figure out how to get it to be visible from 400 nm [19:43:31] okay, there was a ptc refsmat before mcc1, then there was one option 3 refsmat after that and now on day two there is another option 3 [19:45:52] rcflyinghokie, is the LM docking target back lit? [19:46:11] Yeah it is [19:47:30] Radioluminescent green [19:48:37] hmm I wonder how that could be implemented [19:49:08] Maybe just the current background or a green one? [19:49:29] it would have to be added to the docking target texture [19:49:57] I cannot seem to find the power control for it yet though [19:50:50] Oh its self luminous [19:51:02] oh [19:51:13] Duh "radioluminescent" [19:51:38] @indy91 okay so i went back to day and i tried that first p52 option 3 after the ptc refsmat and it couldn't even lock onto the star it was way off [19:52:00] ill just make the docking target background texture have a slight green glow [19:52:05] Yeah [19:52:40] The target in the CSM was lit my CSM power [19:52:50] But the LM target was radioactive glow [19:53:01] lit by* CSM [19:54:30] You can see the discs clearly glowing (though you cant see that it is green) in this video [19:54:32] https://www.youtube.com/watch?v=QPXwVPPS6X0 [19:54:40] maybe it has something to do with that crappy p23 mark that i accepted by mistake [19:54:57] astronauthen96__, then something went wrong during the P52 option 1 that aligned your IMU to the PTC alignment [19:55:48] okay i will try it again [19:55:52] might have to study that P52 option 1 procedure [19:56:12] I know you got confused with the 2 options you have, torquing and coarse alignment [19:56:26] these options actually didn't exist in the CMC prior to Apollo 10 [19:56:26] i chose coarse i think [19:56:29] i hit pro [19:56:39] then you will get a NO ATT light [19:56:44] yes [19:56:46] IMU attitude changes quickly [19:57:00] NO ATT light goes out and you do the normal realignment [19:57:10] do you think that would have messed up my mcc1 [19:57:51] it might have, but that's not clear to me yet [19:58:01] that your alignment was actually for the MCC [19:58:09] it could all be good [19:58:24] i will go back anyways and try it again [19:58:50] if you insist, haha. It's probably all fixable in your current scenario [19:59:02] how could it be fixed [19:59:32] Good SV, good REFSMMAT uplink, and a good P52 [19:59:38] okay [19:59:46] I can take a look at your current scenario, to see what exactly is wrong [19:59:50] okay [19:59:54] one second [20:02:31] @indy91 https://www.dropbox.com/s/u90mak1h9w07ufu/BEGIN%20DAY%202.scn?dl=0 [20:04:02] first check, MCC-2 calculation [20:04:04] 2 ft/s [20:04:08] your trajectory is good [20:04:45] that is great to hear [20:05:53] did you do P52 option 1 twice perhaps? [20:06:01] not directly back to back [20:06:04] i think i did [20:06:30] ok, quick lesson how P52 option 1 works on the computer side. [20:06:46] an uplink for it (like the PTC REFSMMAT) is stored in a temporary location [20:07:12] that's why that type of uplink is called "Desired REFSMMAT", not REFSMMAT itself [20:07:28] during a P52 you still need a valid REFSMMAT all the time [20:07:46] so the actual REFSMMAT is overwritten with the temporary one during the P52 option 1. [20:08:07] now, there is one annoying thing about the temporary REFSMMAT [20:08:11] its location gets reused [20:08:24] i am fairly sure there was an option 3 p52 between the first option 1 and the second option one that i mistakenly did [20:08:25] that has broken many CMCs [20:08:50] so, if any other uplink is done after the PTC REFSMMAT, like a state vector update [20:08:50] but i don't think that was the problem [20:09:00] that overwrites the temporary REFSMMAT [20:09:06] and if you then do another P52 option 1 [20:09:25] it will use nonsense for your REFSMMAT [20:09:31] so what happens if i do a second option 1? [20:09:32] because the uplinked one was overwritten [20:09:54] as long as nothing else was uplinked in between two option 1s, then it's safe to do [20:10:04] but I bet there was a state vector update in between [20:10:12] and that will have broken the temporary REFSMMAT [20:10:24] and thus broken your actual one as well during the second P52 option 1 [20:10:24] so did you find anything wrong [20:12:23] started a P52 in your scenario, but forgot to power up the optics [20:12:28] have to try again [20:12:33] okay [20:13:31] yeah i tried to do another p52 right at the begining of that scenario but the sextant wouldnt move [20:13:40] i forgot to power up the optics as well [20:14:10] at least it finds stars right now [20:14:41] but I have to see at the end of the P52 [20:15:17] hmm [20:15:22] in that scenario at least [20:15:25] everything was good [20:15:35] star angle difference, torquing angles [20:15:39] i will try it again [20:15:41] good P52 option 3 [20:16:58] thewonderidiot: Do you happen to have any knowledge about using pybluez? [20:17:30] nope [20:19:19] @indy91 just did the p52 again with 00000 [20:19:28] very strange why that happened the first time [20:19:32] and small torquing angles? [20:19:35] Too bad. I can't figure out why I'm getting an unsupported protocol error. [20:19:57] 00014, 00004 00024 [20:20:02] yeah, very small [20:20:11] the unit there is 00.000° [20:20:22] weird [20:20:47] could a variety of things. bad mark, wrong star etc. [20:27:09] I am going to remove ClearBeacons() and SetTrackLight() from SetLmLandedMesh() [20:27:21] obviously they are redundant [20:28:20] indy91, did you figure out the inverter issue? [20:28:52] I came up with a solution, didn't like the solution and deleted it all again [20:29:13] that's where I am right now on it [20:29:40] Haha ok [20:29:48] So what exactly is the issue? [20:30:41] it's doesn't produce heat for the inactive inverter [20:30:47] if that one has its CB closed [20:31:10] that's not a usual case, because the CB is usually opened for the unused inverter [20:31:37] Right [20:31:45] Though both are closed for brief moments in switching [20:31:50] yes [20:32:01] So if someone left them closed, the consequence should be there [20:32:25] of course! [20:32:30] PR sent [20:32:34] those precious 40 Watts [20:32:47] Actually [20:32:52] Both cbs are closed during ascent [20:33:29] AlexB_88, SetLmLandedMesh isn't used when loading from a scenario, right? [20:33:41] or at least not exclusively [20:34:30] no, looks like it's just used once in the timestep [20:34:54] yeah [20:34:54] in which case, PR merged [20:34:58] thanks [20:35:21] I tested it of course [20:35:38] rcflyinghokie, I'm not sure we even need the "active" parameter of the inverter at all [20:35:49] because, the wiring is done in the inverter switch code [20:36:19] AC buses wired to the AC inverter feed CBs [20:36:34] and those in turn are wired to the right inverter [20:36:51] probably not [20:36:59] That was just the old code [20:37:13] old code? [20:38:41] the "active" parameter [20:39:01] That was already in the inverter code before we started [20:39:18] ok [20:39:26] and wasn't in the inverter code before we started? [20:39:32] what wasn't* [20:39:50] You mean what did I add? [20:39:59] will your guys changes affect my scenarios? [20:40:11] not the inverter changes, no [20:40:18] okay [20:40:39] i will try to get to the end of day 3 tonight and start fresh on day 4 in the morning [20:40:40] rcflyinghokie, I thought you meant that the active parameter is obsolete and the wiring was added later... or something like that. nevermind. [20:40:47] Oh haha no [20:41:09] I mean I used that for my timestep because it was already there, before finding the rabbit hole that was the efficiency [20:41:53] ah, right [20:43:13] so the power load in the unused inverter should be 0 anyway [20:43:22] now I still need to determine a on/off state for the inverter [20:43:36] because in the current code it simply generates a lower voltage if the input voltage is too low [20:44:53] But it will still be generating heat [20:45:01] If the cb is closed [20:45:18] also when open if I simply remove the active parameter [20:45:47] the CSM inverter class also uses a factor of input voltage determining the efficiency [20:50:58] it also uses 19V as a cutoff voltage [20:51:04] below that nothing works in the inverter [20:53:15] So if its getting the normal voltage, even under no load, it should generate heat [20:54:30] yes, the 40W idle heat loss [20:54:45] but that should of course not be the case if the inverter has no input voltage at all [20:55:03] and the only way the inverter code has to determine if any power goes into it is by that input voltage [20:55:10] the input is the CB [20:55:18] and the CB code sets the voltage to 0 if open [20:55:42] CSM inverter code again, it can regulate the input voltage up to 25V and down to 30V [20:55:55] but below 19V it's completely off [20:56:06] so I need to find the right number for that [20:56:44] Trying to reconfigure IRC on my phone [20:59:50] Works again yay [21:00:36] I have to rewire a few outlets and the modem is on that breaker, so switching to IRC [21:01:17] sounds familiar [21:19:24] is LCA coming soon, maybe I can get the backlit start/stop switches in [21:20:02] LCA is coming when Snoopy is docked to Charlie Brown [21:20:32] haha great [21:22:52] The backlit switches cam go in now [21:22:56] Can [21:22:59] Well I just made my Linux mess up of the year. [21:23:11] I just accidentally deleted everything in /boot [21:23:14] Ill jist wire them to the breaker and lighting test for now [21:23:27] ok [21:23:35] i'll do them tomorrow [21:23:52] Thymo: kernels are overrated [21:24:18] Kernel, bootloader? Don't need that junk. [21:24:31] they are usually controlled by the ANUN/NUM dimmer, correct? [21:24:32] Pfft. Who needs an EFI directory? [21:25:19] Well. Let's just hope this is enough of a motivation to finally start making backups... [21:26:04] or maybe its the integral dimmer [21:26:27] night! [21:33:03] Pretty sure its anun [21:33:12] But i need to check [21:33:27] Its easy to follow in the lighting pg of the lm 8 handbook [21:53:56] Alright, time to reboot and hope I got everything. [21:54:13] If I'm not back within 3 minutes, I missed something. [21:57:02] Not broken. :) [22:07:01] night! [10:38:55] good morning indy [10:39:13] i know what i did wrong on the p52 [10:39:45] hey [10:40:02] forgot to change the star code as i switched to a different one as the lem was in the way [10:40:54] ah, yeah, that explains it [10:41:04] you can change the star code after or before the mark [10:41:32] i alwways change it after [10:41:34] after the mark it displays you the star code again to confirm the code [10:41:54] yeah, if the LM is in the way, you can't really know before the mark [10:43:22] so, the first indication that something was wrong there was the star angle difference, right? [10:43:31] yes [10:43:35] you can do a V32E at that point [10:43:41] this time i got 00000 [10:43:47] that will get you to the display with the code 00014 [10:44:10] code 14 is "alignment check". It usually appears after the marks [10:44:18] ENTR to bypass, PRO to recheck [10:44:44] so if you press V32E and then PRO if you get a bad star angle difference, then P52 will start from the beginning [10:45:00] of course you can also find this in the checklists [10:45:36] https://history.nasa.gov/afj/ap14fj/pdf/csm_gc.pdf [10:45:48] P52 procedure should be identical for Apollo 10 and later [10:46:13] PDF page 96 to 98 in that document [11:14:44] @indy91 well i am going to finish day two now i will see you in a bit if i have any problems [11:14:51] ok [13:15:39] hello again [13:17:04] @indy91 so i accidentally pressed pro again at the 6 49, so should i just uplink another state vector from the rtcc? [13:17:43] or did i already ask that? [13:19:11] you have asked about that, yes. You can uplink another state vector, but you don't have to. Your state vector won't be wrong by much and before any maneuver you will get a new state vector anyway. [13:19:38] yeah sorry about that [13:22:06] no problem [13:23:40] so after your changes to the lem are finished and the mcc's what is gonna happen next with nassp just curios [13:23:47] curious* [13:25:39] morning [13:25:48] hi alex [13:27:46] hey Alex [13:27:50] astronauthen96__, next is Apollo 11 MCC [13:28:05] then we progress to NASSP 8.0 Beta [13:28:18] and will spent a lot of time refining things, fix long time bugs etc. [13:28:39] AlexB_88, don't get confused, I moved EPS and lightning code from lemsystems to a lm_eps file [13:28:44] lighting* [13:29:41] I like it, the LM is looking very "organic" now [13:31:48] working on the CSI calculation now. Using some Skylark routines is very useful, I can use them as building blocks for different kind of rendezvous situations, gives me a lot of flexibility. [13:32:15] nice [13:33:00] memory-wise they probably take more space than the lunar mission routines [13:33:09] got a few days off now so I can continue to find some bugs (sorry) :D [13:33:16] oh no [13:34:01] but today I'll try and get the docking light on the LM working [13:34:12] great [13:34:31] also need to find out how to get the tracking light to work at 400 nm [13:35:43] According to the API, SetVisibilityLimit() is used to define how far you can see the mesh/lights [13:36:13] but I have not had success with it yet [13:41:55] looks a bit complicated [13:42:11] what number do you have to use as the input for that function? [13:46:07] 2 values, vis limit and spotlimit [13:46:34] but as to what those actually mean, I am still confused, the API description is quite convoluted [13:48:03] is it a limit in meters, or a size limit of the visible mesh itself (as you zoom out and the size gets smaller) [13:57:11] ok [13:57:17] I think I have a calculation going for it [13:57:26] I think the normal vis limit can stay the same [13:57:39] we just need spotlimit, right? [13:57:43] yes [13:58:49] Good morning [13:58:57] hey [13:59:14] I already told Alex, don't get confused, I moved EPS and lighting code into their own files [13:59:28] AlexB_88, LM ascent stage is size 5 [13:59:38] normal aperture is 30° I think [13:59:50] so if that is supposed to be visible from 400NM [13:59:59] I get 1.169e-5 for the spotlimit [14:00:17] ok thanks [14:00:29] and do you have a value for ascent+descent stage? [14:00:30] and vislimit can stay 1.0e-3 [14:00:31] Haha I saw the merge on git but thanks for the heads up [14:01:11] with extended gear size is 7 [14:01:34] that would be 1.6367e-5 [14:01:42] ok [14:02:04] and retracted is 6 but maybe the same value will work for that? [14:02:21] sure [14:02:35] or use 1.4028e-5 [14:02:40] ok [14:03:28] ill test that right now, thanks [14:05:15] I guess I can put that function below SetSize() [14:05:25] yeah [14:05:59] hmm, RTCC calculated CSI DV randomly jumps between 48 ft/s and 55 ft/s. At least it's in the right range already. [14:11:32] oh interesting, it's the fault of the Skylark routine finding the TPI position vector. [14:11:51] Did I ever say good things about Skylark routines? Never! [14:16:01] "Rien ne va plus" [14:16:05] I found some french [14:16:10] just to be sure, the calculation you made for spotlimit took into account the sextant's FOV of 2 degrees right? [14:16:28] rcflyinghokie, not bad :D [14:17:04] Just caught me off guard reading through haha [14:17:25] AlexB_88, oh [14:17:27] not at all [14:17:29] it was with 30° [14:17:40] should be 1°, half of the FoV [14:17:54] I dont know if the 400 is based on the normal FOV or the sextant FOV [14:18:04] 400 nm* [14:18:19] sextant I bet [14:18:34] rcflyinghokie, below that voltage, nothing will work anymore. So I think it's the appropiate term :D [14:19:07] Very much! [14:19:50] AOH about the track light visibility [14:19:55] Visual: 10 to 140NM [14:20:00] CSM sextant: 30 to 400NM [14:20:19] so I'll recalculate it with 1° [14:20:28] perfect [14:20:52] ascent stage: 3.8668e-4 [14:21:18] descent stage without legs extended: 4.6401e-4 [14:21:35] descent stage with legs extended: 5.4135e-4 [14:22:11] thanks [14:22:54] Your minimum voltage should probably be something like 24 volts, as that is the low end of the inverter input voltage range [14:23:15] Not that it matters right now, but I'd use that instead of 10V [14:24:28] Hmm that is taken into account a little further down [14:25:19] yeah, that's why I used an even lower voltage [14:25:35] CSM AOH mentions the exact voltage that the inverter can still work with [14:25:37] 19V [14:25:43] but the LM AOH doesn't [14:27:39] I'll be taking Guenter offline for a while. Will be testing the fan controller and replacing a faulty fan. [14:27:50] Will be an hour tops. [14:27:55] .stoplogging [14:27:59] .quitlogging [14:28:08] Have fun [14:28:11] .endlogging [14:28:11] Meeting ended by Thymo, total meeting length 99419 seconds