[08:01:30] NASSP Logging has been started by thewonderidiot [13:06:43] hey [13:09:05] Good morning [13:15:55] I have been playing in the LM more getting temps stabilized [13:18:01] what's the trick to do that? [13:23:36] So basically its balancing the heat exchangers [13:23:56] I did cheat a little though with the radiator and put a temperature controller on it [13:24:34] I also increased valve sizes going in and out of the cabin to allow more Q flow [13:24:47] The SGD and CGR valves [13:24:58] hopefully doesn't do anything bad to pressure stability, increasing valve sizes [13:26:10] Also what I am checking [13:26:17] So far no discernable changes [13:26:23] good [13:26:32] It's such an annoying little thing, but I never could find anything in the Apollo 11 FIDO audio on how they determined the time for the CSM separation maneuver. [13:27:25] and now, at about 90h GET, the FIDO asks one of his support people "Do you know why the sep maneuver is at that time? I can't find anything in the log" [13:27:34] all I could think is: right? right?? [13:27:59] Hahaha! [13:28:34] answer is, that was already the time when my shift started [13:28:45] very helpful [13:29:06] I just want to know if it's at a specific longitude, or time before DOI... give me something! [13:31:23] Super helpful [13:34:14] haha [13:34:25] FIDO simply changes the TIG back to the flight plan number [13:35:36] I think that even stays [13:35:40] bad FIDO! [13:35:43] the crew agrees [13:35:58] 099:41:49 Collins (onboard): GET of the separation burn is 100:39:50 even. [13:36:05] 099:42:23 Collins (onboard): I'm surprised they didn't update it by 3 or 4 minutes to, you know, make that Delta-V be in the same position that they wanted. [13:36:09] 099:42:33 Aldrin (onboard): Yes, I agree. [13:36:14] 099:42:38 Collins (onboard): So we're about 3 minutes ahead of the printed Flight Plan. It might be wise to try to Sep about 3 minutes early, and we can give them a GET of Sep that's precise, whenever they want it. [13:37:50] 100:36:21 Armstrong: Mike, what's going to be your pitch angle at Sep? [13:37:56] 100:36:27 Collins: 007 degrees. [13:38:07] that's not what you want, the burn should be radial only [13:38:57] so the current FIDO at 90h GET screwed that up a little bit [13:38:58] LM Sep I assume [13:39:11] yeah, the 2.5 ft/s separation maneuver the CSM does [13:39:15] Yeah radial [13:39:21] very much so [13:39:26] or else you get downrange DV [13:39:46] bad for tracking, bad for returning back to the CSM if the LM does no DOI [13:41:51] and the original sep time they used was 3 minutes early, so the previous FIDO accounted for that [13:42:04] and I already listened to the hours before the landing, they never touch the sep maneuver again [13:48:41] so I have to go back in time even more to find the answer [13:48:47] to the good FIDO [13:53:34] Haha [13:55:24] Oh random question, we have a bunch of checklist holds for recording pressures temps etc...do we want to keep those? [13:55:58] are those in the actual checklists? [13:56:34] probably not [13:56:41] might just be a remnant of our Apollo 7 checklists [13:56:58] where they would have been doing more logging of data I would imagine [13:57:02] Right [13:57:33] Some of them are still in the checklists [13:57:38] But we have a checklist hold on them [13:57:48] (Yellow, have to manually skip) [13:57:54] yellow text [13:57:57] yeah [13:58:03] don't think we need that [13:58:21] ok the "good FIDO" isn't so good, as he didn't write the reason to update the sep time in the FIDO log. And some people are asking FIDO to fix the sep time right now, so that's why there is no more update. [13:59:24] Oh yikes [14:00:10] so just a bit of lack of communication it seems [14:13:18] Well the human element rears its head plenty [15:09:26] hey [15:14:11] hey Alex [15:20:30] I'm making big changes to the two impulse processor [15:21:04] and one thing I am noticing, they just didn't have the capability to calculate the TPI time in the case of a No PDI+12 calculation [15:22:06] in the first step you can calculate multiple solutions, they did that with 60 seconds increments for the arrival time at CDH [15:22:10] Hey Alex [15:22:18] and somehow they concluded that plan 3 was the good one [15:22:48] FIDO did give the elevation angle as an input, but I'm not sure what for haha [15:23:03] listening to earlier times on the Apollo 11 audio to maybe find out more [15:25:36] interesting [15:25:50] I think the worst case scenario is that you have to do the whole thing twice [15:26:12] so abort and NSR/CDH maneuver on MPT [15:26:25] oh and btw, I've been doing my sep maneuvers at specific longitudes, but it helps that the later missions its specified in the SCOT [15:26:39] run two impulse again, this time figuring out the TPI time [15:26:43] and then adjust the NSR time [15:27:01] yeah, they ended up using the flight plan time on 11, but one FIDO did modify the time [15:27:10] I'll just have to find out when he did that [15:27:17] some time before 86h GET [15:29:38] and right now I am hoping they did some preliminary work on the No PDI+12 that I haven't found yet [15:30:15] closing the gap of stuff I haven't listened to yet in the early 90s GET [15:33:06] you can indirectly specify a TPI time with the nominal NSR time option for the NCC/NSR mode [15:45:17] Ok so i am going to stop tweaking and fly a mission with the current state of my ecs branch and see what I find [15:51:17] I just tested your latest tested, rcflyinghokie [15:51:33] I have a bunch of stuff since last night lol [15:51:51] looks good, the suit temps are a bit hard to cool down though, is there a way to do that? [15:52:02] Hmm [15:52:14] this is the commit from 28 mins ago [15:52:32] What were the HXH and HXC lengths? [15:52:45] I lowered them and had issues cooling [15:52:48] So I put them back up [15:53:50] what they are in your latest commit youy mean? [15:53:53] you* [15:58:45] I'll take a look [16:03:06] Mine stay normal [16:06:43] I had tested with my Apollo 17 scenario with the full internals deleted [16:07:14] Oh I know why [16:07:18] I think [16:12:13] LCG? [16:15:54] so the issue I had was when I initialised the LM, I had the crew in suit and the suit temps were a bit low. I then put LCG selector to hot and the suit temps rose past 70 so I then put LCG back to cold, but the suit temps never went back down though it kept slowly increasing to the high 70s [16:16:01] cabin temps though were fine [16:19:24] I seem to be able to get them up and down [16:20:20] But I am investigating [16:24:15] is it again because of older electric section still in your testing scenario maybe? [16:25:03] since they have a lot of boliers/pumps related to ECS [16:25:27] Nope thats gutted [16:25:34] ah ok [16:26:35] With LCG my temps stay good [16:31:40] Actually they are staying low without [16:31:59] But I have uncommitted changes [16:37:39] I just re-tried my scenario again, this time its better [16:37:57] could of been user induced I guess lol [16:39:37] Yeah I have some changes in mine [16:41:22] I see a commit 30 seconds ago, are they in there? [16:41:52] Yes [16:42:01] Give that a try [16:42:04] ok [16:42:07] Probably needs more adjustment [16:42:08] thanks [16:42:17] But I need to do a fresh flythrough to verify things [16:50:00] Cabin temp still drops on launch during cabin pressure relief [16:50:06] For the CM [16:51:14] right [16:51:25] I notice cabin temp drops anytime pressure goes down [16:52:28] Checking to see if thats a heat capacity thing or my proportioning of Q [16:52:32] morning! [16:52:43] Hey good afternoon [16:53:14] suit temps are better [16:53:17] hey [17:02:59] I am just testing TLC, I notice the LM temps dont drop so much anymore [17:05:35] Yep the Q change messed up the temp drop [17:06:44] hmm but thats what we want right? Not to drop to low druring TLC [17:13:35] Oh the temp duriong launch sorry [17:13:38] during [17:13:52] I was trying an experiment with using valve proportions [17:14:00] ah ok [17:14:03] Never changed it back [17:17:20] hey Mike [17:17:27] hey [17:17:30] Sundance is weird :D [17:17:39] I bet [17:18:01] could the T5RUPT thing come from the fact that Sunburst and Luminary both have descent and ascent programs? [17:18:05] but Sundance doesn't [17:18:13] hmmm, possibly [17:18:30] does Sundance use all banks? [17:18:33] yep [17:18:47] well I doubt it's too much trouble though with the memory [17:18:51] it seems rather empty haha [17:18:59] yeah it's interesting [17:20:06] maybe there is a full Retread hidden in Sundance [17:20:40] or more realistically, some remnants of unused and disabled programs [17:21:42] but then it had a fairly separate development history from Luminary, so probably not [17:22:27] I'm pretty sure Skylark still has some lunar coasting integration routine stuff in it, just disabled [17:23:06] Ok AlexB_88 I am leaving things alone for a bit [17:23:17] oh interesting [17:23:25] debug it to your hearts content, just remember to cycle anything connected to a valve or pump [17:23:38] I am trying it from a launch [17:23:46] yeah, based on all of the similarities I was finding to Colossus I was starting to get worried that I misidentified the program [17:24:08] like so far the code I have disassembled is closer to Colossus than it is to Sunburst or Luminary [17:24:18] and there are several chunks now that are only present in Colossus [17:24:38] but no, it uses RUPT10, and there is definitely an EDRUPT in bank 3 [17:24:45] LGC confirmed [17:37:24] rcflyinghokie, sounds good [17:42:21] I am going to fly 11 all the way through making notes instead of changes hopefully identifying any issues [17:46:15] yeah, that will also allow me to finish 14 without giving my LM a new ECS every couple of hours :D [17:46:26] hahahaha [17:50:12] Yeah I am sorry about that! [17:50:16] I was on a roll [17:51:01] no worries haha its part of the testing game [17:54:37] where are you on 14 right now? [17:56:02] just finished LOI [17:56:08] DOI coming up [17:56:33] DOI DVZ looks like about 3 ft/s, indy91 [17:59:11] Oh yeah reverting that Q change stabilized the CM ECS during launch [18:02:50] what was the purpose of the Q flow proportioning? [18:04:53] Well the way the code was written is it was only based on the smallest valve size [18:05:10] So I was experimenting with getting more flow by taking an average [18:05:18] But that ends up too much [18:08:47] right [18:09:25] I had noticed the temps got low with pressure drop, but they did end up stabilizing as the pressure came up [18:09:48] Yeah [18:09:55] But it was just too fast I think [18:16:40] right [18:19:55] ah! here's proof in Sunburst and Luminary that the T5RUPT code changed in Sundance [18:20:01] https://github.com/virtualagc/virtualagc/blob/master/Sunburst120/INTERRUPT_LEAD_INS.agc#L32 [18:20:06] https://github.com/virtualagc/virtualagc/blob/master/Luminary069/INTERRUPT_LEAD_INS.agc#L37 [18:20:33] there's no good reason for that comment to have changed... so they clearly repunched those cards :) [18:28:06] autopilot [18:32:03] AlexB_88, nice [18:33:06] yeah not bad [18:33:40] btw, it looks like abr35's rendezvous window issue is quite weird [18:33:46] https://www.orbiter-forum.com/showthread.php?p=605284&posted=1#post605284 [18:34:14] he is running 1920x1080, but the 4:3 bitmaps are being loaded [18:34:28] yeah I read that [18:34:33] no idea how that can happen [18:34:51] mine dont look 16:9 either [18:35:14] oh really? [18:35:32] Would having a taskbar mess that up [18:35:43] and you're running 1920x1080 [18:35:46] Yes [18:35:56] not sure about the taskbar thing [18:36:03] But I have mine windowed with taskbar [18:36:17] I always use the "Full Screen Window" option [18:36:30] https://www.dropbox.com/s/fb7yys5fnr44o96/Screenshot%202020-04-29%2014.35.20.png?dl=0 [18:38:10] Full screen 1920x1080 window with taskbar [18:38:17] that's the center (hatch) window [18:38:29] oh for that window its normal [18:38:32] Also [18:38:33] yeah [18:38:41] I don't think we have multiple versions for that one [18:38:46] https://www.dropbox.com/s/k52bhuit26b5g50/Screenshot%202020-04-29%2014.35.12.png?dl=0 [18:39:29] so for that hatch, the screenshot looks normal, but for the rendezvous window, it seems you have some space on each side [18:39:47] Yep [18:39:48] the hatch window bitmap already has the gray areas [18:39:54] but it's 16:9 [18:39:59] little space on either side [18:40:16] that might be from the taskbar [18:40:42] haven't looked at the rendezvous window in a bit, let me check if it is even ok for me lol [18:41:07] yep it is just tested it [18:41:15] no space without taskbar [18:41:56] and its still loading the correct bitmap for you [18:42:12] I am getting the 16:9 rendezvous window bitmap [18:42:25] abr35 on the forums is having the 4:3 bitmap loaded which is very weird [18:42:39] since he is also running 1920x1080 apparently [18:44:47] I cant see how that can happen unless somehow he deleted ProjectApolloConfigurator.dll [18:47:53] clean and rebuild maybe? [18:48:49] maybe, he may be using auto-builds though [18:50:00] Ah [19:26:01] so, from comparisons to the main branch, the LM ECS seems a bit less stable now (a bit more flickering in the gauges and things like that) but its definitely not as bad as it used to be [19:27:01] What is flickering? [19:27:23] Usually flickering can be addressed [19:27:46] well during time acceleration I mean [19:27:51] I am testing with 50x [19:28:21] Ohh [19:28:34] Yeah that can be addressed a little bit [19:28:48] I know the process for doing that it just takes a lot [19:28:53] I didnt go through it yet haha [19:29:34] Temps first then fluctuation [19:29:44] ok [19:30:35] Buit yeah keep that info coming [19:30:50] What is fluctuating exactly [19:30:56] indy91, abr35 said "The dll is in the Modules/Startup folder, but not in the Extra tab on the Orbiter configuration" [19:30:58] odd [19:33:26] rcflyinghokie, all the ECS gauges [19:33:34] Ah ok [19:33:36] just a bit more then they used to [19:33:37] replied to him [19:34:30] thanks [19:35:07] Yeah more heat going around lol [19:35:17] I can work on it after a test mission [19:36:01] make sense [19:36:18] a lot of changes like that were bound to make that happen [19:36:22] ok sounds good [19:37:30] Oh yeah [19:37:51] Especially with the head capacity change and recompute [20:18:27] What is the switch called for the CM forward hatch open/close? [20:20:38] I see HatchToggle but it looks like the side hatch [20:25:07] I don't think it's really a switch [20:25:10] it's a click area [20:25:17] which then calls ForwardHatch.Toggle(); [20:25:48] AID_FORWARD_HATCH is the name of the panel area for it [20:26:04] What would be used to highlight via checklist? [20:29:06] hmm [20:29:57] If nothing its ok, but just wanted to add it if we had it [20:29:58] I'm not sure that can be done [20:30:10] Ok no worries [20:31:00] yeah, DrawFlash (the flashing border) is a PanelSwitchItem function [20:31:09] and so only applies to switches [20:31:37] he posted the log, looks like ProjectApolloConfigurator.dll is failing to load [20:31:48] and RTCC MFD and PAMFD [20:34:11] I wonder if he is missing some C++ Redistributable packages [20:34:14] yep [20:50:00] maybe he installed the x64 version accidentally [20:51:04] Ive done that before [21:12:33] night! [21:13:23] Im headed out early, catch you later! Let me know what else you observe AlexB_88 its super helpful [12:47:58] hey [13:21:29] Morning [13:25:54] I just fixed some RTCC MFD bugs that were at least 5 years old haha [13:28:48] Oh wow [13:29:40] it's some of the first stuff I ever worked on, the Apollo 7 NCC-1 calculation [13:32:23] What led you there [13:32:45] working on the two impulse processor, which was the real RTCC tool for that calculation [13:32:51] also for ground solutions for TPI [13:32:55] and No PDI+12 [13:33:08] I'm reworking that a bit, using the real display they had for that etc. [13:34:02] and that has the option to vary the arrival time, e.g. at the Apollo 7 NSR maneuver point [13:34:21] and I noticed that for arrivals a little bit later than what used on Apollo 7, the calculation gave bad results [13:34:30] which it shouldn't [13:34:59] Ahh [13:40:55] On an ECS note, moving the LM cabin position has improved PTC temps [13:41:40] Gets nice and warm [13:41:47] 65 or so [13:41:48] what did you change it to? [13:42:04] forward hatch instead of top hatch [13:42:08] so Z instead of Y? [13:42:17] yeah [13:42:34] yeah that will make it more even in PTC [15:14:30] hey [15:53:08] Morning [15:57:35] whats up? [16:00:45] hey Alex [16:01:05] I fixed some Lambert targeting issues that were at least 5 years old [16:03:04] it nearly had an impact on Apollo 7 NCC-1, in which case I probably would have fixed it 5 years ago :D [16:07:27] wow must be a record [16:09:34] the two impulse processor has the option to have initiation and arrival time fixed [16:09:42] or T1 fixed, T2 variable [16:09:47] or T1 variable, T2 fixed [16:10:10] so I let it display solutions for the nominal Apollo 7 NCC-1, and some arrival times that were later in 1 minute steps [16:10:31] and with a T2 just a few minutes later the calculation broke down [16:14:25] so I looked at some of my sources that I also hadn't looked at for 5 years and figured it out [16:18:31] I still don't really know how they figured out the right T2 time to get TPI right [16:18:41] for No PDI+12 [16:19:09] looking for some preliminary runs in the Apollo 11 audio [16:23:43] I've only seen one No PDI+12 calculation in the audio, the final one, the FIDO takes half a minute which T2 to use, but I can't read his mind :D [16:23:58] half a minute to think about* [16:35:04] those FIDO's should have said everything they thought out loud...you know for us future "listeners" [16:35:27] they said plenty out loud, in general I can't complain [16:35:35] they probably would of sent them to a psychiatric ward after the mission though :D [16:37:38] morning! [16:39:58] an interesting manual popped up on ebay overnight: https://imgur.com/a/IaK7rVf [16:40:01] hey Mike [16:40:45] oh that looks fun [16:41:59] :D [16:42:32] will find out how fun in the next couple of weeks, haha [16:42:33] also! [16:42:36] Sundance is weird, man [16:42:52] like I know it was released early, but parts of it are a lot more primitive than I was expecting [16:43:02] Is there any chance Sundance has the stable orbit rendezvous programs? It's not documented anywhere and it probably wouldn't be functional, but there is a weird comment in an Apollo 9 document [16:43:21] ohhhhh that would be fun [16:43:26] I don't know yet [16:43:41] it's been a challenge but so far I've been able to identify all code in banks 0-2 [16:43:44] "The CSM will compute the two-impulse sequence because this [16:43:45] sequence has not been verified in the SUNDANCE program." [16:43:54] oh that sounds very promising [16:44:04] and that, I think, talks about a rescue case [16:44:17] where the CMC would be used to place it at an offset to the LM [16:44:26] which is what the stable orbit rendezvous programs do [16:44:35] neat :D [16:44:41] but I'm really not sure [16:44:48] we'll find out soon enough, haha [16:45:02] I wanted to ask you -- how does the TRACKER light work in Luminary, exactly? [16:45:15] because the code to handle it is quite different in Sundance [16:49:47] thats the Apollo 9 LM software, right? [16:50:19] yep [16:50:55] is that going to be available sometime? [16:52:35] some reconstructed mishmash of versions, hopefully! [16:52:39] I'm working on it, haha [16:52:56] we have all six modules, but they're from different versions [16:53:21] B1 - Sundance 292 [16:53:22] B2 - Sundance 302 [16:53:23] B3 - Sundance 302 [16:53:23] B4 - Sundance 302 [16:53:24] B5 - Sundance 292 [16:53:24] B6 - Sundance 306 [16:53:38] ah ok [16:53:40] 306 is what flew, and this combination of modules does not make a working program [16:53:54] so my current project is to diassemble all of them, figure out why they're incompatible, and try to make a version that does run [16:54:29] so reading above, if I understand correctly, Apollo 9 LGC software did not have the full rendezvous program suite? [17:04:11] sorry had to go afk [17:04:29] Sundance didn't have (functional) stable orbit rendezvous programs P38 and P39 [17:05:01] which were removed after Apollo 11 anyway [17:05:17] I've seen the tracker light so rarely :D [17:05:22] haha [17:07:02] "Tracker light indicates program unable to obtain good radar samples on each required pass" [17:07:42] and RR CDU failure [17:08:22] hmm [17:09:00] the reason I ask [17:09:03] https://github.com/virtualagc/virtualagc/blob/master/Luminary099/P20-P25.agc#L1538 [17:09:18] is because this comment describing what SETTRKF does is really interesting [17:09:55] as far as I can tell, in Luminary, despite what the comment says, SETTRK does not check anything with the landing radar at all, and TRACKER is only for the RR [17:10:07] but, what is implemented in Sundance exactly matches what this comment describes :P [17:10:30] Apollo 11 was the first mission that even had ALT and VEL lights [17:10:35] maybe related to that? [17:10:43] it was already changed for Luminary 69 [17:10:53] so probably not? [17:11:29] I've seen Luminary 69 use the ALT and VEL lights, very buggy [17:11:57] hahaha [17:12:33] they tested the LR on Apollo 9 [17:12:45] let's see if the procedures have any tracker lights... [17:16:00] no [17:16:46] haha ah well [17:16:48] GSOP section 4 [17:16:51] an interesting difference at least [17:17:00] tracker light is on when [17:17:23] (7) When an LR Altitude Data Good Bar discrete or LR Velocity Data Good Bar discrete occurs during an AGC data read sequence [17:23:27] sounds right :) [17:59:14] tonight's disassembly is going to be boring [17:59:23] I think bank 3 is almost entirely interpreter [18:02:09] boring is good [18:03:10] heh, yeah [18:03:20] bank 4 will be interesting though, I don't know much about it going in [18:11:30] So I think we made a mistake with the LM suit isol valves [18:11:53] I think the overrides work regardless of power connection [18:12:15] The automatic disconnect is the only thing driven by the pressure switch & breaker [18:15:23] indy91, I really like the new way to select thrusters [18:29:29] rcflyinghokie, this? [18:29:30] if (suitisolvlv->GetState() == 0 && lem->ECS_SUIT_FLOW_CONT_CB.IsPowered() && (actuatorovrdswitch->GetState() == 1 || lem->SuitPressureSwitch.GetPressureSwitch() != 0)) [18:29:44] Yeah I am playing with it [18:30:01] AlexB_88, it's using the codes now they used in the MED inputs [18:30:14] the shorter the better for those inputs, hence the C1-4 and L1-4 for the RCS [18:32:50] right [18:33:18] would it be possible to adapt this to other pages as well? I am thing the config selection in the MPT init page [18:34:20] yeah, config is the next longest thing we currently are cycling through I guess [18:37:01] real input was [18:37:08] any combination of: C, S, L, A, D [18:37:47] I can add the logic so that it would reject an invalid combination [18:50:28] Hey [18:52:17] Hey there [18:52:58] yo [19:10:01] Ok code fixed added to my ECS repo [19:10:45] Also I think I need to initialize the glycol at a lower temp or have some means of radiative cooling for it [19:51:30] rcflyinghokie, dont see it yet on your repo, or do you mean just locally? [19:52:04] Locally [19:52:18] I promised I wouldnt push a bunch remember :P [19:52:47] ah ok [19:52:54] Basically just changed the line Niklas sent to this [19:52:55] if (suitisolvlv->GetState() == 0 && (lem->ECS_SUIT_FLOW_CONT_CB.IsPowered() && lem->SuitPressureSwitch.GetPressureSwitch() != 0) || actuatorovrdswitch->GetState() == 1) [19:53:35] that shouldnt affect previous scenarios I think annyway [19:57:17] Nope [20:07:28] But it better works with the checklist as the override was tested without the suit control powered [20:07:37] And I confirmed with the aoh [20:31:32] So LM was pretty happy during TLC [20:31:54] I need to initialize the glycol a bit lower I think and also see if I can get it to cool radiatively a bit more [21:24:48] time to activate Antares [21:39:59] !!! [21:47:13] Have fun [21:47:22] Looking forward to an ECS list :) [21:47:42] I am also looking forward to hear how Luminary 178 performs [21:48:11] I'm like 99% sure that I got it all correct but there is always the potential for errors that cancel each other out in the checksums [21:54:35] right [21:55:06] I know I had tried a landing with it previously using my old Apollo 14 PDI scenario, had no issues with it [22:55:21] thewonderidiot, she passed the self-test :D [22:55:35] excellent :D [12:07:21] Good morning [12:10:48] hey [12:12:43] I fixed that actuator override thing on my local ECS branch so that can go with the fixes [12:13:17] the CB only affecting the pressure switch, not the physical switch, the override [12:13:39] sounds good [12:14:16] Yeah [12:14:32] The physical switch works regardless of power [12:15:34] And when powered, the pressure switch does its job [12:16:24] I was searching for the CB, it's well hidden a row above :D [12:16:54] AOH about the CB being open: "loss of torn suit protection" [12:17:02] Haha [12:17:05] Yeah [12:19:57] I kind of get the feeling that I am taking more capabilities away than I am adding with this two impulse processor update... [12:20:14] but I'm making it more realisitc, so that's good, lol [12:23:24] Realistic is good! [12:23:41] Study sim remember :) [12:24:39] my goal ever since the first MOCR audio tapes became available is to be able to follow along with the calculations [12:25:06] and it's definitely getting there in many cases [12:26:15] Thats always such a good feeling to be on the numbers [12:28:05] yep [12:28:07] back in a bit [12:29:06] Sure [13:26:23] So I am curious, is there any way to, through an MFD, record all PADs sent up via MCC? [13:26:32] Could be a useful tool [13:27:08] Right now I usually screen shot them and reference as necessary [13:33:55] Also were ullage requirements only in the flight plan or were they read up in PADs [13:36:27] hmm [13:36:47] ullage was usually on the Maneuver PAD [13:37:28] and that capability sounds like the hard copy functionality they had in mission control [13:37:46] the flight controllers could press a button and via a tube system they got sent a printout of the screen they were looking at [13:38:17] something like that could be built into the MCC I guess [13:38:40] usually you are expected to write the PADs down by hand of course :D [13:39:18] Of course :) [13:39:47] Screenshots work well enough for me [13:40:13] But yeah for example the LOI2 maneuv.er pad has no ullage reference [13:40:20] But the FP lists a 2 jet 19 second ullage [13:41:04] yeah, I haven't looked much at ullage so far for the MCC [13:41:48] I dont know how it was calculated [13:41:58] I do [13:42:02] Or if they read up different values from the flight plan [13:42:09] they even had an onboard chart for it [13:42:10] That could be useful [13:42:14] Right [13:42:19] This I do remember [13:43:05] you don't need it with full tanks, but with more empty tanks you need to settle the propellant [13:43:35] what seems random to me is 2 jets vs. 4 jets [13:43:50] or is it mostly 2 jets? [13:44:14] I think its a function of ullage time perhaps [13:44:21] 4 jet of course will reduce it [13:44:55] yeah [13:47:40] I thought ullage times were in the maneuver summary [13:48:45] it's in the burn schedule in the flight plan [13:49:16] all 2 jets there [13:49:44] Interesting [14:02:55] So at LOI2, suit and cabin temps are 60-70 [14:03:15] Glycol seems a bit high but still can use some tweaks but its not offscale [14:03:25] (LM) [14:03:33] So I think its on the right track [14:04:45] great [14:05:55] I still want to try to get those time acceleration fluctuations under control [14:06:34] that's a good idea, for the LM ECS there isn't much time acceleration done [14:06:42] But I have a list I am making plus making those Apollo 11 checklist fixes along the way [14:06:48] it gets run multiple times per timestep now [14:07:10] so whatever you changed would have caused fluctuations already at fairly low time acceleration with the old behavior [14:07:16] Exactly [14:07:40] Probably have to look at tank and valve sizes [14:07:43] that's useful to know, let me get you the numbers for what exactly we did [14:07:48] Sure [14:10:27] so from 0x to 1x nothing has changed [14:10:35] the systems timestep gets run once per timestep [14:12:36] hmm [14:13:15] I have to understand it myself again [14:16:27] so from 0x to 1.2x nothing has changed [14:16:35] just how the math works out, nothing special about 1.2 [14:16:57] and then from 1.2x to 24x time acceleration we have a hard limit on the step length [14:17:08] it stays as if it was running 1.2x time acceleration [14:17:28] meaning at 24x time acceleration, we run 20 systems steps per timestep [14:17:47] which is a lot, but we haven't seen bad performance from this really [14:18:08] I know Alex was griping about fluctuation at 50x [14:18:16] but beyond 24x the step length goes up again [14:18:23] I never run that fast so I never saw it in initial testing [14:18:30] what stays constant is the 20 systems steps per timestep, that is the new limit [14:18:31] I usually do 30x max [14:18:44] so the worse performance hit is at 24x, but it stays the same above that [14:18:54] but fluctuations will go up more above 24x [14:19:10] so at 30x there will be a little bit more instability already [14:19:41] Yeah I have noticed that [14:19:46] I also use 50x during TLC [14:20:03] but only TLC, otherwise 10x [14:20:16] I use 30 during TLC typically [14:20:32] I will say the coasting heaters look good it cycles on and off naturally [14:20:51] Still need to look at why it gets so warm though [14:20:58] The glycol I mean [14:21:45] Hmm just realized my LOI 2 was like 15 minutes late [14:23:35] Apollo 11? [14:23:58] Yep [14:24:10] From the FP [14:24:12] quite a bit [14:24:21] I have seen maybe 10 [14:25:06] might improve a bit when the MCC uses the new TLMCC targeting [14:25:23] LOI 1 was 6 minutes late [14:25:31] But LOI 2 surprised me [14:25:42] ah of course [14:25:51] they targeted LOI-2 to a non-circular orbit [14:26:11] so it might not have happened at 60NM [14:26:21] in which case we get a different TIG [14:26:25] that's probably what happens [14:26:26] Ah [14:26:35] mascons are at fault [14:26:49] the non-circular orbit was supposed to become circular by the CDH maneuver [14:27:06] didn't really work out that way, but that's what they targeted LOI-2 for [14:27:18] Orbiter Moon doesn't have mascons [14:27:21] Interesting [14:27:31] Well my V82 shows a 60x60 [14:27:47] PAMFD 58.6x58.4 [14:28:05] So it seems happy [14:28:11] And circular [14:28:16] yeah [14:28:54] HA 65.6 and HP 54.6 [14:29:03] actual LOI-2 Maneuver PAD [14:32:22] Hmm I guess we would have to wait for orbiter to include mascons? [14:34:46] or at least use one of the higher fidelity gravity models [14:35:05] which I guess is partially the same thing [14:35:21] the Moon in Orbiter has the same gravity model as the Apollo 8 AGC [14:35:26] Apollo 10 already had a better one [14:35:41] but with parameters in erasable memory which we can set to 0 [14:36:24] ok not quite [14:36:34] Apollo 10 and 11 or so had a gravity model with one more term [14:36:44] I'll have to check if that can already make a difference [14:36:57] but later missions had some terms in the erasable memory [14:37:09] those could be adjusted for the specific orbit I guess [14:37:16] so accounting for mascons [14:37:23] Wouldnt the flight still depend on orbiters moon model? [14:38:53] my idea is to do some research how some of these terms in the gravity model change the shape of the orbit [14:39:18] and if they would help get us more realistic trajectories, I'd write a little proposal for an Orbiter update [14:40:28] Yeah that would be pretty cool [14:40:33] a fairly simple update in that case [14:40:58] if it's only caused by mascons that probably makes the lunar gravity model a lot more complicated [14:44:25] Implementing mascons in the model would yield interesting results for sure [14:50:21] goodbye long term orbit stability [14:58:04] Haha worth the realism [14:58:36] hey [14:59:14] hey Alex [14:59:58] I was researching the configuration input you wanted, when I realized that they made the config codes much smarter in the lunar landing program version of the RTCC [15:00:14] it's a bitfield [15:00:16] 4 bits [15:00:26] CSM = 1, S-IVB = 2, ascent stage = 4, descent stage = 8 [15:00:38] and the actual config is the addition of those four [15:00:52] so full LM stage is 12, 4+8 [15:01:04] that makes soooo many things more simple in the RTCC [15:01:28] also makes inputting a config much easier [15:02:00] so I am changing it all to that system. Only downside, the config changed in old scenarios by the RTCC MFD will be wrong [15:02:09] saved in old* [15:08:38] interesting [15:09:03] sounds like a good way to do it [15:09:42] that way when you enter the config code manuall it just adds up the inputs [15:09:58] 1 for C, 8 for descent stage etc [15:10:06] and then it just does a check on the total sum [15:10:19] 1+2+4+8 = 15, so it can't be beyond that [15:10:38] in the Earth orbit RTCC version they didn't have the separate ascent and descent stage [15:10:55] so the config numbers are still simpler, and different [15:12:48] config code 9 is probbly illegal [15:12:54] CSM + descent stage [15:13:02] I don't think that is a realistic configuration :D [15:18:02] that wouldbe worrying lol [15:19:17] rcflyinghokie, about the highish glycol temps before activation, maybe that is normal? The activation checklists even mentions that the glycol light may possibly be on at CWEA activation if the temp is high [15:21:56] True [15:22:16] Mine stabilized at 72 or so [15:22:31] Which is probably a function of the heat exchangers with the atmo [15:22:49] I wonder if it would be prudent to turn those off if the glycol pump isnt running [15:23:09] Not super realistic but then again our heat transfer model isnt perfect either [15:28:38] right [15:29:13] Im up to undocking on 14, everything has gone well with the ECS during activation [15:29:32] cabin temps remained in the mid 60s [15:29:43] even wit crew in cabin [15:32:43] Awesome [15:32:55] I added a temperature control on the heat exchanger [15:33:15] Not "real" but it limits how much heat we lose [15:33:35] Is cabin staying at 63 with crew in cabin? [15:33:38] Or warmer? [15:40:13] 63 exactly [15:40:19] at undocking [15:44:27] Yeah thats where the HX temp is set [15:44:39] So any higher it starts losing heat to the radiator [15:44:49] But it wont exchange heat if its below 63 [15:45:09] Might need to reduce the power a bit [15:59:20] well, in my other tests with crew in cabin and all lights on the cabin seems fine mid 70s or so [15:59:32] with crew in cabin [15:59:53] so in my case it may just be since the crew hasnt had a lot of time in cabin yet to heat it up [16:45:17] morning! [17:01:23] hey Mike [17:01:37] what's up? [17:01:53] breaking the RTCC, what else would I be doing? :D [17:01:59] hahahaha [17:02:01] good point [17:03:42] how goes breaking Sundance [17:04:04] really well! four banks down and still no completely mystery code [17:04:07] just interesting changes [17:04:17] I'm into bank 4 now, working through V37 [17:05:00] these next two banks will be very interesting though since they have the fresh start code and the downlink tables [17:05:36] I'm torn on which module to do next [17:05:39] either B3 or B6 [17:07:06] B6 would be interesting because it's the only Sundance 306 module, so it will show me final locations -- but it will be a bit hard to dig into if stuff moved [17:07:36] B3 would be helpful because it's the only module we have two versions of, 292 which matches this B1 module I'm working on, so I know everything will correctly line up, and 302, so I can see how things moved between the two [17:08:15] do we have the banksums for all the Sundance versions you are working with? [17:09:14] unfortunately no, NARA was missing that drawing [17:09:51] he adds new thing breaks old thing, I fly and say new thing works old things broke, he fix old thing breaks new thing, I fly says new things broke, he fix new thing, repeat! :D [17:10:00] so we won't have any way of knowing how correct things are [17:10:02] hahaha [17:10:20] the endless cycle :D [17:10:34] hopefully only close to endless [17:15:17] time to undock Antares, hopefully Ill make the landing today [17:29:37] this configuration code update can break so many things, that'll be a few days of testing probably :D [17:31:50] and I think there probably was a bug related to that already, in the burn simulation for ascent stage maneuvers [17:44:07] rcflyinghokie, actually I put the crew in suit when the checklist asked for it, 1 hour before undocking [17:44:44] just after undocking it says I have the option to take the helmets and gloves off so Ill put them in cabin and see what the cabin temp does [17:45:24] Yeah its hard to model those variables [17:45:36] I would say helmet and gloves off the body heat is still being put into the suits [17:45:45] And cooling can be done with LCG [17:49:15] right [17:51:13] also if in our tests we find the cabin remains too cool, we can 1st look at the lights heat that was set to 65% of normal and set that back [17:51:18] or maybe that was done already [17:55:02] No its still 65 [17:55:14] But yeah absolutely a possibility [17:56:21] at least before ajusting the radiator/HX [17:56:59] so I put the crew in cabin just to test and the cabin temp has already gone up a bit [17:57:12] closing in on 70 [17:57:42] so far so good [17:57:46] As the temp increases the power will as well to attempt to pull it down harder [17:57:58] But yeah that is good [17:58:05] We want to see 60s though [17:58:08] makes sense [17:58:10] Based on what I have read [18:00:34] AlexB_88, T2 calculation. They ran the launch window processor with no boost maneuver, and then biased that launch time by 74 seconds to account for the missing maneuver [18:01:06] I'll have to try that to confirm it, and the direction, plus or minus 74 [18:01:26] oh interesting [18:01:32] and it's probably not supported right now that CSI is not at apolune after insertion [18:01:37] but it will be [18:02:51] is that for Apollo 11? [18:02:53] yes [18:03:04] just listened to the audio again and finally understood what they meant [18:03:40] Id try it on 14, but I think the trajectory is quite different [18:04:13] and T2 has a HAM on 14 [18:04:51] HAM is nominally zero though [18:05:01] I guess it's the same procedure, just a different bias [18:05:07] my plan was to just use PDI+22:07 which I got from the transcript I think [18:05:08] just have to figure out the bias [18:05:12] right [18:08:49] the next time I fly a full mission I'll write a FIDO worksheet that guides you through the inputs for that specific mission [18:09:07] ok [18:09:30] they talk some times about worksheet, so they probably had that [18:09:37] with nominal values to compare against etc. [18:58:39] So any idea why when starting in the LM you still need to flip a switch before it smooths out [18:59:32] yes [18:59:39] that's an Orbiter Sound bug actually [18:59:47] who would have thought, but that's what it is haha [18:59:58] Wow [19:00:07] well "bug", it was never made compatible with Orbiter 2016 [19:00:10] Yeah I never would have though [19:00:12] thoguht [19:00:15] ugh thought lol [19:00:38] there is an Orbiter Sound alternative [19:00:55] but obviously a lot of work to change it [19:02:30] so flipping a switch plays a sound, which triggers something [19:02:35] on Orbiter Sound [19:02:36] in* [19:02:46] AlexB_88, didn't you notice the same issue in a DeltaGlider or so? [19:04:15] yep [19:05:36] its not an issue if you already have a sound playing [19:05:37] Yeah i just flip a switch haha [19:05:52] like the glycol pumps etc [19:06:21] so its only an issue when you have a cold & dark LM [19:06:36] make the CSM cold and dark then save/reload and you will see the same thing [19:06:50] hopefully not too cold :P [19:07:11] yeah [19:07:27] the reason we never noticed it in the CSM is that there is never a time that a sound isnt playing [19:07:37] cabin fans [19:07:46] yeah or suit compressor [19:07:51] right [19:08:01] and in the T-4h scenario, theres the outside sound playing [19:08:39] all these fun things made us think it's a LM bug haha [19:09:41] yeah [19:11:38] indy91, does switching LM to CSM or vice versa require reinitializing the MPTs, or should it be safe? [19:12:08] it's all running once common stance of the RTCC, so it should be fine [19:12:13] one commonÜ [19:12:14] * [19:12:21] ok [19:12:29] making the PDI 0 pad [19:12:30] instance* [19:12:58] DKI still needs the same updates I gave the SPQ [19:13:00] I had the CIRC burn from the CSM on the MPT, now switched to the LM to make the PDI0 with the CIRC burn [19:13:32] there is very little that still requires you to be in a specific vehicle with MPT mode on [19:14:45] the PAD calculations, but those are barely MPT compatible anyway [19:15:06] and RTE seems to still require you to be in the CSM [19:16:26] right [19:16:45] even when doing an RTE with the LM? [19:17:10] I mean quite a rare case, but there is DPS as an option in the RTE [19:18:57] it's weird, I am not even seeing an input for that in the RTE MEDs [19:19:06] so I guess they always get generated out of the CSM ephemeris? [19:19:19] but the MED to move the maneuver to the MPT let's you then do CSM or LEM MPT [19:19:20] strange [19:19:34] but either way, you can have DPS burns on the CSM MPT, no problem [19:20:26] on Apollo 13 they definitely did use the LM ephemeris and MPT for the flyby maneuver [19:21:58] They didnt really have a choice did they [19:23:16] not sure [19:24:06] good PDI-0 solution [19:24:16] DVX 100 ft/s [19:24:51] is the DKI solution compatible for the new rendezvous display? [19:25:10] not super important as all I need is the CSI time which the DKI already shows [19:25:29] not yet [19:26:08] I can look at that nexrt [19:26:30] the two impulse processor update is done, this configuration code update also, just needs some testing [19:26:59] that update is somewhat of a downgrade though haha [19:27:19] it does not calculate you a TPI time for the No PDI+12 anymore [19:28:09] I still don't know how they determined that on Apollo 11 [19:28:38] they generated a few solutions with different T2 time and somehow knew which one was the good one [19:32:16] I really hope I can still find stuff about it in early lunar orbit or before LOI [19:33:02] if not, then they didn't even touch the two impulse processor until they calculated the final No PDI+12 solution [19:33:16] hmm, weird [19:34:28] I'm sure they ran it at some time [19:35:02] would be weird to not even try it for a whole flight until it really needs to work [19:35:13] they ran most other things many times over [19:36:49] will it be the whole maneuver we cant calculate (no PDI +12) or just not finding the TPI time? [19:37:53] oh we can calculate it no problem [19:38:31] you just have to transfer the whole thing to the MPT, run the TI again for TPI, look at how much off TPI is in time and then change the T2 [19:38:49] just less convenient [19:38:54] ah I see [19:38:54] but that's not what they did [19:39:10] well if its more realistic then im all for it [19:39:27] you have the option to calculate multiple arrival times at once [19:39:38] that's what they did, 600 seconds time range, with 60 second increments [19:39:51] so that will generate 11 solutions, all with a different T2 [19:40:04] and then they looked at that and said "ah yeah, plan 3 looks good" [19:40:07] and that's it [19:41:11] so what I don't understand is how they knew from looking at that solution that it was the right one [19:41:35] the FIDO did give 26.6° elevation angle and 130° transfer angle as inputs though [19:41:45] not sure if out of habit or if that actually did something [19:42:38] maybe they had an updated version of the TI, I don't know [19:42:52] so maybe I'll just re-add that capability to find TPI time [19:43:11] that's why I am searching for more calculations of that kind in the FIDO audio, to learn more about it [19:43:51] oh one thing they do that might be interesting to you is that they are rounding the TPI times to the next 30 seconds [19:45:41] might be easier to handle if you do any calculations with it by hand [19:56:02] interesting [20:40:26] I think I remember something that helps the sound issue [20:41:26] "Allow 3D Audio" is disabled in the OrbiterSound config [20:48:37] I have it enabled [20:57:28] night! [22:51:17] lol [22:51:24] Sundance is definitely going to contain some mysteries [22:52:37] the AOH and GSOP don't say anything at all about P70 or P71 [22:52:47] but they are definitely there in this code [01:58:23] aha [01:58:37] getting very close to the list of programs available to V37 [02:24:18] uuhhhhhhh okay [02:24:49] here's what all programs Sundance can start from V37: [02:28:24] P06, P10, P11, P12, P20, P21, P25, P30, P31, P32, P33, P34, P35, P38, P39, P40, P41, P47, P51, P52, P63, P72, P73, P74, P75, P78, P79 [02:28:51] present in Luminary 69 but missing in Sundance: P22, P57, P68, P76 [02:29:00] present in Sundance but not Luminary 69: P10, P11 [02:29:08] indy91, what the hell are P10 and P11 [07:13:41] @thewonderidiot I know P10 and P11 [07:14:03] oh? [07:14:30] also, good morning :) [07:14:32] earliest GSOP has them [07:14:39] morning! [07:14:55] launch time prediction [07:15:00] oh interesting [07:15:16] P10 for concentric rendezvous [07:15:33] P11 for a short profile [07:16:22] that's why ascent is P12, because of those programs [07:16:59] neat [07:17:43] nice, I found the GSOP section you're talking about [07:17:44] and I was right about P38 and P39! [07:17:48] this will be helpful [07:18:05] :D [07:18:28] yeah I was not really expecting all of this to be here already [07:19:24] I was certainly not expecting any flown program to have P10 and 11 haha [07:19:54] hehehe [07:19:55] they got replaced by a pen and piece of paper [07:20:31] they look like they're going to be a pain to disassemble [07:20:51] I bet [07:21:11] I wonder how functional they even are [07:21:26] maybe we will be able to find out :D [07:22:05] I'm counting on it [07:23:03] P10 and P11 are in bank 32 [07:23:27] I used those calculations from the GSOP in an earlier version of the RTCC MFD [07:24:02] which is in module B5, which is the other Sundance 292 module, so it will at least be at the same rev as the module I'm working on now [07:24:09] oh nice :D [07:25:48] Sunburnt already had P60 and P61 [07:25:57] Sunburst [07:26:09] DOI prediction [07:26:44] nice to see these old programs survive for so long [07:27:43] looks like P10 and P11 were deleted in Luminary 13 [07:28:06] hmm [07:28:26] so then were P60 and P61 deleted before Sundance? [07:29:04] Sunburst kind of needed it [07:29:26] so maybe they had decided to delete them even before [07:30:40] I'm sure some Tindallgram has info about that [07:34:04] almost certainly :) [07:34:11] alright well I'm going to get to bed [07:34:19] might be able to finish the first module tomorrow [07:34:44] depending on how much trouble fresh start and the downlists give me [07:35:01] good night! [07:35:05] goodnight! [13:32:09] hello [13:35:05] hey [13:35:15] Morning [13:35:27] how's it going? [13:35:47] Not too bad making a list of ECS observations to tackle [13:36:14] cool [13:38:07] I've been doing some research on the LM antenna. [13:39:02] everything I read(including the lm handbook) points to phase interferometry as the tracking method [13:40:20] same as the CSM HGA, just one dish with multiple elements, rather than 4 dishes (and a waveguide horn)with single elements [13:40:42] so I think the implementation can be very similar [13:43:14] hey [13:43:20] that makes it easier I guess [13:43:35] and no reacquire mode, just auto, so simpler there as well [13:45:20] Oh very cool [13:45:28] I have been looking at the lunar gravity model [13:45:35] https://imgur.com/a/1uHcmYX [13:45:51] Orbit over time? [13:45:52] this is an initial Apollo 11 post LOI-2 state vector [13:45:57] yes, 10 revs roughly [13:46:08] and this is using the R2 lunar potential model [13:46:10] Very steady trend [13:46:17] which they had in the AGC starting with Apollo 12 [13:46:24] already in the RTCC earlier [13:46:48] How well did this play out in reality? [13:47:05] Because I would guess we have a much better understanding of mascons today [13:47:09] one parameter that is in erasable memory and that we have set to 0 is responsible for making the HA go up and the HP go down [13:47:22] and we can't have this in Orbiter [13:47:29] on Apollo 11 they tried to do this backwards [13:47:45] start with an elliptical orbit that becomes near circular at CDH during rendezvous [13:47:49] and it did not work out very well [13:47:57] caused by mascons I guess, yeah [13:48:34] if we were able to use the R2 model in Orbiter then we would get more realistic trajectories [13:48:51] but I don't think we can [13:48:57] Whys that [13:48:59] but it's interesting to see the effect at least [13:49:34] in the config file for Earth, Moon etc. you can only specify J2, J3 etc. parameters, which change the gravity as a function of latitude [13:50:14] one parameter in the R2 model makes it a function of longitude, that has a downrange effect [13:50:24] Oh [13:50:32] and the parameter that causes this trend, I don't even know what it does haha [13:50:43] Haha gotcha [13:51:26] for some of the later missions not having this effects messes with the timeline a bit [13:51:47] Alex had a CSM circ maneuver at the same time as a DOI-2 maneuver on Apollo 17 [13:52:14] that's not easy to do, CSM and LM maneuver at the same time haha [13:53:19] Haha yeah [13:53:57] I mean, you COULD implement some sort of autopilot similar to the SIVB I suppose :P [13:54:40] you could use P99 for the DOI-2 burn [13:55:11] that's the erasable memory program used to deorbit the LM ascent stage on the later missions [13:55:18] automatic and guided RCS program [13:56:10] oh, Mike discovered something fun about Sundance. It apparently has P10 and P11, at least in some fashion, which were the onboard lunar launchtime prediction programs [13:57:16] we didn't think those programs ever made it to any flown AGC version [13:58:40] Oh wow [13:59:08] would be fun to get those working [13:59:26] the programs were deleted from Luminary in early 1968 [13:59:41] but they apparently never bothered in Sundance [14:03:34] Could be fun to play with and see how it works [14:05:03] yeah [14:05:20] we have an early GSOP that has the equations, but no program flow or procedures or anything [14:06:45] I think it's likely that access to the programs is disabled in some way, so that they didn't accidentally start those programs on Apollo 9 [14:06:54] hopefully just via a flag or so [14:07:09] that's how the prelaunch alignment programs are disabled in the CMC [14:07:33] Well didnt Lovell accidently call P01 during TLC? [14:07:41] TEC [14:07:44] but yes :D [14:07:44] Yeah [14:08:01] So not disabled on 8 lol [14:08:36] oh I meant P03 [14:08:52] which lets you point the sextant at targets near the launchpad [14:11:41] Oh [14:11:47] I didnt know about that [14:13:12] that's why our sextant has no optics door on the launchpad [14:13:18] to be able to use that [14:14:31] So was this ever used? [14:15:10] during checkout yes [14:15:14] but not by the crew [14:16:26] So the optics cover was installed when it was on the pad [14:16:59] I'm sure they removed it for the test or something [14:17:07] but in NASSP the door is not there before launch [14:17:41] I remember that [14:17:52] I thought it was a mesh issue tbh [14:18:30] definitely on purpose [14:18:43] although I might be getting some details wrong, can't find the flag I was talking about [14:25:12] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=1751.msg15774#msg15774 [14:27:35] Oh wow [14:29:23] OK time to fire up Eagle and see what needs to be fixed [15:13:48] the Apollo 11 RETRO doesn't discriminate. Everyone gets called babe, even Poppy Northcutt [15:22:38] Ok babe [15:22:44] ;) [15:23:18] So even running 1x, with the tunnel wide open, the cm o2flow spikes a lot [15:26:59] hmm, not so good [15:27:12] wait, what do you mean with spike? [15:27:20] instability or randomly goes up for a while? [15:27:42] because the second behavior would be normal I think, some things cycle on and off depending on pressure etc. [15:27:59] Second [15:28:06] creeps up [15:28:09] pegs [15:28:11] comes back down [15:28:13] repeat [15:28:40] Could be because the LM is on egress regulators [15:28:42] I think we had that behavior since forever [15:29:07] I guess I never noticed [15:29:18] how does the LM regulator play into it? [15:29:48] Well the LM isnt going to try to push oxygen in until it hits about 3.8psi [15:29:55] oh with the tunnel open. Well, that could be due to the gigantic valve sizes we use for the tunnel [15:30:05] but even with the tunnel closed we sometimes got that [15:30:05] Yeah tunnel open [15:30:32] With the valves open? [15:31:01] isn't one of the O2 regulators causing that when the pressure has fallen a bit [15:31:04] in the CSM [15:31:16] but it could of course indicate a proper instability somewhere in the LM [15:32:33] Yeah the CM pressure is falling below 5 or so [15:32:51] And the LM likes 4.8 [15:33:06] So I guess its simply replenishing the oxygen [15:33:27] could be yeah [15:35:40] I don't think that behavior is particularly problematic unless it's caused by an issue somewhere else [15:35:47] I wouldn't like jittering needles [15:36:55] morning [15:37:06] hey [15:38:42] https://i.imgur.com/8rq3mUI.png [15:39:09] this is what a realistic lunar potential model would do with a post LOI-2 state vector [15:40:33] over 10 revs [15:47:05] oh wow [15:47:18] thats quite erratic [15:51:36] well after Apollo 11 LOI-2 they were in a 53.6x65.6 [15:51:44] which was supposed to be circular after CDH [15:51:55] so I think that looks about right for that, just the reverse effect [15:52:25] if I would use an initial orbit with those HA and HP and would place the argument of periapsis right I could probably get the same, circular after 20 or so revs [15:53:41] the AGC supports this gravity model, our RTCC could support it, but Orbiter doesn't [15:53:52] it would help with LOI-2/DOI timing and circ maneuver I guess [15:55:56] right [15:56:17] had a good landing with 14 [15:56:55] cabin temps remained in the mid 60s, rcflyinghokie [16:26:59] Ok cool [16:27:10] I might reduce the power a bit after I fly through [16:29:31] ok [16:39:30] Odd my CO2pp is high [16:41:34] morning! [16:41:56] I have a CO2 filter problem on the LM it seems [16:42:23] *pulls out square peg in round hole contingency procedure* [16:43:18] hey Mike [16:43:23] hey [16:43:44] rcflyinghokie, did you have crew in suit for any amount of time with suit fans off? [16:44:13] I think so actually [16:44:19] I still have CO2 partial pressure nightmares, that's the other gauge next to the suit temperature where I made a error with the signal conditioner... [16:44:20] yeah that will do it [16:44:26] in the CSM [16:44:35] hopefully not in the LM as well :D [16:44:58] Why is it doing it though [16:45:06] I wait until the suit fans are running and H20 sep light out before putting crew in suit [16:45:16] crew in cabin, just closed the hatch and put the regs to cabin [16:45:21] and it climbs quick [16:45:48] hmm [16:45:56] when I put the SGD to cabin it jumps [16:46:10] so co2 isnt getting out of the suit circuit [16:46:48] thewonderidiot, I have to say, getting a working version of Sundance would be really great, but discovering that it might have P10 and P11 is even more exciting :D [16:47:35] hehehe [16:47:58] so far I haven't found any evidence that they are disabled [16:48:33] but do you think they are actually working versions of the programs? [16:48:54] I have no idea [16:49:04] I'm pretty sure Sundance can do navigation in lunar orbit [16:49:08] so that wouldn't be the issue [16:52:53] thewonderidiot, Luminary178 crashed horribly in a crater short of the landing site [16:53:04] kidding! :D flawless landing [16:53:43] hey, I had already tested a landing just when 178 was ready [16:53:49] but I didn't test anything else [16:55:22] I did find one oddity, the AGS Hdot diverged a bit from PGNS throughout descent [16:55:34] but that is the AGS [16:56:12] so at PDI ignition they were both identical, but by P64, there was about a 5 ft/s difference [16:56:28] hahaha [16:56:30] which is weird because I did not have this happen on 17 [16:58:12] thewonderidiot, and you said there is P70 and P71 as well? [16:58:51] yes, V37 checks for them [16:59:01] in a slightly different way from Luminary, but they are definitely there [16:59:23] but no P12 [16:59:39] P12 is also here [16:59:41] oh [16:59:42] ok [16:59:51] that would have been strange [17:00:11] I was already thinking if it had some Sunburst ascent code or so :D [17:01:12] hahaha, that would be very strange [17:01:57] yeah from V37, only missing are P22, P57, P68, P76 [17:03:15] what about P63 and P64? [17:03:40] P63 is definitely startable via V37, and lives in the same bank as P10 and P11 [17:04:09] I took a brief look at it and the first dozen instructions or so look quite similar to Luminary 69 [17:04:22] not sure about P64 yet [17:08:59] all I can confidently say is that you can't start P64 from V37 :P [17:24:57] haha yeah [17:51:42] looks like the rest of this bank is just the update program [18:04:17] So it looks like with the tunnel open and 2 crew in the LM the cabin co2 is what gets super concentrated [18:10:47] strange [18:11:08] So after being in and out of the LM before ECS powerup, the pp is 14mmHg [18:11:11] In the cabin [18:11:24] And it slowly decreases as it flows into the CM [18:11:33] thats weird I never had that happen with crew in cabin [18:11:52] This is cabin pp not the sensor [18:12:03] oh [18:13:37] The sensor reads an average between before the hot heat exchanger and after the suit circuit relief [18:14:05] technically the sensor is on a small pipe between the two [18:14:24] But it looks like the cabin CO2 is high because its not exiting fast [18:20:48] And its not exiting because the CM is slightly higher pressure than the LM [18:22:10] also the sensor logic might need some work [18:22:18] but thats independent of this situation [18:26:51] thankfully the crew cant die yet due to CO2 in cabin :D [18:26:55] lol [18:27:10] So I wonder if there is a good way to fix this issue [18:27:42] The sensor goes off because once the ECS is powered up that high concentration goes everywhere else [18:27:51] Enough to go to 12 or so on the gauge [18:28:12] it does comer back down, but I need to look at a way to keep it from building up [18:36:28] did they do anything to prevent that during the real missions? [18:36:43] I dont know [18:37:24] The only way I can think of would be suit hoses [18:39:06] ppCo2 in the cabin at transfer to LM power is 15mmHg [18:39:15] of course everywhere else in the LM ECS its small [18:39:36] Ohhh [18:39:48] During the initial entries they took CSM O2 hoses in [18:41:30] I bet that would keep it down [18:41:38] Because it builds up during each IVT [18:41:48] And wont go down until the suit fans are running [18:42:06] If we had csm hoses then it would run the LM atmo through the CSM scrubbers [18:42:39] But that sounds like a fix to go along with CSM ECS [18:43:06] sounds like a realistic way to do it [18:43:25] Yeah if you look at IVT checklists bringing CSM hoses is a step [18:43:44] So I bet thats exactly what its for, suit flow into the LM and return into the CSM [18:44:07] Otherwise the CO2 wouldnt move in 0g [18:44:22] yep [18:45:16] So idk if theres an easy way to emulate that without reworking CSM ECS [18:46:28] we could add something in the PAMFD [18:46:33] Thats what I was thinking [18:46:40] like "IVT" [18:46:43] maybe a pump from CM cabin to LM cabin and one from LM cabin to CM cabin? [18:46:44] or something to the effect [18:47:15] A real fix would be implementing the suit/cabin flow valves in the CM [18:47:22] Which would also solve the direct O2 issue [18:47:39] But thats part of a lot of redeisgn [18:47:43] redesign* [18:48:04] The pumps could work [18:48:32] I like a CSM redesign better [18:48:39] Yeah thats where my head was going with that [18:48:43] we are breaking the ECS anyway [18:48:52] The pumps are more of a bandaid [18:49:05] yeah [18:49:21] For now, until the CSM ECS is reworked, perhaps an IVT state in PAMFD that doesnt add CO2 to the LM? [18:50:22] Hm but the CSM still would need 3 crew members to emulate the O2 metabolism [18:50:32] Because the CSM is working that load [18:50:44] yeah, disabling CO2 flow somehow doesn't sound good [18:51:20] Yeah essentially the crew is on CSM ECS until the hatch is closed [18:51:31] Other than the final IVT to the LM [18:51:53] Maybe remove moving the crew in PAMFD to the LM until final IVT? [18:51:59] It would just ber a checklist fix [18:59:04] hmm maybe [19:00:20] But it could be interesting to make the suit hose connections and see what happens [19:06:26] https://www.youtube.com/watch?v=1UN3C4Blamg [19:06:53] interesting video showing RTCC & the CSM/LM simulators [19:11:02] sounds like something for me [19:13:38] block 1 sim? [19:18:56] looks like it [19:20:04] isn't it funny, that guy just hitting every switch he sees? looks like me sometimes when I get bored flying NASSP :D [19:21:16] Lol me too! [19:21:29] "Is this implemented yet" click [19:21:37] *master caution* [19:21:39] yep [19:21:41] haha [19:24:53] hehehe [19:28:21] I was showing it to someone the other day and he was convinced it was on rails [19:28:28] So I separated the CM from the SM [19:28:36] In LPO [19:29:30] haha nice [19:32:25] lol [19:53:01] Any idea where the CO2 removal rate came from for the scrubbers? [20:01:08] it's the same as in the AtmRegen class for the CSM [20:01:33] and those numbers have been there for forever [20:01:40] if you are lucky you find something in the old forum [20:05:52] indy91, do we have any documents other than the LM-3 systems handbook that have Sundance flagword bits? [20:07:35] I just found one of the sources of shifted erasables -- a flag bit that got moved to FLAGWRD8 in Luminary but exists in a different erasable apart from the flagwords in Sundance [20:07:46] Yeah "numbers in there forever" scares me haha\ [20:08:01] I am curious if the capacity of the LM scrubbers was different than the CM [20:08:11] Or rather the removal rate [20:08:40] seems almost more like they're different than the same [20:13:00] not sure [20:13:15] I have some pages from the G&N Dictionary, but not the right ones [20:13:44] AOH doesn't have it, while later AOHs usually do I think [20:13:57] hmm, okay [20:14:17] definitely going to need some more documents [20:15:14] might email Don... he has two copies of the Functional Description and Operation using Flight Program Sundance, from different dates [20:16:49] REFSMMAT flag is the same as Luminary, that's all I know :D [20:17:03] hehehe [20:17:13] every flag up until this one has been the same [20:17:16] REINTFLG [20:19:29] er , I mean, it's in flagword 10 in Luminary [20:19:47] I think Sundance may only have flagwords 0-9 [20:24:27] the DAP document has some DAP flags [20:24:34] most are in DAPBOOLS though [20:24:48] APS flag, flagword 1, bit 12 [20:29:08] you could email the owner of the Apollo 9 G&N Dictionary [20:29:27] https://www.echoes-from-apollo.com/my-blog/2019/07/apollo-ix-lm-3-final-flight-crew-gn-dictionary-dated-february-24-1969-.html [20:30:11] indy91 I just got another DAP PAD around 98:30 on 11 is this new? [20:30:35] the one with gyro torquing angles [20:31:46] hmm [20:31:50] that should only come once [20:32:28] how much time since you got it the first time? [20:32:45] Well I got DAP data already [20:32:58] I just dont remember getting the torquing angles [20:33:01] oh [20:33:03] Its correct per the FP [20:33:08] I just didnt have it in the checklist [20:33:11] I doubt it's new [20:33:21] maybe new enough for you to not have gotten it before :D [20:33:26] Thats what I mean :) [20:33:45] CO2 is back to normal after the suit tests [20:34:01] But I will come up with a solution for the other IVTs [20:36:04] it's definitely one of the latest Apollo 11 MCC updates [20:36:28] I think before you got the torquing angles separately [20:36:35] but now as part of the DAP PAD or so [20:36:42] that might be the difference [20:36:52] changed 1 Sep 2018 [20:38:43] Oh another thing, any reason the CO2 is computed in two places? [20:38:50] GetSensorCO2MMHg [20:39:02] GetECSSensorCO2MMHg [20:39:16] in lm_ecs [20:39:28] looks like an accidental duplication [20:39:56] I remember the first but not the second [20:40:18] they are different [20:40:24] one checks the CB [20:41:12] the one without CB check is used in the crew health determination [20:41:20] Oh I see [20:41:41] Seems a little inefficient [20:41:45] they should probably be renamed so that it is more clear what they do [20:41:50] Yeah [20:41:58] Also changes on one need to be duplicated [20:42:00] and only one function should have the complicated code [20:42:12] the one with the CB check should just call the other one [20:42:16] Yes [20:45:10] AlexB_88, I found how they calculated the CSM sep time I think [20:45:27] not the "just use the flight plan time" version [20:45:51] DOI TIG on the LDP display (so impulsive) minus a specific time [20:46:03] although that time they mention seems off by a minute [20:46:07] but that makes sense [20:46:15] works best for the timeline [20:48:16] hahahaha [20:48:23] GUIDO is off the console [20:48:38] someone was calling him and FIDO says he is standing in [20:48:54] so someone now called "hey Fuidance" [20:50:48] who needs a separate guidance officer anyway :D [20:52:48] haha [20:53:15] I think Ive been using the SCOT CSM sep longitude on 14 & 17 [20:53:34] I guess there isn't a correct answer to that [20:53:37] up to each FIDO [20:54:55] Ive been testing the delta-gliders collision physics on the moon [20:55:03] so much better then we we have on the LM lol [20:55:50] there mus be a way to improve it [20:55:53] must* [20:56:08] I think it has a more complex shape [21:08:25] So I am experimenting with putting the cabin in the LM co2 computation [21:09:10] Because the 2 inlets of the co2 sensor, one is right by the suit gas diverter it might give a better average instead of being zero the whole time the crew is in the cabin [21:10:30] bank 4 disassembly complete! and bank 5 starts off with the downlists, looks like [21:12:12] great [21:12:14] good night! [21:12:16] night! [21:13:05] Annnd hes gone [21:13:20] lol [21:23:54] Totally drawing a blank, AGS time is decimal minutes correct? [21:26:28] uhhhhh [21:26:51] no idea :D [21:30:24] yep [21:30:40] 0000.0 [21:38:20] Haha I thought so [22:05:25] Watching the RR ant move is cool! [22:05:33] We need to do that for the LR lol [22:05:52] After we put one on there, of course [22:29:32] ohhh man these downlists are going to be difficult to untangle [23:35:12] yeah I should get around to making an LR mesh [23:35:55] I have just finished a few updates for the LM touchdown points [23:36:30] just adjusted the height of them a bit [23:37:28] btw, make sure you have "linear interpolation" selected in the Orbiter settings "Visual effects" tab [23:38:48] or else in some parts of the terrain, the LM will seem to be sunken into or floating over the terrain [23:48:10] Lol changed [23:57:56] I only found out about that from reading the AMSO 2016 post lol [23:58:28] I had cubic interpolation up until now, and linear makes quite a difference I find [01:55:46] I always had cubic as well I'll see what it looks like tomorrow [01:55:49] night! [05:39:23] confirmed that Sundance did not have CONTROLLED CONSTANTS [05:39:52] the constants that FRESH START is using are just mixed in with the normal ones [05:49:10] I'm skipping over the downlink tables for now because I don't have enough info, but I got their structure sketched out and I know which addresses correspond to which word in which list [05:49:38] so with the systems handbook I know their function, just not necessarily their variable name [05:50:03] fresh start is starting off better than expected, there's been enough context that I have been able to mostly figure out what is here and what isn't [14:15:44] Good morning [14:34:17] hey Ryan [14:34:56] So I am walking through the LM cold fire and hot fire procedures again and am trying to figure out where I got the procedures for SCS min and max db holds in the CSM [14:35:30] I have the BMAG switches moved to rate 2 then att1/rate 2 [14:35:38] I have no idea why [14:37:18] that would reset the attitude it is holding I guess [14:40:00] CMP Solo Book has a handwritten note [14:40:05] "uncage BMAGs" [14:40:08] Ahh [14:40:16] I guess thats what does it [14:40:31] the printed part sets deadband and rate low [14:40:32] Just sanity checking my procedures [14:40:39] but not attitude hold [14:42:03] So cycling the BMAGS is what establishes the attitude to hold [14:43:45] from Att 1/Rate 2 to Rate 2 and back to Att 1/Rate 2 would give it a new attitude to hold [14:45:40] OK cool thats what I have in there [14:48:27] Just didnt realize why so I was questioning it [14:48:48] Also, do you know if they used the CMC to establish orb rate in LPO? [14:51:20] I don't think so [14:51:24] not on 11 [14:52:50] Ok [14:53:04] I saw the procedure in the ops checklist so had me wondering [14:53:25] oh it's in there? [14:53:35] ah 2-6 [14:54:48] Yeah [14:57:59] I still don't think they actually used it on 11 [14:59:24] or 12 [14:59:34] on Apollo 13 they already had the V79 it seems [14:59:42] which was later incorporated in P20 [15:01:36] Yeah I never saw any reference to use it [15:04:50] hey [15:08:03] Morning [15:09:01] hey Alex [15:10:41] I have a few small fixes for the LM touchdown points [15:11:40] oh and I just learned something, you have to have linear interpolation set for the surface elevation in the "Visual effects" tab [15:12:07] that makes the LM not sink into or float above the terrain when landed in some cases [15:24:14] good catch [15:25:42] about the touchdown points, I just raised them a bit as the LM was sitting just a tad high when landed [15:30:55] right [15:38:05] another thing I played with was lowering the stiffness of the probe touchdown points, as you would have a noticeable foward pitching after contact [15:38:20] Hmm any reason my DPS is trying to gimbal when maneuvering after undocking? [15:38:36] I am thinking that would still be a realistic effect but probably not as noticeable as it is [15:38:37] I dont recall ever getting a gimbal light when station keeping with the CM [15:39:03] did you do a V48 recently? [15:39:47] Yes [15:40:02] you might of PRO on the angles display then [15:40:09] But V34 after the DAP load [15:40:14] oh [15:40:22] weird [15:40:24] Yeah [15:40:49] It only does it after I maneuver the LM [15:41:43] are you under AGS control? [15:41:49] Yes [15:42:18] ah [15:42:24] let me check something [15:44:12] I think you need to be careful with that [15:44:37] you have to have engine gimbal disabled most of the time under AGS control [15:44:56] pretty sure that behavior is correct, but I will check [15:45:33] Hmm is there a step that has it disabled? [15:51:38] where are you in the checklist? [15:51:52] is there really an AGS controlled attitude maneuver? [15:52:31] I think it did go into the gimbal test somehow [15:52:40] I was letting the auto checklist run [15:52:45] So maybe it goofed in there [15:54:23] the PGNS can't even control the DPS gimballing if you are in AGS mode [15:56:40] Yeah i think somehow it went into test [15:57:39] before you went to AGS control? [15:58:45] Yes [15:58:47] I think [15:58:59] I am backtracking through the checklist for errors [15:59:36] I'm checking the control logic for it [16:02:39] ok I think it should work correctly. Under AGS control it will gimballing if you have: gimbal switch enabled, attitude control in mode control and DPS needs to be armed [16:03:01] and DECA needs power, obviously [16:03:08] I am thinking it was the self test accidently run [16:03:30] self test or V48 gimbal drive test? [16:04:37] drive test [16:04:44] Hmm or not [16:04:56] Want a scn? [16:05:14] sure, I can check it [16:05:27] making sure it's not an issue in the electronics somewhere haha [16:06:04] I have a feeling its procedural but yeah one sec [16:06:35] https://www.dropbox.com/s/c5dj9qj48ye0pir/Apollo%2011%20MCC%20-%20LM%20Undocking%200001%200001.scn?dl=0 [16:07:26] and I'll ignore all master alarms [16:07:31] or I have to switch to your branch :D [16:08:02] Lol [16:08:41] so at what state is that scenario, with the gimbals currently moving? [16:09:08] pulse mode [16:09:17] so that should already disable the gimballing [16:10:39] Configuration before undocking per the apollo 12 activation checklist [16:10:41] what should I do to replicate it [16:10:56] Guidance mode to PGNS [16:11:50] anything else? [16:13:13] start the undocking checklist? [16:14:12] Yeah [16:14:21] Actually [16:15:07] Just moving to mode control [16:15:30] att control to mode control does it independent of the pgns ags switch [16:15:33] you have the abort switch pressed in the scenario [16:15:40] that also arms the DPS [16:15:41] Uhh [16:15:44] might be the cause [16:15:46] haha [16:15:48] thats weird [16:15:59] and then a V48 with accidental gimbal drive test [16:16:02] that would do it [16:16:25] I am going back to see when that happened [16:16:39] also IMU TEMP light on, that's strange [16:16:54] Muse have been an accidental click [16:16:57] probably glcol loop having some issues with the old behavior :D [16:17:02] Must [16:17:09] Glycol heat capacity is different [16:17:12] So yeah [16:17:13] I guess you don't have it on [16:17:19] Nope [16:17:31] Temps are all normal for me [16:17:36] ok [16:18:03] so it probably was the abort switch plus V48 gimbal test [16:18:09] I have a save 30 minutes prior after the gimbal test, and the abort is not pressed so I guess it was an accidental thing [16:18:11] abort button* [16:18:20] Running through it to make sure [16:18:31] you just want to give the flight controller a scare after Apollo 14 [16:19:23] Haha [16:27:03] the APS and DPS engine arming wiring in the LM is very weird though [16:27:12] wouldn't have surprised me that it's a bug somehow [16:28:27] if the engine arm switch is pressed, then the state of the abort button determines which circuit breaker is used to arm the DPS [16:28:35] switch is in DPS* [16:29:16] Interesting [16:29:18] indy91, PR sent [16:29:23] some redundancy thing I guess [16:30:19] have you tried a P57 or made sure there is no jittering or that kind of issues that we had in the past? [16:31:01] I have not gotten that far yet [16:31:25] oh sorry, that was meant for Alex and his PR [16:31:29] Ahh [16:31:37] its the same as before [16:31:42] great [16:31:46] what we had was already quite stable actually [16:32:18] yeah [16:32:19] merged [16:32:23] in the PR, its only the height of the TD points that change, also I reduced the stiffness of the probe touchdown points [16:32:48] so there is now less of a pitch-forward motion when the probes contact the durface [16:41:56] for old scenarios, you have to fire a thruster in order for the LM to settle at it s new TD points [16:42:06] for landed LM's [16:43:06] ah interesting [16:43:38] I first though "what is saved about the touchdown points", but it's the position of the LM [16:54:43] was listening to more of the Apollo 11 FIDO audio, they got some orbital elements for Luna 15 from the Soviets [16:54:51] which was a mission going on at the same time [16:55:27] "declination relative to the lunar equator... is that their phrase for inclination?" [16:57:13] I mean arent they the same thing? [16:57:39] yeah [16:57:48] just slightly different terminology I guess [16:58:27] morning! [16:58:40] I think I would have enough information to put a Luna 15 in scenarios haha [16:58:42] hey Mike [16:59:22] 125° inclination, so very different orbit [16:59:57] but it's nice that they didn't want to interfer with Apollo 11 and were cooperative [17:03:53] haha [17:16:00] So yeah I guess I punched the abort button by mistake lol [17:16:12] No checklist mistakes causing it [17:16:24] Trying undocking again shortly to make sure [17:17:58] good systems test [17:18:02] that does indeed arm the DPS [17:19:33] So that was it [17:19:57] Were the abort buttons backlit? [17:20:16] dont think so [17:20:52] I think I remember us looking it up a while ago after we back lit the start/stop buttons [17:21:02] and came to the conclusion that the abort buttons are not [17:22:08] Yeah that was what I was remembering [17:26:49] No issues this time [17:26:54] Pilot error [17:48:36] don't you hate it when you chase a bug for a while and think it's something really complicated and then it turns out you just forget a divide by 2, which is way to easy to spot [17:48:46] too* [17:51:13] haha [17:51:25] in the RTCC I bet? [17:51:54] yes [17:51:59] fun orbital mechanics fact [17:52:20] if you apply a DV and travel for one orbit (instead of half an orbit) you arrive at the same altitude again, doesn't matter the DV! [17:56:38] hahahaha [18:00:52] disclaimer: only applies to elliptical orbits [18:07:38] lol [18:07:47] At least you didnt divide by zero [18:13:45] lol [18:21:02] indy91, I have done more work with the TD points [18:21:22] no change in the functionality, but a clean-up of the functions [18:22:11] ok [18:22:20] basically I made it like saturn, make it all in one function and call ConfigTouchdownPoints from each stage that needs to redefine them [18:22:53] for example, hover stage is now ConfigTouchdownPoints(7137.75, 3.5, 4.25, -3.60, -5.31, 3.86, -0.25) [18:23:26] nice [18:23:32] instead of the whole thing repeated at each stage [18:24:01] yeah, makes sense [18:24:01] 4.25 is the legs extended distance from center [18:24:15] in the docked stage I set that to 3.5 [18:24:38] so if you forget to extend the landing gear, big surprise at landing lol [18:24:54] uh not 3.5, 0.5 [18:25:56] first you partially melt the landing gear during the descent [18:35:06] the function now has 12 points :D [18:36:23] 1 top, 4 middle, 4 bottom and 3 probes [18:38:06] I wonder if there was a contingency for using DPS with gear retracted [18:38:38] Say Aquarius' pyros didnt fire [18:39:25] short bursts maybe [18:41:10] I wonder how the thrust would be effected by impingement [18:42:59] "If unable to deploy one or more landing gear, a landing will not be attempted. Descent engine burns will be continued since control problems are not expected to exist and damage to the landing gear from the burn will not affect alternate missions" [18:43:02] from the mission rules [18:43:30] what, so now I have to make some roasted landing gear mesh/textures? :D [18:43:31] so it's more a problem to the landing gear than anything else [18:44:57] Interesting [18:45:05] Haha yep oh and a landing radar [18:45:35] ouch yeah [18:45:42] so much to do :D [18:45:50] chop chop! [18:45:56] *hides in LM ECS* [18:46:15] you probably made the valve sizes large enough to fit in there [18:46:20] Haha [18:46:41] I am going to experiment with making them smaller now that I have a better heat capacity [18:50:21] I don't even know if smaller is more realistic, but it certainly makes things more stable [18:51:30] Yeah [18:52:02] As long as I can emulate the flow/behavior [18:52:10] I will mess with dropping them [18:57:34] hmmm, mysterious coding in fresh start code, clearing a flagword bit that Luminary doesn't have [18:57:44] "INT FLG 2", according to the systems handbook [18:57:50] flagword 5 bit 14 [19:01:02] do other ones have INT FLG 3? [19:01:48] I haven't hit any code that uses that one yet [19:02:01] just "INTFLAG" is integration in process [19:02:09] in Luminary [19:02:33] in flagword 10 [19:02:38] which sundance doesn't even have :D [19:04:10] right haha [19:05:19] I hadn't looked at those flagwords in the Systems Handbook before [19:06:08] I definitely see ascent guidance flags [19:07:54] hahaha, and here is a chunk of RR handling code, from the middle of RRZEROSB, right inside fresh start [19:07:58] Sundance is so weird [19:08:43] Was the 11 CSM sep maneuver radially towards the moon? [19:08:51] Had to be right [19:09:54] yes [19:10:02] DVZ +2.5 which is towards the Moon [19:10:06] with the -X thrusters [19:10:34] So that would mean P41 would show +5fps when done? [19:10:36] note to self, when cleaning your VS solution, remember to rebuild modules after instead of loading the sim and wondering where the hell your LM is [19:10:41] lol [19:10:42] I think so [19:10:45] ok [19:10:59] I'll write a special procedure for that then [19:11:10] Instead of calling the normal P41 [19:11:11] thewonderidiot, have you done pinball noun tables yet? [19:11:44] rcflyinghokie, look at the Solo Book [19:11:47] it has that [19:11:58] "BURN 2.5 0 0 -> 5, 0, 0) it says [19:12:17] Ah thats right we have that [19:12:52] we got 4 full new Apollo 11 checklists last year :D [19:13:25] I know I have them locally now [19:13:34] I just forgot about the solo book [19:13:36] indy91: no, I was thinking about hitting that after this module is done though [19:14:01] that will give some hints about P10 and P11 [19:15:30] oh nice [19:15:55] "Several P10 and P11 erasables that had been deleted from [19:15:56] Rev. 13 were temporarily redefined to prevent cusses since [19:15:57] they were referenced by the Pinball Noun Tables." [19:16:46] oh boy lol [19:18:00] and those programs had alarm codes [19:18:59] "The P10 and P11 pad-load TIG (AS) was deleted from Erasables and from the Downlink lists" [19:25:39] I wish they named those erasables haha [19:26:16] TIG (AS) [19:26:54] right [19:27:03] but not the ones referenced by the noun tables [19:27:12] right [19:27:35] the GSOP promises quite a few parameters available for display [19:41:57] almost done with fresh start [19:42:08] it is both more similar and less similar to Luminary than I was expecting, lol [19:43:00] remember when I thought Sundance was going to be a bit boring based on the GSOP [19:43:08] hahaha yeah [19:44:33] on the one hand I'm super happy that it's so interesting and different [19:44:45] but on the other it's going to make making a working version of it quite a bit harder lol [19:45:17] just think of the video that's going to come from it. "The hidden programs of Apollo 9" [19:46:02] hehehe [19:46:28] Is it the LM uplink that comes with the T2 abort pad? [19:47:08] what do you mean? [19:47:47] I got a "ready for uplink" with the T2 abort pad [19:48:03] let me check what that is [19:48:04] Unless I missed the DOI uplink after resuming a quicksave [19:48:10] doesn't it say if it's for CSM or LM? [19:48:26] indy91, PR sent [19:48:51] LM CSM SV [19:49:00] post sep [19:49:25] "CSM state vector, time tagged PDI+25 minutes" [19:49:40] basically same functionality as before, but half the code :D [19:49:45] that's what gets uplinked with the T2 update [19:50:19] Right [19:51:11] I guess there have been a few minor updates since you did the checklist [19:51:17] but even those are from 2018 [19:52:14] Yeah I was halfway through fixing 11 when I was on hiatus [19:53:47] Are the T2/T3 considered the "Lunar Surface PAD" [19:54:53] hmm, the noun tables should be in module B6, our one Sundance 306 module [19:55:01] I guess that solidifies it as the next one to work on [19:55:39] T2 and T3 are on the Lunar Surface Data Card in the LM Data Card Book [19:56:33] I mean as far as the flight plan goes [19:56:39] is that the reference [19:57:24] yep, I think that's what it refers to [19:58:03] Ok cool [20:01:29] If thats the case everything lines up nicely with a bunch of switching lol [20:13:54] would it be possible to put T2 and T3 in the same message? [20:14:04] Instead of 2 separate ones [20:16:33] maybe. but that would be a pretty large PAD, wouldn't it? [20:17:03] Nope [20:17:14] Together they would be smaller than a normal maneuver PAD [20:18:03] ok [20:18:06] yes it's possible [20:18:17] would it help you out a lot with the checklist? [20:18:19] 16 lines long for T3 [20:18:26] done with fresh start! surprisingly few unknowns :D [20:18:46] Yeah it would help follow the flight plan better and use less time [20:18:52] If its not much work, of course [20:20:44] shouldn't be a problem [20:20:52] I can probably just merge the display code [20:20:56] the rest is quick [20:21:18] Ok cool [20:21:41] And it would just display at the same time as the T2/ LM CSM SV uplink comes up [20:21:58] T2 is 13 lines T3 is 16 [20:22:07] Should both fit with space between [20:31:26] adding a completely new PAD for the MCC, that is work [20:31:39] but putting those two together, no problem [20:32:37] Awesome [20:32:47] And it removes an uplink [20:33:00] or thread [20:35:21] even the down-telemetry program has differences [20:36:03] is that pretty much the same all through Luminary? [20:38:59] they changed the rate between 69 and 99 [20:39:09] I think [20:39:27] but mostly yeah [20:44:41] the end of module B1 is in sight :D [20:48:21] :D [20:49:38] So I will be making some more tweaks but cabin and suit temps and CO2 are very stable now [20:50:02] I do have some ideas for fixing the buildup during IVT [20:50:15] But it does eventually come down to a nice stable level when in suit and cabin [20:50:27] rcflyinghokie and AlexB_88 did you actually read yesterday why I am so excited about Sundance? [20:50:31] it seems to have P10 and P11 [20:50:37] onboard lunar launchtime prediction programs [20:50:50] which we didn't think ever making it into flown software [20:50:59] but it might be there in Sundance [20:51:05] Yes I did! [20:52:01] nice [20:52:34] I used the equations for that from a very early GSOP in my first MFD for Orbiter [20:52:47] I think the 1st thing Ill try if we get it is P63/64 [20:53:14] haha [20:53:20] see if Spider can do it :p [20:53:28] and we thought landing with Luminary 69 is an achievement [20:53:34] yeah [20:53:44] I wonder if we somehow could convince Sunburst to land [20:54:03] lol [20:54:08] probably not without modifying some hardcoded constants [20:54:11] so there is one note in an early Luminary memo [20:54:14] but it has everything, in a way [20:54:32] Sunburst has ascent, DOI TIG prediction, DOI guidance, descent guidance... [20:55:08] It appears that P46 should be assigned to someone other than Peter [20:55:08] Adler (perhaps someone in Eldon Hall's group) and that Peter Adler should [20:55:09] develop the SUNDANCE powered flight programs for the lunar as well as [20:55:09] earth environment required for LUMINARY. The powered flight programs in [20:55:10] SUNDANCE are known (known to Dan Lickly and Peter Adler) not to work for [20:55:11] the lunar environment. [20:55:54] well, I didn't expect it to work out of the box [20:56:01] but who knows what that really means... and this was 3 months before the release of Sundance 292 so maybe they fixed it [20:56:12] hehe [20:56:29] we'll see [20:58:15] aaaaaand done with module b1! for now [20:59:40] I can confirm that I must have read that early GSOP in 2012 already [21:00:19] and implemented the equations for P10 and P11 in a lua script I released [21:00:25] haha [21:00:51] yeah, I downloaded in July 8th 2012 [21:01:19] oldest file in my MIT folder [21:01:47] oh wow lol [21:02:06] I just hope that we don't have to cheat and modify the code to fix it [21:02:35] I have to imagine that they mostly worked [21:03:17] hmmm [21:03:26] should I do this module in order, or just skip to pinball banks? [21:03:30] I'm definitely more confident about P10/P11 working than P63 [21:03:32] it starts with bank 36, which contains the P40s [21:04:15] if there is no downside to that, go with the fun stuff [21:04:34] all of it is fun stuff haha [21:04:57] the very first thing in bank 36 is the tables for the ignition routine [21:06:10] hmmm [21:06:15] but that will be quite complex [21:06:25] let's see [21:06:36] only thing I know for sure from module B1 is that P06 is in bank 37 [21:06:39] bank 40 is pinball [21:06:59] P06 shouldn't be too difficult [21:07:26] yes, but what else is in that bank is what scares me :D [21:07:41] haha [21:07:46] pinball will be a good place to start anyways [21:07:51] that did not change a lot even since retread [21:08:08] so it will be very easy to identify stuff in fixed-fixed and erasable that moved between 292 and 306 [21:10:03] oohhh [21:10:10] except bank 40 does not start with pinball as it does in luminary [21:10:28] this is the AGS initialization code [21:12:28] must have been moved to make space for something [21:12:33] yeah [21:12:40] ah well, I guess I'll start with AGSINIT then :D [21:12:57] so far so good, for fixed-fixed [21:13:01] REFSMBIT did not move from 5012 [21:13:45] uh oh [21:13:47] but ALARM may have [21:15:00] aha! it did [21:15:05] the game is afoot, lol [21:15:34] three extra words were added between address 5012 and 5561 between Sundance 292 and 306 [21:15:47] it is immediately clear why this set of modules does not work together :D [21:16:19] ha, I was thinking about asking you if we could create a sort of Frankenstein's Sundance just to see what happens [21:16:25] but not many good things I guess [21:16:29] hopefully I'll be able to narrow that down [21:16:39] oh yes I've already tried to run all of these modules together in virtualagc [21:16:43] it just crashes instantly [21:16:47] yeah [21:17:27] well have more fun with Sundance [21:17:35] good night! [21:17:45] night! [01:19:43] oh boy there are a lot of things shifting between sundance 292 and 306 [01:47:18] huh [01:47:24] AGS initialization is almost exactly the same [01:47:35] except they had two scale factors change [01:47:40] "METERS TO FEET SCALE FACTOR" [01:47:44] seems like that should not change :D [02:05:39] RSCALE 2DEC 3.280839 B-3 [02:05:41] in Luminary [02:05:48] was this in Sundance, apparently: [02:05:51] RSCALE 2DEC 3.280833 B-3 [02:47:25] AGS stuff done, apparently corrections for RSCALE and VSCALE are the only difference from Luminary 69 [02:47:41] now I've hit PINBALL code [02:59:31] interesting [02:59:39] im off, good night! [07:27:36] aha! I believe I have identified a change made between Sundance 292 and 306 :D [07:35:30] https://github.com/virtualagc/virtualagc/blob/master/Luminary069/WAITLIST.agc#L185 [07:35:51] the five instructions at CKIMUSE and three at SVCT3X are not present in Sundance 292 [07:36:35] however in Sundance 306, WAITLIST at the same address as it was in 292.... but TASKOVER is eight addresses higher [07:36:50] and there are no other differences between Sundance and Luminary between those two [07:37:00] seems like a perfect match :) [07:37:40] it will be easy to tell, too, if this is from 302 or 306 [12:45:01] Good morning [12:45:46] hey [12:45:53] you got your T2/T3 PAD combination [12:45:59] Awesome! [12:46:54] I forgot to put a redirect thing in there, when you have a scenario with the mission state of the old T3 calculation that it redirects you to the combined T2/T3 now [12:46:57] Merged into my ECS branch :) [12:47:22] but that's a 3 minute window where old scenarios won't continue in the MCC calculations, not really a big deal [12:47:29] Yeah [12:47:39] I was going to say the odds are slim, possible, but slim [12:47:59] I'll go through all the missions again anyway [12:48:02] Me too [12:48:07] removing some old calculations etc [12:48:31] there is a lot of duplications in the RTCC right now, where the MCC still uses old calculations and I was afraid to just put in the new ones without proper testing [12:49:55] Right [13:23:37] T2 and T3 aborts look good [13:24:01] Plenty of room [13:29:50] good [13:30:15] FIDO doesn't understand something about a RTCC program, so what does he do? He gives the person who programmed the thing a call... [13:30:29] kind of wish I could do that sometimes haha [13:31:17] Seriously [14:02:52] VHF ranging works doesnt it? [14:03:03] it does [14:03:09] it needs the right switch settings in the LM [14:03:12] and CSM [14:04:02] Hmm what do i need? [14:07:18] also a reset on the VHF ranging to make it work [14:08:52] in the CSM [14:08:58] VHF AM A - off [14:09:03] VHF AM B - Duplex [14:09:10] VHF RNG - on (up) [14:09:17] EMS FUNC and MODE - VHF RNG [14:09:38] and then on panel 9: VHF RNG - RSET [14:10:47] Had everything but the reset [14:11:38] yeah, that's a bit of a weird one [14:11:59] Hm still nothing [14:12:28] Oh got it [14:12:32] Took a second [14:14:57] yep [14:15:19] takes a moment [14:17:04] and now you never want to do sextant marks ever again [14:18:25] Lol [14:18:31] I will play with it after DOI [14:18:40] I am so rusty with the LM P52 [14:22:20] btw, how do you like the new CMC auto optics behavior? [14:23:08] It was weird at first [14:23:15] But I like it it feels more natural [14:23:23] Like motors are actually drivign it [14:23:26] driving* [14:24:04] yeah, that definitely wasn't the case before. It just added the CMC drive commands to the actual optics angles [14:24:28] I'm still not 100% happy with it, but it's better [14:24:33] and P24 can now work [14:24:47] P24 is rate aided landmark tracking [14:25:15] you have the optics switch in manual and you still get CMC optics drive, that tries to keep the optics on the landmark [14:25:23] and you just do manual adjustments that get added to that [14:25:59] before it wasn't possible to have both manual and CMC commands driving the optics at the same time [14:29:02] Certainly is an improvement at least [14:29:17] Hmm I am trying an AGS update during P40 and it seems like its just stalled [14:30:32] high bitrate? [14:30:52] Yep [14:31:12] I am going to try again [14:31:22] I needed to exit for a bit anyways [15:20:10] AGS is still not updating for some reason [15:20:37] hey [15:20:56] Morning [15:22:05] hey Alex [15:22:58] the two impulse processor update is up [15:24:13] rcflyinghokie, the flag is just not going to 0? [15:24:21] Correct [15:24:24] what is the COMP ACTY light doing? [15:24:28] does it stay on? [15:24:35] And V47 stays on 06 16 [15:24:39] Yep [15:24:41] Solid on [15:24:43] I know what it is [15:24:58] the flight plan specifies time tags for the state vectors [15:25:14] Too far ahead? [15:25:27] e.g. [15:25:34] PDI +25 etc [15:25:40] Uplink LGC: CSM State Vector PDI+25 [15:25:41] yep [15:25:48] Ohh it finally went [15:25:56] Took 4 minutes [15:25:57] yeah it has a state vector that is far out [15:26:10] and in V47 it first needs to go back in time [15:26:32] I must be misunderstanding that time tag [15:27:02] it be a state vector at current time, with a time bias adjusted so that the state vector is correct in downrange at PDI + 25 [15:27:09] it must* [15:27:31] due to onboard propagation accuracy limits [15:27:41] we have the same thing on Apollo 10 as well [15:27:52] the LGC just takes ages to do anything with a SV that is so far out [15:27:57] just can't be right [15:28:23] so I guess I'll remove all those time tags and make them all valid at current time [15:29:12] rcflyinghokie, I have seen that too, its due to the future SV time [15:29:30] Right [15:29:31] just takes longer [15:30:15] it's really close in some cases that you can even follow the normal procedures [15:30:29] DOI for example [15:33:11] I'll have to listen to GUIDO to see if there is any talk of this [15:34:35] I have wondered about that, if the SV time tag method was somehow not correct [15:35:27] the mission techniques document for lunar orbit is full of it [15:35:45] Well its likely going to make me miss DOI lol [15:35:46] but it could still be interpreted in a way that means that the SV is current time with a time bias [15:35:58] yeah, it's the worst for DOI haha [15:36:23] I'll go ahead and remove all of the time tags [15:36:38] we won't get any propagation problems from it [15:37:10] there is an Apollo 15 document that talks about it [15:37:23] Will we sacrifice any realism with that? [15:37:48] I don't think so [15:37:57] it's the lunar potential model again [15:38:16] the AGC can do the same thing as Orbiter [15:38:38] even on Apollo 15 they still did a bunch of biasing [15:38:45] but it's the time tag on the state vector [15:38:50] not a state vector far into the future [15:42:40] the only one I'll keep is the LM state vector for the CMC pre lunar liftoff [15:42:46] insertion + 18 minutes [15:44:43] seems like I misremembered that about Apollo 10 [15:44:50] no future state vectors [15:48:33] I can have that ready now [15:50:16] done [15:52:06] And I won't ever think about using state vectors from the future until it's actually nessary [15:52:21] and even then I'd rather calculate a downrange time bias [15:54:45] which is the correct way to do it [16:10:10] So what are the units in the EMS VHF Range display [16:12:43] ah right the decimal point is blanked [16:13:37] x.xx nm? [16:13:53] yes [16:14:01] was looking it up as I forgot :D [16:14:16] who implemented that? [16:14:18] ah right, me [16:15:16] lol [16:15:29] Also, what triggers the uplink light during a P20 in the CM [16:16:42] if you are 10° away from the desired tracking attitude [16:17:35] Ah [16:18:23] do a V58(I think?) and it gives a new 50 18 and auto maneuver [16:19:04] yes, V58 [16:21:14] Got it [16:21:52] Interesting thats not in the P20 procedure [16:22:07] "reset Stick Flag" [16:22:51] yeah [16:22:58] it's in the more detailed procedures in the AOH [16:24:35] Ah [16:24:41] I have the ops checklist open [16:26:35] yeah that doesn't have it [16:33:36] Wow even V83 takes forever during P40 [16:34:23] of course, same issue, needs state vector at current time [16:34:43] but permanent state vector is at PDI + 25 or so [16:35:04] and permanent state vector is only updated if it's outdated, not too far into the future [16:37:32] you could uplink new SVs with the RTCC MFD [16:37:41] then the problem will go away [16:39:03] True [17:09:34] morning! [17:17:06] hey Mike [17:18:24] what's up? [17:19:23] making the LGC faster [17:19:57] by not uplinking a state vector that is far into the future and first needs to propagated to current time before anything can proceed :D [17:20:56] hahahah [17:21:32] and you? [17:21:59] overslept because my phone alarm was somehow turned off [17:22:08] ah fun [17:22:11] lol [17:22:33] but found a nice weird difference in Sundance last night [17:22:55] that ft scaling thing? [17:23:02] yeah :P [17:23:23] it's defined as 1 foot = 0.3048 meter [17:23:27] so inverse is [17:23:34] 3.280839895 [17:24:14] yeah [17:24:24] so 3.280833 must have been a calculation mistake [17:24:34] yeah [17:24:38] probably not a typo since they had it in there twice [17:24:45] haven't we seen something like that before? [17:24:48] can't remember where [17:24:53] I think so [17:25:03] something that got fixed for Luminary 1D maybe [17:26:43] feet should only be used for displays, so not a terrible bug I guess [17:26:58] hmm, even when communicating with the AGS? [17:27:16] these looked like they were being used for the AGS calculations [17:27:51] ah right [17:27:57] AGS uses feet and feet/second [17:28:04] so it is relevant haha [17:28:13] rcflyinghokie, do you think you'd be able to add implement the temperature readings for DPS and RCS propellent temp gauges in the LM at some point? [17:29:38] Absolutely [17:29:56] I already created fuel and oxidizer substance properties with that intention [17:30:17] Question is will it play nice [17:30:39] My last experimentation with it was trying to pressurize it [17:31:05] But the two substances (liquid and gas phases) mixing together didnt play nice [17:40:10] right [17:42:51] also, my sec glycol pump pressures are very erratic [17:43:12] Yeah I am having issues with them [17:43:15] Its because of the temp [17:43:22] ah ok [17:43:25] And it needs to be tweaked a bit more [17:43:34] and if you kill the glycol all together, shouldnt temps rise? [17:43:48] I mean cabin/suit temps [17:43:49] If you kill the pump? [17:43:53] yeah [17:44:02] If you have the evap flow still on it will still cool [17:44:50] so what are the effects you could expect after a while of running without running glycol pumps? [17:45:08] Well in reality what would happen is the evaporator would freeze [17:45:09] other then cabin/suit temps I guess [17:45:20] Because warm glycol is not getting pumped into it [17:45:32] ok [17:45:36] Also, you would begin to see overheating of your vital systems [17:45:42] ASA, IMU for one [17:46:07] I used to see the temp light on the DSKY come on [17:46:13] when killing glycol [17:46:37] Killing the pump and leaving the evap on? [17:46:42] yeah [17:46:50] It should still come on eventually [17:46:52] oh I should kill that too to test it I guess [17:46:59] right [17:47:08] Ideally yeah since the heat flow isnt very well behaved [17:47:25] The temp sensor is downrange of the evaporator [17:47:39] So the loop 1 and loop 2 will be warmer than the temp gauge shows [17:49:03] Additionally when I add the cold rails things will heat much better [17:49:16] Different areas in the loop will be different temperature [17:49:30] Right now the deltas arent very big [18:00:39] they had the ascent rendezvous monitor up on one of the plotboards during the Apollo 11 ascent [18:00:46] that's a display I have been looking for [18:00:55] so far only partially to see in the MOCR footage [18:09:37] is that similar to the FDO launch analog display [18:14:39] no, but they had something like that for lunar ascent as well [18:14:45] shown a lot in the footage [18:15:49] ARM is quickly recalculating the rendezvous profile to update a tweak burn DV every 2 seconds [18:16:02] even had that for Apollo 11, as some descent aborts needed a tweak [18:16:30] https://youtu.be/UGgdcA516hQ?t=15823 [18:16:42] that's the analog display for lunar ascent [18:16:45] quite similar [19:52:22] indy91, I think we should implement a keyboard press for abort/abort stage in the LM [19:53:15] say so you can initiate it easily from external view or the VC [19:53:34] ok [19:53:48] Ill look into it today [19:54:08] should definitely be a combination [19:54:14] CTRL or Shift [19:54:18] right [19:54:21] or else it is too easy to do it accidentally [19:55:03] so say CTRL-A for abort and SHIFT-A for aborts stage type thing [19:55:30] A just for the example, it may already be used by something [19:56:20] I don't think it is [19:56:23] unless Orbiter uses it [19:56:57] Ill look in Keymap.cfg [19:57:09] btw you can set a lot of stuff to NULL in there [19:57:34] thats how I disable my Orbiter main/hover engine controls [19:58:09] ah [20:02:45] these displys are annoying me... [20:03:00] current working theory, there are two separate displays called Rendezvous Planning Table [20:03:18] one used by the DKI, one used by the lunar launch window processor [20:03:29] in the list of display they are both "RPT" [20:03:32] I think [20:04:11] so I originally thought DKI, SPQ and LLWP all use the same displays to show data for CSI, CDH etc. [20:04:20] but I'm not sure anymore [20:17:26] weird [20:17:39] CTRL/SHIFT A not used by Orbiter [20:19:59] I know the LLWP outputs, I'll just implement a display with those and nothing else [20:20:16] it will be a bit more than it currently has [20:22:37] sure, then we can use those [20:30:35] done [20:30:46] hmm, so abort stage works [20:32:04] but for the stage button, actioning it with the keyboard you can hear the click and see it go in, but nothing happens (no abort) [20:32:24] but clicking it works [20:32:49] how did you implement it? [20:34:10] hmm [20:34:15] I think it's not so easy [20:34:26] the code for those buttons needs to be changed a bit [20:34:36] there is some stuff that is only done in a mouse click [20:34:48] and the mouse click function calls SwitchTo [20:35:07] AbortStageSwitch.SetState(0); [20:35:15] AbortSwitch.SetState(0); [20:35:27] the abort stage key works fine [20:36:17] ah SetState [20:36:44] abort button only sets the LGC and AEA discretes in the mouse click function [20:36:51] right [20:37:07] that needs to be improved [20:37:11] the abort button might not be so important to have as a keypress for now anyway [20:37:13] before it can work [20:37:24] abort stage works so that should be good [20:37:29] I made it SHIFT-A [20:37:38] I can change the abort button tomorrow [20:38:01] CTRL-A would be to close to CTRL-S which we know what that for [20:38:12] I wanted to save not abort!! [20:38:48] maybe ALT-A would be better for the abort button [20:38:54] haha [20:43:38] good night! [21:38:38] Time for my first PDI in ages [21:51:18] So on the Apollo 11 LM timeline, theres a pre PDI section that says "P20 MODE II LOCK-ON N18, R,P,Y ENTR" [21:51:46] Does that mean I am to call N18 angles when its moving to mode II? [21:51:55] I am just kind of confused what its looking for [21:56:50] P20 gets into mode II and tracks nicely, but I am unclear as to that part [22:03:41] Also are we using flight plan TLAND in AGS or obtaining it via uplink/PAD/RTCC [22:10:20] I just used RTCC but I wonder if that was changed or they just used the FP value [22:16:25] Also PDI -8 the OHW at 34 does that mean the surface at 34 deg on it?> [07:18:51] indy91, I went through the first noun table out of curiosity [07:19:19] what you see in the table on page 199 of the LM-3 systems handbook is what you get; unlike programs, there are no secret nouns [07:19:31] (except for 99, which is not listed but is the same as Luminary 69) [12:50:11] good afternoon [12:50:36] Morning [12:50:53] I have been running through PDI a few times [12:51:27] a right, you had a few questions last night [12:51:35] let me look at those again [12:51:43] I did yes [12:53:25] on the first thing [12:53:29] I think you enter P20 [12:53:33] but don't let it do the auto maneuver [12:53:39] instead stay in the attitude you are [12:53:47] which will result in a mode II lock on [12:53:54] so RR pointing backwards [12:54:01] that's the enter on the N18 [12:54:04] instead of PRO [12:54:16] then you wait until you have lock on and then continue [12:56:03] Oh the reason I had the question is my attitude is <10 deg from N18 so no auto maneuver comes up [12:56:21] Just happily goes to mode II without displaying N18 [12:56:28] ah, ok [12:56:40] So its an enter if a 50 18 comes up [12:56:42] so you had the uplink light [12:56:44] Thats all its saying [12:56:49] yeah I think so [12:56:56] Not in the LM no [12:57:47] If <10deg and radar in LGC it just moves it to track [12:58:08] did you have the PGNS mode control in auto? [12:58:52] No [12:59:01] well then that's the explanation [12:59:09] if you aren't it auto it moves the RR [12:59:28] and doesn't give the N18 [12:59:48] Ah ok [13:00:05] hmm [13:00:12] I have nothing that tells me to go auto before that though [13:00:13] there is an auto maneuver earlier [13:00:15] but followed by V76 [13:00:16] Yes [13:00:27] so I am in PGNS att hold [13:00:35] The automaneuver is to PDI attitude [13:00:48] where does it say to switch to att hold? [13:00:51] Oh its not auto [13:01:05] the auto is in P52 [13:01:16] oh right [13:01:19] And then "pitch to FDAI 180, 285, 0" [13:01:28] So i did that manually [13:01:28] after the V76, so manually [13:01:33] weird [13:02:00] I guess revision N of the timeline book was still not perfect :D [13:02:05] Haha yeah [13:02:10] Well that makes sense then [13:02:21] The goal of that step is simply to prevent an automaneuver [13:02:32] So PDI attitude is maintained [13:02:42] I guess so [13:03:05] I'm not sure about the AGS TLAND. If it has a fixed number in the book then that's probably good enough. I think the copy we have is from the flown version and I see no update [13:03:29] I just used RTCC TLAND and converted [13:04:40] And they were exactly the same [13:04:54] So that answered itself [13:06:17] I don't think that time is too critical [13:06:26] you input a landed state vector for the AGS there [13:06:30] for T2 abort or so [13:06:42] the time on it is probably not all that critical [13:07:06] Moon doesn't rotate that quickly and that's the only error [13:07:15] I guess it would need to be updated if it's too far off [13:07:29] but a few minutes wouldn't be an issue [13:08:15] and that overhead window angle is probably a horizon check [13:08:15] Cool [13:08:26] Yeah which ours doesnt line up with [13:09:06] is it even centered? [13:09:56] What do you mean [13:10:14] is the zero line of the markings there in the center of the screen? [13:10:23] I don't think it is [13:10:55] https://www.dropbox.com/s/8pjtlqqpqfmx35j/Screenshot%202020-05-05%2009.10.50.png?dl=0 [13:12:08] close enough haha, but not good enough for an accurate check like that [13:12:53] and the field of view is also probably not right for the markings [13:14:43] Ah right [13:14:55] Ok new question [13:15:07] I want to get my joysticks set up for this [13:15:16] Trying to figure out the best way [13:16:12] The simplest way is probably using my T16000m [13:16:32] But thats in the box right now since I might be selling it [13:17:24] other joystick(s) are two axis? [13:17:30] Yes [13:17:53] But its on an extension [13:18:03] So it might be prudent to just use the desk mount T16000 [13:18:34] Be awkward moving the center mount stick all the way lol [13:18:39] I didnt consider that until i just did it [13:19:24] yeah unfortunatel we don't support two separate devices to control different axes yet [13:21:48] Ok I have it back in [13:21:59] In the project apollo config menu [13:22:11] RCA/ACA enabled checked with the id in [13:22:45] What about ACA with throttle slider? [13:22:45] my preferred configuration is one joystick as the ACA [13:22:55] using its slider as the throttle control of the TTCA [13:23:04] and the numpad as translational controls [13:23:34] but if you don't check "ACA with throttle slider" then it will be the numpad for throttle [13:24:01] Oh ok [13:24:12] the ID for those is the slider ID [13:24:19] should always be 0 [13:24:32] haven't seen many joysticks with more than one slider [13:24:34] well [13:24:41] I guess for multi engine aircraft [13:24:43] Lol [13:24:55] I have one with 3 sliders [13:25:12] But for this one, not the case [13:25:15] but is that part of the joystick? [13:25:21] No [13:25:25] Its a throttle [13:25:45] yeah [13:25:53] Well I guess technically the slew stick on one of my sticks is 2 sliders [13:26:14] might be yeah, not sure how it would detect it [13:26:35] But anyways the t16000 is back up [13:26:40] Lets see if it works [13:26:58] is that the one with the "precise" yaw control? [13:28:28] Not sure [13:28:41] But it has zero slop [13:28:58] you had a joystick that couldn't be properly used for ACA yaw [13:29:07] Ohhh [13:29:10] because it wasn't zeroed or something [13:29:17] didn't stay in the detent [13:29:19] Yeah my 10 year old 3d pro [13:29:31] It was just worn out [13:29:41] yeah [13:29:46] Hmm no luck [13:30:56] default joystick control in Orbiter is disabled? [13:31:01] yes [13:31:25] the joystick ID might not be right [13:31:28] It is [13:32:22] maybe it just didn't fire anything in PGNS min imp? [13:32:40] Maybe [13:33:09] those firing commands are roughly as long as a timestep at 60 fps [13:33:19] so it's close to not firing thrusters at all [13:33:38] tried in the cm as well nothing [13:34:29] hmm [13:34:51] I have a program that identifies the joystick id [13:35:05] It should be correct [13:35:09] you have RHC/ACA enabled and ACA with throttle slider selected? [13:35:12] and only those [13:35:42] Oh also that if only checkbox, let me disable that [13:36:27] then it might have tried to be a TTCA [13:36:40] No change [13:38:18] which joystick ID did you use? [13:38:24] maybe it's a different system [13:38:30] 10 [13:38:43] you have 10 USB devices connected? [13:38:53] Yes [13:41:19] https://www.dropbox.com/s/rwirdqfaerab6dz/Screenshot%202020-05-05%2009.41.17.png?dl=0 [13:43:29] all I can say is that it looks through all direct input compatible devices [13:44:33] hmm [13:44:34] if(lem->js_enabled > 1){ // Do we already have enough joysticks? [13:44:42] I wonder if that is the issue [13:44:50] that's in EnumJoysticksCallback [13:44:52] in LEM.cpp [13:44:59] maybe change that to 10 and see if it works? [13:45:10] or 11 to be safe [13:45:28] and that could be a permanent change of course [13:45:35] Ok checking [13:45:56] or maybe your joystick ID 0, that might also work if it just doesn't look past the 2nd connected decive [13:45:58] device [13:47:10] Trying 11 [13:48:45] causes a crash [13:49:05] ouch [13:54:22] I moved the joystick id to 1 [13:55:50] No change [13:56:48] it might be overwhelmed by your setup :D [13:57:01] Possibly! [13:57:05] maybe ask Alex when he comes line, probably has more experience with this [13:57:09] Will do [14:27:20] In the mean time I am going to fly this PDI with numpad [14:37:25] Ok remind me how to use the LPD in P64? [14:37:35] Also what keyboard commands the ROD [14:40:10] in P64 you press PRO [14:40:15] enables LPD commands [14:40:25] then with the ACA pitch and roll deflections [14:40:40] Does it work ok with the numpad? [14:40:45] Minus: Increase Descent Rate [14:40:45] Equals: Decrease Descent Rate [14:40:48] yes [14:41:19] actually because of a bug in our code interacting with the Virtual AGC LDP commands used to work mainly with the numpad, badly with joystick [14:41:30] lol [14:41:42] because it is instant deflection and back to detent with numpad [14:42:03] Its hard over right [14:47:40] hmm? [14:48:08] keyboard ACA controls are full deflection yes [14:48:38] Yeah [14:48:54] so I recommend disabling ACA/4 Jet [15:03:06] I am so rusty lol [15:03:12] But I got it down [15:06:44] not caught by Alex's new crew survival condition for the descent speed :D [15:07:06] Seems like they are alive [15:08:34] Do we have the K value for AGS 225 during T1? [15:10:56] lower limit for variable insertion? [15:11:13] I think that is always the same so that it gives a 30NM apolune minimum [15:11:20] will still be a function of landing site radius [15:11:24] but not by a lot [15:11:34] was that value updated? [15:11:37] The timeline says 225 + K [15:11:50] Checking [15:12:46] oh after landing [15:13:09] Yeah [15:13:43] I see no mention of it in transcript after landing [15:15:28] Apollo 12 has [15:15:30] 225R [15:15:34] set 226 equal to 225 [15:15:39] which I think is correct [15:15:42] Ah that makes sense [15:15:48] T2 insertion is to lower limit [15:15:52] 30NM apolune [15:21:17] For loading 465, still using 00320? [15:21:24] insertion target [15:21:48] hmm [15:21:57] doesn't sound right [15:22:14] Thats from the surface checklist [15:22:38] Thats Hdot [15:22:45] not alt [15:22:49] yes [15:23:12] Still not sounding right? [15:23:16] 19.5 should be preloaded for T2 [15:23:25] for T3 it's changed to nominal insertion values [15:23:31] using 32.0 ft/s RDOT [15:23:36] padloaded* [15:24:04] surface checklists starts after T2, so loading 32 is correct [15:25:13] Ok [15:27:16] Now to see how this P57 goes [15:27:22] hey [15:27:29] Good morning [15:29:08] hey Alex [15:31:24] rcflyinghokie, I missed your questions last night, sorry about that...I was away from kb and just saw them now in the log [15:31:36] No worries [15:31:40] Niklas helped :) [15:31:46] haha great [15:32:26] However I do have a joystick question [15:32:33] I cannot seem to get it to use mine [15:33:05] And wondering if its because I have so many usb devices [15:33:11] https://www.dropbox.com/s/rwirdqfaerab6dz/Screenshot%202020-05-05%2009.41.17.png?dl=0 [15:40:37] Also for the first celestial body P57, were star codes read up? [15:43:10] don't think so [15:43:49] Hmm wonder where they got the data [15:44:22] I think I had the same issue with the joysticks [15:44:44] doesn't P57 come up with stars to use? [15:45:21] I have a USB hub with most of my game controllers connected, but I unplug it when using NASSP so that just my joystick is plugged in [15:45:30] Yeah I just didnt know if they used the ones that come up or had preplanned ones [15:45:40] AlexB_88 i wonder if thats it [15:46:06] But still thats annoying as hell for me, wonder if theres a workaround [15:46:36] yeah some code changes will be required I think, Ill look at it [15:47:07] As long as it can use the joystick ID [15:47:50] I think the ID can only be used for the 1st 2-3 joysticks or something [15:48:24] which one in your list is it usingÉ [15:48:29] ?* [15:49:06] 10 [15:49:12] but I also moved it to 1 [15:49:17] (T1600m) [15:49:27] 1 also didnt work [15:49:58] what about ID 0? [15:51:00] but which is the one that it is using now? [15:51:15] you said "I cannot seem to get it to use mine" [15:54:36] I was confused about that because I cant set anything to id zero [15:55:18] so in your program ID=1 is ID0 for Orbiter [15:55:21] maybe* [15:56:58] I tried that as well [15:57:40] ooh [15:57:51] https://www.orbiter-forum.com/showthread.php?p=605499#post605499 [15:58:43] hopefully will fix the bugs in Orbiter 2016 [15:58:50] for Orbiter Sound [15:59:27] yeah [15:59:28] Sweet! [16:00:14] Oh interesting! [16:00:28] That joystick id list is not the same as what orbiter is reading [16:00:38] btw were we still planning on continuing XRSound implementation? Maybe this news means otherwise... [16:01:08] Any other good ways to discover joystick id number? [16:01:24] I am going to guess and test for now [16:06:05] maybe in the windows settings somewhere [16:06:16] device manager or whatever it is called in english [16:07:33] Ok so if I go to orbiter joystick screen there is a dropdown list [16:07:48] That list seems to coincide with the id number [16:08:06] But only id 0 seems to work [16:17:18] so I selecting the ID only works with the 1st 3 joysticks connected [16:17:25] so I think* [16:17:58] when you set ID 0, which joystick is being used? [16:18:03] out of your 10 [16:22:55] 8 [16:23:15] But again I dont think that list is correct [16:29:10] something I've been working on [16:29:54] https://www.dropbox.com/s/3m2e4x730elx3ef/Screenshot%202020-05-05%2010.28.42.png?dl=0 [16:30:00] https://www.dropbox.com/s/v7grthfxmx7xqvt/Screenshot%202020-05-05%2010.28.57.png?dl=0 [16:31:04] wow [16:31:45] for now just making a static panel 1-4 [16:32:53] I mean maybe I could try adding a few important gauges to it for now, (FDAI,tape-meter,etc) [16:33:11] If only we had reentry's model lol [16:33:27] I dont know if the 2D gauges are compatible with the VC though [16:34:06] oh yeah, reentry's one is sick [16:34:28] I am not there yet in 3D modelling haha [16:35:16] even this I have to rely on the AAPO mesh for reference [16:38:18] I havent tried the apollo part of reentry...feels like cheating lol [16:38:30] But I wonder how the backend works [16:38:35] As far as realism [16:39:32] we either should have the exact panel measurements already or will get them at some point [16:39:44] from the LM Grumman schematics that Ron is scanning [16:40:06] nice [16:40:49] hopefully there will be some side/top/front views which is what is best for me to make them [16:41:18] I had a lot of angled views but thats not really great for making a model with [16:44:20] morning! [16:45:33] good afternoon [16:45:49] what's up? [16:46:07] Trying to figure out how to get my joystick working with NASSP without unplugging everthing [16:46:10] everything* [16:48:00] hey Mike [16:48:09] thewonderidiot, I should have studied that list of nouns earlier [16:48:16] haha [16:48:21] there are clearly nouns that are not in Luminary [16:48:25] and they are very cleary for P10 [16:48:28] indeed [16:48:30] oh! nice :D [16:48:38] N30 and N31, time of CSI and CDH [16:49:06] and some 50s nouns have even more [16:50:51] so Luminary 69 does have time of CSI, as noun 11 [16:51:10] which I thought was weird, that they both have it, but as different nouns [16:52:12] yeah N11 is input in P32, rendezvous program [16:52:48] but it makes sense that P10 and P11 have separate displays [16:53:01] N30 and N31 would be output rather than input [16:53:51] ah, I see, gotcha [16:54:56] oh TIG(AS) is also how it is called in Luminary [16:55:01] the ascent ignition time [16:55:03] in P12 [16:55:10] but it said that's a P10/P11 padload [16:55:23] could be the first display in those [16:55:30] indy91, I dont think I want to explore anymore then just adding the main panel as a static image for the VC in version 8, the heavy VC stuff will come in version 9 I guess. But what I would like is make the LM VC view usable for the lunar landing in V8 [16:55:33] threshold time for liftoff time [16:56:09] sounds good [16:56:14] so from the VC view, you can use key commands to go to att hold and stuff like that [16:56:17] I'm sure we can figure out how to display stuff [16:56:26] right [16:59:32] one thing I thought of is using the debug line that would only appear in VC view and would have info such as: "PXX, height, height dot, LPD time & angle, X-pointer data" [16:59:56] and that data coming from LGC source [17:05:25] ok [17:05:43] more P10/P11 nouns [17:05:53] N91, 92 and 94 [17:06:08] TPI ALT, TIME AND ANGLE FROM LAUNCH TO TPI [17:06:20] TIME AND ANGLE FROM LAUNCH TO TPF [17:06:30] CSI ALT, TIME AND ANGLE FROM LAUNCH TO CSI [17:07:03] haha, that's a lot of nouns :D [17:07:22] funny that they hid the fact that P10/P11 are in Sundance but didn't bother to also hide the nouns [17:10:38] they could still be disabled in some way [17:11:03] I doubt they would be a big issue to run though [17:11:08] not setting any flags or so [17:11:11] probably [17:11:16] not as bad as running P01 in space [17:13:00] Training for 13 duh [17:13:23] you probably get a divide by zero or something quite quickly in P10 if your RLS is all zeros [17:14:07] even before that [17:14:19] alarm for being in Earth SOI or something [17:14:56] haha, true [17:16:23] what was I working on? right, the RTCC launch time prediction [17:16:30] practicing for P10 :D [17:16:34] hehehe [17:16:53] you've still got quite a while to practice, Sundance is going to take a long time to be ready :D [17:19:04] P11 is for the short rendezvous profile [17:19:16] I think that's compatible with the profile flown by Apollo 14+ [17:19:25] although you need to input insertion velocities [17:19:34] RTCC version computes them [17:21:00] if P12 is properly working then we should be able to fly a complete ascent and rendezvous [17:21:08] is still some space for P10 and P11 in Terminus? :D [17:21:24] hahaha no way [17:21:42] N100 and N101 [17:21:52] we would need [17:22:03] and some of that nice auxiliary memory [17:22:08] yeah [17:22:15] they are at the beginning of bank 32 [17:22:25] and P63 is at 32,671 [17:22:44] so, 440 words, assuming they are entirely contained in that bank [17:22:59] that's a big chunk :) [17:23:21] the programs are 440 words? Doesn't sound like a lot [17:24:14] when all of the banks have <10 words left it is :P [17:24:44] how large is e.g. P12 in Luminary? [17:24:49] rough estimate [17:25:02] oh we don't need a rough estimate for that [17:25:03] hold on [17:26:38] my estimate is that P10 and P11 need half of P12 memory [17:26:43] but that could be a very bad guess [17:28:37] hmm [17:29:44] I guess it depends on what all you count as P12 [17:30:20] the words explicitly counted as belonging to P12 in Luminary 69 add up to... 201 words [17:30:25] uhh [17:30:41] but there's also ASENT and CSI tags [17:30:49] what about P70/P71 code? [17:31:05] most of it will be common with P12 [17:31:28] P70 -- 228 [17:31:32] aha [17:31:41] no way that's all P70 only code [17:32:44] but in any case, I probably overestimated how many words you need for this stuff :D [17:32:55] haha [17:33:05] yeah 440 is a lot [17:33:10] that is going to be difficult to work through [17:35:45] Hmm interesting thing in the P57 [17:36:04] If the star code is >45, it skips the F 06 79 [17:36:21] Why would that be? [17:36:27] tried aligning with the Earth? :D [17:36:46] Oh wait [17:37:01] 46 is Sun, 47 is Earth, 50 is Moon [17:37:06] stars are 1-45 [17:37:08] Yeah I just remembered [17:37:25] Well thats what the P57 gave me [17:37:44] 00546 [17:38:04] interesting [17:38:17] it probably only does that when it finds nothing else [17:39:12] So goes back to the question about what they used [17:39:32] that's the first P57 on the surface? [17:39:54] Aldrin chose some himself [17:40:17] Had we landed straight ahead (instead of being yawed left 13 degrees), my intent was to use Rigel in the left (rear) detent number 6 and Capella in the right (rear) detent. The 13-degree yaw moved Capella out of the right-rear detent, but Rigel was in good shape there. That's the one I used first. I then selected Navi in number 4 detent, [17:40:53] Yeah [17:41:37] So I guess I am choosing appropriately [17:42:24] And the stars line up to that statement [17:43:09] https://airandspace.si.edu/collection-objects/star-chart-circular-apollo-11/nasm_A20150319000 [17:43:14] you need something like thatz [17:43:22] that's what Buzz would have used as reference [17:43:48] Perfect [17:44:14] it's the wrong one though [17:44:16] it's for liftoff [17:44:20] Well I am not using that one [17:44:32] Haha I am just looking and seeing whats in the detents since I dont have it [17:44:43] there was a guy here in this chat a year ago or so who owned a few of these [17:44:47] training used, Apollo 15 [17:44:59] we talked a bunch about it [17:45:08] I gave him some screenshots from NASSP to compare [17:46:11] you can rotate to account for yaw, so that the detents line up [17:46:15] rotate themÜ [17:46:27] Pretty handy [17:46:45] How is the P57 working [17:50:36] Hmm I can move my AOT screen [17:50:47] Might be that taskbar thing [17:55:19] NASSP is a full screen application that allows distraction from the taskbar [17:55:31] says the person who probably holds the alt+tabbing record in Orbiter [17:56:00] allows no* [17:56:14] Haha oh I am likely up there [17:56:33] I am trying to remember how this all works [17:56:57] best don't fly a J-type mission anytime soon then [17:57:00] Because I know it had issues last time I tried [17:57:03] you can re-learn P57 for those [17:57:47] so I managed to get PGNS H & Hdot information in a debug string for the VC view [17:57:48] https://www.dropbox.com/s/3e0qmqlggqjc6dz/Screenshot%202020-05-05%2011.56.30.png?dl=0 [17:58:21] where are you getting the data from? [17:58:24] this would only be visible for the VC [17:58:29] So when on F 54 71 I move the star in the spiral and mark? [17:58:51] its from the LGC [17:59:07] throught LEMRadarTape [17:59:41] RadarTape.GetLGCAltitude() * 3.2808 [18:00:03] I added GetLGCAltitude to RadarTape class [18:00:14] which returns double lgc_alt [18:00:41] dont know if its the best way to do it but it works [18:01:03] the mark is just for the timing I think [18:01:12] as the Moon rotates that changes the direction of the star [18:01:45] And then I get the cursor and spiral codes [18:01:53] And type them in? [18:02:05] yeah [18:02:14] cursor being the upper y axis? [18:02:53] where the spirale meets the vertical line [18:03:25] the side of it with the three lines going up [18:03:25] or the VC key commands, I added K to switch PGNS - ATT HOLD [18:03:43] for* [18:03:48] Ok and then when I am on the first 06 79 do I need to change the position code? [18:04:00] the AOT view when CSM and LM are docked is interesting [18:04:46] wait that's bad isn't it [18:05:00] I see the crew in the CSM through the AOT [18:05:05] lol [18:05:08] I remember that [18:05:11] ah [18:05:13] wrong detent [18:05:28] not the one they used in the docked P52 on later missions :D [18:05:40] Is the position code the detent? [18:05:52] the third digit, yes [18:06:10] uhh [18:06:13] the middle one I mean [18:06:18] third out of 5 [18:06:30] no on 06 79 [18:06:40] cursor spiral position [18:07:25] ah right [18:07:31] yes R3 is the detent [18:07:38] Ok [18:07:46] R1 and R2 are the angles [18:07:47] So I need to change that to match my manual entry [18:07:52] indy91, I would like to also like to display the current LGC program in the VC debug string, IE "P64" or "P66" [18:08:05] can you not directly access the DSKY [18:08:08] might be the easiest [18:08:24] Hmm doesnt want to change [18:09:53] Nope [18:09:58] Just recycles back to 5 [18:10:13] AlexB_88, char Prog[3]; in the DSKY class [18:10:35] It's a bit since I did a P57 [18:10:38] been* [18:10:39] ah thanks [18:11:40] might not be directly accessible [18:11:54] Ah I can change it after the mark [18:12:20] N71 or N79? [18:15:55] 79 [18:16:23] ah right that one comes twice [18:16:40] the first time you can only change it with a V32, which goes back one display [18:26:14] Its starting to come back to me [18:28:35] what would be the character to use for a char in a debug string? [18:37:47] Should be c [18:42:23] 00003 on my first attempt haha [18:42:36] I remember getting huge angle differences before [18:47:09] that was probably before the spirale was fixed [18:47:16] AlexB_88, it's %s for a character array [18:48:40] %s for a string, %c for a character. Using %s for a character will just give you garbage because it tries to cast a char to a pointer. [18:48:54] but the spirale had surely already been fixed when you were last doing P52s, Ryan [18:49:17] but you might remember the "before time" [18:55:52] Yeah it was fixed when I was here [18:55:58] I just hadnt run a P57 since it was [18:56:13] Lol "the before time, in the long long ago" [18:57:41] But yeah now that I remember it the P57 was pretty seamless [18:58:47] Alex made the lines thinner recently [18:58:51] fairly recently [18:58:58] don't think I've done a P57 since [19:05:01] when is the ascent PAD, RLS, CSM SV update triggered to come up? [19:08:57] I am trying to remember where in the solution those are [19:17:35] MoonRev >= 15 && MoonRevTime > 5.0*60.0 [19:17:55] if that helps [19:18:19] Where in the solution is it [19:18:46] MCC project [19:18:55] MCC_Mission_G.cpp [19:18:56] Thanks [19:19:38] I have the Apollo 11 surface times on the checklist I am working to make them better fit the timeline that establishes [19:19:54] Those triggers help [19:20:13] when you feel a trigger is wrongly placed, those can always be adjusted [19:20:52] the times relative to rev crossing are usually convenient to account for the delay of arriving in lunar orbit [19:22:30] I am making them PDI relative instead of mission times [19:22:38] I will see how that lines up [19:23:04] should be good [19:23:33] I could also implement something relative to landing [19:23:43] or PDI [19:23:52] that's an MCC event that gets saved and loaded [19:25:25] Yeah almost all of these are PDI relativew [19:25:42] And then simulated ascent tig relative [19:26:24] I think PDI relative would be interesting to see [19:26:34] I think in some cases PDI relative could make sense. Later on, the actual ascent (not T3) depends on the CSM orbit, so over longer period the times relative to rev make sense [19:27:02] Yeah this would be basically up until the simulated P12 [19:27:25] Which is also computed [19:27:27] lunar liftoff is another event that it keeps track of [19:27:49] Simulated or actual or both [19:28:00] both it looks like [19:28:08] and the time already gets saved [19:29:34] So I would be curious how those times line up [19:29:42] These checklist events have 3 cues [19:29:45] mission time [19:29:49] PDI [19:29:54] and TIG simulated ascent [19:30:16] I'd guess even with the rev crossing times it will be quite close [19:31:20] After landing everything is pretty much PDI relative up until about PDI+1:12 [19:31:27] Then its TIG ascent relative [19:31:51] yeah if the checklist specifies those, then I can make it PDI and T3 relative [19:31:57] It does [19:32:02] surface checklist [19:32:54] yeah [19:35:15] I think a PDI and T3 event would be useful here [19:36:29] for which MCC updates? [19:36:35] T3 Ascent PAD? [19:36:55] Yeah that update for sure [19:37:10] But also a checklist relative item I can use in the checklist itself [19:37:24] ooooh [19:37:32] that's entirely different [19:37:35] that's not so easy [19:37:45] Like the TLI and such [19:37:58] right [19:38:09] I even hate the current code that stores the TLI time haha [19:38:23] because it's so out of place where that is done [19:38:54] I don't think PDI is really possible tbh [19:38:59] Ok no problem [19:39:07] the first ground contact for the LM, that might work [19:39:15] Nah [19:39:20] I can make due [19:39:26] But that update should be [19:39:38] I'd say T3 relative [19:39:50] But either work [19:39:53] They should be close [19:40:25] TIG-50 [19:40:30] has the surface checklist [19:40:33] Yep [19:41:06] ah wait [19:41:11] that doesn't work [19:41:22] the updated liftoff time gets calculated together with the ascent PAD [19:41:33] so it can't use that as a condition, as it's not been calculated yet [19:41:38] I make it PDI+1:02 [19:41:44] which it says about the TIG-50 [19:45:08] PDI is fine [19:45:17] As I said either work and will be close [19:46:01] yeah [19:46:16] CSI PAD is 3 minutes later [19:46:45] for the actual ascent it calculates the liftoff time earlier [19:46:57] so there I could make it relative to liftoff [19:48:57] Yeah thats about when the checklist switches from PDI to ascent [19:50:06] And the PDI+ tiome is PDI ignition, correct? [19:52:39] yes, as calculated by the DOI targeting [19:52:47] so it could be a few seconds off, but not any more [19:53:22] Yeah thats close enough for sure [19:54:30] I should let it get updated by the calculation for the PDI PAD [19:54:37] that goes through the ignition algorithm [19:54:49] and will be within 1 tenth or so [19:58:43] Yeah I think that ought to be close enough ;) [19:59:13] Yeah just passed PDI+1:02 I am curious where this uplink comes in [19:59:23] Currently I mean [20:02:19] probably too late as you have not said something yet :D [20:03:04] lol [20:03:12] PDI+1h15 [20:03:17] nothing yet [20:03:35] ouch [20:03:57] PDI+1h19m [20:04:08] Thats when it came [20:04:26] hmm [20:04:36] Rev 15 + 5 min looks about right in the flight plan [20:05:22] Yeah thats TIG-50 or very close [20:05:42] So I will just use TIG-50 instead of PDI for that one [20:06:15] But does that mean my PDI was 17 minutes early? [20:07:06] even then, it should all be based on CSM/LM relative motion [20:07:14] PDI and rev crossing should be fairly consistent [20:09:28] Wonder why the time differential [20:10:21] PDI TIG was 102:41:10 [20:10:47] T3 TIG is 104:48:01 [20:12:41] too far apart for sure [20:13:23] Wonder what happened [20:13:27] real mission: [20:13:39] PDI TIG 102:33:04 [20:14:10] hmm, using %s gave me a build warning, and %c just shows 0 in-sim [20:14:16] T3 TIG 104:39:47 [20:14:22] hey that works [20:14:31] why is the lunar surface checklist wrong? :D [20:14:35] Haha [20:14:52] Probably why they used all 3 relative events in there [20:14:54] AlexB_88, what's your debug line [20:15:08] rcflyinghokie, redundancy, one of the three times will be right! [20:15:31] Yep and TIG is [20:15:38] I am good with that [20:15:50] sprintf(oapiDebugString(), "PROG P%c ALTITUDE %lf ALTITUDE RATE %lf", dsky.GetLGCProgram(), RadarTape.GetLGCAltitude() * 3.2808, RadarTape.GetLGCAltitudeRate() * 3.2808); [20:16:44] GetLGCProgram is returning a char* ? [20:16:48] char pointer [20:16:55] yes [20:17:13] then definitely %s instead of %c [20:17:20] what's the warning you got? [20:17:22] I added char GetLGCProgram() { return Prog[3]; }; in dsjy.h [20:17:30] no, that doesn't work [20:17:32] dsky.h [20:17:33] unsafe code even [20:17:46] Prog[3] is the 4th digit (starting from 0) of Prog [20:17:52] Prog is 3 long [20:18:03] you have to return uhh [20:18:12] &Prog I think [20:18:15] address of Prog [20:18:39] hmm [20:18:52] and char* [20:18:53] not char [20:18:57] char is a character [20:19:03] not an array of characters [20:19:07] &Prog said return value did not match [20:19:15] but *Prog seems to work [20:19:17] Is Prog a string representing the prog register? [20:19:24] Prog is [20:19:29] char Prog[3]; [20:19:30] and yes [20:19:39] maybe it's * not &, I always forget :D [20:19:54] you don't need it, just "return Prog;" is sufficient [20:20:14] and yes the return type has to be "char*" [20:20:21] oh [20:20:23] Arrays are pointers in C [20:20:24] right [20:20:26] it's neither [20:20:27] char *GetProg() { return Prog; } [20:20:54] ah ok [20:21:04] and GetProg sounds better too [20:21:23] so now its %s? [20:21:28] yep [20:21:29] Yes [20:22:34] I never know these things, trial and error always works for me [20:23:30] works! thanks again [20:24:08] good that we haven't changed the DSKY class to a lot of relays yet [20:24:43] Fun fact. 3[Prog] would get you the same thing because a[b] is *(a + b) [20:26:28] { return 3[Prog]; } ?? [20:26:47] that doesn't look like valid code [20:28:26] It is. You offset the address of Prog by 3 or you offset the address of 3 by Prog [20:28:57] well Visual Studio doesn't like it [20:29:07] in which language does that work? [20:29:09] Probably because you normally don't want to do this [20:30:06] char *GetProg() { return 3[Prog]; } [20:30:22] gets me a C2440 build error [20:31:27] Try casting them to char * [20:32:12] C++ doesn't allow you to assign a void * to a different type of pointer [20:32:14] 3[Prog] gets you a char, not a char* [20:32:24] that's why it doesn't like it [20:32:31] Ahh right [20:32:32] it's not a pointer [20:33:12] yeah, with a return char it works [20:33:14] fun [20:34:41] http://dpaste.com/16CQ9TE [20:35:11] right [20:35:47] is there a way to limit a returned double to only show a 1 decimal precision? [20:35:48] looks as weird to me as "++var" vs "var++" :D [20:35:49] But also *(test + 1) [20:35:58] in the debug string [20:36:00] %.1lf [20:36:06] ah thanks [20:36:12] var++ is read then increment. ++var is increment then read [20:36:17] I know [20:37:05] AlexB_88: All specifiers are defined here: http://man7.org/linux/man-pages/man3/printf.3.html [20:37:36] I have a lot of experience with those, haha [20:37:45] ah great [20:37:48] thanks [20:37:51] the RTCC MFD has nearly 90 pages full of that stuff... [20:46:28] so I have set up a few keys for landing the LM from the VC: K cycles between PGNS AUTO and ATT HOLD [20:46:45] M cycles between Throttle MAN and AUTO [20:47:10] both those keys were not yet used by NASSP or Orbiter [20:53:17] indy91 was there no LM weight given for the LM Ascent PAD? [20:53:56] Ah they gave an updated weight [20:54:10] 104:18:38 Aldrin: Houston, Tranquility Base. Do you have an updated LM weight for us? Over. [20:54:11] 104:18:42 Duke: That's affirmative. Stand by on the DAP (Digital Auto Pilot). Our DAP Pad for you is LM weight 10906 (terrestrial pounds). Over. [20:54:39] ah separate from the Ascent PAD [20:54:44] I guess I'll add that in some way [20:54:49] maybe comment on the T3 Ascent PAD [20:54:57] that way I don't have to add anything extra [20:55:39] Yeah just a remark ought to be fine [21:05:35] night! [21:06:13] AlexB_88 I have a word doc building of ECS observations during this flythrough [21:06:40] So I am hoping my ECS branch will get better, as well as including the checklist updates [21:06:53] I see the 10x/30x instability in suit [21:07:08] And I think its because of the glycol loop connections and that Q transfer [21:07:30] temp changes and therefore pressure changes and more different temp O2 gets pumped in [21:07:32] etc etc [21:11:33] I will say though with the crew in suits, the LGC does make a difference [21:11:40] LCG* [21:15:03] yeah same observations on my end [21:16:15] I have some ideas to help [21:16:34] But I am going to finish this mission before trying them, I want a complete list of observations first [21:16:53] And since this patch will be save breaking, I want to incorporate as much as possible to fix things [21:17:18] And your observations are very useful so keep them coming [21:37:20] Night! [01:59:31] AGS initialization changed between Sundance 292 and 306 [01:59:59] 292 wants CHARIN to be at 40,2202, but it is actually at 40,2212 in 306 [02:00:10] so it was somehow changed such that it took an extra 10 words [02:00:26] this is now the oldest AGS initialization code we have so there may be no figuring out what exactly changed, heh [02:35:20] good evening [02:42:18] hey [02:44:10] hey [02:44:29] thewonderidiot, interesting stuff [02:46:04] on my end I've managed to make the LM flyable from the VC [02:46:21] no working panels of course [02:47:04] but key commands and a string showing the essentials [02:49:14] https://www.dropbox.com/s/ad9d0jmxnk1708b/Screenshot%202020-05-05%2020.49.05.png?dl=0 [02:49:29] oh awesome!! [02:50:14] btw the alt & alt rate are taken from the LGC, not directly from Orbiter [02:51:31] nice :D [02:51:38] the long term goal of course is to make the gauges work in the VC [02:51:57] but in the mean time this debug string works nicely I think [04:04:18] sorry, 8 words different [04:04:32] and they didn't renumber routines between Sundance 306 and Luminary 69 [04:04:57] so thanks to punch card numbers, I know precisely what the change in AGS initialization was between 292 and 306 :D [04:05:15] turns out, it's essentially the same thing that happened in fixed-fixed [04:05:54] https://github.com/virtualagc/virtualagc/blob/master/Luminary069/AGS_INITIALIZATION.agc#L150 [04:06:04] these 8 words at CKSTALL, almost guaranteed [12:29:23] Morning [12:29:53] hey Ryan [12:31:45] I wondered if they maybe had a different rendezvous profile in mind for T3 when they created the Apollo 11 lunar surface checklist [12:31:53] maybe that's why the time is off [12:32:38] Hmm [12:33:21] Would actual versus surface checklist time hold a clue? [12:37:12] Planned: PDI 102:35:19, T3 104:42:05, actual: PDI 102:33:04 T3 104:39:41 [12:37:20] damn that works :D [12:38:08] Haha [12:40:25] hmm [12:40:33] 103:38, PDI+1:02, TIG-50 [12:40:42] GET and PDI time align [12:40:51] but that would suggest T3 is at 104:28:00 [12:41:06] while the surface checklist says later it is at 104:42:05 [12:42:20] Thats really weird [12:49:00] it's quite consistent in a way [12:49:11] up to a point the TIG counts up to 104:28:00 [12:49:15] after that 104:42 [12:53:37] even if it was default insertion velocity vs. nominal, that doesn't up to a 14 minute difference [12:53:42] more like 1-2 minutes [12:56:13] 103:35:30 Duke: Tranquility, Houston. On my Mark, 62:30. Mark. 62:30 past PDI. (Pause) [12:56:56] That coincides with the actual PDI [12:57:49] Wonder if its just incorrect on the checklist [12:57:50] I think the GETs and PDI times are consistent, just not the TIG up to a certain point [12:57:59] maybe [12:58:59] http://www.mpwright.com/content-surf3.htm [12:59:08] it's like that in the flown version [13:00:05] yep dates are same too [13:10:45] So other times like plane change etc are also pushed by this since they are rev relative? [13:11:48] the solo book has the plane change decision at 105:00 [13:13:09] yeah, it's based on rev time [13:13:19] rev 15, 70 minutes since 180° longitude [13:13:40] is the plane change decision [13:14:22] Hmm so I need to make these checklist items relative then [13:14:35] "Wait for Plane Change Decision" or similar [13:14:46] it's not a GET in any case [13:16:15] True [13:18:28] I have a better value for that evaluation now [13:18:39] current logic is 4 NM crossrange [13:18:44] if it's more the PC is done [13:18:51] actually should be a DV [13:19:09] 23 ft/s [14:39:15] morning [14:40:39] Hey good morning [16:02:07] Yay found eagle with the P22 [16:16:23] nice [16:26:34] morning! [16:29:19] hey Mike [16:29:32] indy91, I pushed my VC work [16:29:34] https://github.com/jalexb88/NASSP/commit/78a74c3c07f6a5b44661434caf9863eea6e98682 [16:29:58] I still have a few updates before PRing [17:33:17] right now I am trying to get the hat switch working through our joystick code [17:33:42] for panning the view around in the VC & external views [17:58:41] looks like the hat switch fwd/back is used for THC +/- X translations [17:59:01] which is needed for people that dont have a yaw axis [17:59:24] maybe I can make it use the hat for view panning, only when in rotation mode [18:09:54] yep, the translation code is tied to thc_pov_id [18:10:11] so I can make the same code for rhc_pov_id and they are separate [18:56:47] did they change the AGS time bias on 11 at all? [18:56:55] Or was 90h used throughout [19:09:55] they probably used 120 for liftoff [19:12:22] I am just trying to find it [19:13:30] I cant find it in the transcript at least [19:15:34] Ah [19:15:37] 119:59:5992 [19:16:12] It was read up [19:18:08] I wonder if Niklas can generate a K factor [19:21:23] That would really get our AGS timing correct [19:22:40] All it would need to do is compute the delta between LGC and AEA clocks [19:22:55] And then add/subtract that delta from the bias time [19:30:51] hey [19:31:41] Welcome back [19:31:51] Its like you knew I mentioned you [19:32:43] just catching up on the log [19:33:16] I've looked at K Factor in the past, the annoying thing is the AEA doesn't update its clock very often [19:33:21] 6 second cycle or something [19:33:42] so I can't just get the clock time out of the AEA memory like I can with the AGC [19:33:42] So how did MCC generate it [19:33:59] I think it just gives the nominal time, doesn't it? [19:34:11] Nope [19:34:19] They give the K factor [19:34:40] oh, I thought you meant our MCC [19:34:49] Oh sorry! [19:34:52] 122:28:24 Aldrin: Roger. Go ahead with the K-factor. [19:34:53] 122:28:27 Evans: Roger. 119 plus 59 plus 59 point 92. Over. [19:34:57] yeah [19:34:58] That K factor lol [19:35:27] well I think they had a constant stream of telemetry and maybe had a time trap, when the clock gets incremented [19:35:32] because that is a precise time [19:35:59] Hmm how would we replicate this [19:36:02] so it kind of needs to monitor and find the exact time when the clock changes [19:36:31] running a thread for a limited amount of time (no more than 10 seconds) that looks at the AEA and registers a change [19:36:40] maybe that's how they did it [19:37:10] I got to the point where they update the K Factor in the Apollo 11 MOCR audio, but I'm not sure where the updated time came from [19:38:00] it's weird, the clock time is stored and telemetered as a double precision value [19:38:11] From AEA? [19:38:22] Or LGC or both [19:38:23] yes [19:38:27] AEA [19:38:51] but the more precise part of it doesn't even get updated [19:38:58] it's a fraction of 6 seconds or something [19:39:38] and only the 1st word gets time increments [19:39:41] one bit every 6 seconds [19:39:45] that's how I remember it at least [19:40:09] so the precise time when that value changes, then the two words together make the precise AEA time [19:44:45] hey Niklas [19:44:54] Very interesting and makes it a PITA [19:45:11] you might of seen it in the log, I pushed my VC work [19:46:06] oh RETRO is taking care of the K-Factor [19:46:14] yeah [19:47:12] RETRO is? [19:47:20] Interesting [19:48:17] RETRO is doing a bunch of helping tasks for FIDO [19:48:20] and GUIDO I guess [19:59:15] the LGC P22 is just before the K-Factor update on the surface [19:59:24] so it's a bit difficult to find where they talk about it [19:59:28] probably earlier [20:05:19] at 122:10 it was just updated in the RTCC [20:12:07] apparently deriving the K-factor involves subtracting the signal delay [20:13:43] Uhh [20:14:12] For both LGC and AEA telemetry? [20:14:44] I'm not sure they do a direct comparison with the LGC [20:14:57] they have a separate LGC clock zero time stored anyway [20:15:24] although comparing with the LGC seems more precise [20:17:15] And afterall the K factor is what gets entered into the LGC [20:17:31] For the alignment [20:17:51] yeah [20:26:10] you'd think I would have found a procedure for this by now in the documentation... [20:39:02] night! [13:23:46] hey [13:33:29] Morning [13:35:18] Resetting the lunar surface flag makes the CMC take forever on a activity light lol [13:38:47] does the LM have a post-insertion SV yet when you did that? [13:39:02] You mean the CM? [13:39:05] LM slot of the CMC that is* [13:39:08] Nope [13:39:17] ah thats probably why I think [13:39:19] Yeah [13:39:25] I figured that is why [13:39:56] I dont know if MCC can do that yet, but RTCC MFD can [13:40:04] I think MCC does [13:40:54] I am trying to get this checklist timing smoothed out [13:40:55] n7275, nice work on the LM steerable! [13:41:05] Is it working?? [13:41:24] he has a PR with it implemented [13:41:34] I tried it last night [13:44:06] Oh sweet [13:47:56] thanks [14:02:14] I am looking forward to trying it in the LM [14:17:02] So speaking of antennas, I guess we need the AOT to get blocked by the RR in certain detents now [14:30:44] hey [14:32:58] Morning [14:41:04] Working through these lunar liftoff procedures now getting everything synced up to events rather than mission times [14:41:56] looking at the log [14:42:08] the MCC does uplink a post insertion state vector to the CMC [14:45:36] Yeah I know [14:46:08] But that V45 before takes forever lol [14:48:04] V96 is your friend [14:48:18] Would that mess up the integration? [14:48:29] yes [14:48:43] Lol so I dont want to use that I want the V45 to run its course [14:49:12] well, if a LM state vector is uplinked anyway it's not so bad [14:49:55] I remember them talking about in the transcript [14:50:08] 122:31:43 Collins: Yes sir. Keep it that way. (Long Pause) Columbia is coming up on a Verb 45, Enter to reset the surface flag. [14:50:13] 122:32:15 Evans: Columbia, Houston. Negative. Standby on the Verb 45. [14:50:19] 122:32:52 Evans: Columbia. Roger. We copy. (Long Pause) Columbia, Houston. We've got a couple more vectors to send up to you. They'll be coming up shortly and then you can do the Verb 45 after you get those in. Over. [14:50:47] which is not the order from the flight plan I believe [14:52:16] Ohh [14:52:32] Yeah FP has the V45 like 20 minutes before CMC uplink [14:52:42] Maybe I should move our V45 until that uplink? [14:52:53] yeah probably [14:52:59] I haven't gotten that far in the MOCR audio, but I bet GUIDO is complaining about thart [14:53:07] that he wants the V45 later [14:54:16] Ok [15:00:49] n7275, your PR is quite good, I have a few suggestions for changes: https://github.com/orbiternassp/NASSP/pull/526#pullrequestreview-407559295 [15:01:00] was playing around with the Github review features, just to see how they work haha [15:03:17] just looked at them. those seem like great suggestions! I will make changes tonight when I get home. [15:04:31] good, I'll play a bit around with it, maybe I find some bugs [15:05:10] oh and I saw that you made the ground station transmit(?) power 10x higher for the CSM HGA [15:05:25] is that helping out the wide beamwidth signal strength? [15:27:24] indy91, yes I the increased power definitely helps [15:27:57] I misread the power rating. [15:28:40] 20kW is accurate [15:41:35] ah good [16:41:58] rcflyinghokie,e I believe the RR should already block the AOT view if its in a certain position [16:42:14] Oh does it? [16:42:26] I had already made the RR mesh visible from the AOT view for that purpose [16:42:51] if you have the RR in the wrong position you it will block certain detents already [16:43:34] that being said, the position of the AOT view might still need some adjustment so that the amount of blocking is accurate [16:43:51] Oh I havent tried yet lol [16:43:59] I just remember it didnt in the past [16:44:38] yeah, that was after the new LM mesh was made [16:46:41] AlexB_88, I'm going to make the lunar launch window and the stuff for the short rendezvous profile separate [16:46:47] https://cdn.arstechnica.net/wp-content/uploads/2019/06/console-row1-retro2.jpg [16:47:08] as you can see in this picture if you zoom in, the display for the short rendezvous profile has all the inputs displayed [16:47:19] so what do you prefer. A separate page for the inputs? [16:47:36] Or the display with lots of buttons to change the inputs and they get changed on that display then? [16:49:11] hmm good question [16:49:45] some of those have to be tweaked right? like DT INS-TPI, so maybe have the buttons on the main display? [16:50:01] if I understood your question [16:50:19] well I either make it one page or two pages [16:50:29] input and display separate, or one page with both [16:50:59] the inputs get shown on that display, in some cases display don't have all the inputs [16:51:00] what ever is most logical I guess, if its cleaner with 2 pages then maybe thats better [16:51:21] ill be back in a bit [16:58:11] I feel that in this case at least all the inputs are nicely displayed together [16:58:29] morning! [16:58:34] hey [16:59:51] what's up? [17:00:01] chasing bugs [17:00:15] and you? [17:00:26] chasing Sundance mysteries [17:01:12] Hey I am about to be chasing the CM ;) [17:01:17] haha [17:01:24] good morning [17:01:50] [16:59:58] thewonderidiot, there really is nothing in Sundance that simply got removed for Luminary [17:01:53] that aged well [17:01:56] lol [17:02:16] this function is a conundrum [17:02:34] defined at the end of fixed-fixed, six instructions long, added for sundance 302 [17:02:41] calls to it placed in at least six places [17:02:56] what does it do? [17:03:00] I have no clue [17:03:26] you must have some idea [17:03:26] it's not in Luminary -- all locations that call this function in Sundance simply, don't, in Luminary, and Luminary doesn't have it [17:03:41] it doesn't appear in the Sundance 302 DAP flowcharts [17:03:44] where all is it called from? [17:03:59] I need to disassemble all of the surrounding areas to be sure [17:04:31] https://github.com/thewonderidiot/sundance/blob/master/b3_302.disagc#L4105 [17:04:35] that's the first instance of it [17:04:40] TC 7766 [17:04:50] that code is http://www.ibiblio.org/apollo/listings/Luminary069/EXTENDED_VERBS.agc.html#4441504441544131 [17:04:56] DAPDATA1 [17:05:09] so called in V48 [17:05:20] and the lead-in up to it, the DAPDISP code in bank 43, is identical to Luminary [17:05:20] yeah [17:05:26] I know of one difference in Sundance in V48 [17:05:30] oh? [17:06:00] first digit [17:06:10] 1 = Ascent stage, 2 = Descent, 3 = Docked [17:06:13] that's Luminary [17:06:20] and 0 DAP off [17:06:30] I think that works in Luminary as well at least... [17:06:36] Sundance doesn't have that [17:06:42] 0 = Ascent stage, 1 = Descent, 2 = Docked [17:06:43] that's not going to be it [17:06:48] that's Sundance [17:06:51] I think [17:07:04] I think this is related to some anomaly related to either extended verb internals or display code [17:07:27] let's see, what else... I know that it is six instructions long :) [17:07:28] right [17:09:09] https://i.imgur.com/wgSQdYZ.png [17:09:15] that is the DAP flowchart [17:09:25] allegedly for rev 302 [17:09:39] hehe [17:11:30] guess they whipped out MS paint in the 60s ;) [17:11:46] I'll disassemble all of the other areas it's called from tonight to see if I can pick out a pattern [17:12:20] if I'm able to identify them, some look like they are in code that doesn't really exist in luminary (probably due to rewriting more than deletion) [17:15:20] is the code used at the beginning of DAPDATA1 or just before? [17:15:48] right where I pointed to in the flowchart -- just after the job priority change, before loading and masking DAPBOOLS [17:16:23] it's the first instruction of DAPDATA1 [17:16:27] ah ok [17:19:35] oh also we can guess about its location in the listing [17:19:43] and therefore which log section it may have been in [17:20:39] do we have dates for the Sundance revisions? [17:20:39] it's positioned after the end of DOWNENT2 [17:20:55] 292 -- April 1968, 302 -- July 1968, 306 -- October 1968 [17:21:32] then the SCB meeting has something useful [17:21:38] SCB meeting from June 1968 [17:21:52] I hate that SCB meeting memo :D [17:22:05] haha [17:22:15] oh no it's the July one that's annoying [17:22:22] change to APS minimum impulse burn constants [17:22:36] should be in the GSOP [17:22:41] hmm [17:22:42] well [17:22:47] maybe not the old value [17:22:54] values [17:23:03] depending on which module those numbers were in we may already have the newer ones [17:23:05] but it's something we could easily reconstruct for 306 [17:23:14] if we don't have that section of 306 [17:23:46] this is why I hate the July one: [17:23:49] PCN 423 ' Approved. PCN 425 Approved. ' - PCN 435 Approved. PCN 436 Approved. [17:23:59] all Sundance PCNs, no information other than approval [17:24:31] I did find a note in a report last night that said that a total of 46 anomalies were corrected between 292 and 306, lol [17:26:39] that's a bunch of anomalies [17:28:24] the darn GSOP doesn't help either [17:29:05] yeah [17:29:12] section 4 is usually good for this haha [17:31:22] Neil Armstrong collection has some Sundance memos [17:31:32] yeah, but doesn't look like anything related [17:32:15] oh actually [17:32:18] DANCE 56 [17:32:20] hm [17:32:36] maybe some of those would be helpful [17:33:47] that's only april though, probably slightly too early for this change [17:33:48] hmm [18:04:42] interesting I didnt realized they pulled the ASA breaker on 13 [18:07:08] I remember some discussion about it between the flight controllers [18:07:26] Yeah i have it on in the background again [18:07:46] Sounds like they were sure they werent going to use AGS [18:08:22] as sure as FIDO was about not doing a flyby maneuver [18:08:37] some off duty FIDO was calling and he answered "I don't have much to do" [18:09:00] not long after he was deep in figuring out the right maneuver parameters :D [18:10:09] lol [18:11:31] also, they nearly turned off the CMC too early [18:11:58] before they thought giving the LGC a docked alignment and keep the LGC running for a while [18:13:06] Yeah haha, probably in the mindset that they could just P51/52 later [18:13:44] yeah [18:13:50] it's kind of a chain of events [18:14:06] P51/P52 will be difficult, so LGC needs an alignment [18:14:25] power is limited and we have the LGC running now and want to turn it off, better do a flyby maneuver [18:14:53] At least the chain worked [18:15:08] So many wrong decisions could have messed it up [18:15:18] yeah [18:15:24] I think there weren't any big mistakes [18:15:42] they were sometimes chasing leads to the problem that were clearly not useful [18:15:51] at least clear to some people [18:15:54] the experts on a system [18:16:11] like checking the circuit breakers for the O2 fans and heaters [18:16:29] EPS specialist noticed the extra current from them being on [18:16:36] and told EECOM so [18:16:43] but they still spent a bunch of time checking that [18:16:50] and that whole business with disabling Auto RCS [18:16:54] some thrusters [18:17:20] maybe the astronauts should have been clearer that the rates they were developing didn't come from failed on thrusters or so [18:17:56] the only mistake, and the flight directors report also said so, they disabled CSM RCS control before they had it running in the LM [18:18:10] so they had no attitude control at all for a few minutes [18:18:20] could have drifted into LM IMU gimbal lock [18:18:47] Yeah [18:19:10] Kranz mentions something about the sublimator venting when trying to go into PTC after PC+2 [18:19:18] So it was thought about [18:19:40] haven't gotten that far haha [18:20:15] I'm about 1-2 hours after the flyby maneuver [18:20:21] then I got distracted by Apollo 11 again [18:20:32] tried to find some specific calculations by the FIDO [18:23:13] Haha [18:23:19] Yeah i am about 80 hours [18:23:30] 80:30 now [18:23:35] PPCO2 just came on [18:26:14] And on NASSP, time to leave the surface [18:41:12] Hmm is the sband supposed to track during ascent? [18:41:16] LM SBD [18:41:36] auto tracking sits in a PR on Github [18:41:42] hasn't been merged yet [18:42:31] Ah [18:42:36] Never mind [18:42:51] I switched to N7275's branch this morning and gave it a test [18:43:17] I'll test it some myself, but right now I am stuck finding some annoying bug in my new lunar launch window processor [18:44:58] I think Ill make a post in the forums about the LM VC updates [18:45:24] and the NASSP Keyboard commands thread needs some updates btw [18:46:10] yep, will do [18:46:18] thanks [18:46:27] beautiful mode II lockon on pitchover :) [18:47:35] and very little RCS usage [18:48:40] yeah that RR powered flight designate routine is great [18:48:49] especially nice to see as it was never used in flight [18:49:19] Apollo 11 was supposed to use it, but of course didn't risk it with the RR CDUs causing problems [18:49:42] Right [18:49:53] Can confirm..would have worked ;) [18:50:04] 12 didn't use it [18:50:07] 13 still had it I think [18:50:10] then the routine got deleted [18:51:21] Deemed unnecessary I suppose [18:51:41] yeah [18:54:35] should I make a post in the V8 Release Work Thread about the procedure to fly the LM from the VC, or make it its own sticky post? [18:57:49] I think release work thread is enough [18:59:44] ok [19:19:10] are you kidding me [19:19:22] I just didn't update the landing site coordinates in the RTCC MFD [19:19:36] no bug in the SPQ or LLWP [19:21:00] I guess it's somewhat of a bug [19:21:16] the trajectory update with the LM landed only updates landing site lat and long, not radius [19:24:13] hmm [19:24:48] that doesn't make sense though. It didn't use an inconsistent set of coordinates [19:29:52] but I get good results now [19:30:07] optimum CSI only 11 seconds off from what the LLWP had predicted [20:26:27] night! [11:52:02] good morning [12:04:27] hey [12:04:36] a new era has begin for the RTCC MFD! [12:04:39] begun* [12:04:48] I figured out to draw greek characters haha [12:17:23] oh nice! [12:17:33] bring on the thetas [12:17:54] and lots of deltas [12:18:42] they also use the arc symbol, which unicode has as well, it's just being display too small [12:18:48] have to figure out that one... [12:22:42] but otherwise it's great to finally be able to do that! Most displays I have been implementing are actually from the real-time auxiliary computing facility not the RTCC itself, which has nearly the same displays, except it can't display greek letters [12:22:49] so this feels like an upgrade from RTACF to RTCC [12:26:58] back in a bit [12:28:49] that should be fun [13:56:16] For the CSI AGS 605 (COT of LOS CSM) are we just using the FP value of 00777 [13:59:14] is that the 26.6° elevation angle? [14:01:54] it is [14:01:59] so yes, that's always the same [14:09:38] Ok I thought so [14:10:11] Also, might be reading the FP too literally, but TTCA CDR is disabled during ascent, was this enabled to null residuals? [14:10:19] Because the enable step comes later it seems [14:10:42] Nulling after insertion [14:12:43] that's a handwritten change in the surface checklist to disable the two TTCAs [14:13:44] pre-mission change probably [14:14:30] I assume they need to be enabled to null insertion residuals though [14:14:38] yes [14:14:44] not sure when that was done [14:14:52] or if they even actually had it disabled during ascent [15:17:19] hey [15:19:10] hey Alex [15:27:21] formatting the display for the short rendezvous profile [15:27:37] I figured out how to display greek symbols, so I am making use of that [15:30:02] ah nice [15:30:20] I guess that picture you posted yesterday helps for the format [15:30:38] yep [15:31:32] lol they put the Apollo 11 landing coordinates in that display [15:31:51] I don't think the display looked like that for Apollo 11 yet :D [15:37:05] they had a hard copy of a Apollo 15 display for this [15:37:21] must be 15, as the DT between insertion and TPI is 45 minutes [16:08:59] how are we on the LM SBD tracking? [16:09:09] I am ready for my SBD light to not go off during ascent ;) [16:12:57] I made the changes @indy91 requested last night. just waiting on approval [16:19:52] yes, they look good [16:20:01] I was busy with other things, will give them a quick test and merge then [16:26:33] that's a lot of signal strength haha [16:26:38] full scale high [16:28:34] noticed that too when I tested it [16:37:06] Did it go off scale high? [16:39:58] not actually offscale, but 99.9% or so [16:40:22] seems to be scaled in such a way that it reaches nearly 100% at lunar distance and fully aligned with the Earth [16:43:11] n7275, SignalStrength = (135.0 + dBm)*1.1764706; //convert from dBm to the 0-100% signal strength used in NASSP [16:43:14] what is this for? [16:45:04] converts from a -135 to 50 dBm range to a 0-100% signal strength range. [16:45:18] may have something wrong though [16:46:54] is the display not -135 to 50? [16:47:00] that's what the Systems Handbook suggests [16:47:22] morning! [16:48:24] -135 to -50 dBm actually [16:48:27] hey Mike [16:49:45] ah right [16:49:49] I get it now [16:49:56] that does work properly [16:57:37] okay, that's good [17:01:31] the actual decibel value is still in there behind the scenes, so we could use it for bit-rate error if we wanted [17:02:53] *bit error rate [17:22:21] hmm [17:22:39] the signal strength calculation is in the for loop [17:23:15] doesn't cause any problems as it will get the right value on the 4th time around [17:23:52] SignalStrengthScaleFactor is -45 [17:23:57] Do you remember what the CW code was for the SBD? [17:24:03] Was that based on strength? [17:24:15] that's the max the signal strength can be, so it will be slightly off scale [17:24:20] -50 is max displayed [17:24:44] SBDCautFF.Set(lem->scera1.GetVoltage(5, 4) < 1.071); [17:25:05] and that comes from [17:25:05] SA5.SetOutput(4, scale_data(lem->SBand.rcvr_agc_voltage, 0.0, 100.0)); [17:25:43] meaning that when the signal strength drops below 21.42% it will generate the alarm [17:28:54] Ok cool [17:28:57] So no changed needed [17:29:36] yeah I think that is good [17:31:59] n7275, are you happy with that value? -45 dBM max at lunar distance? So with lock on it will be slightly off scale high? [17:32:57] if you want you can still fix that SignalStrength line, but it's not a bad bug, I can merge and we can fix it later [17:39:17] yeah we can merge it, I'll mess around with it this weekend [17:39:37] good [17:39:59] and it's merged [17:43:22] awesome [17:43:59] if you want you can also look at CSM and LM omnis and RR signal strength stuff [17:44:16] we definitely have some data on the RR [17:44:26] but I couldn't figure out the right calculation to put in for that [17:46:14] was going to ask if you want me to do those next [17:46:22] I'd be happy to [17:47:27] great [17:47:51] but feel free to search for something different to do, you don't have to be stuck in antenna land [17:56:18] lol, cool. I've learned soooooo much about antennas in the past few weeks. I'm an aerospace engineer by trade, but I feel like I could be an EE now. [17:57:06] Thats awesome [17:57:18] I am a chemical engineer and got sucked into ECS lol [18:01:07] I guess then I am an aerospace engineer who just didn't want to learn about antennas [18:05:25] 3 engineers working on this project, no wonder its gotten so good :D [18:11:02] Hmm I have no idea what I screwed up here [18:11:12] I am getting constant 525 errors after CSI [18:12:58] delta THETA > 3 degrees [18:13:47] Yeah [18:14:06] Its like a SV didnt update or something during the burn [18:15:59] side lobe lock on due to a state vector that is off [18:16:30] how does V82 look for both vehicles? [18:17:43] LM 44.8 x 40.9 [18:18:03] CM 60.5 x 59.5 [18:19:06] CM according to the LM 59.9x58.9 [18:20:38] Yeah it was side lobe locked I knew the sig strntgh looked off [18:29:50] Relocked main lobe and SV is updating [18:32:57] hopefully a fluke [18:33:02] could also be an alignment issue [18:33:07] P52 was good? [18:33:41] Yep [18:33:45] 00002 [18:34:00] Its correcting it slowly [18:34:23] I slewed to main lobe lockon, auto track, then back to LGC and its happy [18:35:56] nice [18:36:45] 06 49 incorporating [18:36:59] steering closer to center looks like it will be good before CDH [18:40:07] did the CSM do anything bad? [18:40:30] or maybe you had side lobe lock-on before but the LGC didn't recognize it first [18:41:27] CSM is good [18:41:33] It was the side lobe lock [18:41:46] So pilot error [18:42:51] well, that has rarely happened to me before [18:43:03] so hardly pilot error [18:43:14] must have been alignment or something being off enough to cause that [18:43:29] LGC clock, could be so many things [18:47:22] Haha I will run insertion again and see [18:56:09] https://i.imgur.com/ksbDJ1F.png [18:56:15] look at these beautiful greek letters [18:58:22] with your magnifying glass [19:02:13] nice [19:02:24] I used binoculars though [19:15:05] in non-MPT mode it shows the target vehicle as the CSM station ID [19:15:20] close enough [19:27:19] AlexB_88, the new launch window processor (concentric profile) doesn't calculate insertion velocity anymore. Should I implement some small utility function that calculates something for that? [19:27:36] Right now it has the onboard P12 default targets (10x30 orbit) [19:27:39] and it's only input [19:27:51] I need to figure out something better for that and for TPI time [19:28:00] then this update is basically done [19:32:24] I think in reality the VH and RDOT were tweaked for minimal CDH DV and nominal insertion to CSI time or something like that [19:38:38] you mean the function that used to calculate it automatically? [19:39:16] I think only input is fine...I dont think I was using the calculate method anymore now that you could input your own [19:39:47] but maybe there is other reasons to keep it? I dont know [19:40:21] oh so you were using input mainly [19:40:28] and how did you derive your own values? [19:40:56] I used the values in the procedures [19:41:27] for normal concentric profile I used +5535.6, +32.0 [19:42:12] yeah, 32.0 is nominal even for the concentric profile [19:42:16] but they tweak it a lot [19:42:20] Apollo 12 had 37.0 or so [19:42:25] I mean, maybe those were making my insertion to CSI time slightly off [19:43:00] but I found that using calculate made the insertion HDOT too low, around 29-30 fps if I recll [19:43:04] recall* [19:43:27] oh didn't know that [19:43:44] so which ones should we preload [19:43:50] I can use +5535.6, +32.0 [19:44:07] but for T2 you would need to change it to the default onboard values [19:44:47] right [19:45:27] +5535.6, +32.0 is the T3 values in the Apollo 11 procedures [19:45:31] but nominal is used more often [19:45:49] and I think that would be valid for T4-onwards [19:46:20] yeah [19:46:50] I also thought about making it separate values for short and concentric profile, but that would be annoying for the ascent targeting [19:47:30] and because it's actually calculating a launch window now (liftoff times for DH=10, 15 and 20) you also need to manually input the liftoff time for the ascent processor [19:47:58] I can add a function where you type in the ID of the solution and it copies that time over [19:48:15] but it's not that much effort to manually copy over a GET [19:48:28] right [19:48:32] and for T2 you don't use the value it calculates anyway [19:48:43] you would use that -74 seconds bias I was talking about [19:48:50] have tested that, works fairly well [19:49:17] but I guess it makes sense to use the nominal targets instead of default [19:49:26] bias accounts for 10 ft/s phasing maneuver that is not considered in the LLWP [19:49:44] and is TPI time control still possible for concentric/direct? [19:49:56] it can only do TPI on time or at a longitude [19:50:00] so not really... [19:50:33] right, but it has the functionality like before [19:50:43] yes [19:50:50] I guess for direct its by playing with DT [19:50:51] you can input a TPI time [19:51:00] ins-TPI DT [19:51:02] ok [19:51:11] for concentric I mean [19:51:14] right [19:51:24] for direct its playing with DT [19:51:27] yeah [19:51:39] great [19:51:42] in MPT mode you go through the sunrise/sunset table anyway [19:51:52] yeah [19:52:01] in non-MPT mode the DKI TPI only calculation still works [19:52:06] I think I'll make that its own thing [19:52:10] Ive been actually printing off screenshots of that on my missions :D [19:52:23] on the page with the rendezvous processors [19:53:08] yeah, in reality they knew the three relevant TPI times for all the pre descent targeting [19:53:19] I invert the colours of course, or else I would be buying a black ink cartridge every week [19:53:35] they just had to figure them out once and then, with help of their worksheets, knew which ones to use [19:54:33] I usually write them down by hand [19:55:10] or you can cheat and use the DKI "TPI time only" [19:55:28] but I am guessing that will be a short-lived feature haha [19:55:50] that's what I was talking about, I want to make that a separate thing to get TPI times [19:55:55] mainly for non-MPT mode [19:56:20] the sunrise/sunset table is interpolating the ephemeris, that method is definitely not compatible with non-MPT mode :D [19:56:30] yeah that makes sense [19:56:37] its a useful feature [19:58:16] ha, the RTCC calculation for predicting the TB6 for TLI is just quickly building an ephemeris for itself and then also interpolates to find the TB6 time [19:58:27] when you have lots of spare memory, but not so much spare processing power... [19:58:44] yeah [20:00:29] they were inconsistent with these TPI times though [20:00:39] the real DKI processor had a TPF lighting feature they used [20:00:55] "TPF 20 minutes into day" [20:02:53] and the SPQ has a bunch of TPI and TPF lighting options, but apparently it was broken in lunar reference for Apollo 11 or so [20:07:46] I do think it's better to use a consistent set of TPI times though, the rendezvous processors might come up with something slightly different when you let them choose [20:08:32] right [20:09:21] Ill have to test the lambert targeting updates, havent done that yet [20:12:17] it's another case of taking more features away than adding them :D [20:12:30] but you don't have to input the N, the number of orbits anymore [20:12:39] that gets calculated automatically. One new feature [20:13:20] nice [20:21:46] the display initially looks simpler then before [20:21:54] yeah, certainly is [20:22:09] some options were only really useful for the Apollo 7 phasing maneuver [20:22:26] but I no longer believe they targeted it that [20:22:41] whats the function of "OPT"? [20:22:48] Both Fixed,etc [20:22:58] initiation and arrival time [20:23:06] both fixed means both times are fixed [20:23:15] and then you can vary either the first or the second [20:23:48] and it will calculate a bunch of solutions for that [20:23:54] both fixed is always only one solution [20:24:22] for the Apollo 11 No PDI+12 they used "first fixed" and then somehow derived that solution 3 is the one they want to use [20:25:13] there is a second mode which I have not implemented yet, NCC/NSR mode. That also can vary DH and the phase angle [20:25:27] but I don't think they used it for anything else than Apollo 7 NCC-1 [20:25:43] right [20:26:15] so, for TPI calculation, or direct insertion tweak, you would use "both fixed" I guess [20:27:32] yeah [20:27:52] what does the 60s, 600s mean? [20:27:53] and as before, you set the T1 to something negative to find the T1 based on elevation angle [20:28:00] right [20:28:02] and T2 for the same for travel angle [20:28:14] that's the increments for the options with one time fixed [20:28:27] 60 seconds increment, 600 seconds total range covered [20:28:34] so if your T2 is e.g. 100:00:00 [20:28:41] and you use first fixed [20:29:03] the it calculates solutions for T2 = 100:00, 100:01, 100:02 ... 100:10 [20:29:21] ah ok [20:31:01] so for No PDI+12, I use first fixed and PDI+12 TIG [20:31:09] for T2 do I just use an estimate? [20:32:07] I think so [20:32:22] I'm still not really sure how they did that [20:32:50] they might have looked at pitch angle and DV and used what looked nominal [20:32:55] that would be a bit of a crude procedure [20:34:30] but you can put the two TI maneuvers on the MPT and then run the TI again to find TPI [20:34:41] and use that as the time delta [20:34:52] takes a bit more effort than before [20:37:41] hmm "no two impulse plans available" [20:39:40] which inputs did you use? [20:39:58] P51,15,-4.475; [20:40:28] and T1: PDI+12 TIG and then T2: 1 hour later to start [20:40:32] well first, it's not minus anymore [20:40:35] I had that wrong before [20:40:36] with first fixed [20:40:38] ah [20:41:11] a positive phasing angle is when the chaser is behind the target [20:41:24] try a bit more than an hour [20:41:42] close to 180° and 360° transfers it might fail [20:41:54] ah yes [20:42:16] and nominal abort maneuver to CDH is more like 1:40h or so [20:42:28] so in its showing data for 2 maneuvers [20:42:45] ah so the 2nd is CDH [20:43:03] yeah [20:43:20] two impulse maneuver processor, using two impulses to establish a coelliptic orbit [20:43:34] so now I put that on the MPT and use the rendevous display to find TPI time? [20:43:51] you can run the TI again, with zero phase and DH [20:43:57] and let it find T1 and T2 [20:44:17] what's nicer than before is that both maneuvers are transferred at the same time [20:44:19] ok [20:44:45] so you don't have to run the SPQ to calculate CDH [20:45:50] "and let it find T1 and T2" but isnt 1st fixed selected? [20:46:15] I mean isnt T1 always No PDI+12? [20:46:26] I thought you wanted to find the TPI time [20:46:28] PDI TIG +12 mins* [20:46:31] right [20:46:52] with No PDI+12 and CDH on the MPT, you can run the TI again to find that time [20:47:02] both fixed in that case I guess [20:47:09] ooh [20:47:52] with elevation angle and travel angle search and first fixed it would have solution as the 130° transfer [20:47:56] solution 1* [20:48:13] and then increments T2, so longer transfers [20:49:01] but I think you are only really interested in the one solution for TPI [20:50:49] Im doing the MPT transfer now [20:51:04] I hit CLC but nothing happens [20:51:21] PLN 1 [20:51:28] that cant seem to be changed [20:53:10] also on the DIS the calculation shows "both fixed" but I had selected "first fixed" on the previous page [20:53:47] void ApolloRTCCMFD::menuCycleTIPlanNumber() [20:53:48] { [20:53:48] } [20:53:49] oops [20:54:00] but plan 1 is the best one most of the time anyway :D [20:54:19] the display shows what was last calculated [20:55:08] hmm [20:55:12] although I am seeing a potential bug [21:07:44] did you not get it to transfer? [21:08:03] that at least should work. The first fixed thing would just be a display bug [21:10:05] I couldn't [21:10:08] let me try again [21:13:20] anything on the online monitor about it? [21:17:32] hmm tried again and still wont transfer [21:17:37] I've tested quite a bit, as two maneuvers being transferred at once is new [21:17:58] but you have a valid solution, right? [21:18:16] last online monitor message: PMSTICN (REQUESTED TWO-IMPULSE SOLUTION NUM [21:18:22] haha [21:18:22] it cuts off at the end [21:18:33] yeah, it can't do automatic line breaks... [21:18:42] but it did look good in the DIS page [21:19:01] "REQUESTED TWO-IMPULSE SOLUTION NUMBER NOT AVAILABLE" [21:19:48] https://www.dropbox.com/s/wpp7tat7egq9ddm/Screenshot%202020-05-08%2015.19.40.png?dl=0 [21:20:18] I am using the default Apollo 11 before PDI scenario btw [21:20:34] I've most tested it with cases where it was only one solution [21:20:46] and that's the bug :D [21:20:47] if (opt.SingSolNum < PZTIPREG.Solutions) [21:20:55] oh and shouldnt it say OPTION BOTH FIXED> [21:20:56] SignSolNum is the requested solution [21:20:58] always 1 [21:21:17] I got that logic backwards [21:21:24] I mean OPTION FIRST FIXED [21:21:27] it gives that error if there are more solutions available :D [21:22:04] so it will work if you only have one solution [21:22:08] and I'll fix that of course [21:23:14] and yeah, somehow it doesn't save the requested option for display [21:23:22] must have deleted that last minute by accident or so [21:23:26] I remember it being there [21:23:51] ah I see [21:24:04] well done, found two bugs already [21:24:20] I'll push it with my LLWP update [21:24:29] should be done Sunday or so [21:24:44] but as I said, if you use the both fixed option it will work [21:25:28] if you use the both fixed option then both issues are fixed! [21:25:36] haha [21:25:58] thats the secret meaning, eh? [21:26:58] of course [21:27:34] ah yes, it works with both fixed [21:28:31] ok, so with them on the MPT, I go back and recalculate with 0,0 for the offset,DH [21:29:28] and the minus times for T1 and T2 [21:29:36] ah so basically I am doing am calculating the TPI itself [21:29:40] yeah [21:29:54] see, the FIDO did give the 26.6° and 130° as inputs for this [21:30:15] makes sense [21:30:20] but I just don't see how it can find the TPI time [21:30:28] in the No PDI+12 calculation [21:30:37] and the TPI time I get, I use the delta from the time I wanted [21:30:41] yeah [21:30:57] and re-calculate the whole thing with itr [21:30:59] it* [21:31:03] yeah [21:31:20] but that's not what they did on 11. They just looked at the display with the multiple solutions and somehow determined that whay which is the good solution [21:31:40] way* [21:31:45] right [21:31:50] I can't see how though... [21:32:11] and they never ran the TI again to look if it gives a good TPI tme [21:32:12] they must of had some tools we dont to interpret the data maybe? [21:32:35] or the TI processor did have the capability to calculate TPI times after all [21:32:44] well, for the No PDI+12 I mean [21:32:55] right [21:33:26] FIDO did give 26.6° and 130° as inputs for the No PDI+12, which is not needed for that [21:33:42] not sure if he did that out of habit or if it could calculate TPI times [21:33:48] I might just re-add that feature [21:34:02] when DH and phase are both non-zero [21:34:24] and when elevation angle and travel angle are non-zero as well I guess [21:35:13] if the TPI time is on the display then they could have looked at the desired TPI time [21:35:21] and then choose the plan which is the closest to that [21:35:32] I think I'll do that. In doubt go for more features, not fewer [21:36:15] and that way you don't need to re-calculate with a new T2 at all [21:36:21] hmm so I calculate that I need to remove 23 minutes from my T2 [21:36:23] the 60 seconds increments are small enough [21:36:54] but then that makes it say "no two impulse plans available" again [21:37:15] hmm [21:37:23] which T2 did you use initially? [21:37:36] 104:20:0 [21:37:50] remove 23 minutes from that? That is weird [21:37:55] nominal is 104:33:38 [21:37:58] and that gave a TPI time of 105:43:0 or so [21:38:08] in our scenario it should be 5-7 minutes more even [21:38:16] hmm, I must of screwed somethin up then [21:38:20] pretty sure that 104:40 is the correct value [21:38:55] the T1 time is displayed in the upper part of the display [21:39:00] that's what you used? [21:40:11] ohhh wait [21:40:16] I was looking at GET2 [21:40:28] thats probably TPF time [21:40:34] yep [21:40:56] so I re-did it with 104:30 as initial T2 [21:41:04] the "fixed" time is always displayed up there [21:41:09] now GET1 is 105:10 [21:41:24] so I need to add 10 minutes since my desired TPI time is 105:20 [21:41:28] yeah [21:42:05] the longer I think about it, the more I am convinced that it did show a TPI time. You won't even have to manually iterate on the T2 time, as one solution will be close enough [21:42:16] if you do 60 second increments [21:42:30] so that's even less work than before then [21:42:53] yeah, I agree [21:43:13] and it could agree with what I heard on the FIDO audio [21:44:52] and it will be only under certain conditions [21:45:17] T1 and T2 need to have been input, DH and phase are non-zero, elevation angle and travel angle are non-zero [21:46:25] makes sense [21:46:54] so once you have your NoPDI+12 calculated, to find the CSI time, I can use the SPQ I guess [21:47:07] I know it should be very near 0 [21:47:16] optimum CSI [21:47:20] that's what the FIDO used [21:47:29] I guess I can delete the second TI maneuver [21:47:33] and got accused of cheating, as Rendezvous did it some other, more difficult way [21:47:40] yep, that's what the FIDO did as well [21:47:50] but you can just use a threshold time before the second TI maneuver [21:48:00] oh right [21:53:53] night! [06:28:55] done with the noun tables, now on to the extended verbs [06:29:06] there's a couple of P10/P11-related nouns that may not work at all [06:29:21] but I need to spend some more time looking at their conversions before I can say that for sure [06:31:46] on the verb side, apparently V45 is the w-matrix display instead of v67 (neither are shown in the systems handbook) -- that got renumbered early in Luminary [06:33:05] there is no V68 for P64NOW [06:33:50] nor is there a V57 or V58 for LRON/LROFF [06:34:41] which is interesting because the systems handbook *does* show those [14:01:22] hey [14:02:11] good morning [14:03:33] I am trying to figure out sband insertion configurations [14:03:48] strictly following sur its in CWEA enable at launch [14:04:07] however the transcript has them do brief ranging and then to off [14:04:20] and in cwea enable, autotrack doesnt work on pitchover [14:04:36] well rather, auto track doesnt hold lock on pitchover, setting off the CW [14:07:25] but from reading the transcript is seems as if it did hold lock [14:09:30] I think the steerable in the LM can do faster rates than the CSM HGA [14:10:12] but we still have a 5°/s limit [14:10:21] should be 20°/s or so, at least for auto tracking [14:10:28] Ah that would do it [14:11:53] I implemented 5°/s for manual mode [14:12:07] which I think is correct, although I have to check again [14:12:28] well n7275 wanted to do some fixes anyway, might as well do that [14:15:08] sounds good [14:17:36] 20 deg/sec [14:17:52] with an acceleration of 60 deg/s/s [14:18:42] I dont see an auto/manual difference [14:20:18] I am pretty sure that would keep the lock on pitchover [14:24:49] Other than that it seems to be tracking nicely [14:24:54] yeah [14:25:03] Even while doing a P52 [14:25:04] I might have not found a good source for the speed in manual [14:25:14] and used the same as the HGA [14:25:41] I just found it in a systems handbook [14:26:00] it just gave tracking velocity and acceleration no reference to mode [14:26:38] yeah [14:36:57] in the rendevous checklist the post insertion p52 dap load, is says 1(2) 1012 [14:37:14] why would it have the parenthesis [14:37:30] My first guess is an option to use 2 or 4 jet RCS [14:37:44] but the (2) is next to the configuration digit [14:37:49] so its a little confusing [14:38:32] same thing on the dap load after insertion and before p52 [14:40:52] the checklist is also used for descent aborts [14:40:56] ahh [14:41:00] that makes sense then [14:43:06] it's clearer in the later timeline boosk [14:43:08] books [14:43:18] there it has one nominal checklist fro short rendezvous profile [14:43:30] and then procedures for all variants of coelliptic rendezvous [14:54:55] Man how I wish we could have multiplayer [14:55:02] Especially rendezvous [14:56:12] that would be so fun [14:56:18] rescuing each other :D [14:59:48] Haha seriously [15:01:01] Oh and redoing insertion no issues [15:01:17] I think not paying attention tot he side lobe is what threw me off [15:02:41] hey [15:05:31] hey Alex [15:07:35] still getting somewhat inconsistent results between LLWP and SPQ [15:07:51] although mostly it's been bugs in the overhauled SPQ rather than the LLWP :D [15:09:55] I am happy when the optimum CSI that the SPQ calculates agrees within a few seconds with the value of the launch window calculation [15:10:02] but that is not always the case yet unfortunately [15:14:56] right [15:16:31] now I randomly get quite good results haha [15:16:52] optimum CSI 13 seconds off from predicted [15:16:58] that's definitely good enough [15:17:08] that's like a 30 second difference, almost nothing in DH [15:22:33] ok, I think the disagreement is mainly in the CDH calculation [15:33:16] I am loving this VHF marking in the CM [15:35:00] wasn't even hard to implement [15:35:32] Skylark (and Artemis?) has a fun feature [15:35:41] the VHF ranging worked at ranges much higher than expected [15:35:46] Nice [15:35:55] so high that the register that contains the range data overflows [15:36:10] but they make it still work [15:36:16] Oh thats cool [15:36:18] I don't know the exact number, let's say 320NM is the max [15:36:24] and the range is 325NM [15:36:32] then the VHF ranging would say range is 5NM [15:36:48] and the software knows that 325 is much more likely than 5NM [15:36:58] and incorporates it as 325 [15:37:47] don't think I properly tested it but that's how it should already behave from the VHF ranging side [15:38:03] earlier CMC versions just don't allow ranging beyond the max value of the register [15:38:32] So making sure I am doing this right [15:38:42] I did a P76 in the CM after CSI [15:38:46] The started P20 [15:38:54] V87 [15:39:09] And V80? [15:39:23] probably V80 yes [15:39:28] updates the LM state vector in the CMC [15:39:36] CSM state vector should be better known [15:40:04] Yeah after P76 I only got 1 06 49 [15:40:14] And then marking uninturrupted after [15:40:24] no 06 49s in the LM this time [15:40:30] sound slike my usual experience [15:40:43] did you add half the burntime for P76? [15:40:55] it's super confusing that it shows DV first and then TIG... [15:41:29] Hmm no I didnt add half the burn time [15:41:37] I did pay attention to the DV first then TIG [15:41:49] P76 adds the DV impulsively [15:42:03] so it's best to use the middle of the burn time [15:42:09] Gotcha [15:42:20] Well considering I didnt the 1 incorporation was pretty good [15:42:26] they reminded Collins of that on Apollo 11 [15:42:29] reminded* [15:42:36] I'll remember that for the rest [15:42:45] the real VHF ranging usually had one really bad mark at first [15:42:53] which was rejected [15:42:59] and then worked fine [15:43:03] not quite sure why [15:43:36] AlexB_88, 5535.6 ft/s horizontal velocity seems to overshoot 15NM DH usually [15:44:43] will of course depend on the LS radius [15:46:17] I guess yoy have to tweak it then [15:46:22] you* [15:48:20] well I just want to select a default value that works good for most missions [15:49:32] interesting, that value is the exact Apollo 12 SCOT value [15:51:09] I just tried Apollo 12 though, gave me 13NM [15:51:11] DH [15:51:48] maybe it was just the CSM orbit being off [15:58:24] I also find that each mission had a quite different insertion vertical velocity for concentric profile [15:59:25] yeah, they tweaked ZDOT to get the right altitude at CSI and RDOT to get nominal time from insertion to CSI or so [15:59:29] Apollo 12 was 37 fps [15:59:54] will it be easy for us to tweak it in this updateÉ [15:59:59] ?* [16:01:40] I think it's pretty easy [16:01:55] you just have to have the page open with the targeting parameters [16:02:04] and the LLWP display in another MFD [16:02:05] At what range does the tracking light become visible? [16:02:28] I mean by that, you can see the targets change with every tweak (insertion-CSI time, DH) [16:03:23] oh it should be from quite far [16:03:39] but in NASSP its only visible from 100 NM or so I think [16:03:53] which is wrong I think [16:04:03] interesting, 37 ft/s RDOT is what you need to get exactly 50min for insertion to CSI [16:04:23] maybe that's what the Apollo 12 FIDO decided on [16:04:31] ah, right [16:05:07] I know the format of the RTACF display which might have been the one for the lunar launch window, but I added some more parameters [16:05:27] it wouldn't have had insertion, CSI, CDH times [16:06:48] https://i.imgur.com/Qf9LcgQ.png [16:06:57] this is what I have right now [16:07:52] looks good [16:08:53] I guess a little bit more than before [16:09:01] but the options, oh boy, there is a lot of options [16:09:22] not all of them enabled yet, as I haven't tested them all [16:09:48] is the ascent pad calculation compatible with the updates? [16:10:04] good question, let me check [16:11:35] I think it's the same as before, the liftoff time on the ascent processor page and the RTCC wide ZDOT and RDOT are used for the ascent PAD [16:12:19] ah ok [16:12:21] I should probably add an input for the liftoff time on the Ascent PAD page though [16:13:01] right now you would need to run the ascent processor first [16:13:17] as the liftoff time isn't getting copied from the LLWP [16:13:26] there is more than one possible liftoff time after all [16:14:02] to get a precise liftoff time you should run the ascent processor anyway, but I'll make it possible to go from LLWP directly to the Ascent PAD [16:14:45] ok [16:15:17] they didn't have an automatic feature to calculate the ascent powered flight arc and time on Apollo 11 [16:15:29] so they used the DMT burn time for ascent [16:15:40] as that's also gone through the ascent integrator [16:15:48] and then played a guessing game for the flight arc :D [16:16:11] FIDO tried subtracting inertial ignition and burnout longitudes [16:16:21] but that doesn't work out so well with spherical geometry [16:17:42] not sure my method is really perfect though [16:17:57] might be off with larger crossrange [16:21:26] hmm [16:21:38] AlexB_88, did I kind of break your method for the tweak burn? [16:29:18] as long as its fixed before my Apollo 14 ascent :D [16:29:38] no I mean, is there a useful display for that now? [16:29:45] the calculation would work [16:29:53] it just gives DV, pitch and yaw [16:29:57] and not a P30 input or so [16:30:58] there is another display, Two Impulse Single Solution, where you can transfer one solution from the list to get more parameters [16:31:41] but the actual display is the Ascent Rendezvous Monitor, I can try and implement that soon [16:31:51] I guess you can disactivate MPT, then you get the DV's on the transfer page? [16:32:02] right, that would work [16:32:15] doesnt seem to much more work [16:32:27] bit of a workaround, but works as before I guess [16:39:20] for the short profile only one liftoff time gets calculated, so I'll let it automatically update the liftoff time for ascent processor and PAD, as before [16:48:51] ok [16:48:59] have you tried landing the LM from the VC yet? [16:50:01] not yet [16:52:29] Apollo 11 would need only 30 minutes from insertion to TPI for nominal TPI lighting [16:53:21] for a direct? [16:53:46] yep [16:54:07] because of the short lunar stay I guess [16:54:15] still close to the terminator [16:58:14] morning! [16:58:15] Auto tracking working nicely throughout [16:58:29] Added the LOS/AOS procedures for the LM as well [17:00:23] AlexB_88, flew an ascent with Apollo 11 for short rendezvous profile, 5 ft/s tweak burn, probably about average? [17:00:25] hey Mike [17:01:10] yeah I think that is normal [17:01:21] a bit in every axis [17:01:44] and Apollo 11 still had an outdated APS cutoff velocity in the LGC [17:01:51] well, inaccurate rather [17:02:15] later LGC versions have a better number [17:02:33] so the DV before trimming or a tweak burn is already a bit off from that [17:02:52] thewonderidiot, tell me about broken P10 nouns in Sundance [17:03:29] I tried finding it in the rendezvous procedures, but there is no V45, or V67 for that matter [17:04:09] https://github.com/thewonderidiot/sundance/blob/master/b6_306.disagc#L4982 [17:04:33] that's the mixed noun address table [17:04:47] should contain ECADRS for what to display in the nouns, or 0 for spare [17:05:58] that is R1 of noun 92 [17:06:03] just "7" [17:06:24] which in erasable memory is just always 0 [17:06:28] and then below [17:06:55] all three registers of N96 are similarly weird [17:07:34] so I dunno if there is some special handling for them... but Sundance is the only program that has weird numbers in this table like this [17:07:39] it might not use R1 in N92 [17:07:49] time and angle from launch to TPF [17:08:39] +X AXIS ATT ICDU ANGLES [17:09:41] 7, 10, and 11 are ZERO, ARUPT, and LRUPT [17:09:46] definitely not angles :P [17:10:10] haha yeah [17:34:44] AlexB_88, 3D cockpit looks good, I'm missing some LPD lines :D [17:35:13] yeah taht will come for sure [17:35:16] that* [17:36:03] I am kind of torn between leaving further work for NASSP 9, and starting some things now like working gauges... [17:36:49] that's me with every new project [17:37:08] I'm telling myself, we can get serious about a NASSP release when there is an Orbiter release we can actually use :D [17:37:44] the thing is since we are in beta, I dont want to go to far with it since I would consider it a "major" feature [17:37:58] yeah [17:39:40] true [17:39:59] but it's something that can be done quite separately, without breaking anything [17:42:25] yeah [17:43:35] we would have to make it from the start so that we can have mission specific panels [17:43:57] I guess the mission file already helps with that [17:44:05] right [17:52:02] thewonderidiot, "In case everyone has not heard, the SUNDANCE program has been [17:52:03] fixed so that the crew can use the rendezvous radar self-test program [17:52:03] (R04) during terminal breaking with the Average g program (P47) running [17:52:04] simultaneously. That is great!" [17:52:20] from a November 1968 Tindallgram if you hadn't seen it [17:56:15] hmmm [17:56:31] what does that mean in terms of code though lol [17:57:44] but I hadn't, that's definitely a 306 change, thanks :D [17:59:01] no idea [17:59:45] oh that's using the range and range rate display on the DSKY during final braking for rendezvous [18:00:02] maybe P47 locked out extended verbs? [18:00:23] that is very possible, and if that's it then it will be easy to fix [18:21:38] indy91, thewonderidiot, do we have any good plans of the LM cockpit with side/top/front views [18:24:24] we haven't gotten there as far as the original drawings are concerned [18:59:21] I think MCC needs to read up a DAP load after LPO docking [18:59:27] *our MCC [19:00:11] The LM got one at about 128:11 [19:00:25] ok [19:01:13] I am trying to figure out if Collins got weights for the CM DAP here as well or if he just used those read to Aldrin [19:03:27] I can squeeze another DAP PAD in there somewhere [19:03:59] Theres a lot of time between the CSM SV and the CSI pad [19:04:22] rather CSI and SV [19:04:57] Actually its the CSM LM SV and the CSM SV [19:05:01] thats the spot [19:05:55] Hmm [19:06:09] Mistake in the transcript? [19:06:11] 128:11:35 Aldrin: Roger. I'm configured now at [garble] for B/D roll, and I have thrusters C4 and B3 turned off, and I copy Register 1 61102, 01111 and LM weight 5785. Thank you. [19:06:15] I think thats Collins [19:06:24] So it is a CSM DAP [19:07:26] https://apolloinrealtime.org/11/?t=128:11:30 [19:07:35] that attributes it to Collins [19:07:38] must be Collins [19:07:54] yeah [19:08:06] I mean Aldrin doesnt make sense with that call at all [19:08:46] would be an interesting DAP config [19:10:29] Yeah [19:10:57] and yeah, with this light ascent stage it's better to have a precise weight [19:12:06] Rendezvous went really well for not having done it in forever [19:12:47] Smoothed out our checklist MFD quite a bit as well [19:13:34] yeah, that's where the checklist got a bit rough [19:13:41] you didn't get that far last time around [19:16:10] Nope [19:16:21] I need to clean up the docking a bit more [19:16:31] But I have the rendezvous procedures pretty smooth [19:16:36] Removed the timestamps [19:16:43] Put TIG holds [19:16:49] Flows very well [19:17:34] The docking is a bit hard because of all the vehicle changes but also the procedures are a bit scattered...like when to put in the CSM docked DAP, using P47 on CSM docking etc [19:19:58] when was the last time you have flown a reentry? :D [19:26:33] Lol longer than my last lunar rendezvous attempt [19:26:50] What's in store? [19:29:06] oh nothing new [19:30:31] well, you can now do an Apollo 13 style SM jettison! [19:31:31] Push pull? [19:33:25] the SM used to fire rcs thrusters all the time at SM jettison, but now I think you can disable the SM RCS before jettison [19:33:44] but maybe you were there when it was implemented [19:33:48] the SMJC [19:35:53] hmmm, verbs 60 and 63 exist in Sundance 306, but are not documented in the systems handbook [19:40:58] AlexB_88, that was working before, I implemented the SMJC version for Apollo 12 and later which doesn't fire forever. So Ryan won't see that. [19:41:23] ah ok [19:43:54] hmm [19:43:58] thewonderidiot, it gets weirder [19:44:06] R32 still exists as an extended verb [19:44:17] it hasn't been turned into P76 yet [19:44:21] they tested the LR during the rendezvous [19:44:32] V61 to command LR to position 2 [19:44:47] procedures from January 31, 1969 [19:44:53] should be pretty up to date [19:44:58] yeah that looks right [19:45:16] and V62 starts R04 instead of V63 [19:45:38] so then what are V60 and V63 :D [19:45:55] that verb has been moving lower and lower [19:46:02] it's V60 in Luminary 69 and 99 [19:46:05] and V59 after that [19:46:08] haha [19:46:42] yeah, I can cofirm the V62 [19:46:49] what is later V63 is V62 in Sundance [19:48:05] "KEY V84E (TGT DV)" [19:48:13] instead of P76 [19:48:22] yep [19:48:36] found V63 [19:48:52] "KEY V63E (PGNS MODE 2 ERR NEEDLES)" [19:49:01] for the RR I think [19:50:31] treating RR mode 2 differently is overrated [19:50:52] in an outdated Apollo 10 procedures document we had RR angles displayed on the DSKY that use a different convention in mode 2 [19:50:59] maybe rcflyinghokie remembers [19:51:13] oh interesting [19:51:19] does that verb exist in any luminaries? [19:51:31] we got the updated version from UHCL and it had the angles that agree with Luminary 69 [19:51:37] yes it probably was in Luminary [19:51:38] pre 69 [19:51:49] well that's not helpful lol [19:51:54] not sure about the V63 [19:55:12] did you know Luminary memos had Sundance changes? [19:55:25] or no [19:55:28] Sundance anomaly [19:55:33] fixed in Luminary I guess [19:55:36] Sundance anomaly Y72 was fixed by resetting LOSCMFLG before [19:55:37] the call to the designation logic by V41. [19:55:43] December 68 [19:56:08] Sundance anomaly Y74 was fixed by making P34 and P74 initialize [19:56:08] CENTANG to 130 degrees. [19:56:33] yes, I've been making a lot of reference to the early Luminary memos [19:56:48] so many of them just say "Sundance anomaly Yxx was fixed." with no further explanation which is maddening [19:56:58] https://www.ibiblio.org/apollo/Documents/COL70.pdf [19:57:08] this Colossus memo from Margaret actually has all of the details on the R32 change [19:58:22] does Don have Sundance anomaly reports? [19:59:15] nope :( [19:59:29] he has barely any sundance stuff sadly [19:59:45] it's not called "Sunburst, Sundance and Luminary" after all [20:00:13] haha [20:00:14] yeah [20:01:46] who worked on Sundance predominantly? [20:02:29] Sundance anomaly Y69 was fixed (incorrect meters-to-feet scale factor [20:02:30] in R47). [20:02:56] sounds familiar :D [20:02:56] yeah I saw that one lol [20:03:03] definite confirmation of the bug :D [20:03:10] Jim Kernan was the rope mother [20:03:15] Don worked on it a lot too [20:03:20] it was essentially the same team [20:03:23] I am looking when they changed the RR angle display [20:03:27] he just didn't think the longer title sounded as catchy [20:03:48] "LUMINARY Revisions 35 - 38" please give [20:05:12] yeah that's a really bad one to be missing :( [20:07:32] also bad to be missing, the Colossus memo when the operator error in V49 was fixed between Colossus 237 and 249 :D [20:08:39] haha yeah [20:12:03] Hmm that sounds familiar about the convention on Apollo 10 [20:12:13] I know I had to adjust a few things in the LM [20:12:48] yeah, that preliminary descent/phasing procedures document caused us a few problems [20:12:56] they were also still testing P63 there [20:22:53] nothing too weird in the verb implementations so far [20:25:46] other than the random 7, 10 and 11 references [20:25:57] hahaha none of those in the verbs [20:25:59] that's just nouns :D [20:26:07] so far... [20:26:08] ah of course [20:27:53] but I'm still in the 40s [20:27:56] stuff is going to get weird soon [20:28:14] maybe with 45 [20:31:17] I'm gonna guess that's the same as 67 [20:31:21] just with a different name? [20:32:25] could be [20:32:27] no idea :D [20:33:00] whatever it is I won't get to it for a bit [20:33:16] I have half of the bank to go before then [20:33:18] V44 is definitely normal [20:38:42] I better don't say these things too definitively, or else I have to quote myself again [20:38:49] hahahaha [20:39:11] well, I've been looking at VC code in various projects today (deltaglider,SSU,etc) [20:39:41] safe to say I have quite a bit to learn, Ill need quite a bit of help once we do launch into it [20:40:03] yeah, it's some heavy coding [20:40:20] I think once we have something working adding more switches etc. will become much easier [20:40:44] its the whole structure of it I think that Ill need in place for me to work with [20:40:59] well some of it [20:41:07] we don't have to re-invent how switches work [20:41:13] right [20:41:22] we mainly need new functions in the switch classes we already have [20:41:26] at least I hope that [20:41:53] Id like to use lots of animations [20:42:52] I mean that I already have a bit of understanding and I could make more 3D components in the gauges, etc [20:45:11] we definitely should go for the most advanced stuff that Orbiter offers [20:46:26] oh yes [20:46:40] the delta-glider seems to have most features we need [20:46:53] right [20:47:02] save for maybe the FDAI ball [20:47:22] but I think another Orbiter vessel may have an example for it [20:47:45] Shuttle A [20:47:51] yeah [20:48:25] mean that sounds like it should be easy to implement, a ball animated on 2 axis I guess [20:48:34] I mean* [20:59:19] ah wait, on Shuttle A it seems to be only on the 2d panel [21:01:37] right, noticed that when I looked just now [21:18:16] oh nice [21:18:21] R04 is in bank 43 [21:18:32] so we have the sundance 306 version of it [21:25:50] ah great [21:25:54] good night! [22:53:45] oh great [22:53:49] P47 should be in this module too [22:53:57] so whatever the change was, we have it [00:51:27] looks like the mystery V60 and V63 are really just V61 and V62, respectively [00:53:03] it's a late addition though, it does use flagword 0 bit 4 (NEEDLFLG), but that bit is also not defined in the systems handbook [02:12:42] Does Orbiter have moving light sources? [02:13:17] If so, modelling a user-controllable flashlight would be neat; The DCS MiG-21 module does so, and you have to use it when starting up at night. [02:14:22] (Since you guys are talking about VC stuff) [02:51:10] man I love the DCS MiG-21 :D [03:31:44] It's fun. [03:33:35] It also happens to run acceptably on my machine [03:33:58] and not require four hands worth of hotas buttons [03:34:54] I've always wanted to give it a shot since I read about the Constant Peg MiGs. [03:35:48] nice! [03:36:54] one of my favorite things to do was try to beat the real-world altitude record [03:37:07] using the JATOs in flight to give me a boost up [03:37:47] I spent so much time in the DCS MiG that for a good while I could read Russian flight instruments more easily than American ones :P [03:38:52] I'll worry when I can switch the language back to Russian and not get lost. [03:39:16] Too bad DCS doesn't have doctrine-appropriate GCI [03:39:46] They describe in the Constant Peg book and it sounds like fun [03:40:36] They owned a guy so hard he accused them of having an extra pilot providing awareness, and played back their tapes of the GCI operator talking them into the merge as "proof" [03:40:43] "Look! He's talking like the fighter pilot he is!" [03:40:59] "Nobody could get that kind of awareness from a radar!" [03:41:36] haha [03:41:48] Now I want to re-read the book (again) [03:42:31] It's on Kindle if you have something capable of reading kindle ebooks [03:42:49] I don't, but I've been thinking about getting one [03:43:03] if you have an iThing, it's available as an iThing app [03:43:18] unfortunately I have no iThings [03:43:19] I have no experience with their devices beyond the original e-ink one [03:43:32] which was pretty slick, but limited for the era [03:44:55] speaking of books though, I just got a fun new one today [03:48:03] Oh? [03:48:23] one sec, taking some pictures [03:51:16] https://photos.app.goo.gl/taMkejgiSTofGJ9Y9 [03:51:57] Oooh, that does look interesting [03:52:34] :D [03:52:42] I'm going to start scanning it tomorrow [03:53:12] Those foldouts will be a chore :< [03:53:59] not so bad, really! I perfected a decent enough foldout scanning technique doing the LM-3 Systems Handbook [03:54:39] they're more than likely going to be the easy part, depending on how the rest of the pages are structured [03:55:48] Well, here's hoping it goes without too much hassle [03:56:48] thanks! hopefully :) [04:50:58] done with extended verbs! no real surprises other than what we talked about above [05:11:09] Hello. So I have been trying to familiarize myself with NASSP 8.0, and I had some weird issues that I want to clarify. So in the state the code is in the Orbiter2016 branch right now, are the scenarios in "Apollo - Mission Scenarios" folder being maintained, or should I be just using the toplevel "Apollo XY[ MCC] - Launch" ones? [05:44:34] hello mizvekov! [05:45:24] that is a good question -- that I am unfortunately not equipped to answer [05:45:55] they probably mostly work, depending on the scenario, but there have been changes recently that may have broken some of them [05:46:23] the toplevel ones should all be good though, as far as I know [05:47:37] I'm not sure what timezone you're in, but if you check in anywhere from now + 7 hours to now + 15 hours, that is when the channel is most active [05:48:00] most of the devs are asleep right now [05:48:20] on the other hand if you hang out for another 3 hours we might get a visit from an early morning indy91 :) [07:02:13] mizvekov, still awake? [07:03:11] yes sorry [07:03:29] no problem [07:03:40] how can I help you? [07:04:12] so I am repeating what I said a few hours earlier: Hello. So I have been trying to familiarize myself with NASSP 8.0, and I had some weird issues that I want to clarify. So in the state the code is in the Orbiter2016 branch right now, are the scenarios in "Apollo - Mission Scenarios" folder being maintained, or should I be just using the toplevel [07:04:13] "Apollo XY[ MCC] - Launch" ones? [07:04:56] they are not properly maintained, but they are at least not causing crashes [07:05:12] some things you can experience in the mission scenarios: [07:05:15] mission timer is 0 [07:05:27] FDAI needs a moment to get back to the right attitude [07:05:35] RCS control needs to be enabled again [07:06:16] the toplevel scenarios are the ones that are always kept up to date [07:08:33] yeah that is what I imagined. [07:08:39] so I will tell you what happened: I was playing the Apollo 8 MCC - Launch, got all the way to TLI, no problems. Then in the middle TLI, I had this Orbiter bug that has been happening to me, problably not related to NASSP, but the mouse went invisible and I have to restart the game to fix it. Problem is, when resuming from the middle of TLI, the [07:08:40] SIVB burn went on for a few more seconds but then cutt off, not neraly enough dV to get me to the moon. [07:09:21] so I resumed from the apollo 8 scenario just before TLI [07:10:03] yeah, out accelerometer implementation doesn't like saving and loading [07:10:06] our* [07:10:25] so saving during a burn (launch, TLI etc.) can cause issues [07:10:31] then I saw some issues that did not appear on the toplevel one. For starters, I got the TLI PAD too late, after some checklist items that were already requiring some data from it [07:10:39] and I've had that mouse bug a few times as well [07:11:21] well, mouse didn't turn invisible, but I couldn't move it anymore [07:11:30] other thing, the SII SEP light did not light at all for the TLI burn, unlike when playing from the toplevel scenario [07:12:15] hmm [07:12:24] maybe those scenarios are more broken than I thought [07:12:41] for Apollo 7 and 8 they are still the same scenarios that were in the NASSP 7.0 release 3 years ago [07:12:47] for me the mouse turns invisible, I can still click and it does still highlight stuff from the orbiter in game menu. It does stay invisible when you back out from the simulation back into the launcher [07:13:33] might be DX9 Client related or so [07:13:45] yeah np, now that I know they are broken I will not report anything based on experiences there [07:14:11] I wanted to fly Apollo 8 again anyway [07:14:22] during that I'll replace the old scenarios [07:15:16] one other issue I have been seeing is that often times I get to the GDC align portion of the checklist, but usually would have been missing some previous step telling me to turn off ORDEAL from FDAI 1 [07:15:55] I guess it's good to save often, the combination of Orbiter, DX9 Client and NASSP can cause issues often enough :D [07:16:08] yes, learned my lesson there :) [07:16:35] yeah I guess sometimes you have the ORDEAL running and want to disable it for a moment, like for GDC Align [07:17:22] but not a big problem anyways because that FDAI is so hard to read, I mostly use N20 anyway [07:18:50] I'm sure you'll get more used to the FDAI [07:20:24] yeah I guess, though looking at RL pictures of it, I see that it has a lot of fine detail that would be pretty hard to achieve in the current state of the game [07:20:45] might be better in an eventual 3D cockpit [07:21:29] then you can just zoom in at will [07:22:10] one other issue that I remember from the top of my head right now is that I forgot SPS propellant line heater on, and when I came to my senses the SPS propellant tank temperature was reading full scale high. A couple hours after turning it off, still has not recovered [07:22:54] yeah that would be cool [07:24:19] I don't think that causes any harm in the simulation right now [07:24:26] will just take a long while to go back to normal [07:24:56] right, but do you remember from the top of your head if there should be a thermostat there? [07:27:56] hmm, not sure [07:28:32] temperatures do matter in some instances [07:28:39] the RCS can freeze [07:29:04] although you would have to point a RCS quad away from the sun for many, many hours to do that [07:29:56] I see. I am taking a look at the systems handbook right now [07:39:21] indy91, the ignition routine has a lot of changes. the tables for it have more entries and are ordered differently. plus there's two more tables -- I've identified P12, P40, P41, P42, and P63, but there's two more tables on top of that that Luminary doesn't have [07:39:37] lots of fun to be had in this bank [07:39:59] interesting [07:41:19] both of the new tables display V06N75, if that means anything to you [07:42:48] hmm [07:43:15] could be in the rendezvous procedures [07:45:02] no N75 to be seen [07:47:43] which is weird [07:47:55] in Luminary it's a pretty normal P32 noun [07:48:20] that's N50 in Sundance [07:50:28] about those line heaters: no thermostat, although there are temp probes downstream of those heaters that should have triggered some C/W (basing this on drawing 9.1 / 1 SPS) [07:50:54] thewonderidiot, oh I saw you got that Saturn schematic document :D [07:51:03] I'll check if that is not properly wired [07:51:45] indy91: yeah it looks super great. and scanning might go relatively fast [07:52:29] mizvekov, which alarm would that be? [07:52:37] C&W light I mean [07:53:50] thewonderidiot, how many pages has it? [07:55:14] SPS FLANGE TEMP HI? [07:56:13] indy91 I am still looking for which alarm, that was a guess based on there being temperature probes there. but I have to check it out [07:56:23] indy91, it's an interesting question. there's 20 shematic foldouts, each with their own section. but the listing of parts section is enormous, almost 400 pages [07:57:10] might help me sometime when I am chasing down a signal and I want to find the connector for it [07:58:10] ENG INJ FLANGE TEMP? That temperature measurement? [07:58:17] would be a wonder to somehow convert those schematics to some modern CAD tool :P [07:58:48] which System Handbook are you looking at? CSM-104? [07:59:24] SP0049TENG OXIDFEED LINE TEMP0 to 200 F1 S/S1 S/S [07:59:41] there is an equivalent one for the fuel line as well [07:59:50] ah right [07:59:52] I am looking at HSI-481260.pdf [07:59:55] I guess that's the one used for the display [07:59:59] the gauge [08:00:02] and telemetry [08:00:43] so worst case C/W from capcom? :p [08:01:06] also the system test meter [08:01:20] yeah [08:01:21] hmm [08:01:28] what is displayed on our gauge then? [08:02:46] the problem is there is only one temp gauge, but there are obviously two temp sensors, one for each of fuel and oxid lines [08:04:21] ox line temp should be on the system test meter [08:05:55] fuel on the prop temp gauge [08:05:57] both of them, B-6 and D-4 [08:07:24] the stuff shown on the system test meter was changed a lot for Apollo 15+ [08:07:49] I see [08:08:52] on my apollo 8 save ith that FSH temp gauge, B-6 reads 4 volts, D-4 reads zip [08:09:43] 6B is "TEMP -P ENG INJECTOR SYS A" for us [08:09:46] not simulated yet [08:10:05] range -50 to 50°F [08:10:10] hardcoded to 30°F [08:10:12] so that's the 4V [08:10:37] our 4D is CSM TO LM CURRENT [08:10:40] that is simulated [08:10:43] if you have a LM [08:11:50] I'm not really sure where you got 6B and 4D, for any CSM [08:11:59] weird. do you see the same schematic, it has that D (big Z) 4 symbol in it [08:12:54] oh that's a reference in the Systems Handbook [08:13:01] schematic 10.2, location D4 [08:13:31] oh okay, sorry, my bad [08:13:35] haha no problem [08:13:45] 10.2, D4 has the RCS temps going to the system test meter [08:13:50] and that ox line temp from the SPS [08:14:12] roger, I have to study this stuff more carefully :) [08:14:43] and I don't think there is a C&W light for this [08:14:55] I bet EECOM has a light for it though [08:15:31] yeah, although there is no sort of MSFN warnings implemented right now I bet [08:15:44] or maybe rather GNC [08:16:33] which is something we can check actually [08:18:55] GNC flight controller has a "SPS LINES" light on his console [08:19:16] cool [08:20:00] might be a combined light for both ox and fuel [08:20:06] if they out of a specified range [08:20:13] offscale high or low or so [08:20:48] I guess that temp is not critical enough to be a C&W light [08:20:55] yeah. It's pretty weird that heater is so unprotected. I guess [08:21:27] CSM Data Book only has a lower limit for those temps [08:21:51] I do remember something about hypergolics explosively decomposing in high temperatures though :P [08:22:31] but maybe even with no flow, those lines never get hot enough [08:23:16] and I guess you can always pull the circuit breakers if the heaters fail on [08:26:05] every document I am looking at just worries about the temp being too low [08:26:13] just says it's turned off above 75°F [08:26:59] but unless I am not reading this right, there is no thermostat there, which means it would have to be done manually [08:27:19] yeah, switched on or off [08:27:30] it's part of a pre SPS burn checklist [08:27:35] to turn it on if the temp is low [08:27:50] and to turn it off if it was turned on earlier, before the burn [08:27:58] yes, no checklist entry reminding you to turn it off though :p [08:28:25] hmm, could be a long time between those burns, it got hot pretty fast [08:28:42] yeah, you usually don't have it on for long [08:28:50] maybe it's just our Checklist MFD missing that step :D [08:29:11] yeah [08:29:28] so there could be a lot of interesting dynamics for simulating those lines. For example, when the engine is firing, that temp will tend to go down towards the fuel/oxid temperature in the tank. When it stops firing, the heat from the engine should soak back into those lines somewhat [08:30:18] sounds about right [08:33:42] but rather difficult to achieve with our current systems simulation I think [08:39:01] I see. Thanks for your help :) It's late, have to check out to bed, but ill try to stick around and see if there are other issues. Later! [08:41:10] cya! [14:19:22] Good morning [14:19:57] hey [14:20:21] I see some more antenna merges [14:20:25] my lunar launch window processor updates is finally done [14:20:26] yes [14:20:31] n7275 did some more fixes [14:20:42] not the increase speed though [14:21:09] Ah ok [14:21:17] Also I was looking at the MCC uplinks [14:21:30] A few of them are labeled Apollo 10 for 11 [14:21:41] PT_AP10DAPDATA [14:21:54] PT_AP10CSI [14:22:03] Is that because they are the same for both? [14:23:11] I worked my way through the missions thinking I might have to use mission specific PADs [14:23:18] but I have been reusing a bunch [14:24:04] Ok [14:24:25] Just making sure they werent goofs :) [14:24:44] just laziness [14:26:04] Haha ok [14:26:23] The only thing I need is a DAP load after docking ;) [14:28:33] hey [14:29:10] Good morning [14:29:52] hey Alex [14:29:56] LLWP update is done [14:30:17] and the display for the short rendezvous profile I guess, but that calculation hasn't changed much [14:36:08] ah nice [14:37:36] all input options are implemented, although I have only made those usable that have been tested so far [14:39:10] mizvekov, the mouse issue I believe is a long-standing Orbiter bug. It seems to happen when you are in external view and panning around with the mouse while holding down the right mouse button, and while doing so press F1 to go into the cockpit and the cursor disappears with no way to get it back without restarting the session [14:45:49] I have had luck repeating the F1 and spamming left and right click getting it back lol [14:46:03] but you can move the mouse up and find the menu and still save [14:46:18] https://www.orbiter-forum.com/project.php?issueid=1043 [14:46:48] oh interesting, I ner thought it was possible [14:46:51] never* [14:49:46] AlexB_88, not enough space on the TI display. Under the circumstances we talked about I'll let it show TPI time instead of pitch and yaw for the second maneuver [14:50:44] ok sounds good [14:50:51] Ill give the updates a try [15:00:40] looks quite good [15:01:48] indy91, what about putting the TI TPI time in the online monitor? [15:02:05] for all up to 13 solutions? :D [15:02:16] oh haha [15:03:03] nah, I think I already have a good system [15:03:18] and then you can choose the solution with the closest TPI time to the desired time [15:03:24] and won't even have to iterate on it [15:05:50] right [15:06:16] so I am playing with the LLWP right now [15:06:57] I have my solution on the rendezvous planning table [15:07:01] For the CSM V89, was a preferred option or +x option used? [15:07:52] so I am playing with the VLH & VLV to get CDH DV as low as possible, I guess that is the correct procedure? [15:10:38] AlexB_88, yeah pretty much [15:11:03] rcflyinghokie, R2=2 says the CMP Solo Book [15:11:26] Yeah that makes sense [15:11:52] AlexB_88, I have it default to CSI at apolune, but I at least for T3, T4 etc. they actually used 50 minutes after insertion [15:12:00] not sure if that also applies to nominal [15:12:34] and for T2 they used CSI 217 minutes after insertion [15:12:50] and then subtracted 74 seconds from the liftoff time to get the actual liftoff time [15:13:10] to compensate for the phasing maneuver [15:16:24] ah ok [15:16:27] and make sure you have updated landing site coordinates in the MFD, that has caused me some trouble during testing :D [15:16:35] right [15:16:55] so for direct ascent, do you use the LLWP as well? [15:17:54] nah, there is no launch window for that really [15:17:59] it's only launch on time [15:18:20] so that's all on the LLTP page [15:18:35] I moved descent abort to utilities [15:18:46] it wasn't even an RTCC program, only RTACF [15:21:51] so LLTP is only used for direct, correct? [15:23:24] yes [15:23:38] so two pages, one for concentric rendezvous, one for short profile [15:24:09] in reality it was a bit more complicated than that. They had a launch targeting display even for the concentric profile [15:24:15] it had some more data on a specific launch [15:24:56] it might have also just been more launch targeting data on the lunar rendezvous plan table [15:25:13] just tried a direct ascent solution for Apollo 12 [15:25:15] but I think this is a logical division, one page for each profile [15:25:20] DT would be 38 mins [15:25:26] sounds about right [15:25:35] yes I think this setup looks pretty good [15:26:00] two nested input pages for the LLWP though :D [15:26:08] but that's all the options, there is many of them [15:27:05] oh, when I calculate with the LLWP/LLTP, do I have to go to the Lunar Ascent Processor, calculate, then come back and recalculate the LLWP/LLTP like we use to do? [15:27:26] yeah, same technique [15:27:37] ah ok [15:27:57] maybe I should just use better initial guess for powered flight arc and time [15:28:12] it's a function of ascent stage mass and crossrange [15:28:17] and neither should vary too much [15:28:21] and I see the LLTP automatically gives the Ascent Processor the TIG [15:28:34] yeah, that's more convenient [15:28:35] but for the LLWP I have to manually enter it [15:28:39] and it only comes up with one TIG [15:28:51] LLWP it's 3 or more [15:29:00] right makes sense [15:29:09] I could add a button that copies over the selected TIG to the ascent processor and PAD [15:29:20] press button, type 2, and it copies it over [15:29:44] would add a little bit more convenience [15:39:03] Hmm shouldnt the V89 point the COS to the LM? [15:39:13] I am still a little confused about how it maneuvers [15:39:16] COAS* [15:39:31] yes [15:39:44] did the CSM get all P76s and did VHF ranging until the end? [15:39:53] Yes [15:40:05] And I tried it again with a fresh LM SV [15:40:19] Still points me the wrong way [15:40:27] a bit off or totally wrong? [15:40:36] mode 2 points +X axis [15:40:40] should be COAS [15:40:55] I am 043 [15:41:05] should be about 332 [15:41:29] and it has an accurate CSM SV as well? [15:41:35] Oh hang on, I botched the SV update [15:43:07] I did LM SV to CSM slot lol [15:43:12] not used to the new menu in RTCC [15:43:33] anything I can improve there? [15:43:51] I guess the title is fairly clear [15:44:05] No that was simply user error [15:44:09] I forgot to choose slot [15:44:25] Thats a little better [15:44:36] not bad! [15:44:37] https://www.dropbox.com/s/wpp7tat7egq9ddm/Screenshot%202020-05-08%2015.19.40.png?dl=0 [15:45:06] that is the LLWP prediction on the left, and the whole thing on the MPT on the right [15:45:13] Apollo 12 concentric [15:45:35] ugh wrong image [15:45:53] https://www.dropbox.com/s/k05dgbh71g3to7z/Screenshot%202020-05-10%2009.45.49.png?dl=0 [15:46:39] nice [15:46:49] did you use optimum CSI mode? [15:47:17] yes [15:47:41] looks pretty close [15:48:01] I guess it got a TIG ~30 seconds earlier then the LLWP but still very good [15:48:22] there is a myriad of small differences that will make the LLWP not be exactly like the MPT will all the maneuvers in it [15:48:43] if it was exactly the same FIDO wouldn't have to use optimum CSI mode :D [15:49:09] that they did launch on the full second alone has some error in it [15:49:32] and SPQ and LLWP use quite different methods for CDH and TPI [15:49:57] I'm sure there is still a bunch of small improvements to be made there, but hopefully no large errors at least [15:53:25] yeah [15:54:16] so playing with the VLH,VLV is only to get the CSI 0, it wont have any affect on CSI times? I guess thats decided by the liftoff time itself [15:54:32] CDH 0* [15:55:55] if you put CSI at apolune then VLV definitely has an effect on CSI time [15:56:28] ah right [16:01:33] and TPI time display is done [16:02:11] unrelated: I thought of something last night. When we migrate to virtual cockpits, instead of putting MFDs in the VC, we could develop the "MCC" vessel to have a panel simulating mission control with a bunch of MFDs [16:03:09] so when you calculate a maneuver, you switch to the MCC and then back when your done [16:03:27] like this? [16:03:28] https://i.imgur.com/YB1pjXu.png [16:03:42] ah yes [16:03:56] but more MFDs :D [16:04:20] I am thinking a panel completely covered with MFDs [16:04:56] right [16:05:06] Ok so I have the rendezvous flow pretty good [16:05:14] but that is a nice setup [16:05:16] FIDO only has two, but all of his support people have consoles with two displays as well [16:05:29] I want to see if I can squeeze in P76's but I dont know if I can [16:05:37] and input pages aren't even display etc. [16:06:13] yeah, it's difficult already just to get all LM events done in time [16:06:50] I was able to do it myself but adding it into the checklist MFD probably wont go over well [16:08:07] what I have often done is to be almost exclusively in the LM and only go over to the CSM when it comes to docking [16:08:33] I think for the CSM stuff, you can just put something near the end to have it point to the LM [16:08:50] so its at least in the right attitude [16:09:08] aren't there specificed docking IMU angles for CSM and LM anyway? [16:13:47] n7275, I think the steerable needs a bit more speed [16:14:15] we used 5°/s like in the CSM, but it can actually do 20°/s. It needs that to keep lock at pitchover during lunar ascent [16:14:32] not sure if that's also the speed it has in manual [16:16:43] There are specified docking attitudes yeah [16:16:55] I did the V89 technique this time [16:17:05] ok, next project, fly Apollo 8 (and then 10 and then 11) to update the MCC with new targeting for MCCs and LOI. And some other stuff. [16:17:11] It had me about 15 degrees different in pitch than the flight plan [16:17:21] But it squared up with the LM very well [16:17:37] So I could go that route or the FP angles [16:17:39] well, that will depend on exact timing, which direction the LM is coming from etc. [16:17:58] and would they have docked in that attitude that V89 gave? [16:18:00] The problem with the V89 though as far as this goes is it relies on a good LM SV [16:18:09] I thought they did that until station keeping and then maneuvered [16:18:15] Yeah that sounds right [16:21:51] There is the coas offset with a V89 in +x mode isnt there? [16:23:04] an offset? [16:24:38] Oh I saw coas track 37 [16:24:41] Never mind [16:26:30] So when would be a good time to have this DAP load based on rev [16:26:37] the actual was read at 128:11 [16:27:55] some time early on rev 27 I would wager [16:28:24] yeah [16:28:40] I would say a good guess would be about 35 minutes into it [16:31:34] sure [16:33:20] "Forward, south and down, is south really south?" - philosophical thoughts with the FIDO [16:36:01] Lol [16:36:15] Hes not thinking 4th dimensionally [16:37:42] he's think about the plane change REFSMMAT, a bit too hard I guess [16:37:49] thinking* [16:48:56] "Guidance, CAPCOM, do you have your background guys working on the correlation between the 1202s and the calling the N68?" "Clinically" [16:51:00] morning! [16:53:15] hey Mike [16:57:56] what's up? [17:00:33] got a bunch of updates done [17:00:40] might even do some flying next! [17:02:05] Yay! [17:02:27] I might actually finish repeating rendezvous [17:03:17] nice! [17:33:21] @indy91 I can fix the speed. [17:33:57] indy91, so I want to use some code from the DG to make a working switch in the LM VC. [17:33:57] https://www.dropbox.com/s/tv5ht9sckqufzdb/Screenshot%202020-05-10%2011.33.04.png?dl=0 [17:34:56] n7275, great [17:35:32] should that be placed directly in the current switch classes? [17:36:50] that should be a pure virtual function in the PanelSwitchItem class [17:37:47] that class has a lot of functions like this: virtual void DrawSwitch(SURFHANDLE DrawSurface) = 0; [17:37:59] add a line like that [17:38:10] hmm [17:38:25] that will give you an endless amount of build errors at first :D [17:38:47] I guess you want to start with a simple toggle switch? [17:38:58] n7275 yeah that speed will help LM auto tracking for sure [17:39:09] That way I dont lose it on pitchover :P [17:39:57] AlexB_88, don't add the function like that [17:41:01] although you might have to eventually [17:41:54] my goal right now is just try to make a switch work :D [17:41:56] put a class like that in ToggleSwitch at first I guess if you want to start with that [17:42:05] a function* [17:42:19] right [17:42:38] and it can always be moved to PanelSwitchItem later on [17:42:55] a bunch of this will end up in PanelSwitchItem though I would guess [17:43:02] that's the most basic switch class [17:51:49] so I have an idea of where I can define the VC switch [17:52:05] but what about handling mouse events and redraw requests [17:52:41] in clbkPanelMouseEvent in lmpanel.cpp? [17:53:04] and clbkPanelRedrawEvent following it [17:53:22] but there are VC versions of those [17:53:27] so maybe I need to add that [17:54:02] yeah, those need to be added [17:54:50] IIRC the only difference between the VC versions and the ones now is that the VC versions give you the z coordinate [17:56:00] except that we don't use 2D meshes for anything, only bitmaps [17:56:16] the "new" way of doing 2D panels is similar to 3D panels [18:03:24] so there is probably a lot of new stuff we have to add, more than if we had a 2D panel like the DeltaGlider already [18:04:07] or atleast it will be more difficult, as it's not similar code for 2D and 3D [18:06:07] yeah [18:06:55] I mean Ill start with a switch, then once I have that down go with a 3-pos switch, then a dial and so on [18:07:13] slowly learn how to make each kind of thing I guess [18:07:59] the API guide is not bad for it actually [18:11:13] The Orbiter API guide is actually very good. I have seen far worse in SDKs that previous work paid thousands of dollars to license. [18:12:10] For one, it's actually in English (and not Engrish) [18:12:18] yeah it's quite good [18:12:38] although I recently discovered a hardly documented Sketchpad function, TextW (instead of Text) [18:12:52] which allows me to now print unicode characters in MFDs [18:13:16] would have seen that earlier if it was documented properly :D [18:13:44] At least it was just missing and not outright wrong [18:14:49] yeah, it could definitely be much worse [18:16:05] I remember one product in particular that I should not name since this channel is logged and I don't want sued where the documentation was maintained in the native language of the developers and a separate copy in what passed for english; They would update "their" copy but not "ours" until they got around to it. [18:16:22] So you would have functions in the english manual that had different arguments and/or names than what was actually in the code [18:16:32] and you had to read the chinese version of the manual to work out the differences. [18:16:57] Er, pretend I said "native language" instead of "chinese" [18:18:06] ouch [18:36:38] alright, scanning time :D [18:37:12] the pages are actual individual pages instead of booklets so I might be able to actually use the faster new scanner for this one [18:41:08] indy91 your latest push is failing to build [18:42:01] 'menuCycleTIPlanNumber': is not a member of 'ApolloRTCCMFD' [18:42:29] https://www.dropbox.com/s/c3knqwti2tpi3wh/Screenshot%202020-05-10%2014.42.27.png?dl=0 [18:45:29] ah, forgot to include the file defining the RTCC MFD buttons [18:45:55] thanks! [18:45:58] Sure [18:46:43] last minute change, I renamed it to menuSetTIPlanNumber :D [18:54:39] So after Eagle was jettisoned, did it perform an MCC uplinked maneuver? [18:56:41] Eagle was just left in orbit I think [18:57:30] Thats what i thought [18:57:36] I just couldnt remember [18:58:59] Snoopy got shot into heliocentric orbit [19:05:33] well this scanner was worth it, holy cow [19:05:49] great to hear [19:06:09] 400 pages scanned already [19:06:29] wow [19:11:03] and that's all the work it can do lol [19:11:15] now I just have foldouts and separators left :) [19:14:06] indy91 do we just want to use the FP LM jettison time for 11 or the actual one about 1h20m earlier? [19:15:23] hmm [19:15:47] why was it early on the real flight? [19:17:24] 129:57:20 Duke: Columbia, Houston. It looks like you guys are so speedy on us that we're thinking about moving up jettison time to about a GET of 130 plus 30, if that's okay with y'all. Over. [19:18:57] Ahead of schedule [19:19:08] And I guess not a time critical event for 11 [19:19:33] yeah [19:19:41] Would mesh better with our schedule as well considering we dont need to move rocks from one vehicle to the other :P [19:19:48] not shooting it at a specific point on the Moon [19:19:49] Otherwise you are just waiting [19:20:07] right [19:20:16] usually we go with the mission as planned though [19:20:28] Which is fine with me [19:20:33] Just feeling for opinion [19:22:04] yeah, do it as planned [19:22:19] and maybe even back to GET? [19:22:26] TEI won't be on GET [19:22:43] will be off the same amount as any lunar orbit event [19:58:06] https://www.dropbox.com/s/3fjmysnj6spesxb/Screenshot%202020-05-10%2013.58.07.png?dl=0 [19:58:28] that is from DGSwitch1 in the deltaglider [19:59:06] I renamed it to ToggleSwitchVC [19:59:12] just for intial testing [20:00:47] hmmm [20:01:17] making it a separate class is a bad idea [20:01:38] but if it's just for testing, sure [20:01:54] once I figureit out I can merge it into ToggleSwitch I guess [20:02:23] yeah definitely [20:02:56] we are just creating too many new issues for ourselves if the VC is functionally separate in any way [20:03:03] right [20:03:17] this is the RedrawVC function [20:03:39] https://www.dropbox.com/s/sa04qf5g9pbya30/Screenshot%202020-05-10%2014.03.00.png?dl=0 [20:03:45] yeah ideally we mainly have separate redraw functions for 2D and 3D [20:03:52] of course there is animation definitions etc. [20:04:06] yeah [20:05:44] alright well I've had to further modify my foldout scanning process lol [20:05:54] looks like testing code :D [20:05:58] but this should make foldout stitching more seamless in the future [20:06:24] you are getting as good as Ron [20:07:36] haha [20:07:45] the new scanner was bought on his advice :D [20:10:10] the new step is to put down long pieces of non-sticky tape in big empty areas in the foldout, to give the stitching software something to grab on to [20:10:20] and then edit that out before taking it to pdf form [20:10:47] otherwise it might fail to stitch [20:12:54] ah clever [20:15:19] yeah there we go [20:16:26] https://i.imgur.com/qBqia5s.png [20:16:34] no way it would have done that area right before [20:22:15] 3 foldouts down, 18 to go [20:22:53] I look forward to studying that document [20:48:50] night! [23:18:06] okay, ignition routine is starting to take shape [23:18:19] running across a lot of alarms that don't exist in Luminary [00:21:29] took me an entire day to get one switch working [00:21:36] and I got it working :D [00:26:56] hahahaha nice!! [00:27:55] I still cant figure out how to properly redraw it [00:30:03] I cant seem to update the animation state in clbkVCRedrawEvent [00:30:18] had to put it directly in the time step just to test it lol [00:32:56] hmm [00:33:38] that works but is probably not sustainable :) [00:34:41] no lol [00:34:56] I did it only to check if my animation code wasnt deficient [00:42:01] got it [00:43:30] it was overloaded with a DEVMESHHANDLE, it was unused so I took that out of the function and now it works [01:34:08] ah nice :D [07:07:00] okay, ignition routine complete, I think [07:07:04] on to P40 [13:25:45] good afternoon [13:25:54] Good morning [13:26:07] We dont have any jettison checklists for 11 do we? [13:26:21] I am winging it based on 12's and the transcript at the moment [13:27:58] the Apollo 11 Timeline Book we have is missing those pages [13:28:45] Yeah I know :( [13:28:52] I think I have an approximation [13:29:21] to include an AGS PGNS align, resetting the AGS DB, activating the secondary evap, and leaving the CO2 sensor on [13:29:51] And using the normal jettison timeline [13:33:00] it's weird that it is missing pages [13:33:03] it's the flown version [13:34:22] it's also missing flight plan pages which were in the Timeline Book [13:35:38] I wonder if lm jettison was its own checklist though [13:36:47] 130:04:34 Duke: Hello, Columbia. Houston. We'd like you to start down your jettison checklist. We recommend picking up page F11-12 and we'd like to jettison at ten minutes, that'll be 130:14:45. Over. [13:37:34] interesting [13:39:19] F11-12 is that F11 and F12 or page 12 of F11? [13:40:35] no wait [13:40:39] Hello Columbia [13:41:51] that's in the CSM Operations Checklist [13:41:58] which we have [13:42:12] starts on PDF page 155 [13:45:19] Nice find [13:46:33] but for the LM there wasn't a separate checklist, I am pretty sure [13:46:41] we have the stowage list, everything that was flown [13:46:45] Yeah that was on the timeline book [13:46:48] Or should be [13:50:54] https://www.christies.com/img/LotImages/2019/NYR/2019_NYR_17119_0011_002(the_timeline_book_apollo_11_lm_timeline_book_houston_manned_spacecraft).jpg [13:51:12] I think there are definitely more pages after docking [13:55:04] I'm flying a crazy rendezvous profile right now [13:55:10] Did someone goof on scanning? [13:55:14] Uh oh lol [13:55:22] Apollo 11 anytime lunar liftoff [13:55:29] launch 5 minutes too early [13:55:38] about 0° phasing angle at insertion [13:55:45] which sounds ok, but it's really not [13:55:47] uhh [13:55:55] PGNS? [13:56:14] Wonder how the LGC handles that [13:56:30] I just gave P12 a TIG 5 minutes too early [13:56:36] I did this on purpose :D [13:57:03] in the procedure the LM has to do a +100 ft/s DVX maneuver just after insertion [13:57:13] results in a 10x100 orbit [13:57:21] then the LM powers down a bit [13:57:30] I just killed the AGS and any unneded display [13:57:42] 10 minutes later, CSM deboosts to 60x20 orbit [13:57:48] and circularizes at 20x20 [13:57:55] then you wait two hours [13:58:03] CSM does all the rest [13:58:15] 250 ft/s CSI maneuver [13:58:20] CDH one full rev later [13:58:37] rest is normaly, except for the quite elliptical orbit [13:58:56] I'm between CSI and CDH right now [13:59:11] one of the more complicated case, pre-nominal phasing liftoff [14:00:39] I wonder if they could have really pulled this off [14:01:00] with some time to prepare yet, but if you have time to prepare you don't need to liftoff 5 minutes early [14:01:05] yes* [14:03:52] I'll be in theoretical sextant range soon, 400NM [14:10:38] Oh ok [14:10:44] So this is a CSM rescue [14:11:06] A pretty crazy one at that [14:13:57] yep [14:13:59] Also I was thinking if its easier, you could add that DAP load with the CSM SV update after docking [14:14:19] but it's only a CSM rescue because of DV requirements [14:14:24] But I think it was read up about 30 minutes prior to the SV [14:14:36] there is an even more complicated case where the LM can't do that 100 ft/s maneuver [14:15:09] I guess it's mainly so that the LM can hold attitude well after LM jettison, right? [14:17:12] I'm confused now, when was this DAP update send up in reality? Before or after docking? [14:19:13] After docking for the CSM [14:19:35] hey [14:19:41] 128:11:07 Evans: Roger. Your LM weight, 5785. For an R1 we'd like to have 61102; R2, 01111. Use B/D roll. Over. [14:20:12] hey Alex [14:20:16] morning Alex [14:20:45] it was pretty soon after docking [14:20:52] docking was 128:03 [14:21:34] So yeah it should be its own thing [14:22:17] Maybe rev 27 plus 55 minutes or so? [14:22:27] I think the CSM SV is plus 95 [14:22:45] indy91, https://github.com/jalexb88/NASSP/commit/7763b6f130a26ab45859fd059ba8f33e1aa450b3 [14:23:10] thats what I came up with so far, I got my switch working :D [14:24:40] nice! [14:26:02] what do you think of the structure of it? I added a function in ToggleSwitch to process the mouse from the VC [14:27:41] and then I added the animations for the switches in InitVC() and drive them from clbkRedrawEvent tied to the state of the switches like: [14:27:42] if (EngineDescentCommandOverrideSwitch.IsUp()) { [14:27:42] SetAnimation(anim_P3switch[0], 1.0); [14:27:43] } [14:27:43] else { [14:27:44] SetAnimation(anim_P3switch[0], 0.0); [14:27:44] } [14:30:40] clbkVCMouseEvent and clbkVCRedrawEvent can of course be much more automated [14:31:00] otherwise it doesn't look too invasive into our current system [14:33:41] right [14:35:19] some of the code I got from AAPO [14:39:41] 200NM distance, still can't see the LM in the sextant [14:41:30] in terms of efficiency, has there to be a redraw event for the switches on each timestep? [14:42:06] I guess it's the same as the 2D panel [14:42:28] Checklist MFD can change switch position, so mouse click is not enough as a redraw trigger [14:45:49] right [14:46:43] any ideas of how to make the RedrawEvent/MouseEvent more automated? [14:49:56] yes [14:50:29] in the 2D panel most switch redraws are managed in switch rows [14:50:33] it just calls this: MainPanel.DrawRow(id, surf, PanelFlashOn) [14:51:01] an instance of the PanelSwitches class owns all the switch rows of a vessel [14:51:17] and that calls the DrawRow function for all switch rows [14:51:43] and SwitchRow::DrawRow then calls the DrawSwitch functions of all switches it owns [14:52:47] so we probably need DrawRowVC functions in both these classes [15:01:47] right [15:03:31] one thing though is right now I handle the animation outside the switch class, animating it case by case [15:03:53] but I guess ideally it should be animated directly in the switch class? [15:08:47] probably? [15:11:59] I guess like you say, in DrawRowVC [15:20:28] hmm, my VHF marks weren't all that good it seems [15:21:18] didn't really get a good CDH solution [15:22:53] must be the initial state vectors being off or so [15:25:36] is there any limitation on the marking [15:25:46] as far as deltas [15:26:20] I know when I didnt do a P76, I used a few sextant marks to supplement the VHF and it worked nicely [15:26:36] well the first limit is internally, it won't show the 06 49 if the mark is good enough [15:26:55] I think I have seen some numbers for manual accept or reject [15:27:31] for a bit I thought updating the CSM state vector makes sense, as the CSM is doing the maneuvers [15:28:27] ah I think that is it. I screwed up my CSM state vector a bit doing that, then I uplinked a new LM state vector, but then did more marks for LM state vector update [15:28:45] so CSM state vector stayed bad [15:32:20] ahh [15:32:46] I also have higher range rates than during a usual rendezvous [15:33:52] Yeah thats what i means by deltas haha [15:33:55] meant* [15:34:02] ah, I thought the N49s [15:34:15] yeah poor context on my part lol [15:34:27] I was thinking higher rates could be the issue with vhf only marking [15:37:31] 1800 ft/s seems to be a limit [15:37:40] I didn't have rates THAT high [15:38:06] maybe the CMC accounts for a delay we don't have in the system [15:41:24] or maybe I just don't have enough practice :D [15:55:13] Hmm I guess I am jettisoning the LM before AOS lol [15:56:13] Sticking to the FP I will jettison 6 minutes before AOS instead of 3 minutes after [16:03:26] so I added a RedrawVC ToggleSwitch class and put the animation logic there [16:04:20] 3 minutes before instead of 3 minutes after* [16:04:21] and then call the function overloaded with the animation itself from the clbkVCRedrawEvent [16:04:26] https://www.dropbox.com/s/at1ykwwq0hnsyw6/Screenshot%202020-05-11%2010.03.35.png?dl=0 [16:05:59] not exactly the way you described, but cleaner [16:07:53] I can eventually send some flags to the RedrawVC to specify more complex animations [16:15:57] That VC should be interesting! [16:17:26] its a long way to go, but at least I have some framework laid down [16:21:02] Ohh nice, on LM jettison, even though I do it before AOS, when AOS is hit the actual LM SBD angles got an auto track right at earthrise [16:21:18] Always nice to see those actual numbers work [16:33:49] Ok homeward bound on this checklist finally [16:34:23] Then I will debug the LM ECS a bit more and once thats better this save breaking patch will be ready ;) [16:45:17] nice [16:46:33] just realized right mouse clicks cant be used in the VC [16:52:20] but its quite easy to add a check for the left mouse button click location and I can use the already present sideways bool as well [16:53:09] ok got threeposswitch working in the VC [16:53:29] and should be compatible with sideways [16:54:03] morning! [16:54:11] hey Mike [16:58:30] what's up? [17:00:23] more VC work, now have 3-position switches working [17:00:30] nice! :D [18:04:50] Hmm is the TEI pad supposed to have SPS P&Y as zero? [18:11:15] yes [18:11:26] the CSM alone has a perfect CoG [18:11:44] in NASSP at least [18:15:47] Ahh ok [18:15:57] Its been a while since I have been CSM alone [19:48:28] hmm [19:48:38] having trouble accessing the vessel animations from RotationalSwitch class [19:49:06] https://www.dropbox.com/s/l215f54hgtnoygu/Screenshot%202020-05-11%2012.58.12.png?dl=0 [19:49:55] seems like the OurVessel-> pointer is failing, but that is weird since there is identical code in ToggleSwitch class and that works [20:04:27] well if I initialize the damn thing 1st it works :D [20:04:57] Haha [23:53:35] Speaking of pointer initialization, I found out the Fun way today that on ARM platforms, the processor will reorder memory accesses according to pipeline conditions, so even if you initialize a pointer first and use it after, the processor may decide to reorder the operations to put the access before the initialization. [23:53:49] Or in my case, the access before the offset. [23:54:29] There's a specific instruction you have to ensure gets executed to flush the pipeline before you do anything order-dependent, which means taking a speed penalty. [23:54:43] The "correct" answer: "Don't do that." [00:43:40] good old dsb() [00:44:35] or I guess dmb would work for that too? [01:37:01] oh interesting [01:37:08] DPS force is different in Sundance [01:44:17] Luminary 69 specifies it as 9817.5 lbs [01:44:29] in Sundance it is 9710 lbs [01:45:14] is that a LM-3 to LM-4 difference? [02:22:26] got the rotaries done on panel 3 [02:22:28] https://www.dropbox.com/s/kxji61wd8ttoq0q/Screenshot%202020-05-11%2020.21.34.png?dl=0 [02:25:44] Suzuran, and I spent quite a few hours scratching my head before finding that missing init, lol [02:27:28] AlexB_88: Looking good. Do they actually "pull" when you rotate them? [02:28:01] AlexB_88: And yeah, that stuff's annoying, doubly so because building in debug mode initializes memory to 0 and masks failure to init (if you init to null) [02:28:47] no pulling yet, I have them function like the 2d versions right now [02:29:11] right click: move right, left click: move left [02:32:22] night! [05:57:21] FAPS is also different [05:59:47] ah, only slightly though, they rounded up instead of down [06:00:05] 3499.8256lbs instead of Luminary's 3500lbs [14:41:55] hey [14:43:35] hey Alex [14:44:29] https://www.dropbox.com/s/l215f54hgtnoygu/Screenshot%202020-05-11%2012.58.12.png?dl=0 [14:44:51] got some working rotaries on panel 3 [14:45:25] lol [14:45:34] I should really check the link before posting it [14:46:04] https://www.dropbox.com/s/kxji61wd8ttoq0q/Screenshot%202020-05-11%2020.21.34.png?dl=0 [14:46:16] nice :D [14:48:26] next thing to learn is redrawing panel textures [14:48:30] I guess some code must be kept separate from the 2D panel implementation [14:48:43] or else you would need to implement everything all at once [14:49:50] in clbkVCMouseEvent, is it special code for every single switch right now? [14:50:15] yes for now it is [14:50:38] I am not really sure of how to go about making it more compact [14:51:23] but I guess if I dont find a way then those could get very big lol [14:51:47] yeah [14:51:54] I'll switch to your branch and look at the code [14:51:58] maybe I can come up with something [14:51:59] ok [14:52:18] give a few seconds Ill push my latest [14:52:37] ok [14:53:44] I'm thinking about implementing the Vector Comparison Display. It does what it says, it's to compare state vectors. [14:53:49] done [14:53:59] oh nice [14:54:00] mainly ephemeris anchor vector to a potential new update vector [14:54:11] I actually found the display they used [14:54:14] for Shuttle [14:54:16] circa 1980 [14:54:27] should be pretty close to what they had during Apollo [14:54:37] even the MED code is the same :D [14:55:11] and what I really want to do with it is to be able to tell how good the state vectors in the AGC are [14:55:31] you have four columns, so you can compare up to 4 state vectors [14:55:44] one base vector, e.g. your current, actual state vector [14:55:52] and then the one in the AGC for comparison [14:56:37] that's how they checked that an uplinked SV is any good [14:57:59] sounds useful [14:58:17] and you could verify P23 accuracy [14:58:18] yeah, even for us haha [14:58:35] FIDO also always looked at it before commiting to a trajectory update with a new tracking vector [14:59:25] I guess I mainly need to implement "downlink" of the permanent state vector [14:59:27] from the AGC [14:59:44] won't work during powered flight, but should be valid otherwise [15:04:11] ok there is a new panel area system for the VC [15:04:18] which probably can't be avoided [15:04:30] have to look at the DG, how it handles that [15:05:41] hardly any panel areas [15:09:24] it's one switch per VC panel area? [15:10:07] well I think that is needed since every switch click area is tied to a panel area it seems [15:11:22] was just wondering, although I wouldn't have expected it to be different than the 2D panel [15:13:13] the oapiVCSetAreaClickmode_Spherical has to reference the same switch identifier registered with oapiVCRegisterArea [15:13:54] might be better any way [15:14:06] but that doesnt need to be an AID_... I guess, it could be something else, and the AID's kept for clusters of switches? [15:14:58] no idea [15:16:04] what I am thinking right now is to associated a switch with its panel area ID in RegisterActiveAreas [15:16:09] associate* [15:17:12] how is the position of a switch even defined right now? [15:18:25] P3_DIAL_POS? [15:18:26] its physically in the mesh, and the click spot with [15:18:27] oapiVCSetAreaClickmode_Spherical [15:18:29] yes [15:22:01] P3_DIAL_POS that defines the center of the active area [15:45:22] ok I have something [15:45:35] I mean, you still have to have a line of code for every switch [15:45:43] that associates it with the panel ID [15:46:55] im all ears [15:47:43] I'm almost at the testing stage [15:47:53] ok [15:51:25] btw, AID_SWITCH_P3_01 right now is tied to EDLGDeploy, that is wrong I was just testing something [15:51:42] should be EngGimbalEnableSwitch [15:53:06] oh ok [15:53:12] that would have screwed my first test :D [15:53:19] haha sorry [15:53:20] although I'll first try it without my changes [15:53:49] what I have is nothing fancy, the switches just get managed [15:54:00] ok [15:54:10] in clbkVCMouseEvent and clbkVCRedrawEvent it just calls a function [15:54:21] the switch mesh you see is also very much unfinished, just a test mesh I was using [15:54:28] and nothing will have to get added there, ever [15:54:51] in RegisterActiveAreas I have something like this: [15:54:56] MainPanelVC.AddSwitch(&EDLGDeploy, AID_SWITCH_P3_01, &anim_P3switch[0]); [15:55:03] and every switch will need this line [15:55:10] but only this one line [15:55:19] ah makes sense [15:57:00] so I should fix EDLGDeploy.ProcessMouseVC etc. to EngGimbalEnableSwitch [15:57:28] yes [15:57:46] ok, will do a before and after test now [15:57:51] should be exactly the same [15:58:00] well, that switch will eventually be there [15:58:14] but there is no mesh for it yet [15:58:28] how do you rotate rotational switches clockwise? [15:58:33] right click [15:58:39] oh [15:58:45] I thought that wasn't going to work? [15:58:54] I thought too but I was wrong [15:59:24] oapiVCRegisterPanelArea, there you can define any type of mouse action [16:00:35] PANEL_MOUSE_DOWN means both mouse buttons are active [16:01:10] before test was good, now let's see if my system works [16:01:52] it does [16:04:22] https://github.com/indy91/NASSP/commit/da12070da8fd111786af9e88968ab489c36ad1f5 [16:04:26] if you want to look at it [16:05:43] you can switch to that branch to see, or I can PR it if you trust me with VC code :D [16:05:53] looks great [16:06:21] I was trying to have something like this yesterday but I couldnt wrap my head around it [16:06:23] thanks [16:06:52] no problem [16:08:23] I guess clbkVCMouseEvent/clbkVCRedrawEvent can still be directly used but only for very special cases? [16:15:37] yes [16:15:48] I guess that's the same for the 2D panel [16:16:08] most switches are handled with the MainPanel call, but there are a bunch of special cases [16:16:19] just have to be put before that MainPanelVC thing [16:16:26] because that is a return [16:16:40] right [16:17:36] I guess you'll PR this to my branch? [16:22:21] can do [16:29:35] done [16:29:40] alos, I can add RedrawVC/ProcessMouseVC to further switch classes and they will be accessed with the new function? [16:29:44] thanks [16:30:44] merged [16:37:05] yes, should be [16:37:22] the base class of them, PanelSwitchItem, now has those functions [16:37:33] and every class derived from that will overload them [16:38:00] oh gotcha [16:39:02] so RegisterActiveAreas along with all the add switches will be recalled at staging btw [16:39:09] from LoadVC() [16:39:42] that is needed for the new height offset for each call of oapiVCSetAreaClickmode_Spherical [16:40:09] but I am wondering if its bad to call all the MainPanel.AddSwitch... all over again [16:41:38] good point [16:41:52] yeah that's probably really bad [16:42:11] well [16:42:16] it's not broken or anything [16:42:23] what I am thinking is making the addswitches in its own function, called once from clbkLoadVC [16:42:26] it will just have the list of switches twice [16:42:51] sounds good [16:43:05] taht should take care of it [16:43:15] or not [16:43:21] clbkLoadVC [16:43:26] Called when Orbiter tries to switch the cockpit view to a 3-D virtual cockpit mode (for example in response to the user switching cockpit modes with F8). [16:43:36] oh right lol [16:43:42] postcreation? [16:44:12] clbkPostCreation()* [16:45:07] the anim_P3switch etc. are constants, right? [16:45:11] or do they change as well [16:45:43] also, I am pretty sure that's what we are doing in the 2D panel already [16:46:07] calling a bunch of extra stuff [16:46:08] thoe get initialized and dont change I think [16:46:16] yeah, Init and Register is separate [16:47:10] in any case it's probably best to have a function that clears the list of switches before the AddSwitches are done [16:47:48] wait a moment, it's in clbkLoadVC already [16:48:04] clbkLoadVC calls LoadVC, LoadVC calls RegisterActiveAreas [16:49:37] morning! [16:50:28] the DG registers panel areas in clbkLoadVC. Might not be the most efficient way, but it's ok I guess. There just needs to be a function that clears the switch list. I'll add and PR it [16:50:30] hey Mike [16:50:52] what's up? [16:51:06] assisting Alex a bit with his VC work [16:51:22] hey Mike [16:51:36] nice :D [16:52:53] we'll see if that is causing bad delay when switching to the VC [16:52:56] can always be moved [16:53:26] I wonder if LoadVC() should even be in clbkLoadVC at all...it really only needs to be called at init and staging [16:53:37] yeah [16:53:49] well, it can be moved as a block I guess, when we come up with something better [16:55:30] new PR is up [16:56:53] merged, thanks [16:57:06] so with that we can leave the functions as they are for now I guess [16:58:32] that is safe code now at least [16:58:45] no matter how often RegisterActiveAreas is called [16:59:04] I am thinking though, maybe Ill move LoadVC() out of clbkLoadVC now [16:59:19] since now it would be called at very camera change [16:59:30] doesnt sound efficient [17:00:30] Im thinking of having it once in clbkPostCreation() and once at staging [17:00:54] you mean from one 3D panel camera position to another [17:01:12] yeah [17:01:29] yeah the switches should always be accessible [17:03:47] I'm pretty sure that's what the DG does as well though [17:04:56] I'll test that [17:05:15] if the clbkLoadVC function of all panel elements it has is called when you switch seats [17:06:15] I tried transferring it to clbkPostCreation() but that didnt work [17:07:21] hmm [17:07:29] the DG HUD control has this: [17:07:30] if (vcid != 0) return false; [17:07:43] it only reloads it if you switch to the pilot position [17:08:25] I think it would be good to leave the code in clbkLoadVC, but maybe put something different in place so that they aren't loaded multiple times [17:08:59] ok [17:09:04] there could even be a check to MainPanelVC [17:09:13] if it already has added the switches [17:09:18] and if yes it won't do it again [17:09:41] do you also want to move the oapiVCRegisterArea? [17:13:10] I can yes [17:14:09] you mean out of RegisterActiveAreas? [17:14:22] yeah, was just asking if that is what you were trying to do [17:14:28] or only my new code [17:15:34] well, I was thinking of making all the MainPanelVC stuff in its own function, but now with the latest PR, it seems we can keep them together [17:18:08] it's still getting called on every panel switch [17:18:19] or camera switch [17:18:38] but it was bad code without the clear function [17:18:46] now it's inefficient at best [17:22:03] at worst* [17:23:40] yeah [17:24:03] once we need to separate them it should be easy to do I guess [17:41:36] making the switch meshes right now [17:42:00] hopefully by tonight I will have all the main panel switches and rotaries in place [17:43:00] right now I am looking up proper switch size & shape [17:43:36] might have to use some photos to jusge it [17:43:49] I dont know if the exact switch specs are detailed anywhere [17:44:31] hmm [17:44:54] the answer is probably again: not yet? [17:45:25] right [17:48:38] maybe we can find a drawing number [17:48:46] then we will know if we already have switches or so [17:51:19] perks up [17:51:22] drawing number you say? :D [17:52:22] specification for switches used in the Lunar Module [18:02:05] ah, no, we don't have them, and won't for quite a while unfortunately [18:02:19] those would be LSC-xxx-xxxx drawings, more than likely [18:08:17] hmmmm [18:08:23] but I'm having a hard time finding a drawing number [18:11:03] same [18:11:21] oh wait [18:11:39] I got the level III drawing of the displays and controls subsystem from NARA a couple of years ago [18:11:45] that will have it [18:12:00] if I can find it [18:13:34] found part numbers for CSM switches :D [18:14:46] found specification numbers [18:15:01] LSP-350-802 for toggle switch? [18:15:07] what's that type of number [18:15:27] not sure about LSP, I think that will be more of a worded specification than a drawing [18:16:00] LSC350-81-00111 SW, SHAFT/TRUNNION [18:16:13] er [18:16:18] LSC350-82-00111 SW, SHAFT/TRUNNION [18:16:30] LSC-81-02112 SW, MODE/SELECT [18:16:36] wow I can't type ttoday [18:16:42] LSC350-81-02112 SW, MODE/SELECT [18:18:38] LSC350-81-02112 is a three position switch then [18:18:56] LSC350-82-00111 is toggle [18:19:37] those should both be the commonly used type, not a special version of it [18:21:02] both would be probably be in box 676 [18:21:17] Ron has so far scanned only 502 through 523 [18:22:17] so about 2022 [18:22:30] lol, yeah [18:22:41] depending on when NARA reopens [18:23:13] and I'm not helping considering I now want a couple of thousand pages of Sundance documentation that NARA has [18:23:28] between the missing GSOP sections and the Functional Description and Operation manual [18:23:45] I'm happy to postpone any RTCC documents for Sundance :D [18:23:54] hahaha thanks :D [18:26:55] ok back to Orbiter2016 branch, I wanted to steal some state vectors from the AGC today [18:28:48] the addresses of the permanent state vectors seem pretty stable [18:29:47] I may already know those addresses in Sundance [18:29:58] what are they named? [18:30:13] RRECTCSM and RRECTLEM [18:30:18] starting with them at least [18:30:33] E3,1554 and E3,1626 wherever I have checked so far [18:31:22] makes things easier, no AGC software specific handling [18:32:06] I haven't come across those in Sundance yet [18:32:16] but TETCSM and TETLEM are in the same places, which I think is a good sign? [18:32:20] yeah [18:32:26] it will be the same everywhere [18:32:33] would be annoying to handle otherwise [18:32:39] I'm sure Sunburst is different [18:32:47] but it has a different uplink format for SVs anyway [18:32:57] heh yeah [18:33:28] it doesn't even use the basic reference coordinate system [18:33:41] so no REFSMMAT [18:33:56] coordinate system is the IMU alignment [18:34:06] like the AEA [18:34:44] early revs of Sundance would be really interesting to see [18:34:50] when they were first switching this stuff over [18:35:04] Sundance, while different in a lot of ways, is already very Luminary-like [18:35:14] that is, the manufactured versions are [18:35:15] yeah [18:35:34] more than Sundisk and Colossus I think [18:35:41] Sundisk has a bunch of noun differences [18:36:13] and program differences, like a delta time from TPI to TPF in the rendezvous programs instead of an angle [18:36:29] first thing we noticed when studying the Apollo 7 rendezvous procedures [18:37:04] ok, Sundance also has a lot of noun differences [18:37:17] and differences in rendezvous programs. They are all different :D [18:40:38] I'll make no further definitive statements about Sundance [18:48:19] and I guess I need CMOONFLG and LMOONFLG [18:48:50] and SURFFLAG [18:58:05] MoonFlag = (vagc->Erasable[0][0104] & (1 << 13)); to check bit 12 of flagword 8 I think? [18:58:56] ugh, flaky work vpn made me miss some of your messages and it looks like you didn't get any of mine [19:00:11] damn [19:00:16] okay so [19:00:21] "that is, the manufactured versions are" is the last I got [19:00:46] I was mostly being snarky about your definitive Sundance statements lol [19:01:19] and also saying that I should be able to fully finish module 6 in the next couple of days, and that I'll probably do module 2 next unless there's something interesting to be learned from other modules [19:01:50] also I think your code should be: [19:02:00] MoonFlag = (vagc->Erasable[0][0104] & (1 << 11)); [19:02:05] to check bit 12, right [19:02:10] because (1 << 0) would get you bit 1 [19:02:25] (1 << 1) for bit 2, etc. [19:02:35] unless the data is stored shifted [19:02:57] it's been too long since I've looked at that, haha [19:03:16] flagwords are definitely at the same spot in Sundance, there's just less of them [19:03:31] what became flagwords 9 and 10 still have a lot of the same functions, but they are elsewhere in memory [19:03:36] yes I added 1 where I should have subtracted 1 from bit 12 [19:04:07] yeah I'll check on the flags in all the AGC versions next [19:04:15] hopefully it's always bits 11 and 12 of flag 8 [19:04:54] my favourite check is Colossus 237 versus Luminary 210 [19:05:11] if it's the same in those two there is usually a good chance it's the same address anywhere [19:05:45] MOONFLAG is the same at least [19:05:48] and lol yeah that is a good check :D [19:06:20] oh that reminds me, I think I found the name of FLGWRD10 in some luminary memo [19:06:21] I think I need CMOONFLG and LMOONFLG though [19:06:24] what was it... [19:06:30] not MOONFLAG [19:06:30] haven't found references to those yet [19:08:12] FLGWRD11 was LRSTAT originally [19:08:48] is there enough reserved space for flagwords? [19:08:57] or did they have to push things around after Sundance [19:09:09] that is a great question, and I don't know yet [19:09:53] no references yet to anything in those addresses I guess [19:10:08] DSEXIT and INTBIT15 are at addresses 114 and 115 still, which is a good sign that they reserved it [19:10:11] but yeah [19:11:10] oh this flag that I've been seeing in BURNBABY was called GIMBFLG, not GIMBLFLG [19:11:13] will have to fix that [19:12:16] is GIMBLFLG already too long? [19:12:26] no, it's just incorrect, haha [19:12:34] I pulled that from the systems handbook [19:12:40] what's the limit on that anyway? [19:12:48] 8 characters [19:13:22] oh, RASFLAG [19:13:23] leads to weird names sometimes [19:13:29] I think that is what became FLGWRD10 [19:13:39] oh you were talking about thrust values yesterday [19:13:59] DPS was quite different than normally, right? [19:14:28] was it FDPS? [19:14:34] yeah [19:14:42] FAPS, FRCS2, and FRCS4 are all slightly different [19:14:46] but FDPS is quite different [19:16:30] Sundance has the value that looks more normal [19:16:40] 92.5% of 10500 lbf is 9712.5 [19:16:48] oh really? [19:16:49] huh [19:16:53] the later value is 93.5% [19:17:18] what's that used in.... [19:18:35] even for the P30 calculation [19:19:39] actually quite a relevant difference in the RTCC calculations [19:20:09] as you need to consider both actual and onboard thrust value for thrust direction calculations [19:20:41] RTCC system parameter MCTDT9 needs to be different for Apollo 9 then, at some point :D [19:21:01] I wonder why they use a high estimate there though [19:21:18] it might be closer to the thrust after a descent abort [19:21:37] thrust increases and specific impulse decreases due to DPS throat erosion [19:21:57] I feel like I have read a Luminary memo about this [19:22:34] https://www.ibiblio.org/apollo/Documents/LUM47_text.pdf [19:22:54] they take the average thrust value [19:26:00] yay, got the state vector scaling on the first try [19:36:25] https://iss-sim.spacex.com/ [19:45:46] nice! [19:46:03] and good find on that Luminary memo :D [19:55:36] find in my brain, as I had of course read it before [20:04:06] and this docking simulator is neat :) [20:04:55] yeah [20:04:59] too easy though [20:05:03] lol yeah [20:05:08] success! [20:09:10] https://www.dropbox.com/s/al34uxnhq7pj69n/Screenshot%202020-05-12%2014.08.46.png?dl=0 [20:09:23] referncing this pic [20:09:25] https://www.hq.nasa.gov/alsj/a16/LM11-co47.jpg [20:10:03] nice work [20:10:25] nice! :D [20:42:15] the RR slew switch might be a special case [20:42:26] since I have to send it 2 animation pointers [20:43:26] it's a FivePosSwitch [20:43:35] so different anyway [20:43:53] I guess you need to work out the logic for that switch type [20:44:09] yeah [20:44:32] it's the only switch of that type, so that does make it a special case haha [20:45:04] I mean I dont think Ill be able to use the normal MainPanelVC route to send the animations [20:45:35] unless you can already send more then 1 with that? [20:46:07] no just 1 [20:46:29] is it really two animations? [20:46:43] but yeah, like you said its the only switch like that so Ill just have a special case for it [20:47:23] well, it has 2 move on 2 axis [20:47:36] it has to* [20:48:31] an animation is to rotate a mesh around an axis? [20:49:25] a mesh group yeah [20:49:35] right [20:49:38] and one animation can depend on another [20:50:32] like the antennas they have multiple animations relying on each other [20:50:41] but for the slew switch I think I can make them separate [20:51:39] I do think that the animation UINT should be rather given to the switch class in some way [20:53:44] the MainPanelVC thing shouldn't have to deal with it [20:54:23] but I guess that would mean to have at least one more line of code for every switch [20:57:40] are you talking still about the slew switch? [20:58:00] yes [20:58:07] well, in general I guess [20:58:26] but there probably should be an Init function in the switch classes [20:58:42] an Init function that takes VC parameters like the animation definition [20:58:52] animation handle I guess [21:00:21] right [21:07:29] night! [12:43:48] good afternoon [12:44:06] I merged n7275's PR that has the higher LM steerable antenna rates [12:44:54] oh nice [12:45:07] I'll swing back and see how it does on ascent [12:50:37] Yep tracks it [12:50:44] no LOS on pitchover [12:52:24] great [12:53:37] R and SBD both track nicely on ascent [12:53:39] RR [13:02:56] Hmm curious about a post TEI step on the 11 FP [13:02:57] PITCH DOWN TO ACQ MSFN AND VISUALLY ACQ MOON [13:03:07] Wouldnt it be pitch up from TEI attitude? [13:04:38] Also another DAP update post TEI [13:05:23] just after TEI: [13:05:24] 135:29:18 Collins (onboard): I'm going to go to SCS and pitch up in the meantime. [13:05:29] before AOS [13:06:04] and the astronautd are equally confused about the DAP update [13:06:12] 135:29:33 Armstrong (onboard): Okay, we're in P00, now who wants what? Verb 48? [13:06:21] 135:29:35 Aldrin (onboard): No - yes. Verb - oh, okay. [13:06:25] 135:29:38 Armstrong (onboard): Ah... [13:06:31] 135:29:40 Aldrin (onboard): I don't know [garble]... [13:06:35] 135:29:41 Armstrong (onboard): Well, it says change spacecraft weight. [13:08:41] how can you update the weight without MCC-h [13:08:45] MCC-H* [13:08:57] Well they end up getting a DAP update from MCC [13:09:12] And yeah I thought the pitch was wrong [13:09:52] But the dap update is after the PTC REFSMMAT uplink [13:10:12] ah ok [13:10:32] 136:21:54 Duke: 11, Houston. We have a DAP CSM update for you. [13:10:50] 135:47:24 Duke: Apollo 11, Houston. Would you give us P00 and Accept? We've got a REFSMMAT for you. Over. [Pause.] [13:10:58] So quite a bit later than the FP lol [13:12:44] If you wanted to add it you could put it with the PTC REFSMMAT uplink for convenience [13:14:11] I have a different version of the flight plan with handwritten changes [13:14:31] I have so many Apollo 11 flight plan versions... [13:14:34] Haha [13:14:51] I am using the final flight plan but yeah a lot of differences I am tweaking [13:17:00] I think the NARA version is the best [13:17:06] check the TEI page in there [13:17:07] https://catalog.archives.gov/id/117677443 [13:17:38] has all the revisions that are not in the usual copies [13:18:03] https://catalog.archives.gov/catalogmedia/lz/fort-worth/rg-255/573157/117677443_Apollo11FlightPlan.pdf [13:18:07] for the direct download link [13:22:51] Nice [13:30:12] other MFDs seem to be able to scale their text better than the RTCC MFD, weird [13:30:21] when I open it in an external MFD [13:33:46] Wonder why [13:34:06] most MFDs use an outdated system that the Orbiter API says not to use anymore [13:38:41] figured lol [13:38:43] figures [13:40:01] have to play around with the font [13:40:22] I'm using greek letters now that you can't see on the tiny MFD very well [13:40:33] So I wanted to look at it in large, using the external MFD [13:40:51] but especially longer strings like GETs are now too large horizontally [13:46:13] hey [13:47:15] Morning [13:48:48] got all panel 3 switches done [13:48:50] https://www.dropbox.com/s/flmmjt5hhj0qfqf/Screenshot%202020-05-12%2019.38.42.png?dl=0 [13:49:09] how did you end up doing the RR slew one? [13:49:34] havent done it yet [13:49:57] so I lied haha, all the panel 3 switches done except 1 :D [13:50:05] still awesome haha [13:50:20] but I think Ill have a special case for it [13:50:49] oh btw, I discovered something about the VC switches [13:52:26] the method I am using to get the clickspot (oapiVCSetAreaClickmode_Spherical) only sends the distance from center of the active area for the mouse event [13:53:45] so that means you cant really define the direction relative from center of your click, say if you want to click on the top side of it or the bottom side to have a different effect [13:54:21] for taht I would need to use another Clickmode (Quadrilateral) [13:54:42] right [13:54:58] which defines 4 points around the switch instead of 1 [13:55:11] but [13:56:16] there other solution is keep the mode I have now, and add use of the right mouse button as well for VC switches [13:57:54] and that is what I have done already in my copy, which I think is the best way since defining 4 points per switch for every switch in the LM and eventually CSM, well that is a LOT of points to define lol [13:59:59] hmm [14:00:06] SSU has a smart solution [14:00:17] it does use oapiVCSetAreaClickmode_Quadrilateral [14:00:35] but defines that (flat I guess) area for a whole panel [14:00:46] and then each switch is just 2D coordinates [14:00:59] which needs 4 numbers only [14:01:12] oh interesting [14:02:17] hmm [14:03:48] it also sets a reference of sorts [14:04:50] so a few numbers more I guess [14:08:25] ill take a looj [14:08:28] look* [14:08:51] where in SSU code did you see this? [14:09:14] ah I think I found it [14:09:36] each panel is its own class there [14:17:34] so I could make all of panel 3 a big click area [14:18:01] and send the 2D switch coordinates along with the AddSwitch calls I guess [14:18:53] and then code in ToggleSwitch to check that the mouse click is within bounds (same as it does for the 2D panels) [14:19:08] yeah, it's probably more like the 2D panel then [14:19:20] https://i.imgur.com/lnRH9aL.png [14:19:35] oh nice [14:19:52] scaled up like this it actually does look nice haha [14:20:14] 4 columns, the first one has the base vector, the other ones get compared to the first one [14:20:31] that's a pre PDI day state vector [14:20:41] compared to what's in the CMC for the CSM [14:20:52] +0.16° longitude error accumulated since LOI-2 [14:21:00] or the uplink for LOI-2 rather [14:21:27] amounts to 3NM downrange, that's the V further down [14:21:55] if you just have uplinked a new SV it's nearly all zero as expected [14:22:25] the largest errors are after Earth launch, oblate vs. spherical Earth in P11 [14:27:48] right now this can only do CSM actual state vector vs. CSM in the CMC, and LM actual vs. LM in the LGC. [14:30:18] but I want this to be able to handle all combinations of AGC state vectors, actual current state vectors and, in MPT mode, interpolated ephemeris vectors [14:30:33] and AGS and IU I guess eventually [15:25:41] I think to day Ill take a break from switches and start looking at dynamic texture loading on VC panels [15:25:46] today* [15:27:00] but before that I tried something for the quadrilateral click method, but with not much lucl [15:27:07] luck* [15:29:00] I can make myself familiar with that as well when I have this display done [15:29:12] ok [15:29:23] no rush [15:31:10] the way I am imagining it is making it like the 2D panels, where you send the top left corner x, y and then the width/height of the clcik area [15:31:48] and then put checks on p.x & p.y in the ToggleSwitch code [15:32:16] yeah, that would be nice [15:32:37] like there is with the 2D panels [15:32:38] like [15:32:39] if (p.x < xp || p.y < yp) [15:32:40] return false; [15:32:40] if (p.x > xp + w || p.y > yp + h) [15:32:41] return false; [15:33:02] w being width and h being height [15:33:33] and each switch type could have a pre-defined width and height [15:34:06] so taht would make it quite easy to add new switches since you only need to figure out the top left corner [15:37:56] yeah [15:42:24] hmm [15:42:56] well I still need to define the pivot point of each switch [15:43:05] so its not really making it less work [15:44:41] right now the pivot point is used as the Spherical click location as well [16:45:03] morning! [16:56:21] hey Mike [17:07:42] what's up? [17:09:55] getting some results with my new display: https://i.imgur.com/lnRH9aL.png [17:10:08] this is actual state vector compared to the CSM state vector in the CMC [17:10:21] at the beginning of PDI day, so an older CMC state vector [17:10:26] ooooh nice [17:10:50] and I was not quite using the right method to get the state vector from the AGCs [17:11:13] I was using the recified state vector together with the current state vector time [17:11:30] but the AGC doesn't exactly keep a current state vector around [17:11:32] http://www.ibiblio.org/apollo/listings/Luminary099/LEM_GEOMETRY.agc.html [17:11:38] here is what it does for telemetry [17:11:48] THESE TWO ROUTINES COMPUTE THE ACTUAL STATE VECTOR FOR LM,CSM BY ADDING [17:11:48] 013459,000043: # THE CONIC R,V AND THE DEVIATIONS R,V [17:13:19] ah, interesting [17:13:55] does this have to be explicitly run, or does it periodically do this for downlink? [17:17:09] indy91, any reason why LEMLoadMeshes() in lemmesh.cpp is a extern void? [17:17:55] hLMVC is a meshhandle that I need to make available globally [17:18:09] to access the VC texture in it for repainting [17:18:34] AlexB_88, I'll check later [17:19:03] right now is a static MESHHANDLE at the top of lemmesh.cpp [17:19:05] sounds good [17:19:07] thewonderidiot, not sure how often it does that, but that's how it assembles the state vector for downlink [17:19:34] that's basically the method I use in the RTCC MFD to store state vectors on every integration step [17:19:55] I don't want to access those downlink state vectors, the addresses changed all the time [17:20:33] right right [17:20:36] my simple temporary solutions: [17:20:49] the AGC also stores the time since the last rectification [17:21:09] so I use that state vector and subtract the time from the current state vector time [17:21:21] that gets me a slightly outdated SV from the AGC [17:21:28] but it's a valid one, with the right time tag [17:21:37] I could do it the same as that downlink routine [17:21:51] add conic state vector and deviations together [17:21:55] might be the better way [17:22:11] if I uplink a new state vector then the deviations get reset to 0 [17:22:30] so I at first got really bad results due to a wrong time tag [17:22:41] and then perfect results when I uplinked a new one [17:23:00] so I thought: it can't be THAT bad due to an older state vector :D [17:23:46] hehehe [17:30:43] hmm I think the entry target load is quite early [17:33:19] indy91 I am getting the uplink for it when I would have had a non scrubbed MCC6' [17:39:39] rcflyinghokie, that is on purpose [17:39:51] Oh? [17:39:53] you are getting entry lat and long for MCC-6 and MCC-7, scrubbed or not [17:40:01] and MCC-5 [17:40:24] Hmm am I missing it in the FP/transcript? [17:40:50] have to check why I did that, it's been a long time [17:41:02] Just trying to sync it up with the checklist [17:41:22] Looks like they got the entry PAD and a clock update when MCC 6 was scrubbed [17:41:24] and those targets are assuming no further MCC [17:42:39] there is this [17:42:40] 148:33:45 McCandless: Apollo 11, this is Houston. We see you in P00. When you can give us Accept, we have a state vector and target load uplink ready for you. [Long pause.] [17:42:47] but that's earlier [17:43:19] thats MCC5 [17:44:41] thats the P30 load [17:45:34] and entry targets as well [17:45:41] it's a combined format actually [17:45:46] Retrofire External DV Update [17:45:53] TIG, DV, splashdown lat and long [17:46:14] but looking through the transcript, there aren't very many "please go to P00 and accept" [17:46:43] so seems like they didn't get another entry target update until [17:46:46] 190:45:13 Evans: Apollo 11, Houston. Request P00 and Accept, and we'll send you a REFSMMAT, state vector, and entry target load. Over. [17:47:18] that's the MCC-7 update [17:47:22] or would have been [17:47:42] I guess I can delete those updates for MCC-5 and 6 if they were scrubbed [17:48:44] Doesnt hurt I suppose [17:48:57] no SV either? [17:49:06] doesnt look like it, just a clock update [17:49:15] unless they did a SV with ti and didnt say so [17:49:39] 160:00:54 Duke: Hello, Apollo 11. Houston. Would you please give us P00 and Accept? We've got a clock update for you. [Long pause.] [17:49:57] it definitely happened that they sneaked an uplink in [17:50:03] but they did get an entry pad [17:50:09] 159:51:14 Duke: Roger. Copy all that, Neil. And we got an Entry PAD if you're ready to copy. Over. [Long pause.] [17:50:21] Is there a list of uplinks? [17:51:00] I have a good one for Apollo 15 [17:51:10] with uplink format [17:51:19] mission report might have something less detailed [17:52:21] or not [17:52:27] yeah not seeing anything [17:59:29] I'll tell you a few months when I have listened through all of the Apollo 11 GUIDO audio :D [18:01:11] lol fair enough [18:18:24] stupid question [18:18:25] clbkPanelRedrawEvent is overloaded with SURFHANDLE surf, what is surf exactly? [18:18:48] the current used texture? [18:19:47] "and surf is a handle to the dynamic texture to be redrawn." [18:20:17] nevermind then :D [19:09:48] DSKY is working!! [19:10:29] https://www.dropbox.com/s/4a64as5zj7bxiue/Screenshot%202020-05-13%2013.10.16.png?dl=0 [19:11:01] this was a test, still have to tweak the position [19:12:46] wow [19:12:55] how did you manage that?? [19:13:42] I am calling the same function called in the 2D redraw callback [19:14:08] just sending it .DDS versions of the bitmaps [19:15:24] pretty awesome [19:16:00] I was thinking about the DSKY. But I didn't know if it was going to be easier or harder to do it [19:17:12] well it was a nightmare to think about how to make a function that does the oapiBlt for it, but for the VC [19:17:27] but it seems you can just use the same one again! [19:18:09] I literally have identical code in lemvc.cpp as it is in lempanel.cpp [19:19:35] the oapiVCRegisterArea is almost the same as oapiRegisterPanelArea for the 2D panel [19:20:01] except at the end you have to give it a handle to the texture in the mesh itself [19:20:27] and in the mesh file, the texture has to be labeled as dynamic "D" [19:21:05] but the rest in the oapiVCRegisterArea call is the same, with the defining rectangle [19:21:29] oh wow AlexB_88, awesome!! [19:21:59] thanks! [19:22:51] in clbkVCRedrawEvent, I added case AID_VC_DSKY_DISPLAY and then dsky.RenderData(surf, digitaldisp_vc, dsky_disp_vc); [19:24:11] seems fairly straight forward [19:24:15] and that is identical to the call in clbkPanelRedrawEvent, except for the digitaldisp_vc, dsky_disp_vc [19:24:36] those are the DDS's that I converted from the original bmps [19:25:13] and those are loaded in my InitSwitchesVC() function further down ie. oapiLoadTexture("ProjectApollo/VC/digitaldisp.dds" [19:25:36] maybe I need to find something fancier then that for the loading of the source textures [19:27:05] "hLMVC is a meshhandle that I need to make available globally" did you figure that out yet? [19:27:26] well not really [19:27:42] I made a temporary hack so that it works [19:28:19] I moved everything from LEMLoadMeshes() to SetMeshes() [19:28:31] but then LEMSaturn cannot access them [19:28:48] ah the annoying LEMSaturn [19:28:51] for the test I just commented the call from LEMSaturn [19:30:19] hmm, hLMVC is static [19:30:32] meaning that only one instances of it will exist [19:30:52] so if you had two LEMs in a scenario and you draw on it, it would draw the same on any LEM [19:31:32] right [19:34:50] in my test I removed the static [19:35:07] and put hLMVC in the main lem.h [19:35:24] and initialized it to NULL [19:35:37] I guess we should look at SSU once more [19:41:04] is removing the static not enough? [19:46:14] in SSU the mesh handle is part of the Atlantis class [19:55:52] in saturn, all mesh handles are global it seems [20:01:49] and some are extern MESHHANDLE [20:03:49] well the extern MESHANDLE's are the globally accessible ones I guess [20:15:52] so what I have done now is just make it like the saturn class does it, all MESHHANDLE at the top of lemmesh.cpp and added the extern MESHHANDLE in lem.h, seems to work and that makes LEMSaturn work again [20:32:47] if the Saturn class does it then it can't be too bad [20:33:52] works on my tests [20:50:15] great [20:50:24] good night! [23:59:09] DSKY is done [23:59:11] https://www.dropbox.com/s/zjzk04km6qrilal/Screenshot%202020-05-13%2017.58.58.png?dl=0 [00:08:59] awesome! :D [00:09:04] that looks great [13:13:54] good afternoon [13:14:27] hey [13:14:48] hey Alex [13:15:13] managed to rescue Eagle in the CSM rescue case I flew [13:15:30] everything handled the 10x100 orbit well [13:15:52] I had some issues with state vector accuracy, that's why I wanted that vector compare display in the first place :D [13:16:04] cool stuff [13:16:16] never flew a CSM rescue case myself yet [13:16:58] I did an anytime liftoff [13:17:10] liftoff 5 minutes too early [13:17:45] Apollo 11 CMP Solo Book has the list of 18 rescue cases for Apollo 11 [13:17:57] later missions probably simplified procedures a bit [13:20:10] Apollo 17 might be a good mission to try rescue cases, we have the CSM Rescue Book [13:22:10] I have fresh scenarios for 17 too [13:22:50] they definitely do a more normal rendezvous for the early liftoff case [13:22:55] in the Apollo 17 procedures [13:23:37] I guess that liftoff a few minutes early is the case where you have a leaky APS [13:25:56] but what are the insertion parameters for that case [13:26:15] CSI happens when the CSM is below the LM, so it's not the default parameters [13:31:49] got the DSKY & DSKY buttons fully working last night [13:31:52] https://www.dropbox.com/s/zjzk04km6qrilal/Screenshot%202020-05-13%2017.58.58.png?dl=0 [13:32:55] awesome [13:33:34] I also got the radar signal strength meter working [13:35:12] the 2D panel uses GDI tools to draw the needles for the meters [13:35:29] but for the VC, I actually animated a physical needle [13:36:18] makes sense [13:36:54] and I think Ill do that for things like the cross-pointer [13:37:14] I also want to have a 3D animated FDAI [13:38:57] I guess if it's all 3D then it makes sense to simulate them more accurately in that way [13:40:46] and probably better on performance not to have all that GDI stuff running [13:41:49] yeah [13:52:05] Good morning [13:52:19] hey [13:56:16] hey Ryan [14:00:18] Going to try to get to entry today, and then look back at the ECS [14:09:30] reacq works well during PTC I must say [14:10:00] ah nice, hadn't tested that yet [14:26:07] So should I mirror the checklist to the current state of the uplinks or are they going to be changed per the flight plan? [14:27:17] regarding the MCC6 and the loads there [14:28:07] keep it as the uplinks are right now, I think, I first want to do some Apollo 8 and 10 MCC fixes before I get to 11 [14:28:29] No problem [14:29:53] I'll go back through again when those get changed [14:30:26] yeah, or I'll fix it myself when I get there, we will see [14:30:31] in the technical debriefing Neil mentioned that they had a post TEI state vector in their LM SV slot [14:31:51] triple me [14:32:12] uplinked before TEI, so that they could compare how close to planned their TEI was [14:32:26] seems like a fun little thing to do, I can easily implement in the MCC as well [14:35:24] Yeah to check the TEI burn [14:35:40] Then they did a what, V83? [14:36:18] yeah [14:37:00] Buzz also once wanted to try V83 on the lunar surface [14:37:20] I doubt it's really going to hurt anything, but he got told no from MCC-H [14:38:31] Lol [14:39:16] 135:29:58 Collins (onboard): ...RCS monitors checked - (Laughter). Okay, here comes Buzz's baby - Verb 83 - de-dum-de-dum-de-dum. Operator error. [Laughter.] [14:39:48] how can that cause an operator error [14:40:26] Maybe too soon after ending P40 [14:40:32] ACTY light still on maybe [14:40:34] yeah, probably something like that [14:40:38] I like this one [14:40:38] 135:30:22 Aldrin (onboard): Alright, now call the Verb 89 in and see which way that... [14:40:45] 135:30:25 Collins (onboard): Oh, come on, you're not serious. [14:40:58] Haha yeah [14:41:13] you would be able to tell if you are behind or ahead of the planned trajectory :D [14:41:21] Lots of fun commentary here [14:41:22] 135:31:34 Armstrong (onboard): What are you doing, Mike? What you taking pictures of... [14:41:23] 135:31:40 Collins (onboard): Oh, I don't know. Wasting film, I guess. [14:41:46] they were in a good moode pre and post TEI it seems [14:42:14] 135:33:14 Aldrin (onboard): Alright, I've seen enough of Verb 83, Mike... [14:42:15] 135:33:16 Collins (onboard): Here you go. [14:42:16] 135:33:20 Aldrin (onboard): ...unless you want to call a Verb 89. [14:42:16] 135:33:24 Collins (onboard): Not me. I'd rather take pictures. [14:42:58] 135:33:55 Armstrong (onboard): Anybody got any choice greetings they want to make to Houston? [14:47:38] RIP REFSMMAT in the RTCC MFD, so served us well [14:47:43] you* [14:47:53] being replaced by about 20 REFSMMATs in the RTCC class :D [14:50:01] Aww are we sunset on that? [14:51:28] what do you mean by that? [14:51:55] not a native english speaker here :D [14:57:17] Haha sorry [14:57:42] It generally means ending a server or feature [14:58:22] https://en.wikipedia.org/wiki/Server_sunset [14:58:44] But we also use it for features in a product or module [14:58:58] generally means intentionally phasing out [14:59:06] ah ok, now I get it [14:59:30] but yeah, the RTCC was keeping multiple types of REFSMMATs around [14:59:47] current REFSMMAT, previous current, AGS, telemetry, manually input etc. [15:00:00] one table for the CSM one for the LM [15:00:29] I guess this will require a bit more REFSMMAT management, but also gives more capabilities [15:04:45] and I had a feature on the REFSMMAT page where you send the REFSMMAT of the CSM in one MFD to the MFD in the LM [15:04:58] that will no longer be needed as it is all in common memory [15:10:03] tape meters are in [15:11:24] impressive pace [15:14:12] its nice that I can re-use a lot of the 2D panel function to draw the displays [15:14:33] have you thought about CDR and LMP positions and view direction for LPD yet? [15:17:34] the positions are already set for those 2 but minor tweaking probably still needed [15:17:49] the LMP position is already there [15:18:00] ALT-7 I think [15:18:17] don't you move around with CTRL? [15:18:20] and arrow keys [15:18:32] and CTRL + Shift and arrow key to change view direction [15:21:36] I just mean the fixed positions [15:21:40] CSM has a few [15:21:44] LM has 2 right now [15:21:48] CMP and LMP [15:22:11] but I will definetly revise that, add more [15:26:37] but what is doing ALT + 7? [15:28:05] viewpos = LMVIEW_LMP; [15:29:23] I don't think we need any custom code for this [15:29:28] that must be very outdated [15:29:41] yeah its been there for ever I think [15:29:58] we should get rid of that and define them properly [15:33:50] yeah [15:34:08] I also have to figure out how to properly load the VC surfaces [15:35:11] may I should just load them in InitPanel where all the 2D surfaces are loaded [15:35:40] like the srf[SRF_RADAR_TAPE] = oapiCreateSurface (LOADBMP (IDB_RADAR_TAPE)); [15:35:43] etc [15:36:20] but load DDS files [15:36:58] hmm, oapiCreateSurface is just for bitmaps it seems [15:37:58] I can just use oapiLoadTexture directly then [15:39:21] ie. srf[radar_tape_vc] = oapiLoadTexture ("ProjectApollo/VC/lm_range_rate_indicator_scales.dds")); [16:06:13] yep that works [16:07:20] nice [16:12:29] So during PTC, did the crew switch to omni when the SC was between the HGA and Earth? [16:13:14] Or did they just suffer through a little loss [16:21:36] probably switched from MCC-H [16:22:23] Makes sense [16:24:55] we can do that with the telemetry client [16:25:03] might get boring after a while :D [16:28:37] I made a separate enum SurfaceID_VC for the VC surfaces [16:29:12] and a ReleaseSurfacesVC() [16:30:11] Oh imagine the switching on 13 [16:30:12] that way it only release/loads the VC textures when going to the VC [16:38:26] I guess I understand why Omni D was on the same switch as Hi Gain [16:38:51] Never really thought about it until now haha [16:56:13] oh wow yes, because Omni D is on the side unavailable for the HGA [16:56:50] didn't occur to me until now as well [16:56:57] I guess it took auto tracking to realize that [17:04:39] haha yep [17:04:54] morning! [17:05:09] I always thought it was just because they needed more switch positions [17:05:12] Hey Mike [17:05:16] what's up? [17:05:19] But it actually makes sense [17:05:34] Haha just had a eureka moment regarding the antenna switches in the CM lol [17:06:13] hahaha nice [17:06:43] same [17:07:05] I wonder how it was in Block I... [17:10:00] no idea [17:10:21] I'm checking [17:12:02] did block 1 have a HGA [17:12:16] http://heroicrelics.org/info/apollo-4/apollo-4-ctrl-panel/apollo-4-ctrl-panel.jpg [17:14:51] I guess not [17:14:58] only two omni antennas? [17:15:07] at least for S-Band [17:15:17] Yeah upper and lower? [17:15:21] and it did have a mode to automatically choose the one with the higher signal strength [17:15:42] there is just one switch I see, which has the positions Auto, Upper, Lower [17:17:57] Block I had extra C-Band equipment [17:18:42] It was never designed to go beyond LEO correct [17:18:51] yeah [17:18:54] well [17:19:01] Apollo 4 and 6 definitely went below LEO [17:19:04] but not to the Moon [17:19:08] above* [17:20:23] Haha right [17:20:55] And I think all of those flights went below LEO ;) [17:21:09] eventually [17:21:21] I think the word I wanted to use was beyond haha [17:22:05] Haha I know I am just teasing [17:24:26] Hmm I didnt get a go/nogo for MCC7 [17:24:42] Just a uplink with SV, entry target, and entry REFSMMAT [17:25:02] hmm ok [17:25:08] I guess that's the "MCC-7 decision update" [17:25:11] Yeah [17:25:22] Normally it says "has been scrubbed" or something to that effect [17:25:28] Which I use as the checklist trigger [17:25:38] yeah [17:25:42] the code is there for it [17:26:11] https://www.dropbox.com/s/ii65ljyyaec16bv/Screenshot%202020-05-14%2013.25.54.png?dl=0 [17:26:23] oh wait, an uplink? [17:26:29] the decision dosn't come with an uplink [17:26:42] Oh the uplink is before the decision? [17:26:44] that must be the actual MCC-7 update already [17:26:54] I never got a message [17:27:05] MCC-7 decision message should be at EI -6h [17:27:17] MCC-7 update at EI-4:35h [17:27:33] No decision message came up [17:27:38] hmm [17:27:42] Unless it didnt stop time [17:27:52] there only is a message if it was scrubbed [17:28:35] "CSM state vector, entry target, Entry REFSMMAT" [17:28:40] that is what you got? [17:28:45] yeah [17:28:48] so scrubbed [17:29:06] I must have missed the message, I thought they stopped time accel [17:29:18] hmm [17:30:18] I guess they do only with an uplink or pad [17:30:25] checking [17:30:51] it should slow down even with that update type [17:31:46] well the slow down actually happens before it uses that update type [17:32:05] so it doesn't depend on the type [17:32:35] strange [17:32:43] I'll check in an old scenario, what happens there [17:33:41] Sure [17:33:45] bad example [17:33:58] in our old scenarios MCC-7 has to be done [17:34:30] do you have any scenario that is definitely pre EI-6 hours? [17:35:01] and then just check the mission state and increase it until you get to that message again [17:36:08] Yeah hang on [17:36:13] could be that I never tested a case where MCC-7 is scrubbed [17:36:25] Guess I had a damn good MCC5 lol [17:37:07] I get 1.2 ft/s [17:37:12] threshold is 1.0 [17:37:18] so close [17:37:20] Yep [17:37:21] Scrubbed [17:37:26] I also see code that is definitely not right [17:37:32] Want a scn? [17:37:33] sprintf(upDesc, "%s has been scrubbed", manname); [17:37:34] sprintf(upDesc, "CSM state vector, entry target, Entry REFSMMAT"); [17:37:40] it overwrites upDesc [17:37:48] oh wait [17:38:01] that is not even supposed to be the uplink description, but just a message [17:38:11] that is for the actual MCC-7 update [17:38:20] so it should have said that it is scrubbed again [17:38:44] yeah, give me that scenario. And I'll do a quick fix there [17:38:49] Sure [17:39:12] https://www.dropbox.com/s/snm8venw9cbl09s/Apollo%2011%20MCC%20-MCC7.scn?dl=0 [17:39:14] that's definitely a bug at least, the MCC-7 update should have repeated that it was scrubbed [17:39:22] not sure about the decision 1.5 hours earlier [17:39:33] thanks! [17:39:55] This one is pre EI -6 [17:40:03] ah good [17:40:13] Advancing the state gave me the scrubbed message [17:40:34] without an uplink [17:40:56] I get the same [17:41:25] and with the fix I get the scrubbed message again with the uplink [17:41:52] I am surprised I have no MCC7 [17:42:07] your scenario is fun [17:42:18] Lol all sorts of alarms? [17:42:18] I get "interesting" cryo pressures [17:42:22] Yep [17:42:37] and about 60 seconds in the FCs must have been starved of its supply [17:42:43] because everything shuts down [17:42:59] shortly after a MNB Undervolt [17:43:08] https://www.dropbox.com/s/gjhrhs8dry0m8e9/Screenshot%202020-05-14%2013.42.57.png?dl=0 [17:43:17] My cryo state [17:43:55] normal [17:44:12] yep [17:44:29] These changes work well when initialized that way from the beginning lol [17:45:57] All because of a few chemical property changes haha [17:46:00] with battery supports they keep on working for a while [17:46:16] FC3 died very quickly when I turn off battery support for it [17:46:31] after 3 minutes they are completely dried up [17:46:33] Haha I am sure [17:46:46] Thats the one big drawback with my branch [17:47:05] but starting from the beginning it works well, just need to address more stability fixes in the LM [17:47:07] I guess I would do an emergency power down [17:47:16] but it shouldn't be so bad so close to EI [17:47:22] You also dont get drops in temp when cabin fans go off [17:47:30] that's good [17:47:32] Yeah you have full batteries [17:47:53] I am excited for this to be pushed [17:48:08] But I still have more LM work [17:49:22] making valves smaller hopefully does the trick [17:49:39] But I have a lot of ideas jotted down as well from flying the mission [17:51:26] take your time [17:57:17] Yeah I'm in no rush [17:57:44] I'll also be getting the cold rails in there that will help [17:58:02] But getting the temp/press stable is the main goal [18:00:13] got a nice system in so that only the REFSMMATs that have been used are being saved in the scenario. Don't want to save 20 empty ones lol [18:02:29] Oh nice [18:03:20] thewonderidiot, "FIXME: VERY DIFFERENT in Luminary. Scaling change?" [18:03:31] hahaha yes [18:03:44] I'm not even sure it's the same constant, but it's in the right spot for it to be [18:03:55] has to be [18:03:58] it seems weird for it to have changed by that much [18:04:29] hmmmm [18:04:30] or does it [18:05:24] neither Sundance or Luminary have the MDOTDPS in the GSOP where I would have suspected... [18:05:46] what is that even used for [18:06:28] is that only used in P70INIT? [18:07:08] hmm [18:07:10] kinda looks like it [18:07:42] used to find the initial time-to-go for a P70 abort [18:08:13] so naturally Sundance GSOP doesn't have it listed [18:08:20] but that means less than nothing at this point [18:08:33] hehehe [18:08:37] yeah [18:08:56] so it's probably not MDOTDPS, or different scaling for the proto P70 [18:08:58] and who knows what I'll find when I locate what exists already of P70 :D [18:09:27] I made it up to R31 in bank 37 last night before I got stuck [18:09:54] but a Luminary memo pointed out to me that R31 in Sundance has a lot of Colossus-only stuff that ended up getting removed [18:10:04] and sure enough, what I'm looking at is very very similar to Colossus 237 [18:10:32] interesting [18:18:03] wasn't R31 the one that could interfer with P47? [18:18:44] which they had to fix? [18:19:49] or what am I remembering. It wasn't that long that we talked about that :D [18:21:02] oh no that was R04 [18:21:09] well similar [18:21:13] :D [18:23:40] haha [18:23:52] yeah [18:24:17] lol, learning to use Sundance is going to be really interesting, once I have a build going [18:24:37] trying to figure out how it's supposed to be use, and probably troubleshooting problems caused by our mixture of revisions :D [18:38:42] I already used R31 (V83) at the same time as P47 today [18:38:49] CSM active rendezvous [18:38:54] maybe that's why I thought that :D [18:39:25] hehehe [18:53:57] CW lights done [18:54:51] now on to the timers [19:07:04] and done [19:24:05] sweet! [19:42:14] hmm [19:43:28] I think we have a duplication of the call to redraw the 2D panel left x-pointer [19:43:49] in clbkPanelRedrawEvent [19:43:57] there is case AID_XPOINTER [19:44:05] and case AID_XPOINTERCDR [19:44:13] is one for the LMP? [19:44:21] but theu both do the exact same thing [19:44:27] RedrawPanel_XPointer( &crossPointerLeft, surf); [19:44:30] oh [19:44:34] oh the LMP is below it [19:44:35] yep thats CDR side lol [19:45:03] there is 2 redraw requests for just the CDR side [19:45:37] XPOINTER and XPOINTERCDR both have the same commands? [19:45:49] sounds like duplicate to me [19:45:51] there might be a reason I guess [19:45:52] yes [19:46:20] AID_XPOINTER is unused [19:46:48] that call can be deleted I guess [19:46:56] ok [19:47:01] but it's not drawing the same thing twice right now at least :D [19:47:11] yeah [19:47:24] I am working the the VC version of it now [19:56:50] Honeydo list time, catch you guys later! [20:44:51] night! [05:02:59] module B6 is done [05:03:05] on to B2-302 [05:49:18] Sundance 302 does indeed have the PROCEED button [05:49:32] we might be able to tell from addresses if 292 did [06:36:44] oooh interesting it probably did [13:16:24] good afternoon [13:18:29] Morning! [13:18:38] Its entry day haha [13:19:02] I really am realizing compared to how many rendezvous I have flown, I have hardly done entry [13:19:59] luckily it's quite automatic haha [13:20:31] the art is getting everything prepared for it [13:20:53] Yeah those are the procedures I am less famillar with [13:21:08] Its funny, I feel more time crunched during entry than I did on rendezvous [13:21:21] Only because I know those procedures better [13:23:16] one change, not sure when it was done, is that we now have a panel for the 31.7° line in the rendezvous window [13:23:34] so the horizon check can be done in the right attitude [13:23:54] I hope the MCC uses the right pitch angle there [13:23:56] it should [13:26:50] Oh nice [13:27:21] Oh nice [13:27:28] 268 is the ck pitch [13:27:50] Who delay sending lol [13:27:52] whoa* [13:28:39] Apollo 11 had 267° on their PAD, so that sounds right [13:30:02] Is my RSI supposed to be at 45 degrees when my GDC is aligned? [13:31:42] at what point in the checklist? [13:32:03] I mean its been at 45 the whole mission [13:32:29] oh really [13:32:31] that's weird [13:32:37] Yeah [13:32:45] Trying to figure out what happened [13:32:51] probably from a prelaunch test [13:33:00] RSI align [13:33:10] Thats what I am trying to do [13:33:18] Thats what made me notice [13:33:53] probably a small error in the procedure [13:33:58] you press and hold GDC align [13:34:11] the ASCP yaw to 45° [13:34:21] and see both GDC attitude and RSI move to 45° [13:34:24] and then back to 0° [13:34:28] and release GDC align [13:34:53] the behavior of that might have slightly changed with the GDC update I did a year ago or so [13:35:28] Yeah it works fine [13:35:55] after 0.05g you will notice another change [13:36:01] I just centered it with that procedure, put ems roll back off, gdc align, and then rsi again [13:36:07] the GDC driven FDAI only drives in roll [13:36:46] By design I assume [13:37:51] yeah, it's a redundancy thing. It combines yaw and roll for stability axis roll, with the offset CG and the 20° angle of attack [13:38:26] and it does that with both BMAGs, so with that it can't even output any roll, as there is no signal path for it anymore [13:38:40] it's the most redundant thing I have encountered in the CSM [13:38:48] with the most redundancy I mean [13:39:03] there even is a relay that switches power sources [13:39:35] so you can have most of your power and systems fail and it will still give you a signal for FDAI and RSI [13:40:26] Well I'd imagine if any area needed it its entry [13:40:41] yeah [13:41:53] so careful with the EMS 0.05g switch, there is no more 3 axis attitude reference then [13:42:28] with the same update I also implemented all the SCS logic buses [13:42:58] This should be interesting [13:43:17] But again I am flying a PGNS entry so hopefully just watching ;) [13:43:54] hey [13:44:39] hey Alex [13:45:40] got the x-pointers working [13:46:24] great [13:46:29] and pushed my latest LMVC state [13:46:46] I'll take a look later [13:46:58] right now I am working on comp lights [13:48:20] any fancy way of doing lights in the VC? [13:48:39] they will be in 3D and I am modifying the material emissive property dynamically in the simulation [13:48:53] to simulate on/off light [13:49:52] yeah [13:54:22] Ok so maneuvering to SPS sep attitude, is that given anywhere or is it the horizon check pitch? [13:57:12] SM sep? [13:58:41] yes sorry [13:58:45] I think you spend most of the time in the 0.05g attitude [13:59:03] then you pitch to horizon check [13:59:17] procedure says maneuver to pad attitude and it gives 265 in () [13:59:20] and then 45° yawed [13:59:54] yeah that's the 268° you got [13:59:55] Mnvr to CM/SM Sep P,R ATT [14:00:04] "MNVR to PAD ATT" [14:00:09] where is that from? [14:00:17] entry summary [14:00:35] p25 (pdf 28) [14:01:24] roll and yaw from Entry PAD [14:01:42] and pitch for horizon check [14:02:48] that procedure seems incomplete [14:03:43] or no [14:04:26] as I said roll and yaw from Entry PAD and pitch for horizon check [14:04:49] yaw and roll should be very close to 0 anyway [14:05:38] 193:47:47 Armstrong: That's affirmative, we completed the P52. We'll give you the data from it in just a second. We passed our sextant star check at entry attitude, and right now we're maneuvering to our first horizon check pitch attitude of 298 degrees. [14:05:58] So they maneuvered to that attitude early [14:06:37] 298 [14:06:58] must be an extra check [14:07:11] EI minus 30 horizon check, 194:33:06, pitch 298 [14:07:23] normally that's EI minus 17 [14:07:34] I would ignore it, it's not in the procedures [14:07:36] yeah that was an additional check [14:08:01] Got it [14:09:07] maybe they were in darkness at EI-17? [14:11:29] No it looks like they just had 2 [14:11:38] They added it in the remarks of the entry PAD [14:11:52] Additional comments: Use non-exit EMS pattern; EI minus 30 horizon check, GET 194:33:06; pitch 298. [14:13:25] We dont have 11's entry checklist do we [14:15:44] hey all [14:16:41] hey [14:16:57] I can't even find pictures of the Apollo 11 Entry Operations Checklist [14:17:07] we got the Apollo 13 one now which should be fairly close [14:17:09] hey [14:17:22] hey n7275, your auto tracking is working nicely [14:18:06] sweet! [14:20:06] the increased LM SBD tracking speed also handles the pitchover on liftoff [14:20:20] so no CW light anymore [14:20:49] and reacq works during PTC though I am not quite sure what the intended behavior is [14:21:37] it should track to the tracking limit [14:21:45] then drive all the way to the manual set angles [14:21:57] and wait there until it reacquires [14:23:37] Ahh that makes sense [14:24:01] I'll get some more HGA angles in the checklist on my next iteration [14:25:09] for the J-type missions they pointed the SIM bay all through the night at the Moon [14:25:20] so they had the HGA manual angles right for AOS [14:25:35] and it just automatically tracked all the time [14:25:52] and LOS back to the angles for AOS [14:26:00] at LOS* [14:27:13] I'm looking at updating the omnis. right now they look at a vector to the center of the earth. ideally these would point to s-band stations, but that's proving to be a bit harder. [14:28:03] yeah that is hard [14:28:33] I think we would need a general system for all antennas if we want to consider tracking stations [14:29:54] maybe best to leave out for now? then we can impliment a RF/antenna simulation later [14:30:14] yeah center of Earth is fine for now [14:31:41] Yeah [14:34:41] okay [14:34:45] sounds good [14:49:19] Do the VHF antennas on the CM work? [14:50:04] I don't think so [14:50:11] question for you guys [14:50:12] but there isn't even any gauge for it or so [14:50:19] Yeah theres no indicator for it anyways [14:50:34] So moot point right now haha [14:50:35] this function: [14:50:36] https://www.dropbox.com/s/rvvdvzk7c8grd27/Screenshot%202020-05-15%2008.49.45.png?dl=0 [14:50:37] Whats up Alex? [14:50:44] is giving me a CTD [14:50:57] this is the debug: [14:50:58] https://www.dropbox.com/s/48j2jd1rs3f4no0/Screenshot%202020-05-15%2008.43.27.png?dl=0 [14:53:07] oh maybe its because its missing values for the other properties [14:53:12] diffuse, etc [14:53:27] but I just want to change emissive [14:54:43] oapiMeshMaterial doesn't like something [15:11:07] AlexB_88, why material index 1? [15:11:18] how many materials does it have? [15:11:27] if it only has one you need to use 0 [15:11:54] there is also oapiMeshMaterialCount which would give you a number [15:12:15] its the 1st listed material in the mesh [15:12:42] so 0, not 1? [15:13:31] right [15:15:56] aha [15:16:16] I was using the wrong meshhandle in oapiMeshMaterial [15:16:24] I was using the devmeshhandle [15:16:39] but I should use the meshhandle of course for that one [15:16:57] then apply it to the devmeshhandle in oapiSetMaterial [15:18:36] works [15:20:03] ah nice [15:29:01] also, I get "truncation from 'double' to 'float'" [15:29:03] AlexB_88, the RTCC online monitor is now also written to a file [15:29:14] oh great [15:29:18] I'm sure the real RTCC had it printed out immediately or something like that [15:29:34] where do you get that warning? [15:29:42] mat->emissive.g = 0.878; [15:30:01] use [15:30:02] 0.878f [15:30:06] oh of course [15:30:10] thanks [15:30:22] I wish I could easily write the MCC PAD data to a file [15:30:30] but that requires more changes I fear [15:31:05] Yeah that would be cool [15:32:00] the problem is the display code is called whenever the PAD is shown [15:32:12] so not when the data is generated, but when it's actually printed on the screen [15:32:33] so with the easy solution it would repeatedly write the PAD to file every time you let it display the same PAD again [15:42:14] but I'll keep thinking about it [15:47:11] comp light: https://www.dropbox.com/s/t2zgrhbr8qkjuoj/Screenshot%202020-05-15%2009.46.38.png?dl=0 [15:53:28] nice [15:53:38] the RR signal strength meter doesn't really look right [15:53:52] it's not an arrow like that [15:55:29] but I am sure down the road we can make improve things switch by switch and meter by meter [16:03:30] https://www.hq.nasa.gov/alsj/a16/LM11-co46.jpg [16:04:10] it sort of looks like an arrow, but the middle of the meter seems to "overlay" ontop of most of it [16:05:56] oh [16:06:04] it looked quite different here: https://history.nasa.gov/alsj/a12/LM6-co27.jpg [16:06:11] but maybe that's just the perspective [16:06:42] Yeah that caught my eye as well [16:06:58] Also we still dont have the temperature bands on the temp gauge [16:07:15] those were not present until later missions though [16:07:29] I discovered that while making them lol [16:07:42] but Apollo 11 had the same bands that we have right now [16:07:50] they were on 12 [16:07:57] but I can surely add them for 12 and later [16:09:25] indy91, it almost looks like the whole middle part of the meter should rotate with the arrow [16:09:32] yeah [16:09:43] just noticed that, should be easy to fix [16:10:00] its nice that I notice it only after making one of these :D [16:12:12] Hmm any good pictures of that gauge for 11? [16:13:30] https://fineartamerica.com/featured/apollo-11-buzz-aldrin-inside-lunar-science-source.html [16:13:35] you can sort of see it there [16:15:16] https://www.flickr.com/photos/projectapolloarchive/21078671954/in/album-72157659051355812/ [16:16:07] https://youtu.be/gtxyB0h2V3g?t=4612 [16:16:14] Yep got a good look there [16:17:20] So yep confirmed [16:18:26] but I think I have the bitmap already made [16:18:50] so once I get around to it, Ill figure something out to add it for the later missions [16:18:57] Cool [16:19:04] I forgot it wasnt on 11 [16:19:05] we have a better system to handle it noe [16:19:08] now* [16:19:15] with the mission file [16:21:59] Also that glare shield on the xpointers is a lot more pronounced in later missions [16:23:23] yeah I think it had cracks on an early mission and they made it thicker [16:26:39] Not just the glass, the glareshield itself somes out [16:29:43] comes* [16:29:54] damn this horizon check is hard in the dark lol [16:33:26] But right on the money from the lack of stars [16:39:32] Ok back to my rookie entry here [16:39:45] What are the pitches on the checklist post SM sep [16:40:42] Am I supposed to keep the horizon line on it until I am at entry attitude? [16:41:18] entry summary p27 (pdf 30) [16:42:48] are sep you track the horizon yes [16:42:51] if possible :D [16:45:18] Haha [16:45:19] Ok [16:46:13] can someone please try this scenario: https://www.orbiter-forum.com/showthread.php?p=605549&postcount=5 [16:46:18] I just can't reproduce that bug [16:46:43] just start the scenario, MCC debug menu, increase state [16:46:50] yeah one sec [16:46:52] morning! [16:49:30] hey [16:49:43] what's up? [16:49:55] the last time something like that happened it was an uninitialized variable that basically made it fail randomly, depending on the build I guess [16:50:04] chasing bugs [16:50:52] so did he say the thread is hanging on DOI [16:51:09] works for me [16:55:23] good DOI thread [17:07:48] yeah must be the DOI PAD [17:11:53] it iterates on the whole rendezvous plan in that thread [17:11:58] so definitely more potential for issues [17:12:01] but I don't get any... [17:13:25] Hmm does the CM_SM_SEPARATION_DONE [17:13:26] event still work? [17:14:08] it doesnt seem to be advancing the checklist MFD [17:15:05] it should [17:15:27] case CM_STAGE: [17:15:27] eventControl.CM_SM_SEPARATION_DONE = MissionTime; [17:16:03] yeah its not advancing the checklist mfd at those times [17:18:10] with time 0? [17:19:05] I'm not seeing what is different about that event as compared to e.g. TLI_DONE [17:19:35] Me either [17:20:42] have we been using that even before? [17:20:49] event* [17:21:58] I mean its been on there since before my time [17:22:02] I recall it working [17:22:15] what time are you using it with? [17:22:40] A bunch of different ones [17:22:41] it's saved in the scenario, can you check if the value is set? [17:22:46] and to what [17:22:48] Yeah [17:23:17] FDAI shaping up [17:23:18] https://www.dropbox.com/s/z83or9cwm0wtrml/Screenshot%202020-05-15%2011.23.03.png?dl=0 [17:24:25] very nice [17:27:08] hmm reloaded and its working [17:27:16] go figure [17:27:39] time is correct and everything idk haha [17:31:37] weird [17:32:00] yeah I am running through it all again to see that it advances properly [17:51:10] now to try and animate it [17:52:03] I might have to make some "ghost" meshgroups in order to make it work properly [17:52:33] since I need to have a parent and 2 child rotations [17:53:10] but usually the "child" is a separate mesh, but in this case its all the same mesh [18:21:26] is EI time the same as RRT [18:29:08] yes [18:29:13] Reentry Reference Time [18:30:48] Thanks [18:31:34] alright, I think I got all the animations defined, now to try to somehow feed them to FDAI code [18:36:47] well I might not even have to go through FDAI class at all [18:37:17] just get the total attitude from the GASTA [18:38:52] all graphics, no code :D [18:39:15] which is a good thing for our CPU limited simulation [18:39:52] yep [18:50:40] what is the scaling of the attitude returned from the GSATA? [18:50:48] I need to format it into 0-1 [18:50:58] for the animation [18:53:28] ah its in radians [18:55:53] it works! [18:58:39] nice! [18:59:17] except my roll is reversed [18:59:38] but its just a question of reversing the axis I guess [18:59:46] yeah [19:00:37] which is 0.00, sin(7.95581 * RAD), -cos(7.95581 * RAD) [19:00:50] need to figure out how to reverse that [19:01:34] what are those angles? [19:02:02] is that a vector? [19:02:21] its the FDAI roll axis which is usually 0,0,1, but it needs to be tilted 7.95581 to align with the panel [19:02:24] yes [19:03:03] ok I think I got it [19:03:25] used -sin, + cos [19:04:12] yeah that makes the vector go into the opposite direction [19:05:38] ok that works [19:05:56] next issue [19:06:11] the FDAI works perfectly as long as my roll is heads-up [19:06:26] but if I go heads-down, every thing gets messed up for some reason [19:07:30] it seems like that euler angle conversion issues the LVDC used to have a long time ago [19:08:04] when the SIVB rolled 180 during the maneuver to sep attitude [19:14:31] hmm [19:15:00] I really have no idea how this animation code looks like [19:15:14] if I did I could probably help with this geometry stuff [19:17:36] SetAnimation sets the state of you animation from 0 to 1 [19:17:58] so what I did for example for roll: [19:17:59] SetAnimation(anim_fdai_roll, (attitude.x * DEG) / 360); [19:18:49] first of all, do attitude.x/PI2 a bit more efficient [19:19:36] and I think it's going to depend on the order of animations [19:20:35] ok [19:51:07] hahaha [19:51:18] just saw my RR fly across the window [19:51:38] it helps when you dont try and use the same variable names of other animations :D [19:53:58] the radar can rendezvous on its own then [19:55:29] looks like it [20:13:54] lol [20:14:55] hahahahaha [20:38:47] night! [05:14:45] ooooooooohhhh man [05:15:04] the fixed-fixed mystery in Sundance has seriously thickened [05:16:01] I think ZEROICDU was moved from bank 2 to the end of bank 3 [05:17:19] probably to make room for... CLEARMARK maybe? [05:18:37] yeeaaahh [05:18:40] fascinating [05:20:16] that gets bank 3 up to the correct address for our mystery function, but doesn't yet explain what it is [05:20:27] I do know for a fact that it's related to extended verb handling though [05:20:32] whatever it is [05:44:46] also the location of ZEROICDU further narrows down the range of pages in which mystery function can appear [05:45:01] I think [05:45:03] maybe not [05:45:03] lol [05:52:11] yeah, movement of ZEROICDU 100% confirmed [05:52:12] how strange [05:52:35] Sundance 292 has it in exactly the same place as Luminary 69, which is why it's so interesting [07:27:53] mmm, bank 10 shows no signs of CLEARMRK having been added... it still has the pre-CLEARMRK coding in 302 [07:28:06] also there's a mystery two words between ZEROICDU and UPENT2 [07:28:08] wtf did they do [13:44:30] hey guys [13:44:47] hey [13:47:45] still having issues with the FDAI animations [13:50:41] do you have your latest state on Github? [13:50:46] good morning [13:51:06] good afternoon [13:51:40] hey [13:51:51] indy91, Ill push it [14:00:43] pushed [14:01:49] building [14:02:45] or no [14:02:56] I probably should switch to your branch before building :D [14:03:16] ideally :D [14:07:03] FDAI is all black for me [14:07:51] or no [14:07:57] it's just very dark [14:08:55] I can see it move, but barely [14:09:13] ah probably no internal lighting yet [14:09:18] yeah, I have to adjust the materials of it for more lighting [14:09:18] need a scenario in sunshine [14:09:40] or you can temporarily increase the ambient light level [14:10:07] right [14:10:10] ok I see the problem [14:11:14] GASTA code already checks that the result is 0 to 2*pi [14:14:24] I would have thought that roll and yaw axis need to be switched in their animation order [14:14:36] but that doesn't work right. Maybe it needs changes to the axes [14:15:11] or wait I did something wrong [14:17:19] it does look more like an issue with those roll and yaw axes though [14:18:30] I just randomly made it [14:18:31] const VECTOR3 rollaxis = { -0.00, sin(7.95581 * RAD), -cos(7.95581 * RAD) }; [14:18:31] const VECTOR3 yawvaxis = { -0.00, sin(97.95581 * RAD), -cos(97.95581 * RAD) }; [14:18:39] so the minus on the cos() [14:18:48] that seems to do good things [14:20:41] just trying it [14:20:47] by my roll axis seems reversed [14:21:24] so is yaw, but that isn't really difficult to fix. Just a sign change on the animation [14:21:58] oh I forgot to remove the - on the sins [14:23:28] did you do any other changes the the sin/cos changes? [14:23:40] because I still have the issue when you go to yaw 180 [14:23:48] everything is reversed [14:24:33] yeah I still get lots of issues [14:25:18] just the yaw-roll coupling went away [14:25:52] right [14:26:22] and I am getting that yaw issue [14:27:22] maybe an animation order issue [14:28:14] when I put the GASTA angles in a debug string, the yaw never goes above 90 [14:28:56] so if I am at 0 yaw, and a yaw right all the way to 180, the GASTA value on the debug string looks like this: 0-90-0 [14:29:03] and not 0-180 [14:29:15] that would not help the animation of course [14:29:35] I think the issue is we need to somehow convert the angles driving the animation [14:31:29] the yaw should only be 0° to 90° and 270° to 360° [14:32:25] hmm [14:33:01] so once it passes 90 when I yaw right, it should jump to 270? [14:33:17] no [14:33:24] down from 90 again [14:33:41] right and thats what it does [14:33:42] no jump [14:33:55] well from 1° to 359° there is a jump [14:36:13] so the issue now is just the yaw being reversed when you are rolled heads=down [14:40:00] I wonder if there is a way to tell it, "if roll is > 90, invert the yaw" or something [14:42:10] that really shouldn't be necessary [14:46:10] I'm getting pretty good results when I changed yaw and roll animation [14:46:19] I have these lines changed [14:46:20] fdai_proc[0] = 1.0 - attitude.x / PI2; [14:46:26] const VECTOR3 rollaxis = { -0.00, sin(7.95581 * RAD), -cos(7.95581 * RAD) }; [14:46:30] const VECTOR3 yawvaxis = { -0.00, sin(97.95581 * RAD), -cos(97.95581 * RAD) }; [14:46:41] ach_FDAI_roll = AddAnimationComponent(anim_fdai_roll, 0.0f, 1.0f, &mgt_FDAI_Roll); [14:46:41] ach_FDAI_yaw = AddAnimationComponent(anim_fdai_yaw, 0.0f, 1.0f, &mgt_FDAI_Yaw, ach_FDAI_roll); [14:46:42] ach_FDAI_pitch = AddAnimationComponent(anim_fdai_pitch, 0.0f, 1.0f, &mgt_FDAI_Pitch, ach_FDAI_yaw); [14:47:53] Wow out atmosphere pressure modeling is spot on [14:47:57] *our [14:48:02] or oribters is lol [14:48:06] ugh cant spell [14:48:28] Orbiter probably [14:48:31] I used a atmospheric pressure table to find approximate pressure at 90k feet to change the pegged steam pressure [14:48:42] And it now pegs our gauge at 90k [14:50:06] it's a pretty detailed model in Orbiter for pressure and temperature [14:50:33] Well now our steam pressure gauge in the CM pegs at 90k feet per the entry checklist [14:51:25] yes! [14:52:05] hmm [14:52:12] pitch is still a bit off though [14:53:15] Ok entry is done, checklists done, now back to that pesky LM [14:53:32] pitch is off with what yaw and roll? None? [14:55:40] so I start at 0 pitch, pitch up to 30 (heads-up) [14:56:02] then I just roll 180 so I am heads-down (no change to pitch/yaw) [14:56:19] pitch should stay at 30, but it goes straight to 330 [14:56:59] does that happen with you? [14:59:14] ush [14:59:19] ugh* [14:59:21] sorry [14:59:27] it goes to 0 [14:59:29] not 330 [14:59:41] but it still should stay at 30 and not go to 0 [15:01:41] on the 2d panel, 30° pitch, 180° roll [15:01:47] that is not at 30° pitch then? [15:01:53] in the VC [15:03:08] its 0 pitch 180 roll in the VC [15:03:18] with 30 pitch 180 roll in 2D [15:03:25] no I am not getting that [15:03:36] ok, this might be just my settings then [15:03:37] did you use all of the lines I posted above? [15:03:44] that's all the changes I have in right now [15:03:57] ohhh [15:03:58] compared to your commited version [15:04:12] I missed the 1st one [15:04:13] fdai_proc[0] = 1.0 - attitude.x / PI2; [15:04:38] that fixes the roll direction [15:05:35] did you change fdai_proc[1] and fdai_proc[2]? [15:05:57] no [15:06:02] ok [15:06:31] 6 lines of code changed [15:10:02] it works [15:10:05] thanks!! [15:10:19] damn I spent the whole day yesterday trying to figure this out [15:10:35] mostly trial and error [15:10:45] so could use some more trial I guess [15:10:50] but it looks good [15:10:57] yes it does [15:11:29] well I was doing trial and error all day yestreday, but it doesnt help when you are doing trial & error with the completly wrong things lol [15:11:46] true [15:12:51] this REFSMMAT update I am doing affects all RTCC MFD users, not just the MPT mode. And I think I am going to use at least one MED input. It's not too difficult really [15:13:01] oh nice [15:13:07] G00,Vehicle 1, Matrix 1, Vehicle 2, Matrix 2; [15:13:09] your working on the REFSMMATs [15:13:25] for moving a REFSMMAT from one slot to another [15:13:46] the RTCC has two REFSMMAT tables, one for the CSM, one for the LEM [15:13:52] the main REFSMMAT has the code CUR, current [15:14:07] and the REFSMMAT calculation page, for now, updates that one [15:14:40] the downlink button saves a REFSMMAT in the TLM, telemetry, slot [15:14:49] so to make that one the current REFSMMAT, you would do [15:14:55] G00,CSM,TLM,CSM,CUR; [15:15:09] and you get a detailed message on the online monitor [15:15:37] nice [15:15:49] and on the REFSMMAT uplink page you can choose any REFSMMAT you want [15:16:06] and I guess I can do the same for e.g. the Maneuver PAD [15:16:09] yeah thats convenient [15:17:34] the REFSMMAT page just needs to say that the online monitor has the messages if the update went well or so [15:18:48] and something for the telemetry REFSMMAT update [15:19:31] other than that not a lot of other changes have to be done for everything to work, although I am planning to untangle the REFSMMAT page. It's all very centralized when the different types of REFSMMAT were actually calculated in very separate programs [15:21:43] and some MPT mode only features, like saving a DMT RESFMMAT [15:33:15] the AEA attitude seems to work as well with the animations, but its very jerky [15:36:22] oh and there is the heads-down yaw issue with the AEA attitude [15:36:33] yaw is inverted when heads-down [15:40:50] ok I think I fixed it [15:41:54] only when AttitudeMonSwitch is in AGS, I made fdai_proc[0] = -attitude.x / PI2; [15:42:02] instead of fdai_proc[0] = 1.0 - attitude.x / PI2; [15:43:48] hmm [15:43:54] weird that that is required [15:44:22] yeah [15:44:27] but it seems to work [15:45:16] maybe the AEA attitude wasn't returned in 0 to PI2? [15:56:06] doesnt seem like it has any code for that [17:02:44] morning! [17:05:01] hey Mike [17:05:59] what's up? [17:06:37] from what you wrote last night it sounds like Sundance had some bug fixes that needed some annoying moving of routines and ended up moving away from Luminary in some ways [17:07:19] yeah [17:07:53] I realized belayedly that the ZEROICDU move was necessary because the SVCTX3 changes made them run out of room in bank 2 [17:08:06] but the extra two words between it and UPENT2 are strange [18:05:42] https://www.dropbox.com/s/rm8dquum2r3p6ow/Screenshot%202020-05-16%2012.05.25.png?dl=0 [18:05:59] oooh nice [18:07:32] time to animate those needles [18:07:46] :D [18:15:43] might even animating the off flag :D [18:15:50] animate* [18:29:48] :D [19:01:01] oh [19:01:11] Sundance has something extra after RCS monitoring [19:01:20] Sunburst and Luminary both just RESUME [19:01:22] what is this [19:02:14] RCS failure monitoring? [19:02:28] yeah [19:03:50] oh it's futzing with a flag [19:03:54] may be a Sundance-only flag [19:04:56] let's see, flagword 1, bit 12 [19:05:15] yeah, definitely spare in Luminary [19:05:49] APS FLG, according to the systems handbook [19:05:50] APS FLG? [19:05:53] yep [19:06:17] DAP document has it [19:06:30] Set: LM stages or on lunar surface [19:06:44] Cleared: LM unstaged and not on lunar surface [19:08:05] interesting [19:08:38] related to the input discrete for descent stage present? [19:09:07] hmm [19:09:10] good question [19:09:20] it's looking at bit 12 of channel 30 [19:09:23] sorry [19:09:25] bit 2 of channel 30 [19:09:28] yes [19:09:36] that's the one [19:09:53] does the dap document happen to have this in flowchart form? [19:09:53] the one that is somehow inversed in Sunburst [19:09:54] haha [19:10:05] and actually relevant for Sunburst [19:10:13] didn't I just read a Tindallgram about this... [19:10:36] checking [19:11:59] APSFLG, not to be confused with APSFLAG... [19:12:16] O_o [19:12:43] but yeah it is mentioned in the DAP document [19:12:46] Luminary has [19:12:47] APSFLAG [19:12:54] flag 10 bit 13 [19:13:01] ah [19:13:59] ok error needles working [19:14:40] I don't think Luminary checks bit 2 of channel 30 for APSFLAG though [19:15:35] they are not sensitive enough though [19:15:58] "Here is one more note in the continuing "Stage Verify" story. According to John Norton the lunar ascent program (PI2) no longer checks stage verify. That strikes me as a real improvement in the program but it mystifies me as how it go changed without a PCR or PCN, or even letting anyone know. Norton, of course, uncovered it by going meticulously through the program listing." [19:16:22] ! [19:16:25] what's the date on that? [19:16:43] May 24, 1968 [19:16:48] nice [19:17:23] oop [19:17:32] Luminary rev 31 [19:17:55] "All usages of the stage-verify bit were replaced by usages of APSFLAG (PCR 419)." [19:18:04] so there was a PCR... [19:18:08] yeah, that makes sense [19:18:09] and yes, here it is [19:18:09] haha [19:18:19] but does it have a Sundance PCR? :D [19:18:22] "Stagemon was deleted from T4RUPT (part of PCR 419 changes)." [19:18:30] that is exactly what I'm looking at, STAGEMON [19:18:31] :D [19:18:34] yeah, that's what I thought [19:18:43] Sunburst needs it [19:18:46] but otherwise... [19:19:24] so Sundance 306 doesn't have that either in T4RUPT? [19:19:53] Sundance 302 certainly does [19:20:19] and Sundance 306 still uses APSFLG at least [19:20:53] actually [19:21:04] and from module B6's perspective, bank 6 addresses are the same between 302 and 306 [19:21:05] I think I told you wrong things about V48 in Sundance some time ago [19:21:15] so I think this code still existed in Sundance 306 [19:21:22] only removed for Luminary [19:21:23] oh? [19:22:12] I don't think you can even tell it that you are in ascent or descent configuration [19:22:26] digit 1 of R1 is just 0 for undocked and 1 for docked [19:22:42] in that V48 flow chart it even checks channel 30 bit 2 [19:23:28] so if there is no way to tell it the configuration then it of course stills needs that input bit and probably the APS FLG [19:24:26] ah [19:24:38] well, I haven't gotten that far yet, that one's in module B3 :D [19:24:48] so we will find out! [19:25:19] in the checklist they load a 0 before docking [19:25:32] before undocking* [19:26:02] but that doesn't necessarily mean that 0 is docked [19:26:12] the DAPBOOLS flag is CSMDOCKED [19:26:20] so probably 1 = docked [19:32:03] "Ascent Phase Mission Techniques meeting - February 27 - 1968" Tindallgram has some more about stage verify [19:32:23] too long to quote [19:34:33] nice, will look [19:34:43] I'm almost done with bank 6 here [19:34:47] that's the kind of stuff why someone like Tindall was very productive. Nobody else would really think much about it [19:35:18] as he says, all that needs to fail is a relay and the LGC would forever think it's in the descent stage configuration [19:35:32] that doesn't make controlling the ascent stage very fun for the DAP [19:35:43] haha nope [19:37:30] you get that for a moment when you abort stage from descent with Luminary 210 and the abort input bits suppressed [19:51:40] AlexB_88, more luck with the needles? [19:53:02] well they work, just the sensitivity of the needles is much less then what the 2D FDAI shows [19:54:43] weird [19:54:57] you have it 0 to 1 from one end of the FDAI to the other? [19:56:22] hmm yes [19:56:48] I adjusted the vector lengths for them [19:57:13] so the animation from 0-1 is definitely good [19:57:24] SetAnimation(anim_fdai_rollerror, (errors.x + 384) / 768); [19:57:24] SetAnimation(anim_fdai_pitcherror, (-errors.y + 384) / 768); [19:57:25] SetAnimation(anim_fdai_yawerror, (errors.z + 384) / 768); [19:57:31] and thats what I use to drive it [20:07:13] have you looked at the values of error? Are they not going up to +/- 384 [20:08:44] if (errors.x > 41) { errors.x = 41; } [20:08:45] else { if (errors.x < -41) { errors.x = -41; } } [20:09:11] is what the 2D panel code does [20:09:17] I don't really understand that though [20:10:21] lgc_err_x etc. are definitely getting the full error counter output from the LGC [20:13:00] are you doing that limit to 41 in your code? [20:13:13] that would of course cause your issue [20:13:57] but it doesn't make sense to me in the 2D panel code either. Should we have scaled that all along? [20:15:53] yeah I am wondering too [20:16:23] the reason I say its "sensitive" was in comparison with the 2D FDAI error needles [20:16:36] but maybe they were too sensitive? [20:17:52] I am not limiting it though [20:19:44] I have the feeling we have it wrong on the 2D panel [20:23:21] I'll do a quick test [20:23:33] should be fairly obvious with the error counters in a debug string [20:25:05] 50% confirmed [20:25:17] I can push my latest if you want to test [20:26:12] bank 6 done. here's STAGEMON if you're interested, indy91: https://github.com/thewonderidiot/sundance/blob/master/b2_302.disagc#L883 [20:26:43] I'm just looking if we got it wrong on the 2D panel [20:27:42] thewonderidiot, wait, Sundance has APSFLBIT? [20:28:02] pushed [20:28:24] uhh [20:28:29] should I have called it something different [20:28:37] that's the bit for APSFLG [20:28:59] I had to push anyway since the poor FDAI was in a very bad state in my last push :D [20:29:37] I don't think Sundance has APSFLAG [20:29:52] ah ok, for a moment I thought it had both :D [20:30:07] APSFLAG and APSFLG [20:30:17] mmm [20:30:23] let me look at DAPDATA1 in bank 20 real fast [20:30:50] despite the similar names the flags are used quite differently [20:32:05] ah okay here [20:32:31] there is at least some overlap [20:32:55] https://github.com/thewonderidiot/sundance/blob/master/b6_306.disagc#L714 [20:32:59] AlexB_88, AOH says PGNS driven error needles show +/-5° [20:33:16] that would be correct with our current behavior [20:33:27] but then it only uses 41 out of 384 bits of the error counter... [20:33:36] have to check if that is really correct [20:42:03] maybe it's correct [20:42:40] have to do more research on that tomorrow, what a waste of the ICDU error counters if it only 10% of its range [20:42:53] only uses* [20:53:51] yeah [21:00:14] night! [14:02:23] hey [14:04:11] hey Alex [14:04:27] I have your definitive answer for the FDAI attitude error [14:04:41] we do it wrong on the 2D panel, but only very slightly [14:04:53] from Luminary code [14:04:54] FULL SCALED DEFLECTION OF THE NEEDLES CORRESPONDS TO 5 1/16 DEGREES, WHILE 384 BITS IN THE IMU ERROR COUNTER [14:05:00] CORRESPONDS TO 42 3/16 DEGREES. (DAC MAXIMUM CAPACITY IS 384 BITS.) 46 BITS EFFECTIVELY PIN THE NEEDLES. [14:06:13] ah interesting [14:06:16] so the atca.lgc_err can be -384 to 384 [14:06:27] that needs to be limited to -46 to 46 [14:06:41] and then scaled from 0 to 1, so (val + 46)/92 [14:07:18] and the 2D panel is wrong by a factor 46/41 [14:07:24] so not very much [14:08:25] making the changes now [14:08:35] I have the rate needles working too [14:09:28] nice [14:12:42] ah that looks much better with +46/92 [14:15:57] now, do you think all the animations should also have "if val > 0 val = 0 / if val > 1 val = 1" code as well [14:16:08] even though they are already scaled 0-1 [14:16:25] if val < 0* [14:17:18] if we are quite sure that the input value can't be out of the scaled range then it's not needed I guess [14:17:29] yeah thats what I am thinking [14:17:41] but I am not sure about the rate needles [14:18:48] rate has two different scalings anyway [14:18:57] so that probably needs the 0 to 1 check [14:19:06] the value pulled for them already seems to be scaled so that -1 is full left deflection and +1 is full right deflection [14:19:34] so I did (rate.x + 1) / 2 for example [14:20:07] but the thing is it seems that the value can go less then -1 and more then +1 [14:20:41] you mean the GetRates() returns -1 to 1? [14:21:03] well it can go higher then those [14:21:21] like if you roll fast enough, it will go to 2 or 3 [14:21:40] but the needles seem to be scaled for the values -1 to +1 [14:21:55] if that makes sense [14:22:06] ah, after rates = rga.GetRates() / (25.0*RAD); [14:22:09] and rates = rga.GetRates() / (5.0*RAD); [14:22:23] then it's -1 to 1 for min and max deflection [14:22:49] yes [14:23:10] I think it would make sense that all the limit checks are the same [14:23:31] so rates should be scaled: (rates.x + 1.0)/2.0 [14:23:38] and after that it should check on 0 to 1 [14:23:42] limit it [14:24:03] yes [14:24:06] that's done in FDAI code as well [14:24:22] yeah that was taken from the HGA code [14:24:47] but I think some of the FDAI stuff might be overkill, like fdai_proc_last stuff [14:25:06] I had used it since the HGA had it [14:25:46] that prevents it from animating on every timestep if nothing changed right? [14:27:35] oh right [14:27:40] I guess that is good then [14:42:01] I am putting the FDAI SetAnimation calls in a separate function AnimateFDAI() [14:42:10] sure [14:42:25] since its going to get very big [14:42:26] and I think a bunch of these animations could be their own class to avoid repeating the same code [14:42:38] I was thinking that [14:42:39] FDAI code is special [14:42:52] that probably shouldn't be in panel or VC code anyway [14:43:08] not sure where else though since it's so different between CSM and LM [14:43:23] well, I could integrate it in the FDAI.cpp [14:43:54] better not, that wiring is definitely outside of the FDAIs themselves [14:44:08] ok [14:44:53] oh, I was listening to the Apollo 11 GUIDANCE loop after launch, but when it comes to REFSMMAT stuff he must have prepared a lot before launch [14:45:10] so I randomly went back to the very beginning of the GUIDANCE audio [14:45:13] T-20 hours [14:45:24] and he is already working on REFSMMAT stuff :D [14:46:17] didn't even have a Dynamics at his console yet, so GUIDO and Computer Sup were guessing how to properly do the MED inputs for what he wanted to do [14:46:52] sounded like a REFSMMAT resulting from a backup GDC alignment or so [14:47:15] I think he does prepare a PTC REFSMMAT at some point [14:47:19] that would be interesting [15:15:11] for now I have made it so that the downlink button on the REFSMMAT page updates both the telemetry as well as the current REFSMMAT [15:15:35] so basically no change from before, everything updates the "main" REFSMMAT, just like before [15:15:39] and it gets used in the same way [15:16:02] so now I can add the proper MCC displays and inputs for REFSMMAT and optics calculations [15:23:42] nice [15:24:23] important step if I ever want to remove the non MPT mode [15:24:41] this will have sextant star and horizon checks and that kind of fun stuff [15:25:20] right [15:26:32] the MEDs are quite complicated so I think I am not going to use them, at least not 1:1 [15:53:38] I am very confused right now if I have high res or low res textures installed [15:54:11] Question 1, do you have the textures in your NASSP folder or stored separately? [15:54:34] Question 2, in the Earth texture folder, do you only have an Archive folder or also Elev, Surf etc. [15:56:47] 1. in my NASSP folder [15:57:15] 2. Archive & Elev_mod [15:57:46] I am talking to the guy who did the update to the Mobile Launcher [15:57:50] nearly ready, PR is already up [15:57:59] oh cool [15:58:00] he uses high res and it looks differently [15:58:20] apparently there are some incompatibilities to low res, which I get [15:58:24] not too bad [15:58:43] I think I installed the high res textures over a Orbiter 2016 install [15:58:54] the 2GB install that comes with textures [15:59:02] maybe I have to delete those to make high res work? [15:59:09] Any settings I could have screwed up? [15:59:52] I thought you can just install the high res textures over the Orbiter 2016 ones [16:00:38] I deleted them and I still have textures [16:01:39] hmm [16:01:48] this is what my archive folder looks like [16:01:57] https://www.dropbox.com/s/jwcy4jgsbxwlmzs/Screenshot%202020-05-17%2010.01.32.png?dl=0 [16:02:36] I have exactly the same, but I have an additional label.tree [16:03:16] maybe he has some KSC specific textures? I'll ask him [16:04:28] on your suggestion I used linear interpolation for surface elevation, maybe it's that [16:08:42] it's not [16:24:35] maybe Terrain Resolution settings? [16:26:27] is there a link to the picture so I can compare with mine? [16:26:45] http://www.imagebam.com/image/9644b11341235202 [16:26:50] http://www.imagebam.com/image/765ecf1340064437 [16:26:54] is what he gets [16:27:05] oh he added that I am sure [16:27:27] well yeah, that is his PR :P [16:27:47] this is how it looks for me: https://imgur.com/a/ziP6c4c [16:28:03] and he says he only gets that issue in a new install with low res textures [16:28:17] but I don't even have low res installed right now... [16:28:26] hmm that is weird [16:28:34] your textures look the same as mine [16:28:55] oh are you looking at his branch? [16:29:50] no not yet [16:30:23] I am just saying that your textures look the same as mine (the greener looking ones I mean further out) [16:30:29] ah right [16:30:59] but I think in general it looks a bit weird having that colour difference [16:31:36] but it is higher resolution so I guess that is better [16:32:00] I mean the custom ones he used [16:32:28] when I zoom in to the picture of it, yeah the resolution is much better on his custom image he used [16:32:48] so I guess its worse the sacrifice of differing colour from the main surface texture [16:36:54] right now I just want to be able to test his changes. But I don't even know what KSC textures he and I are actually using :D [16:47:57] I can switch to his branch an d give it a test [16:48:12] if it's not too much hassle [16:48:18] no problem [16:48:24] I'm curious if you get the same texture glitch [16:48:43] right [16:54:05] building [16:58:09] indy91, I get the same [16:58:11] https://www.dropbox.com/s/mn7k4e1hknvucn4/Screenshot%202020-05-17%2010.57.49.png?dl=0 [16:59:05] holy crap what a nice job he did [17:00:43] no performance hit on my machine [17:01:15] it's only loading a bit slow for me, otherwise it runs great [17:01:41] I guess its just a question of fixing the texture bleeding [17:03:18] yeah [17:04:05] he says he doesnt have the issue? [17:04:44] I posted those images from him above [17:04:46] http://www.imagebam.com/image/9644b11341235202 [17:04:58] http://www.imagebam.com/image/765ecf1340064437 [17:05:46] his first idea was that I have the low res textures only installed, so that's why I started testing what I even have installed [17:05:52] but I guess that is not so [17:08:51] I tried something [17:09:02] I removed the Elev_mod folder [17:09:21] https://www.dropbox.com/s/kgwdxc0thtantu5/Screenshot%202020-05-17%2011.09.07.png?dl=0 [17:09:36] I wonder if he does not have it [17:09:56] that being said, there is still a bit of texture bleeding in that image [17:10:19] yeah [17:10:38] hmm [17:10:45] so elev mod folder 15 is in the repo [17:10:50] but I also have 10 to 14 [17:11:25] do you have those? I think at one point I had SSU installed in this folder, might be messing something up [17:11:31] I only have 15 [17:12:07] I think the others might be Vandenberg etc [17:12:17] but I'll delete them to be safe, I have a separate SSU install now [17:12:32] but it does look like some elev_mod difference is probably the cause [17:16:34] morning! [17:19:28] hey [17:20:47] what's up? [17:23:05] trying to figure out why a pull request for a Mobile Launcher update looks different for us than it does for him [17:57:31] AlexB_88, he uses textures from a different folder. That probably means that the Elev_mod changes NASSP does aren't used, right? [17:59:04] from a different folder where no NASSP files were installed? then yes I think so [17:59:13] that must be it then [18:24:06] I have a PR for the NASSP installation instructions [18:24:09] change [18:24:13] In this case, you must also copy the NASSP texture files to the other directory [18:24:15] to [18:24:54] In this case, you must also copy the NASSP texture files (folders ProjectApollo and Earth\Elev_mod) to the other directory [18:25:02] or something like that :D [18:28:00] thewonderidiot, and I figured out that FDAI attitude error display question we had yesterday thanks to Luminary comments [18:28:07] FULL SCALED DEFLECTION OF THE NEEDLES CORRESPONDS TO 5 1/16 DEGREES, WHILE 384 BITS IN THE IMU ERROR COUNTER [18:28:11] CORRESPONDS TO 42 3/16 DEGREES. (DAC MAXIMUM CAPACITY IS 384 BITS.) 46 BITS EFFECTIVELY PIN THE NEEDLES. [18:28:18] what a waste of 90% of the bits [18:29:44] hah wow [18:30:23] it's different in the CMC. Depends on switch setting and mode there. During Entry the roll scaling is different in the CMC for example [18:31:34] that big block of comments about the FDAI attitude error display subroutine was a nice big copy and paste from CMC to LGC though :D [18:31:38] almost identical [18:33:55] hehehe [18:34:15] that is probably the most surprising thing about Sundance [18:34:18] so far [18:34:34] is how much overlap they had with Colossus, even including code that only actually did anything in the CMC [18:35:56] Sundisk would be so interesting for comparison [18:37:55] just for general progression of development [18:41:23] whats the best way to put a check for my no att flag animation? [18:41:35] I tried if (!fdaiLeft.IsPowered) [18:41:51] isPowered() [18:41:52] but I get "illegal operation on bound member function expression" [18:41:57] it's a function [18:43:25] ah right [18:44:11] works [18:44:21] and with that I have officially finished the CDR FDAI [18:44:42] now to do the LM side [18:44:49] awesome :D [18:44:56] well I doubt it's much work now [18:45:03] for the LMP [18:45:05] no [18:45:29] I made some separate functions for the FDAI animation definitions [18:45:54] should be easy to make the lmp version [18:46:09] Ive already prepared the code for it [19:00:50] Yeah, it seems Jordan didn't know about the unfortunate thing in Orbiter, that when you give it a separate Texture folder it ignores EVERYTHING in your NASSP install texture folder [19:06:50] Ill make the changes you requested to the installation folder [19:06:57] post* [19:07:38] yeah that would probably be good. That little extra folder is easy to forget in that process [19:08:19] CMOONFLG confirmed to be the same in Sundance [19:09:19] so no extra code for me to do in the RTCC MFD to steal the state vector from the AGC :D [19:09:38] I guess ideally I would process the downlink data itself [19:09:40] maybe one day [19:23:55] haha [19:24:06] is it always in the same place in the downlists though? [19:25:06] probably not [19:25:17] not even RN, VN and R-OTHER, V-OTHER are in the same place [19:25:23] so the erasables for downlink [19:27:46] that doesn't mean too much, I think they may have tried harder to keep the actual downlists themselves a bit more consistent [19:29:15] right [19:29:51] thinking about it... I think it's usually one of the first things that gets downlinked [19:30:25] yeah, just after the downlink ID [19:30:32] downlist* [19:31:04] at least the CSM state vector in the CMC [19:31:15] LM starts word 52 [19:31:32] but not in every list [19:31:49] Entry and Update List doesn't even have LM state vector [19:32:22] but it might of course be consistent across CMC and LGC versions per downlist [19:33:20] yeah that looks pretty good [19:53:04] oooohh interesting [19:53:56] there's a display interface routine called by V83 in Sundance 306, that isn't done in Luminary [19:54:05] and sure enough, the display interface routine itself isn't in Luminary [19:54:06] what is this [19:54:50] not in Colossus 237 either... [19:55:08] range and range rate to the tapemeter? [19:55:31] it starts off by looking at bits in flagwrd4 [19:55:55] oh wow, lots of bits [19:56:13] oct 40240 [19:56:33] nope [19:56:37] oct 40420 [19:57:17] so bits 5, 9, and 15 [19:58:33] marking bits [20:01:00] hmmmmmm [20:02:01] V83 looks pretty normal in the rendezvous procedures [20:03:33] lol [20:03:53] it calls this weird function immediately after calling our missing mystery function in fixed-fixed [20:04:30] of course [20:04:40] nothing weird documented about V83 in the GSOp [20:04:42] GSOP [20:05:04] let's see, did Colossus ever have this routine... [20:06:32] yes, it did [20:07:05] it has the exact same gap in punch card numbers where it would have been that Luminary 69 does [20:15:24] hmmmmmmmmmmmmmmm what is this [20:15:39] surely there is a mention of its existence or removal somewhere [20:16:58] oh, narrowed time of its removal down some [20:17:31] Luminary 13 -- "GOMARK3R was added to the Display Interface Routines for use by V48." [20:18:23] Sundance definitely has GOMARK3R [20:20:07] V48? [20:29:23] yeah [20:29:28] hmm [20:32:44] what does GOMARK3R do? [20:33:32] uhh [20:33:35] 10,2253: 54155 1 GOMARK3R TS PLAYTEM1 [20:33:35] 10,2254: 33406 0 CAF MARK3MSK [20:33:36] 10,2255: 12546 0 TCF GODSPRS [20:33:37] that's the whole thing [20:33:45] I don't know much about how the display interface routines work [20:35:39] has to do with the gimbal trim drive I guess [20:35:43] display is blank during that [20:35:49] when it's done the display comes back [20:36:13] it's called in TRIMDONE at least [20:42:04] oh here you go -- not this display thing but [20:42:17] "APSFLAG moved from Bit 12 of FLAGWRD1 to Bit 13 of FLGWRD10" [20:42:28] so APSFLAG and APSFLG really are the same thing [20:42:48] haha [20:43:03] slightly differently used, but yeah [20:46:59] well, I'm stumped [20:47:09] can't find any references to this thing [20:50:27] no idea either [20:56:51] good night! [00:41:37] whoa [00:41:44] nasty bug in INITDSP in Sundance 302 [00:42:08] two instructions are in the wrong order, which makes it always zero SUPERBNK instead of restoring the user's SUPERBNK [00:42:46] which means any functions in banks 40-43 that get here will break [00:43:01] I wonder if they fixed this for 306 [00:47:03] ouch [06:11:40] indy91, I think based on comments in DISPLAY INTERFACE ROUTINES that the function we were looking for earlier might be MARKBRAN [13:49:21] hey [13:51:32] hey Alex [13:54:22] done formatting the GOST, the Guidance Optics Support Table [13:54:48] it definitely has sextant star check, boresight star check and horizon pitch angle for the Entry PAD [13:55:11] not sure yet how to get the attitude for the backup GDC alignment [13:56:25] nice [13:56:46] that one will be useful [13:57:21] yeah, has a bunch of the stuff missing from the DMT that is required for a Maneuver PAD [13:58:45] I also eventually need to create the list of 400 navigation stars that the RTCC had loaded... [14:01:50] right [14:02:19] LMP FDAI is now working and I have all the talkbacks working on the main panel [14:02:32] or no, it's only 391, you can manually specify the last 9 :D [14:02:42] ah even talkbacks, nice [14:03:36] oh, Jordan said that it's probably the best solution for the texture issue at LC-39 to flatten the area [14:03:55] and not raise the texture or mesh or whatever [14:04:32] or make it compatible that way at least [14:04:42] what all did you do to LC-39 2-ish years ago? [14:06:03] I made it flat around the launchpad [14:07:56] why not make that whole texture part of the terrain texture (surf) [14:09:06] I'll tell Jordan to join us here, then you two can talk who does the fixes that make the PR work properly. That is easier than my PM folder on the Orbiter Forum filling up to maximum [14:09:35] ok [15:11:15] ah fun, I have an actual program listing for sextant/scanning telescope/boresight calculations [15:47:27] oh that sounds convenient [15:48:00] Panel 2 comp lights are in [15:48:01] https://www.dropbox.com/s/3y5j0jk90bjpdmi/Screenshot%202020-05-18%2009.47.30.png?dl=0 [15:48:07] thats in the lit state [15:49:27] looks great [15:57:31] oh btw, about having to use a different sign for the AGS FDAI roll axis [15:58:08] we were using 1.0 - attitude.x / PI2; which worked great for the PGNS but not for the AGS [15:58:31] but I tried -attitude.x / PI2; and now it works great for both [15:59:02] interesting [15:59:50] oh and the AGS FDAI was very jerky [16:00:11] found out it didnt like all that FDAI_proc_last stuff so I removed it and now its smooth [16:00:44] with both of these issues I have the feeling that something else is going on :D [16:01:15] probably means that the animation is running every timestep, but to be honest animations are very light on demand it seems [16:01:43] We'll see about that when we have a fully working cockput [16:01:45] cockpit [16:01:56] I have quite a few animations running already and still maxed at 144 fps [16:01:57] ok [16:02:09] especialy the CSM should be a nice performance test :D [16:04:03] I really think the performance killer is when you have a lots texture bliting [16:04:18] my goal is to have the least of that as possible for the VC [16:04:52] yeah makes sense [16:07:28] it also means I dont have to convert our entire bmp stash to DDS :D [16:08:36] oh I have a question for you about DDS textures [16:08:53] it is said that they should always be power of 2 [16:09:08] ie 64x64, 128x64, 1024x512 etc [16:09:22] but I am wondering if that is really necessary [16:09:36] probabl for performance, if it's not strictly necessary [16:09:47] I keep hearing its more for much older graphic cards that had trouble with it [16:09:54] right [16:10:41] they work perfectly fine on my system, even if I keep them at non-standard dimensions [16:11:02] and some can be annoying to covert. IE the tape meter [16:11:18] the bitmap is ~6100 pixels long or so [16:11:42] but that means I have to bring it to 8192 pixels [16:11:50] which of course Orbiter cant read [16:12:24] but right now I am just leaving it at its original dimensions and it works fine [16:14:21] no idea really if it's a problem [16:14:26] in doubt ask on the forum I guess [16:14:41] yeah [16:14:44] tape meter is quite special [16:14:52] Ill do some more research on it [16:15:18] for now its not too important, I am not planning on using very many dynamic textures anyway [16:15:26] not as many as the 2D panel at least [16:18:08] a quick search online seems to say that yes, its important [16:18:26] but Ill ask on the forums to see how it is with Orbiter [16:20:39] I guess alternatively we have to cut up the tape [16:20:55] yes [16:21:00] shouldnt be to hard to do [16:21:29] we have done that already [16:21:33] in two parts [16:33:43] doing the contact lights now [16:34:30] same way as the comp lights, by in-sim material change [16:35:10] I think Ill do the master alarms like that too [16:36:03] morning! [16:37:31] hey Mike [16:37:36] what's up? [16:37:40] I am kind of lost with this particular Sundance mystery :D [16:37:49] I don't know what MARKBRAN does [16:38:28] I don't really either :D [16:39:05] https://github.com/virtualagc/virtualagc/blob/master/Luminary069/DISPLAY_INTERFACE_ROUTINES.agc#L402 [16:39:34] but it's situated in the right place and its return behavior matches [16:39:35] plus [16:39:47] https://github.com/virtualagc/virtualagc/blob/master/Luminary069/DISPLAY_INTERFACE_ROUTINES.agc#L478 [16:40:11] it is the only thing in the entire program that writes anything nonzero to R1SAVE [16:40:42] and Luminary 69 has nothing at all that does so... even though R1SAVE wasn't deleted for being unused until Luminary 1D [16:42:01] and it is called in V83? [16:42:46] yeah [16:43:20] https://github.com/thewonderidiot/sundance/blob/master/b6_306.disagc#L2110 [16:43:28] U10,2771 as I have it labelled there [16:49:56] would there be any reason for only 1 contact light to be illuminated? [16:50:27] or are they wired to always come on together? [16:51:55] they are slightly differently wired [16:52:01] are you only getting one? [16:52:10] no still making them [16:52:31] but yes, it can be the case that only one is ohn [16:52:32] just so I know if I make them separate or the same material [16:52:32] on [16:52:40] so separate it is [16:53:29] they get powered by different CBs [16:54:17] Hi guys. I briefly introduce myself. My name is Iordanis or Jordan for short. I live in Germany. I am currently working on the Mobile Launch Pad and Launch Complex 39. Some of you already knows this. Since my English is not the best, I will use Google Translate more often. So if there are spelling mistakes from me then don't complain to me, [16:54:18] right [16:54:18] complain to google :'=D [16:54:36] Welcome! [16:54:38] No problem [16:54:41] hey [16:54:46] hi Jordan! welcome to the channel :D [16:55:13] indy91 is German too so you can talk to him if there are translation issues ;) [16:55:20] thanks a lot. [16:55:32] yeah we have been talking in German via PMs in the Orbiter Forum a lot [16:55:34] i know indy91 a while [16:55:37] ah nice [16:56:28] I just thought that Alex and Jordan could talk a bit about that remaining texture issue [16:57:24] sure [16:57:35] can I send pictures here? [16:57:45] sure, any links are fine [16:58:08] Alex you made the area flat. Only at the launchpad or also a bit around it? [16:58:09] i mean directly from my computer [16:58:12] and on what level? [16:58:38] hmm, I don't think you can send files like that in IRC [17:00:03] I briefly switch to my pc where I installed orbiter. I'll be right back [17:04:42] hmm its been a while, but I believe it was the launchpad and the whole area around it (where the new texture sits) [17:05:27] so why is it flickering like that if it's all one level? Isn't it caused by some terrain getting into the texture there? [17:06:12] probably [17:06:39] Jordan, what about making that texture part of the terrain surf folder? [17:07:51] thats how Dr Martin S. suggested to handle surface textures in Orbiter 2016 I believe [17:08:09] btw I gave it your branch a try already, it looks amazing! [17:08:22] it flickers because it is a mesh and not just a texture. [17:09:40] look here its a blender rendered image http://www.imagebam.com/image/1794c01341235220 [17:10:58] the whole area is modeled. [17:11:07] right [17:11:38] maybe one thing we could do is raise everything just enough to be compatible with the Elev_mods? [17:12:12] would have to rasie the touchdown points by the same of course [17:12:15] raise* [17:14:35] I've already done it and it works. but I have gaps at the bottom of the floor. it is difficult to do it so that there are no gaps. [17:15:07] hmm o you have a picture of that? [17:15:10] do* [17:18:21] wait i make some screenshots [17:23:14] ok picture are here https://onedrive.live.com/?id=505B1CE5F80D194%21165&cid=0505B1CE5F80D194 [17:23:40] ignore the zip files they are my old mlp and lc39 meshes [17:25:18] look at the pics from above this is how it look now with elev_mod enabled [17:26:12] hmm dont have access to the images it seems [17:26:55] sorry wrong link :-( https://onedrive.live.com/?authkey=%21ADSB7HuS9K06tf4&id=505B1CE5F80D194%21165&cid=0505B1CE5F80D194 [17:29:55] So see the first image capture_001 because you can see the gap very well. from the top you don't really see anything unless you go deep. [17:30:04] all those are with elev_mod enabled? [17:30:28] ah yes I see [17:32:34] thewonderidiot, ever seen a list of all 400 Apollo navigation stars? [17:32:46] I thought I had one, but it's not complete [17:33:17] elev_mod is enabled [17:35:29] I can leave it that way and I can adjust the tanks, tubes and the rest of the details, since it is not visible from above. [17:36:06] hmmm [17:36:29] not that I can think of, but I may have gone right past one and not noticed [17:36:30] later if there was another solution I could correct it again [17:41:10] Jordan, I am switching to your branch to have a better look [17:41:58] wait i have to update it [17:42:37] you have another update? [17:45:14] yes and no. just for testing purpuses i raised the groud of lc39 to avoid textur errors [17:46:08] ah, ok [17:46:19] AlexB_88, you can switch to specific commits if you want to compare [17:48:49] Ok git has the new Testing LC39 [17:51:52] ok [17:53:27] ah yes much better [17:53:48] Ignore all objects that are on the floor. they all seem to be sunk in the ground. [17:55:07] yeah [17:55:35] I see what you mean about the gap when you look from ground level at the extreme ends of the mesh [17:55:55] i think floor should be translated as ground [17:56:09] right [17:56:23] from above it looks ok [17:56:26] I mean, you really have to be at the right angle to see it [17:56:29] yeah [17:57:13] do you think we can lower the Elev_mod? [17:57:22] 50cm or 1 meter? [17:58:25] hmm good question [17:59:31] otherwise I can leave it as it is and put all other objects that are sunk higher [18:00:07] I had made those originally so that the launchpad would be flat to help stabilize the LVIMU for liftoff [18:00:57] I remember you had to play with certain colours to adjust the height of it I think but it was very crude [18:01:05] I dont know if it would be easy to be precise [18:03:22] brb im at phone [18:04:50] indy91, what if we can find another way to make the LVIMU work without the elev_mods? [18:05:08] I think it wasn't a big problem for LC-39 actually [18:05:18] the main issue we had there was a LVDC bug [18:05:21] really [18:05:30] maybe we can test a few launches without it [18:05:34] I will [18:05:43] LC-34 definitely needs to be made flat though [18:05:57] yes that I remember [18:07:06] indy91, what is the git command for the specific commit you mentioned? [18:07:23] you checkout with the commit ID [18:07:48] like, 1ee3a35bd2e42bb1e0d223d30ec3796506891ef9 [18:07:53] git checkout 1ee3a35bd2e42bb1e0d223d30ec3796506891ef9 [18:07:59] for the previous commit [18:08:00] ok [18:08:02] before today [18:10:48] I am testing the original mesh height, with LC39B [18:10:52] Apollo 10 [18:10:57] it also has bleeding textures [18:11:08] so we would have to remove that elev_mod too [18:11:13] yeah looked quite the same from the distance [18:11:19] so test launches from LC39A/B [18:11:20] on 39B [18:12:05] I mean, you can probably see it with the HUD if it's off a bit [18:14:08] right [18:14:19] looks pretty spot on in the HUD [18:14:40] now LC-34 as comparison... [18:15:09] oh, hmm [18:15:26] I think it's spot on because we aren't applying the small force anymore [18:15:34] so the physics of it haven't started yet [18:15:52] well [18:16:01] it stays in its initial attitude [18:16:09] touchdown points aren't doing anything yet [18:16:37] yeah [18:16:47] if do a quick RCS hotfire test it's 3° off on LC-34 :D [18:18:32] the good thing is, GRR happens before any force would be applied [18:18:35] normally at least [18:19:39] ok so LC-34 is 698 [18:19:39] LC-39A looks pretty spot on still after I apply a force [18:19:44] we can keep that one [18:19:55] 699 is LC-39A/B [18:20:01] my test with 39A looks good [18:20:30] oh you know I think I 699 might be LC-39A only [18:20:51] I dont think I touched 39B maybe since it wasnt an issue there [18:22:04] yeah 39B is good too [18:22:28] I agree [18:22:40] I guess we should do some launch tests anyway [18:22:56] right [18:23:08] some time we can implement the real method to give the LV IMU an alignment [18:23:19] there were some alignment targets on the ground [18:23:23] it was a whole process [18:23:53] but I would just need to use the actual attitude before GRR to calculate the initial attitude [18:24:02] right [18:24:08] not easy, but doable [18:24:22] that would be good also, since right now the RCS is active before launch [18:24:38] so if the launch tests are good, I would suggest we remove the Elev_mode stuff from LC-39A and B [18:24:42] and if you fire a thruster, the whole rocket might move a tinny bit [18:24:50] yes [18:24:58] that would be folder 698 [18:25:00] simplest solution [18:25:06] back in a bit [18:25:19] 698/001130.elv [18:29:03] Jordan, so yeah we are thinking of getting rid of the LC-39A elev_mod file [18:29:21] just need to do some test launches and if its good we can use the original mesh height I guess [18:35:05] ok. [18:35:06] I still have a problem that may need to be solved.Die ML sitzt nicht genau auf der LC39. Siehe dir mal die Bilder die ich vorhin verlinkt habe und zwar die beiden mit den ML ecken Nr 4. Die eine ist die süd und die andere die nordseite. Man sieht das die Nordseite höher ist als die südseite. [18:35:33] I still have a problem that may need to be solved.The ML is not exactly on the LC39. Take a look at the pictures I linked earlier, namely the two with the ML corners No. 4. One is the south and the other the north side. You can see that the north side is higher than the south side. [18:35:55] Ignore the german translation :-) [18:37:00] hmm, I see [18:37:07] I think the old mesh also had that issue [18:37:16] This could be because the ML is loaded as a mesh and the LC39 in Canaveral.cfg [18:38:34] normally no one will notice it, but I wanted to do it as well as possible [18:40:29] or can we edit the Canaveral.cfg to solve the problems? [18:40:55] these are just some of my suggestions [18:43:18] we can edit the Canaveral.cfg [18:43:32] we don't use the Orbiter "universe", but our own [18:43:41] so it's our own file, not from Orbiter [18:44:22] Config\ProjectApollo\Earth\Base\Canaveral.cfg that is [18:45:59] I took a look at it yesterday, but couldn't do much with it, didn't know what I could change [18:46:40] AlexB_88, you worked on the elevation stuff in November 2017, I didn't figure out the LVDC bug that were causing accelerometer issues at liftoff until June 2019 [18:46:59] and I think that was the majority of the issues we had as compared to Orbiter 2010, it's a 2016 only bug [18:47:48] Jordan, yeah I don't know the file format much either, have to take a look at it [18:55:46] Should I delete the trial version from my branch and upload the original one again? [19:00:49] I guess both versions have the advantages and disadvantages [19:00:54] their* [19:04:59] The newest RTCC display: https://i.imgur.com/s6vU7lF.png [19:06:07] making good use of those greek letters I see [19:06:24] what was this program listing you were talking about earlier? [19:06:59] Θ Ψ Φ my language :-D [19:07:13] hehehe [19:07:19] they could display those on the screens in mission control haha [19:07:29] an internal little program for optics calculations [19:07:54] ran on 1108s apparently [19:08:16] either my FORTRAN is really rusty or I don't recognize that language [19:08:25] hahaha [19:08:26] link? [19:09:25] it has a weird If logic [19:09:35] if (something) 50 51 52 [19:09:39] where those are gotos [19:09:44] I think for me it is better to use the originals because I will add more details and later if there is no other way, raise the ground again. [19:09:48] 50 for <, 51 for equal, 52 for > [19:09:53] I think [19:10:24] thewonderidiot, https://web.archive.org/web/20100523125225/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740072926_1974072926.pdf [19:11:00] Jordan, sure, then revert the change [19:11:21] and I think I'll test if we can survive without the Elev_mod changes to LC-39 [19:11:52] and if yes, I'll merge your PR and remove the elevation changes in a commit just after [19:12:09] huh, interesting [19:12:21] OK. [19:12:32] I say goodbye for today. Tomorrow work is waiting for me again :-( [19:12:41] was good to have you here! [19:12:49] we are so very close to merging your work haha [19:12:53] (y) [19:13:44] That was a work of about 10 months [19:13:54] bye [19:14:01] goodnight! [19:14:25] also interesting in that document, Block I IMU was aligned with the sextant base [19:14:43] I might have known that at some point [19:15:13] hmm [19:15:21] it just says stable member coordinates [19:15:45] well anyway [19:15:49] recognize the language? [19:15:57] back in a bit [19:23:52] nope [19:23:53] lol [19:24:11] I'll see if Ken, Marc, or Carl do [19:25:00] I mean, I don't need to run this, I understand both the logic presented earlier in the document and I can read the code enough [19:25:06] but it would be interesting to know :D [19:26:23] and I found a list of navigation stars up to octal 236 [19:26:31] so nearly half I have at least [19:29:01] I think they are sorted by magnitude, the last 100 ones might not even be visible in Orbiter [19:29:35] but lots of the other non-AGC stars can be used for alignments [19:53:22] hmm [20:15:47] ok there are settings in Orbiter for the magnitude of stars [20:16:06] you can get "a few" more if you mess with that: https://i.imgur.com/Vsb9aNn.png [20:17:31] the Orbiter star catalogue doesn't come with names attached to them, so I can't get my data from there [20:17:47] hahaha oh man [20:17:48] hmm [20:17:56] yeah I haven't found any big lists [20:18:19] oh I have found very big lists [20:18:30] but it's a question of converting the data [20:19:29] the RTCC had declination and right ascension angles loaded, which were converted to unit vectors at RTCC program initialization [20:20:17] as there is no constraint for using hardcoded AGC numbers I would like to use the same numbers as Orbiter uses, for best precision [20:22:46] back [21:02:37] night! [23:35:28] Christmas in May [23:35:31] https://www.dropbox.com/s/e1rzezj459w7eob/Screenshot%202020-05-18%2017.34.51.png?dl=0 [23:51:55] niiiiiiiice :D [05:08:10] indy91, is INITVEL something that would be in the GSOP? [05:48:55] thewonderidiot, yes, PDF page 221. And if you are looking for a late change, you might already find it on that page [05:50:26] oh nice! [05:50:27] thanks :D [05:51:39] no problem [05:56:33] hmm [05:56:37] not sure this is going to help [05:56:50] in Sundance it uses a flag [05:56:53] B29FLAG [05:56:56] to determine scaling [05:57:03] it doesn't look like this has that level of implementation detail [06:00:32] "INITVEL was modified to use RTX1 and RTX2 instead of X1 and [06:00:33] B29FLAG." [06:01:57] I like that the GSOP doesn't have that level of details, it means I can understand it :D [06:02:09] hehehe [06:02:17] oh one thing it does do though [06:02:30] that maybe will show up [06:03:10] https://github.com/virtualagc/virtualagc/blob/master/Luminary069/P34-P35%2C_P74-P75.agc#L1190 [06:03:21] INITVEL3 uses MUEARTH there [06:03:30] in Sundance it is a completely different constant [06:04:02] the only one that matches its value in Luminary is this one: [06:04:03] EPSFOUR 2DEC .0416666666 [06:06:04] there's also a long lead-in to it that I don't have a name for [06:07:31] are Lambert and Initvel subroutines as separated in code as in the GSOP? [06:08:37] uhh [06:08:47] INITVEL is in bank 11 while LAMBERT is in bank 12 [06:08:51] in Sundance [06:08:54] not sure if that's what you mean [06:08:55] lol [06:10:26] I meant logically separated [06:10:30] but that means yes [06:10:50] and of course there is the P34 code itself that calls Initvel [06:10:55] PDF page 168 [06:11:35] yeah [06:12:00] probably won't be able to say more about this prefix until I get to that [06:14:08] EPSFOUR looks more like the constant that checks on the 180° singularity [06:14:12] maybe [06:16:21] EPSF0IJR: Double precision constant stored as 0.0416666666, scaled [06:16:21] BO in units of revolutions. Equation value: 0.0416666666. [06:16:22] (Equivalent to 15 degrees.) [06:16:34] yep, it's that [06:16:35] yeah [06:16:36] not a MU [06:16:40] right [06:16:50] so it's interesting that INITVEL is referencing it here [06:17:06] mu or EPSFOUR? [06:17:11] EPSFOUR [06:17:18] where Luminary and Colossus use mu [06:17:36] in the GSOP EPSFOUR is an input to Initvel [06:18:33] at the beginning of INITVEL3? [06:18:43] ah yes, you wrote that [06:19:05] and also in this mystery prefix [06:19:10] what does it do with MUEARTH there? [06:19:11] https://github.com/thewonderidiot/sundance/blob/master/b2_302.disagc#L3871 [06:19:39] divides it by UN [06:19:44] in INITVEL3 [06:19:52] I think? [06:19:57] wait maybe not [06:20:13] I really need to learn interpretive code better [06:20:30] PDVL [06:20:34] push down and vector load [06:21:19] ......not sure [06:22:23] I have to go, I can look at it again later [06:22:30] and I have to go to bed :D [06:22:38] talk to you tomorrow, haha [06:22:40] goodnight! [06:22:43] cya! [12:14:50] good afternoon [13:09:03] hey [13:19:18] hey Alex [13:21:54] two more features I figured out that this GOST display has [13:22:11] can show unit vectors for any star in the star catalog, usable by the AGC [13:22:32] and the same for landmarks. You input lat/long/altitude and it also gives you a unit pointing vector for the sextant [13:22:48] Morning gents [13:23:07] hey [13:23:14] indy91, nice [13:23:35] still working on a good system to build the star table [13:23:40] so I guess the pointing vectors would help for the GDC align angles? [13:24:24] oh that's mainly for P52 or any kind of alignment check where the stars in the AGC aren't visible [13:24:34] oh right [13:24:59] backup alignment is a different part of this display [13:25:19] not quite sure yet how they got the ASCP angles, but I'll figure it out [13:25:28] might even be a different display [13:43:30] ha, I successfully automated building the star table [13:43:58] I just need to create a file with a list of Smithsonian Astrophysical Observatory Star Catalog numbers [13:44:16] and it searches through the catalog and builds me the unit vector table in RTCC coordinates [13:45:50] awesome [13:46:12] now please send me that system for adding the switches in the VC :D [13:47:20] I mean, it's probably possible to automate that somethat [13:47:31] minimize the number of functions and stuff you need per switch [13:49:56] its not that bad actually [13:50:25] the longest part is finding the vectors for all the individual sitches [13:51:43] I might go in after the fact and make the code a bit cleaner, but yeah, if that is the lengthy part then the process can't be improved that much [13:56:30] sure [13:57:37] I have all the comp lights, master alarm, contact lights and power fail lights working now [13:58:16] https://www.dropbox.com/s/e1rzezj459w7eob/Screenshot%202020-05-18%2017.34.51.png?dl=0 [13:58:53] yeah I saw this morning, awesome stuff [13:58:58] now working on indicator needles [14:00:05] and then Ill add all the switches/rotaries on panel 1/2 [14:00:35] after that its just the abort switches and panel 1/2/3/4 is pretty much done [14:08:47] lots of repititions on panels 1 and 2 at least [14:11:43] yeah [14:13:12] annoying double stars, I don't know which catalog number to use :D [14:18:05] halfway done, time for a test run [14:21:32] it found Schedar and Delta Cassiopeiae for the boresight check, both famous Apollo navigation stars :D [14:22:17] cool [14:22:48] by default it starts searching with star 1, will look at the AGC stars first [14:22:59] but you can give it a starting star where it begins the search in the table [14:23:27] so normally it would have found stars 1 and 3 [14:24:51] but instead it found 122 and 130 [14:31:47] makes sense [15:28:20] indy91, I have a question about the needle animations [15:29:17] sure [15:29:25] each needle has the same animation length, but each individual gauges are not necessarily the whole range of it, some are shorter ranges (but no longer I think) [15:30:17] I am trying to utilize the minValue/maxValue of the switch class to scale the animations [15:30:29] for example the RCSA temp indicator [15:30:45] in that class I created LMRCSATempInd::DoDrawSwitchVC(UINT anim) { [15:31:37] accessed only by the clbkVCRedrawEvent, case AID_VC_PANEL2_NEEDLES taht I made [15:31:54] so I send the animation to that function in that class [15:32:01] right [15:32:41] and I am wondering what equation I can use that includes the minValue/MaxValue to scale the call I make to GetDisplayValue() [15:33:25] here is the function in LMRCSATempInd [15:33:27] https://www.dropbox.com/s/qrwdbp24zv37h9y/Screenshot%202020-05-19%2009.32.57.png?dl=0 [15:33:53] so I have maxValue in there, but I think it needs to know to start from minValue too [15:36:19] you want maxValue as 1 for the animation and minValue for 0 [15:36:31] hmm [15:36:49] all needles have the same translation range [15:37:06] but some of the indicators, the range is smaller then others [15:37:28] so for some of them I dont want them to start at 0 or finish at 1 [15:40:24] y = y0 + (x - x0)*(y1 - y0)/(x1 - x0) [15:40:32] x is GetDisplayValue [15:40:38] x0 is MinValue [15:40:41] x1 is MaxValue [15:40:51] y0 is your minimum animation state (normally 0) [15:41:00] y1 is your maximum animation state (normally 1) [15:41:29] right [15:41:35] I think I have it [15:41:44] I am using double v = GetDisplayValue() / (maxValue + minValue); [15:42:05] that seems to work perfectly [15:42:49] yes, that's the same thing with y0=0 and y1=1 [15:43:05] uhh wait [15:43:17] maxValue + minValue [15:43:25] shouldn't it be: maxValue - minValue? [15:43:28] actually not perfectly haha [15:43:39] yes [15:45:37] also needed GetDisplayValue() - 20 [15:45:54] ah right haha [15:45:55] the 2D panel redraw does the same v-20 [15:46:03] so double v = (GetDisplayValue() - 20) / (maxValue - minValue); [15:46:04] well, my equation above is the general case [15:46:10] but it works! [15:46:12] thanks [15:46:22] isn't 20 the minValue? [15:46:40] better use minValue then [15:46:42] yeah I guess this is in the specific Switch class but I wanted something that could work for all [15:46:43] right [15:46:59] v = (GetDisplayValue() - minValue) / (maxValue - minValue) as the special case of scaling to 0 to 1 [15:47:17] got it [16:47:48] holy crap, the CO2 meter is a scaling nightmare lol [16:49:16] when I looked at the CSM one it actually seemed like it's all in the sensor [16:49:32] or should be at least [16:50:01] so the CO2 leve to voltage conversion is the one that should be a bit more complicated [16:50:07] not sensor voltage to needle [16:50:19] morning! [16:51:37] hey [16:52:03] hey [16:53:14] and it even depends on cabin pressure [16:56:12] what we have for the CSM is a document called Operational Calibration Curves [16:56:20] basically converting telemetry back to engieering values [16:56:30] and that's where I noticed that the CO2 meter is not linear [16:56:42] so there is probably nothing really special about that meter [16:56:58] how similar are the CSM and LM ones... [16:58:32] quite similar [17:02:36] but it probably shouldn't be changed right now [17:02:56] even if it's more work, not too many projects at once is better [17:04:21] I can probably just reuse the same code for the DoDrawSwitchVC [17:04:29] with a few adjustments [17:05:27] yeah [17:05:46] and I'll adjust the sensor and display code some time later [17:06:03] would be a quadratic function [17:06:32] ok [17:08:00] the RTCC has 5 numbers stored for the calibration of every single measurements [17:08:03] that adds up :D [17:23:53] wow [17:56:49] hi @all [18:00:01] Hello there [18:01:33] hey Jordan [18:02:15] guten abend dr jones ;D [18:03:48] good morning! [18:03:53] Uh oh AlexB_88 they are going to start talking about us in German [18:04:14] today i made some unorthodox attempts to solve the graphic bug, but unfortunately without success. [18:04:23] hey [18:05:15] I actually just watched the Indiana Jones franchise this week [18:05:49] rcflyinghokie, haha [18:05:51] hahaha [18:07:14] I'll do some launches just now to see how flat the Saturns really need LC-39 to be [18:07:46] Jordan, is this still the misaligned support pillars you mean? [18:09:23] that too, but that's not so important to me, not yet [18:11:42] I noticed that this problem exists longer in NASSP [18:13:51] I thought about connecting the ml with the lc39 as a mesh to see how it works [18:17:55] Without Elev_mod: SV Accuracy: 121.860747 [18:18:45] I almost don't need to continue testing, that is quite good [18:25:10] Jordan, that means I am close to merging your PR. One more question, the files are all called LC-39A, do they apply to LC-39B? [18:30:00] Ok I think I am on a good path to stabilize the LM primary glycol loop [18:30:13] Managed to target and shrink valves quite a bit [18:30:24] as far as I know, the lc39a and b are the same in nassp. everything that is in a also affects b. if I understand your question correctly. [18:30:59] yeah, that's what I meant haha [18:31:08] With Elev_mod: SV Accuracy: 123.974269 [18:31:27] so flattening LC-39A had essentially no effect [18:31:45] back then we were chasing a problem that turned out to be a different issue [18:31:58] Jordan, your reverted your experimental changes? [18:32:01] you* [18:32:16] yes [18:32:27] done that yesterday [18:32:39] your PR is merged [18:32:54] (y) [18:32:59] :D [18:33:10] and I guess now we should delete those Elev_mod's for 39A and B [18:33:24] AlexB_88, which areas were that again? [18:33:26] yes [18:34:06] there is 698 and 699 [18:34:18] so you can delete the 15/000698 folder [18:34:28] 689 is LC39A/B [18:34:35] 698** [18:34:41] 699 is LC34 [18:34:47] alright, will do [18:38:35] so I can continue to work as before. I have a few things to add to the mesh. [18:40:41] by the way. how is the performance? [18:41:03] quite good [18:41:26] did you do some improvements to that since your initial version? [18:42:26] and the elevation file has been removed. I checked, no problem with the texture [18:43:14] so the update is all done [18:45:19] something is always added. I want to add the pipes that are distributed throughout the area and renew the remnants from the original nassp lc39. [18:46:40] oh yeah, but I think now we won't have any issues like that texture or many code changes to the ML to check [18:46:50] so your next updates should be easy to merge [18:47:11] There are still a few gfx glitches. there are some hills that I have to build because they cause problems [18:48:19] the ml code is finished. i can now update the meshes without problems [18:49:35] there is always more to do, in most NASSP departments [18:51:04] yeah. i still wait for virtual cockpits. [18:51:11] Alex is working on it [18:51:22] my next updates will only affect the meshes and maybe additional textures. [18:51:57] I already noticed that alex is working on it [18:53:27] I am liking the orbital integration code a lot so far. giant chunks of interpretive code with no differences from Luminary [18:53:58] With this updated ML I kind of want to check how the rollout is working now. Driving around that nice looking ML with the crawler :D [18:54:31] thewonderidiot, yeah, Sundance is fully lunar orbit compatible, so I wouldn't have expected many differences to Luminary 69R0 [18:55:54] if it wasn't lunar orbit compatible there wouldn't be any hope for P10/P11 to work [18:57:25] Jordan, so when can I expect a Mobile Service Structure update :D [18:57:30] Nah, just joking [18:58:50] i wanted to do this also, maybe later. sehr viel später. ;D [18:59:32] around the same time when NASSP has two full virtual cockpits [19:00:23] my dream is nassp with vr googles [19:02:20] and then multiplayer, one person flying the CSM, the other the LM [19:02:44] So while I have stable glycol now...my small valve sizes reduce the flow rate [19:02:58] and the third one walks on the moon [19:03:30] rcflyinghokie, yeah that sounds familiar [19:03:57] Yeah [19:04:49] i played apollo 11 vr on the playstation. dammit. that was a dream [19:05:14] Reentry - Orbital Simulator would be a good candidate for VR, but I don't think it has that [19:05:20] no only track ir [19:07:01] track ir is very good too :) [19:09:46] ok before i go, one more thing. you remember the texture copies that I have. we should delete them. they were originally intended for the ml platform and some small objects. this ml has a completely new texture and in my opinion it looks much better. that means these metal textures are only applied to small objects. because the copies no longer [19:09:46] make sense, since the textures are not so noticeable in small objects we can delete them. [19:11:07] ok, no problem [19:12:56] So then. tests a lot and tells me if there are any problems [19:13:35] will do! [19:14:55] good night, good morning or good day. [19:15:47] thanks for the great update [19:15:49] cya! [19:30:38] finished the panel 2 meters [19:31:48] I tried with the CO2 meter scaling but I couldn't get it to work right, so right now I have it without the scaling just 0-1, 1:1 ratio' [19:32:04] and I will probably revist it in the coming days [19:32:20] next up, panel 1 meters [19:38:48] I upped the primary glycol loop heat now the heat exchanger heats the suit loop lol [19:38:57] Still more balancing with flows [19:39:06] And tank sizes [19:39:38] But now the loops are warmer than the suit loop and then get cooled via evaporator [19:41:27] so the suit temp selector will work right now? :D [19:47:42] well thats the plan [19:51:51] problem now is they get too hot lol [20:00:23] making progress though [20:00:34] the pump stability is there at least [20:00:55] I am not going to sweat the flows right now if I can get the behavior correct [20:03:10] But I am stopping for the day, certainly seeing progress [20:04:32] lots of changes in this branch lol [20:39:57] night! [20:41:30] ECS: Environmental Chaos System :D [21:00:53] Amen [21:01:20] In the CM its the Environmental Cheaty System [21:02:09] hehehe [14:14:07] hey [14:19:25] hey Alex [14:20:29] https://www.dropbox.com/s/8dg16ql2l4frye7/Screenshot%202020-05-20%2008.19.47.png?dl=0 [14:20:42] all panel 1/2 switches and rotaries now working [14:21:56] awesome :D [14:22:12] I have the unit vector display on the GOST done [14:22:29] can give a vector usable by the AGC for any star, the sun or Earth/Moon landmarks [14:25:40] looking at backup GDC alignments now [14:25:52] I think we have very wrong scanning telescope reticle... [14:30:45] right, I remember you finding a document which showed that [14:32:58] well, one issue is that the reticles should probably rotate from the astronaut perspective [14:33:13] but in the case of the SCT the reticle patterns are also not really correct [14:33:36] the backup GDC alignment as in the Apollo 11 Operations Checklist can't really be done that way [14:35:51] I guess we should remove the reticle from the bitmap and draw it dynamicalls like the AOT [14:36:17] I think I actually started trying that [14:36:23] have to do that again some time [14:45:41] the very first thing GUIDO did on the Apollo 11 audio loop is definitely backup GDC alignment related [14:45:48] -20:44:14: GOST, Star 1 as 35, shaft 180, trunnion 32.5°, star 2 is star 30, shaft 180, trunnion 8.7° [14:45:56] the stars are Vega and Deneb [14:46:07] the difference in trunnion is the angle separating the two [14:49:02] right [14:51:06] 32.5° is the trunnion angle to point exactly on an CSM axis [14:51:10] hmm [14:51:52] the center of the reticle actually has the marking 25°, and you would have one star at the 50° marking [14:52:15] doesn't really look right compared to the checklist [14:52:35] well, I still have some things to figure out how to work with this display :D [15:07:10] oh I finally figured out who is callsign YAW [15:07:21] second guidance officer [15:07:44] that's why there are different people talking on the left and right channel of the GUIDO loop :D [15:48:21] even the AFJ gets it much more correct than us [15:48:22] https://history.nasa.gov/afj/ap11fj/pics/gdcbackup.jpg [15:49:39] yeah [15:50:02] I havent been in the CSM in so long I almost forgot what ours looked like lol [16:24:08] uhhhh [16:24:23] "telescope_view.bmp" [16:25:42] https://raw.githubusercontent.com/orbiternassp/NASSP/Orbiter2016/Orbitersdk/samples/ProjectApollo/Bitmaps/Obsolete%20Bitmaps/telescope_view.bmp [16:25:48] that's under obsolete bitmaps [16:26:01] the lines are too thick of course, but that's essentially the correct reticle [16:26:06] why don't we have something like that :D [16:26:36] interesting [16:40:37] going to start the abort switches [16:41:00] with a nice 3D cover :D [16:45:15] :D [16:45:35] after that it will be pretty done for panels 1-4 [16:47:18] after a bit of house-keeping work I think it will be good to bring to the main branch as "phase 1" of the LM VC [16:47:46] Phase 2 is going to be texturing and making the interior itself [16:48:00] then phase 3 is the rest of the panels [17:18:54] LPD would be nice [17:19:03] morning! [17:19:24] hey Mike [17:19:28] what's up? [17:20:14] we have a very wrong scanning telescope reticle, experimenting with replacing it [17:20:22] hahaha [17:21:43] I was working on this MCC display that had angles for a backup GDC alignment using the telescope [17:21:48] indy91, oh yeah for sure that will come [17:21:56] so I revisited the procedure and noticed how wrong it is [17:22:14] hey Mike [17:22:17] under obsolete bitmaps we actually have a bitmap that is a lot more correct :D [17:22:23] https://archive.org/stream/apertureCardBox463NARASW_images#page/n1442/mode/1up [17:22:28] but its lines are too thick and all [17:23:14] ah yes [17:23:18] thewonderidiot, main panel is almost done! [17:23:19] https://www.dropbox.com/s/8dg16ql2l4frye7/Screenshot%202020-05-20%2008.19.47.png?dl=0 [17:23:22] I had some of that info from the Delco manual [17:23:37] AlexB_88: oh wow, awesome!! [17:24:11] I can already see the feature request from Mike for the VC [17:24:17] both versions of the AGC cover :D [17:24:27] hahaha [17:26:25] there seem to be a bunch of pages with the reticle in the drawings [17:34:18] looks like lots of revisions of the same drawing -- unless I'm missing some others [17:35:03] doesn't look like anything important changed [17:35:28] yeah, I think it would have been given a dash number if something did [17:36:28] that part number was just 2011806, all the way from 2TV-1 to Skylab 4 [17:38:07] good to know [17:38:43] but what about CSM-119 :D [17:39:38] also 2011806 :D [17:52:19] oh also, the KEPLER routines were giving me real trouble last night [17:52:28] before I realized they matched Colossus and not Luminary [17:56:31] haha [17:56:52] how is even Kepler different between Luminary and Colossus... [17:58:08] also I found a place where they used the wrong instruction [17:58:21] an LXA (uncomplemented read) instead of LXC (complemented read) [17:58:27] so there's a sign error in there [17:58:41] so that's a candidate for something that may have been fixed between 302 and 306 [17:59:05] ouch [18:10:16] hello [18:11:14] hey Jordan! [18:12:30] any news? did you test the new ml and lc39? [18:13:13] hey [18:13:22] well not much new to test [18:13:46] already did that some days ago, before it got mergedf [18:16:00] now that I look at it... [18:16:07] should the tail service masts have textures? [18:18:29] no. they are only single colored. but it is posible to texture them [18:18:45] ah ok [18:18:54] it's ok, just making sure it's not a forgotten texture [18:19:19] but yeah, it looks great, the animation work. No flickering texture... [18:19:24] all working great :D [18:20:03] back in a bit [18:20:07] did you test the ml transport with the crawler? [18:21:01] not yet [18:21:22] just saw your private message in German, I was confused why my chat client was blinking but no message here :D [18:25:43] hey Jordan [18:25:55] hi alex [18:26:24] i want test results, any news [18:26:25] Im quite busy with the LM VC, but I had a look around at the new LC39/ML [18:26:30] very nice indeed [18:26:38] thanks. [18:26:49] btw its not finiushed yet [18:26:58] right [18:26:59] *finished [18:27:10] here is a preview of the LM VC: [18:27:11] https://www.dropbox.com/s/8dg16ql2l4frye7/Screenshot%202020-05-20%2008.19.47.png?dl=0 [18:27:53] I have most all main panel switches working, now working on the abort buttons [18:28:46] looks good. [18:28:56] Im using Blender too btw [18:29:28] 2.79 still haven't migrated to the new version [18:29:29] blender is the best free software available [18:29:36] I love it [18:30:04] ml and lc39 is my first big project with blender [18:30:51] if you need some help with modeling the vc tell me, maybe i can help [18:31:01] yeah, same. I learned how to use it doing the LM Ascent/Descent stages last year [18:31:11] ok sounds good [18:31:57] Im definitely getting better as I go, but still lots to learn :D [18:32:19] make the next step and switch to 2.8 its a lot better [18:32:43] yeah I think I will do that soon [18:33:11] hows the exporter for it? [18:33:15] i stil use sometimes 2.79 because i have a script( not mine) for calculating vectors [18:34:42] Blender Orbiter Tool is very good better then vlads exporter. i had a lot of ideas and blade the programmer implemented all of then in his exporter [18:35:00] oh nice [18:35:09] thats good to hear [18:35:39] I like vlads exporter but I find it has a few quirks [18:36:19] sometimes the normals get screwed up in the export it seems [18:36:47] he has a good tutorial just follow his instruction and you will see that it easy [18:36:55] right [18:37:54] what would be useful for me is a way to get vectors for the pivot point of my switches, in a more automated way [18:38:44] right now I copy the vectors 1 by 1 from the switches in Blender, and of course need to do the conversion as Orbiter's orientation is different [18:38:47] vlads exporter is for long time not more maintained but blake still work in his exporter if neccesary [18:43:43] the rotation vector of the tail service masts was a mess in nassp. i had a lot of problems to find a way to make them rotate properly. they was rotated only in x or y axis and thats was wrong. they are also slightly rotated in z axis (blender cordinates) with a script that i found i can calculate the exactly rot-axis. [18:44:40] u can see the difference in old and actual ml code [18:45:42] I knew I would break something for the Saturn assembly [18:45:55] some unsafe code in the S-IC electronics, good that I found it [18:46:06] but now I have the new ML mesh in the VAB [18:49:27] there is probably a lot of new code that shouldn't be run before the Saturn is at the launchpad [18:50:58] coding is not my world :-( Ich verstehe nur bahnhof :-) [18:51:23] I'm ok at it [18:54:13] in reality service arm 3 retracts before 1 2 and the others. i thinking to combine it with the animation of the colby crane. is it ok? [18:56:18] yes [18:56:29] we talked about it in a forum post some months ago [18:56:38] " I checked my Saturn documentation and the primary damper (which it is called in the Saturn countdown documents) is connected after the MSS has been removed, during the countdown hold at T-10 hours. And it is retracted at T-3:38. So rotating it away at the same time as the crane is a good solution for now." [18:56:44] oh wait [18:56:53] that's not what you were talking about :D [18:57:35] I will check when that is retracted per procedure [19:00:04] service arm 3 has no exactly retraction time [19:01:30] during the countdown hold at T-14 hours is what I have found [19:01:47] if there is a hold there [19:01:55] lots of activites scheduled at that time [19:02:06] so yeah, with the crane is good for now [19:02:27] if found this https://www.quora.com/What-was-the-role-of-the-4-remaining-service-arms-attached-to-the-Saturn-V-just-prior-to-its-launch [19:02:56] ups there is no sa3 :-( [19:04:08] thewonderidiot, did that AS-511 Launch Vehicle Operations document never end up on the Virtual AGC website? [19:05:52] is alex's vc in the new update [19:05:59] ? [19:06:16] not yet, but he said the first part of it can be merged soon [19:06:35] is it in his branch? [19:07:09] can i download and test it? [19:07:20] LMVC is his branch called for it [19:07:29] yeah, it's on Github [19:08:30] you just need to checkout that branch [19:08:40] if you don't know how to do that, I can help you [19:11:30] its ok. i can download it directly from github [19:12:38] ah, download a zip of the code and then build? [19:12:44] zip file* [19:12:58] careful with that, might overwrite files you don't want overwritten [19:13:31] i make first a backup of my orbiter installation [19:14:51] but mostly i want to check his vc mesh. maybe i can help him [19:15:33] there is definitely a lot to do still, only the main panel is even modelled [19:17:37] I am doing this: https://i.imgur.com/gvXKomP.png [19:20:36] the vab needs a lot of work :-) [19:21:03] oh yes [19:21:19] there have been no changes since Orbiter 2006 [19:21:43] in fact, the VAB wasn't at the exactly same location anymore, was updated (fixed I guess) between Orbiter 2006 and 2010 [19:21:59] so just to get this far I had to adjust some positions [19:22:02] needs more fine tuning [19:22:57] and you wouldn't be able to go all the way to launch with this, a lot of things need to be repaired [19:23:08] but I can do the rollout [19:23:49] ah, damper animation works great [19:24:02] shouldn't the service arm have been retracted in the vab? [19:24:06] just had the step where everything is connected [19:24:31] well, I guess they are connected in the VAB [19:24:52] they should probably be connected on each step of the assembly [19:27:19] https://upload.wikimedia.org/wikipedia/commons/3/32/Saturn-V-Apollo-4-VAB.jpg [19:27:34] only sa3 is retracted [19:29:17] ah [19:29:26] https://i.imgur.com/KOZ600V.png [19:30:33] looks good [19:31:49] definitely better than before :D [19:36:23] the pipes are still from earlier they need to be redone or add a few detail to them. i have just make them straighter and rounder [19:37:49] is alex still here? [19:40:40] AlexB_88 [19:41:00] yep still here [19:41:28] finishing up the abort buttons [19:42:20] oh, yeah you can get my latest work on my LMVC branch [19:42:45] Jordan, https://github.com/jalexb88/NASSP/tree/LMVC [19:43:45] i will check this. thanks [19:44:08] take a look at this script. https://www.orbiter-forum.com/showthread.php?t=36375 [19:44:38] with this i can calculate exactly th rot axis [19:44:42] *the [19:45:16] its only 2.79 compatible [19:45:30] oh thanks [19:46:11] that will be useful for sure once I get to the other panels [19:46:26] be warned. its a bit comlicated. [19:46:38] *complicated [19:47:35] i am not surem [19:48:14] ,maybe blake can implement something like this in his exporter [19:56:43] DM-2 crew arriving at KSC [19:56:48] in a Gulfstream? [19:57:03] what happened to T-38s :D [20:05:20] Jordan, all this stuff is hovering in the air at LC-39: https://i.imgur.com/Q5rUy3J.png [20:10:17] the launch pad is missing. these are the other parts [20:11:10] what can you see if you turn around? can you send me the scenario? [20:11:31] oh it's my fault [20:11:35] I was using the wrong universe [20:12:01] old scenario [20:12:59] let's see what it looks like with a fixed scenario... [20:13:18] better [20:13:25] ok. i go to my pc. I'll be right back [20:18:05] im back [20:18:20] well the crawler drover into the mesh, but that was expected [20:18:39] there is some things that haven't really been made Orbiter 2016 compatible [20:18:50] but other than than it worked fine, no issues specific to your mesh [20:18:57] I could load off the ML [20:23:20] can i try this scenario is it in project apollo folder? [20:23:44] no, I had to fix something in code to make it work again. [20:23:57] oh . ok [20:24:03] and the scenario used to be in the NASSP folder, but isn't anymore. I have a temporary testing scenario [20:24:13] I'll push that fix tomorrow or so [20:24:21] well I guess I can already give you the scenario [20:24:35] do you want before assembly or at the launchpad? [20:24:49] before assembly [20:25:29] sure [20:26:28] and I better don't forget to do that solar system fix to the scenario first :D [20:27:30] as I said, that will crash right now, but will be fixed tomorrow [20:28:46] you know what else the joystick slider axis is good for other then the DPS throttle? Testing animations lol [20:29:15] hahaha [20:39:35] https://www.dropbox.com/s/9condwg308uvo2h/Screenshot%202020-05-20%2014.39.10.png?dl=0 [20:41:34] wow [20:41:48] it will open more then that, just need to adjust the range [20:42:00] so now you have a abort stage cover that can be opened with the throttle slider [20:42:54] of course! :D [20:55:27] indy give me the link of your screenshot with the ml in the vab [20:57:50] https://i.imgur.com/gvXKomP.png [21:00:17] https://1drv.ms/u/s!ApTRgF_OsQUFgUbjVxJwb4tN2TW2?e=fldS6M [21:00:58] big difference with mine [21:01:54] i have no shadows and transparency glitches [21:02:21] weird [21:02:58] maybe my d3d9 settings are wrong [21:04:27] and the whole scaffold is missing [21:07:08] any idea why? [21:14:16] well it's getting late, good night! [21:25:00] I also say good night to everyone. see you [05:31:08] located JOBR32 exactly where Sundance 306 told me it would be :D [05:31:13] now to see how different it is from P76 [05:51:57] turns out, nearly identical [14:15:40] hey [14:18:48] hey Alex [14:20:33] I've been trying to make our scanning telescope view work right, no success yet [14:21:09] with the CGI stuff I guess [14:22:08] I'm drawing the reticle like the AOT [14:22:11] that works quite well [14:22:41] I've been trying with the SetCameraDefaultDirection and oapiCameraSetCockpitDir functions to rotate the view correctly [14:23:14] I believe the whole view should be rotating with the shaft angle [14:23:24] and the reticle as well [14:24:05] actually I am also right now using the AOT bitmap [14:24:18] I made a separate panel for testing [14:30:01] hmm [14:30:38] so you mean like "roll" the camera view [14:31:03] yep [14:31:13] and that is what resolved mode is "fixing" [14:31:21] does Orbiter even support that? [14:31:36] badly [14:31:41] but I think it's possible to do [14:32:53] I wished I could just use a rotation matrix for the view [14:33:14] instead of polar and azimuth angles that I don't really understand how they are defined [14:34:18] right [14:36:48] I got the abort/abort stage and cover working well [14:37:03] also the radar slew switch is working [14:37:21] its a 4-way switch so for that one I used quadrilateral mode [14:38:04] ah, good that you figured that out [14:39:14] I should probably try and do the reticle as an animation [15:00:31] I think I have it! [15:00:55] I put the Earth at the center of the telescope [15:01:02] then used the 25° offset [15:01:11] so Earth is at the 0° marking [15:01:16] and then I rotate the shaft [15:01:23] and the Earth stays on the reticle line [15:03:00] hmm [15:03:59] but I can't put the telescope on any star now :D [15:06:45] as an animation? [15:07:22] no, not trying that yet [15:07:43] just trying to get the view right [15:08:00] if I achieve that I might try drawing the reticle as an animation texture or so [15:10:19] ah I see [15:22:40] I thought I was close, but I really wasn't, damn [15:48:04] bummer [16:30:43] morning! [16:42:51] hey [16:58:05] hey Mike [17:03:26] why is this telescope moving in a figure 8 now... [17:06:30] hahahaha [17:06:32] I just can't figure out what Orbiter uses as "up" when you specify a viewing direction [17:42:30] Hello [17:43:02] good morning! [17:43:27] Good evening ;-) [17:47:00] I'll make it short today. I updated my Meshes. Corrected some Normal errors. +Updated the DamperArm and SwingArm3 animations. [17:48:23] Mike it you? https://www.youtube.com/watch?v=-y37tXoBDx0 [17:49:34] yep, that's me :) [17:56:59] and done! [17:57:04] with panels 1-4 [17:57:13] hey Jordan [17:58:34] nice! [18:01:45] a bit of house-keeping work now and it will be ready for PR [18:25:29] Hello alex [18:25:57] hey [18:26:05] more updates, nice [18:26:25] Mike you must be lucky to hold all these things in your hand [18:27:33] alex i only made corrections, nothing special [18:28:21] spent most of the time with the code. for me it was hard work [18:29:58] well, when it is ready, feel free to do a PR [18:30:49] Jordan: yeah, the whole AGC thing has been hugely lucky :) [18:38:09] Indy its done. But first check the Code first. For me it works. SA3 and Damperarm starts retracting with the Colby Crane but this time i made the Damper arm a bit faster. [18:38:28] const double DAMPERARM_RETRACT_SPEED = 1.0 / 30.0; [18:38:36] const double DAMPERARM_CONNECTING_SPEED = 1.0 / 1000.0; [18:39:12] I dont know if its ok with CONNECTING_SPEED [18:39:38] I will look at it [18:42:05] Ok . i wish you good day and night. Going to watch Gladiator. ZDF NEO. bye [18:43:57] cya! [18:43:59] https://1drv.ms/u/s!ApTRgF_OsQUFgUcNOLn7I9l2BSP7?e=qj81V0 [18:44:15] Here is a scenario for Testing the animation ;-) [18:44:26] ah, that will be useful, thanks [19:11:51] I gave the SM/SLA/S-IVB abort vehicle SM RCS thrusters :D [19:12:06] I want to finally try that No SLA sep procedure [19:12:27] where SLA separation is failed in Earth orbit [19:12:39] you do a LOX dump with the S-IVB, lowering your perigee to 80NM [19:12:49] and then burn through almost all your CM RCS for the rest [19:12:52] and then reentry [19:13:19] and you let the SM RCS fire like after a normal CM/SM sep [19:14:03] whoa [19:14:06] interesting haha [19:15:13] I think the procedure for a SLA sep failure after TLI is: godspeed [19:16:08] might be possible to carry the S-IVB along a free return trajectory all the way to reentry [19:16:21] and do some LOX dumps and SM RCS burns for midcourse corrections [19:16:28] but if that works [19:16:29] big if [20:34:53] lat-long routines are unsurprisingly identicaly to Luminary, aside from certain constants moving to CONTROLLED CONSTANTS [20:35:00] INTEGRATION INITIALIZATION is next [20:39:04] and it looks like that will continue to the end of this bank, which means I start module B3 probably tomorrow :) [20:39:18] the only one for which we have two revs, 292 and 302 [20:55:12] nice [20:55:20] I just pulled off that deorbit procedure with the LOX dump [20:55:34] I don't have a checklist for it, just a very rough outline [20:55:44] landed off Madagascar [20:56:07] there are some department internal documents that would be helpful but UHCL doesn't have them [20:57:41] I wonder, was there ever a Sundance version for a launch before July 1968? [20:59:19] nice! :D [20:59:22] uhh [20:59:32] what do you mean, a Sundance version? [21:01:17] early revision [21:01:26] with an optimisitic launch date :D [21:01:30] haha [21:02:04] I mean 292 was released April 1968 [21:02:06] they would have to change some constants [21:02:12] oh, what constants? [21:02:45] 292 won't have 1967/1968 launch year constants [21:03:12] you need to change some constants every year because the coordinate system and the time references changes [21:03:25] ah, I see what you mean [21:04:27] yeah, can confirm 292 has the 1968/1969 constants [21:04:50] 14,3731: 07571 0 [21:04:51] 14,3732: 17020 0 [21:04:51] 14,3733: 15325 1 [21:05:21] would have surprised me a lot if it hadn't [21:05:36] Luminary 87: PCR 707.2 was implemented. (Change from 1968/1969 Ephemeris [21:05:36] Data to 1969/1970 Ephemeris Data) [21:05:38] like that [21:10:53] indy91, at LM staging we use ShiftCentreOfMass [21:11:13] but I think ShiftCG might be a better one [21:11:30] ShiftCG is automatically doing animations etc, right? [21:11:59] shifting* [21:12:07] yeah, everything including meshes and cockpit camera height [21:12:47] and we have to create everything from scratch at staging [21:12:48] right now I have to recall the whole RegisterActiveArea in the VC at staging so it applies an Offset for the switches [21:13:24] but I change it to ShiftCG at staging, I dont have to call that again [21:13:32] but if I change* [21:13:44] ShiftCG seems to take care of it [21:14:07] yeah [21:14:25] the other issue is the AID's that are the dynamic texture reloading areas (DSKY,timers etc) [21:14:50] those cannot be reloaded at staging or else there is issues with duplicate textures on the displays [21:15:08] so I either have to put a bunch of checks on those [21:16:05] or use ShiftCG then I dont even have to recall the RegisterActiveAreas() [21:17:13] oh and if we use ShiftCG, then we can take out the ShiftMeshes() in SetLmAscentHoverStage() [21:17:27] since ShiftCG takes care of that already [21:17:43] yeah, it's a good change, but there is a bunch of things we need to update for it. But mostly deletions, so that's good [21:22:52] right [21:33:21] good night! [06:37:10] module b2 complete! on to b3 [06:37:17] I guess I'll do 292 first and then 302 [14:32:43] hey [14:42:05] hey Alex [14:55:10] I have ShiftCG implemented for staging in my build [14:55:31] had to make a few adjustments for it [15:15:22] I bet [15:24:36] https://github.com/jalexb88/NASSP/commit/87bb6d5dcf6bbc7336aa3243ae1974a235e2b572#diff-0b8182ac0ead45c1b6078a97f2458466R284 [15:24:54] thats the changes I did if you were curious [15:26:54] that's simpler than I thought [15:28:24] yeah, did a lot of testing with it [15:29:13] in-session staging, then reloading scenario after staging, also LM creation from SIVB [15:30:07] I initially tried ShiftCG +3.0 (as it was 3.0 beforehand) [15:30:28] but that screwed up save/reload with ascent stage only [15:31:28] how it worked at staging is the CG would go down 1.25, then the descent stage created, then up 3.0 and ascent stage created [15:31:36] how it worked before* [15:31:38] yeah [15:32:11] but it seemed that for reloading, it didnt like ShiftCG 3.0 [15:32:56] so what I did was put part of it in the staging function. Now its: Down 1.25, create ascent stage, up 1.25 (to go back) and then create ascent stage [15:33:01] and then up 1.75 [15:33:12] sounds complicated haha [15:33:23] it is a bit weird [15:33:33] could probably be made easier [15:33:52] I mean, the whole thing of going down to create the descent stage is bad [15:34:01] and probably not needed [15:34:07] maybe it was needed at some point [15:34:10] but not any more [15:34:18] but we can revisit it when we implement variable CoG [15:34:48] it should be just create the descent stage at a certain vector down and then just one ShiftCG + 1.75 [15:34:57] right [15:35:26] yeah, I think it should be quite possible to do it that way [15:37:48] I also got the tape meter split for the VC [15:38:44] right now I am wrapping up my housekeeping work with this and I think it should be mergeable later today [15:40:25] great [15:40:45] Jordan also has an update, just needs some scenario fixes so the animations are right at liftoff [15:41:31] and I can also merge my REFSMMAT update. Not going to continue working on GDC alignment display etc., got too frustrated that we can't do the procedure properly :D [15:42:30] I think I'll fly a lunar mission and update the MCC next [15:42:42] haha yeah, how did that project turn out yesterdayÉ [15:42:48] ?* [15:42:54] with the telescope [15:43:43] turned out to me deleting all changes I made [15:43:48] didn't work out [15:43:56] right [15:44:10] I learned a lot and I think I have the correct calculations that Orbiter does in a MATLAB script [15:44:10] hopefully not an Orbiter limitation [15:45:05] there is either an easier solution that I don't see or I have to figure out some complicated calculations for a tilt angle [15:45:21] might ask on the forum for help [15:45:24] I do remember reading posts about Orbiter and implementing VR support, and some of the responses were that it would be difficult since Orbiter cannot "roll" the camera easily or something like that [15:45:38] but I am not sure how true that is [15:45:56] sounds related [15:49:55] Orbiter API has a barely documented feature to get the view rotation matrix [15:50:14] if I could just write to it... [16:13:29] AlexB_88, so the RTCC keeps multiple time references [16:13:39] liftoff time, CMC clock zero, LGC clock zero, AGS clock zero [16:13:53] liftoff time and CMC clock zero are usually kept the same [16:13:57] and I guess LGC as well [16:14:18] so I guess an automatic update in the MFD should update all three times? [16:17:02] you can even enter separate liftoff times for CSM and LM [16:17:28] ah Jordan, I just had sent you a PM [16:17:38] about the scenarios [16:17:46] hi indy. ok [16:18:37] exactly. i wanted to do in now but if you want you can do it. [16:19:37] have you look at the code? i think it is ok [16:19:51] indy91, yeah sounds reasonable [16:19:58] hey Jordan [16:20:09] hi alex [16:22:41] well [16:23:02] the only thing I don't like about the code is where s2aftarmState.action = AnimState::OPENING; etc. is called [16:23:23] it's in the "if (craneProc < 1)" [16:23:33] hmm [16:23:45] I guess that only has to be called once [16:23:52] then it's ok :D [16:24:10] I'll merge the PR and prepare the scenarios and push them as well [16:28:58] if this is a problem you can change it if you want. I don't know where else to insert the code [16:30:57] for my tests it works. every time the crane starts to retract, the sw3 and damper arm retracts too [16:31:15] yeah, I was just confused at first [16:31:32] for a moment I thought you need to call "s2aftarmState.action = AnimState::OPENING;" until it is fully open [16:31:43] but you only need to call it once to get it started [16:31:47] so it works fine [16:31:51] i thougt this is ok because it is in the prelaunch state [16:32:00] yeah [16:32:43] whats about this [16:32:44] const double DAMPERARM_CONNECTING_SPEED = 1.0 / 1000.0; [16:32:46] it's the best solution without bigger changes to the ML code [16:32:59] is 1000 to high [16:33:19] I guess that means it will take 1000 seconds to connect [16:33:35] it's high, but the whole assembly sequence is very slow [16:33:48] and that's the only place where it is called I think [16:33:58] i think so because this " DAMPERARM_RETRACT_SPEED = 1.0 / 30.0;" is only 30 sec [16:34:00] maybe we find a better number for it [16:34:05] and then we can change it [16:34:08] it's good for now [16:34:17] (y) [16:34:53] prelaunch state starts at T-3 hours [16:35:02] so that's when crane and damper are removed, right? [16:35:19] thats right + swingarm3 [16:35:50] right [16:36:10] that's fine [16:36:16] not too difficult to move at some point [16:37:02] updated scenarios pushed [16:38:10] what even is the point of SA-3 if it gets retracted so early... [16:38:24] oh [16:38:36] purely access to the S-II for personnel [16:38:50] probably no umbilicals then [16:39:54] i have no clue. didn't find the right answer [16:42:12] morning! [16:44:19] morning mike [16:46:13] Indy we have to check the Floodlights. Test the "Apollo 8 MCC Launch" Scenario. I have positioned the light as close as posible to the originals but the flood lights are not in the correct place [16:46:29] "This is used by engineers to access the vehicle inside. It also provides a single LOX pump exhaust line interface. This arm is retracted early before launch, as needed." [16:46:38] about swingarm 3 [16:46:39] hey [16:46:52] # [16:47:18] "as needed" in have read about this. there is no exactly time [16:47:55] well I found the time T-14 hours, but it won't be accept. Could be plus/minus a few hours if more has to be done [16:48:05] we might be able to find when it was done for specific missions [16:49:33] for now it is ok i think. [16:49:39] https://1drv.ms/u/s!ApTRgF_OsQUFgUjLGmqDx4MwvOOe?e=sOJrNR [16:50:07] is the LES not to close to CM [16:51:06] yeah it's a bit close [16:51:13] Probably needs some adjustments [16:51:28] to the tilt of the thrust direction [16:51:35] so that it angles away from the Saturn more [16:51:38] and also thrust profile [16:51:50] the total impulse of the tower jettison motor should be correct though [16:52:25] Apollo 8 planned time: T-12h for SA-3 tip retraction, T-11h30m SA-3 full retraction [16:52:34] so it's not even consistent between missions [16:53:13] yep. thats why the say "as needed" [16:55:02] sort of related, but I stumbled across this group the other night: http://www.savethelut.org/links.html [16:55:10] they've got a whole bunch of original engineering drawings for the LUT [16:57:02] yeah, there was a google group or so [16:57:06] they are now here: https://groups.io/g/LUTGroup [16:57:12] lots of good files [16:57:20] I kind of assumed Jordan already knew about it :D [16:57:30] if not then you have some good stuff to discover [16:57:37] hahaha, that's fair, I was just surprised that I had never heard of them [16:59:00] how is Sundance going [16:59:18] module B2 is done! [16:59:30] I know them all. I used a lot of them to model the meshes :-D [16:59:32] I'm back to revision 292 now for module 3 [16:59:37] haha awesome [17:01:40] I don't know how many GBytes I downloaded for references in the last year [17:03:09] haha I bet [17:03:11] http://apollolaunchcontrol.com/Apollo_Launch_Control/Control_Panels/Pages/GSE_panels_files/Media/BC20%20S-II%20AFT%20FR1/BC20%20S-II%20AFT%20FR1.jpg [17:03:21] this must be the console of the most bored person in LCC then [17:03:31] service arm 3 console [17:10:58] hehehe [17:29:11] looking at the tower jettison motor code [17:29:25] I think the thrust vector angle is not large enough [17:44:56] I think I made it better [17:47:18] it should have a thrust vector angle of 4° [17:47:31] and with the previous thrust direction it was about 1.5° [17:48:07] of course there is center of gravity etc. [17:54:31] did you change it? [17:56:02] yeah I gave it better values for the jettison motor thrust direction [17:56:15] https://i.imgur.com/07xNyD4.png [17:56:18] better? [17:57:34] I'm sure there are other numbers that can be improved, but this alone already improved it [17:57:42] improve the separation [17:57:47] improved* [18:00:06] I actually made it worse myself, kind of [18:00:20] the tower jettison motor used to have an unrealistic high thrust [18:00:25] which I fixed [18:00:32] indy91, LMVC branch is ready for PR [18:00:35] but then the distance to the Saturn got a bit too small [18:00:58] awesome [18:01:28] did you want to look over it, or can I just PR now? [18:01:36] indy it looks a lot safer [18:01:56] you can PR it and then I look over it :D [18:02:00] ok [18:02:21] on the PR page it shows all the files that were changed, from all the commits in the PR [18:02:29] that's what I really like to check PRs [18:02:41] right [18:03:34] PR sent [18:06:38] looks pretty clean [18:06:42] back in a bit [18:30:13] I'm not qualified to judge if this VC code is any good :D [18:30:35] but I see no glaring issues, so [18:30:59] merged [18:31:49] fair enough haha [18:31:51] thanks [18:32:10] I did a lot of testing so hopefully nothing to bad will pop up [18:32:32] I also made sure not to disturb any existing functions [18:32:53] just make new functions in the switch classes that pull the needed values [18:35:20] yeah, if you just use the 2D panel you should notice no difference [18:36:05] nope [19:10:39] one thing I'd like to figure out is a way to make the tape-meter smoother when in PGNS/AGS mode [19:12:13] Sorry guys, I had to update the ML. The stair exceeded the max vertex number of 64k and causes errors. I removed the split modifier to reduce the number. if you go close to the ML you will see it. [19:13:37] AlexB_88, what do you mean with smoother? [19:14:45] so that it doesn't snap to exactly the desired position and drive there instead? [19:16:15] Jordan, no problem [19:16:48] the tape meter motion is jerky when its getting data for PGNS/AGS [19:17:03] its been that way forever [19:17:16] there even a comment in the code about it [19:18:18] yeah that's what I mean [19:18:54] of course it will never be perfect, as it wasn't perfect in the real spacecraft [19:19:38] I can put in some code to limit the tape drive speed [19:19:43] that should do it [19:22:27] right [19:22:35] ok PR is out [19:23:04] productive day today :D [19:23:09] even some of my stuff [19:23:34] I looked closely at the ML, but didn't get any issues [19:24:08] :D [19:24:09] but max vertex number sounds scary [19:24:17] merged [19:29:47] before https://1drv.ms/u/s!ApTRgF_OsQUFgUmoAt1R1XIu2Gic?e=rxV7vi [19:30:08] After https://1drv.ms/u/s!ApTRgF_OsQUFgUqo4MlkyRvLxC-F?e=FKOyM5 [19:31:25] ooh, right, yes I got that [19:32:47] if you find some glitches report it to me [19:32:59] ok its time to go for me. Good night @all [19:33:48] night! [19:38:58] goodnight! [19:47:56] oh nice, its finally called the "Two Impulse Processor" :D [19:51:09] people who want Lambert can use this: https://www.orbithangar.com/showAddon.php?id=93baa6a8-9931-4319-beb6-27578e4fa08f [19:54:16] looks like the "great-grandfather" of RTCC MFD [19:54:38] it is [19:55:34] or was it a bit of a side development? Not sure anymore [19:56:04] nah [19:56:10] Lambert MFD came first [19:56:18] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2706.msg22404#msg22404 [19:57:56] and that came from lua scripts for Shuttle rendezvous [20:02:54] I just disassembled the lambert stuff in sundance last night :D [20:09:53] the AGC has a pretty smart implementation of it, but the flowchart isn't very readable [20:41:36] AlexB_88, the VC tape consists of three parts? [20:41:41] of the tapemeter [20:46:32] yeah [20:46:41] I think I had a good way to make the tapemeter smooth [20:46:47] then I noticed your VC code for it :D [20:46:56] hahaha [20:48:26] what changes would be required? [20:48:39] I think I just need to convert something to pixels [20:48:54] you used a mixture of engineering value and pixels (dispRange) [20:49:34] I guess with the different display implementations (2 part vs. 3 part) all of the code that converts the displayed value to a pixel number should be in the redraw function [20:50:12] I think I got it, but I think it can be done cleaner [20:50:26] right [20:50:56] what I did for the VC is use the same code that was used in the 2D redraw function [20:51:15] and use dispRange - 3026 after the switch to part b [20:51:28] 3026 being the pixel difference of the starting point [20:52:41] yeah but the switch point there isn't 3026 [20:52:52] I calculated 3181 pixels, does that sound right? [20:53:19] hmm [20:53:26] instead of reqRange < 24231.6 [20:54:13] one advantage of doing the pixels thing in code is that you can give it a tape drive speed limit in pixels [20:54:31] I guess what the timestep needs to calculate is the actual position on the tape [20:54:46] and that then gets converted to pixels on one of the bitmaps [20:55:33] how did you get to 3181 pixels? [20:57:25] desRange = 6443 - 82 - (int)((reqRange * 3.2808399) * 40.0 / 1000.0); [20:57:39] that's the switch point between bitmaps [20:57:48] different from the offset [20:59:45] 79500 feet [21:00:12] so the 2 bitmaps I created have over-lap [21:00:25] they are both 3500 pixels [21:00:35] the original was 6526 pixels [21:01:03] right [21:05:37] well I'll figure it out over the weekend [21:05:43] shouldn't be too tricky [21:06:16] good night! [21:06:27] cya! [01:12:34] P51 disassembled; no differences whatsoever from Luminary [01:12:37] on to P52 [02:15:55] okay whelp [02:15:58] P52 is very very different [08:09:59] wooooooooow okay [08:10:19] I've been working on disassembling a barely recognizable P57 [08:10:31] like it's definitely P57 but it's almost entirely different [08:10:57] and I've only just now realized that Sundance 292 at least doesn't even have P57 in its V37 tables [08:11:05] I wonder if later sundances did... [08:12:33] but it's very very primitive and not well written [08:12:36] and kinda buggy [08:18:02] good evening :) [08:18:30] sundance 306 provides the answer -- no, even in 306, P57 cannot be started [08:19:12] hey [08:19:35] we have P52 procedures in the rendezvous procedures document [08:19:38] looks pretty standard [08:20:29] well, it's very different in 292 from Luminary :D [08:20:38] 302 may be less different... we'll see [08:20:54] I wanted to ask you [08:21:13] I'd like to use Aurora to do some tapemeter testing [08:21:17] any good procedures for that? [08:21:45] hmm, probably yes [08:22:50] Sundance PCR 412: Remove Landing Site IMU Alignment Option from P-52 [08:22:54] that's a weird one [08:23:11] O_o [08:23:21] maybe they didn't originally think P57 would be its own program? [08:23:23] interesting [08:23:45] maybe... [08:23:59] https://www.ibiblio.org/apollo/AgcDrawingIndexBox433.html [08:24:09] drawing 1002323 is probably going to have it somewhere [08:25:08] hmm [08:27:10] thanks! [08:27:15] the way to use the rear detents is definitely different in Sundance's P52 [08:27:21] also potentially JDC 12613 [08:27:52] and the GSOP section 5 has a fair amount of change to P52 [08:28:11] that makes sense :) [08:31:12] when we originall got Aurora, didn't we have a document with self test procedures that didn't come from the drawings? [08:32:08] ND-1021042 has some high level test procedures in it [08:32:18] there's also a document that lists the programs in aurora, that has some numbers [08:32:53] it does appear to have a dedicated "display inertial data test" [08:33:11] yeah, pretty sure I did that [08:33:36] I guess what I would like to find is a procedure document like I used for the CMC auto optics [08:33:47] with specifications how it should behave etc. [08:34:18] http://klabs.org/history/history_docs/mit_docs/1708.pdf [08:34:24] right [08:34:52] I don't find my number of 500 pixels per second as the tape drive speed very satisfying :D [08:35:37] did you use a JDC for that? [08:36:37] maybe? :D [08:37:00] haha [08:37:04] that's not helpful :D [08:37:05] hmm [08:37:44] there is an "RR velocity meter test" at the end of the semiautomatic mode check [08:38:26] in the box 433 part 2 drawingsß [08:38:27] ? [08:39:34] do we have all the JDCs available? [08:40:28] yes [08:40:42] https://archive.org/stream/apertureCardBox476Part1NARASW_images#page/n93/mode/1up [08:40:52] that page has a velocity meter test on it [08:40:56] not sure if that's what you're looking for [08:43:07] it seems like the Display Inertial Data Test would be better [08:44:00] yeah [08:44:08] although that procedure would be fun to try [08:45:55] but do we have procedures for the DID Test? [08:46:16] hahaha patience man [08:46:22] we have a lot of stuff that is hard to search through :P [08:46:31] I know, that's why I am asking :D [08:46:55] you would use 00016 to start it instead of 00010 for the semi-automatic moding test [08:47:09] yeah [08:47:17] I mean, I have done that when we first got Aurora [08:47:20] fun to watch [08:49:52] weird that the semi-automatic mode test has a velocity meter test, but not altitude [08:51:55] why did I think we had Aurora 88... [08:51:59] we only have 12, right? [08:53:29] well, we have 12, but as far as I can tell it includes all of the features of 88 [08:53:50] ah right [08:53:56] the weird revision numbers [08:55:12] more the DAP group being lazy and not coming up with a new program name when they made their testing branch [08:55:16] :P [08:55:32] it's super late though, I need to get to bed [08:55:44] no luck on finding a procedure but I'll look more tomorrow [08:56:13] goodnight! [08:57:00] ok, thanks for looking, I will search a bit more myself [08:57:03] night! [14:15:45] morning [14:17:16] hey Alex [14:17:32] I think I have the tape speed limit working [14:17:45] what limit do we want to use though, I haven't found any numbers for it [14:17:55] right now I have 500 pixels per second [14:18:05] altitude tape is about 8000 pixels total [14:19:16] hmm good question [14:20:36] btw, this won't change the behavior at all if the desired tape position is close enough [14:21:23] this update will only prevent it from going instantly to the desired position [14:21:38] right [14:21:48] the rest is actual system behavior, especially with that AGC bug in the early Luminary versions [14:22:20] makes sense [14:22:46] there also is a weird feature I implemented [14:22:52] for the range rate [14:22:56] only goes from -700 to 700 [14:23:08] but if the actual rate is 1700, is also shows 700 [14:23:20] so if the rate always increases it goes from 0 to 700 [14:23:29] then it stays at 700 until the rate is 1000 [14:23:42] and then it goes to 0 [14:23:50] and then to 100 for 1100 ft/s [14:23:55] and back up to 700 for 1700 ft/s [14:24:09] until it reaches the RR limit, which is 4900 ft/s [14:25:38] interesting [14:25:54] I think the update is mostly done, just need to decide on the rate [14:26:13] 500 already flies by, but it would take 16 seconds from one end of the tape to the other [14:26:54] and when it looses lock etc. it goes all the way to 0 [14:27:14] not sure if that is correct behavior [14:27:31] actually, there is talk of a range/range rate power/signal fail light [14:27:34] like some of the other meters [14:27:39] where even would that be??? [14:28:29] I mean, there is a thing just above the meter [14:28:37] but it looks different from the other meter lights [14:31:35] it's mentioned in the LM malfunction procedures [14:39:54] never noticed that [14:40:34] btw, looks like OrbiterSound 5 should be released as beta in the coming days [14:42:37] awesome [15:01:26] ok, if you have no objections, I'll use 500 pixels per second. When you test it and think it's too slow or fast, we can still change it [15:15:17] ok sounds good [15:18:46] done [15:20:27] nice [15:20:29] ill test it now [15:21:12] and Ive started work on the LM VC interior [15:21:29] so the walls, windows and stuff [15:23:14] ah great [15:24:39] so if the ShiftCG function is so nice and easy [15:24:49] I might try and implement variable CoG for the LM [15:24:58] oh nice [15:26:41] would definitely help out the LM with full DPS propellant [15:34:02] right [15:34:08] tape=meter looks good [15:37:27] great [15:40:49] I'd like to use the actual LM coordinate system for everything and update the CoG on the first timestep, but that might look weird [15:41:04] as there would be a 200 inches CoG update [15:41:15] LM coordinate system origin is more than 100 inches below the DPS nozzle [15:41:56] so maybe I use the ascent stage base instead, that's an offset of exactly 200 inches from the origin [17:12:01] AlexB_88, I guess ShiftCG would also affect touchdown points? [17:12:13] probably not something you tested [17:12:21] hmm [17:12:32] tested landings and liftoff [17:13:05] I dont think ShiftCG affects that [17:13:24] hello [17:13:55] hey Guest45224 [17:14:01] :D [17:17:17] I can test that [17:19:08] doesn't seem like it [17:19:11] which is bad? [17:19:27] don't I have to manually set the touchdown points then each time? [17:19:36] each time I use ShiftCG [17:20:53] yeah [17:20:57] that's what SSU is doing [17:21:18] each time the CoG is updated it calls a DefineTouchdownPoints()function [17:22:39] slightly annoying, but not too bad I guess [17:23:01] hey [17:23:31] indy91, yeah I guess that makes sense [17:25:53] morning! [17:26:21] hey Mike [17:27:07] what's up? [17:27:11] haven't found a better procedure for tapemeter testing, I just used a constant speed for it that looks ok [17:29:38] cool [17:43:00] yeah I'm not having much luck finding anything else either [17:43:28] have to wait until tapemeter drawings then :D [17:43:47] haha yeah [17:44:35] that thing was quite complicated [17:44:43] it's a digital computer [17:45:05] oh really? [17:45:11] with integrated circuits [17:45:35] huh, wow [17:45:43] it has to deal with quite a lot. Digital data coming from several sources [17:45:51] a tape that has three separate scales [17:46:02] at least for the range/altitude [17:50:45] yeah that makes sense [17:50:51] I guess I never really thought about it, haha [17:52:16] "the system electronics consist of micrologic (flat packs) integrated circuits [17:52:17] that are mounted on 10 multilayer circuit boards." [17:52:30] where do you get one for Marc? :D [17:52:34] do we* [17:52:54] hahahaha good question [17:55:28] who built them? [17:58:17] the Apollo Experience Report is notorious for not mentioning the subcontractors... [17:58:20] I'll look [17:59:19] the name for the thing is also a bit incosistent [17:59:38] the most official name I usually saw is "Altitude/Range Indicator" [18:19:23] http://images.goldbergauctions.com/php/lot_auc.php?site=1&sale=49&lot=144 [18:20:04] P/N LSC-350-307-09 [18:22:37] hmm [18:29:25] made it up to LSC-350-307-31 for LM-4 [18:30:28] nope [18:30:34] LSC-350-307-13 [18:35:45] alright, time to figure out what mysteries remain in P57 [18:37:29] so P10 and P11 are accessible in Sundance via V37 but P57 isn't? lol [18:41:00] yup [18:41:06] hallo [18:41:46] hey [18:42:41] hey Jordan [18:43:55] indy91, yeah it's super weird. but from what I have so far, it doesn't look like the V37 tables changed size in 302 or 306 [18:44:18] so at the very least, something else would have to have been deleted for P57 to be added [18:47:34] hmmm [18:47:41] flagword 6, bit 2 [18:48:32] AUXFLAG in Luminary [18:48:41] but ASCNTFLG according to LM-3 systems handbook [18:50:10] AUXFLAG related to DVMON [18:50:14] is DVMON Average G? [18:51:00] I think it's just the delta-V monitor [18:51:09] i.e. what triggered on LM-1 [18:51:42] ah, engine failure routine, of course [18:52:07] that should be in the GSOP [18:52:43] the logic here is, "if ASCNTFLG is off, store 0 into DSPTEM1, otherwise store TIG in DPSTEM1" [18:52:54] Luminary just always stores TIG [18:53:38] have you seen ASCNTFLG being used so far? [18:54:21] there is definitely late changes to the DV Monitor [18:54:39] no, this is the first time [18:54:44] and I don't think it has anything to do with the DV monitor [18:55:00] hmm, ok [18:55:25] otherwise why would P57 be using it? haha [18:55:25] where are you right now? [18:55:27] P57? [18:55:35] the very beginning of P57, yes [18:55:40] so a TIG in p57 [18:55:42] must be option 4 [18:55:51] the first code that gets executed when you select P57 [18:55:57] yeah [18:56:01] alignment to landing site REFSMMAT [18:57:20] which is of course not documented in the GSOP [18:57:30] as Sundance of course has nothing for a lunar landing [18:57:54] allegedly :P [18:58:29] I mean, that ASCNTFLG could have to do with P10 and P11 [18:58:34] it could! [18:58:40] also wow [18:58:41] if a TIG was calculated by them [18:58:46] if not, set the alignment time to 0 [18:58:47] P57 continues to be poorly written [19:00:28] just, very very inefficient interpretive code [19:00:59] there are even two places so far in this code where interpretive code can incorrectly run into basic, or vice-versa [19:01:13] ouch [19:01:31] hopefully P10 and P11 aren't similarly bad [19:03:08] probably not written by the same person [19:03:24] uhhhh [19:03:31] I think it might be doing that a third time [19:03:39] trying to jump to basic from interpretive [19:03:56] a natural tendency when one tries to read interpretive [19:04:58] i think to add details on the lmvc mesh by alex. I did a test mesh, these are just small details. what do you think? [19:05:09] https://1drv.ms/u/s!ApTRgF_OsQUFgUukiY0DKhUStXYm?e=6eOmkJ [19:07:52] AlexB_88 jordan64 you two just need to make sure to coordinate this well, but otherwise I am sure that there is enough to do in the LM VC for two [19:12:10] 15,3053: 43170 0 AXT,1 BOFF [19:12:10] 15,3054: 00000 1 0 [19:12:10] 15,3055: 01742 1 REFSMFLG [19:12:11] 15,3056: 33061 0 +3 [19:12:11] 15,3057: 77710 1 INCR,1 [19:12:12] 15,3060: 00100 0 FLAGWRD3 [19:12:24] if REFSMFLG (flagwrd3 bit 13) is off, increment flagwrd3??? [19:12:46] dudes you have interpretive instructions to set flags, incrementing is a very bad idea lol [19:13:07] I must be looking at that wrong [19:14:52] manipulating bit 1 of flagword 3? [19:14:59] by incrementing [19:15:08] oh, no, I am looking at that wrong [19:15:34] INCR,1 in interpretive increments the index register by that amount [19:15:49] ah [19:15:50] Jordan, those details look good, I was thinking of that myself for the switches [19:15:54] so that should be DEC 64 [19:15:58] interpreter code, fun as ever [19:16:12] the thing is though, did you need to change the switch position? [19:16:54] like further out to have the detail under it? because that will affect the animation, we will need to fix the pivot point of each switch if thats the case [19:18:40] not all of them the ones in front, the "colored" ones, are just moved outwards. [19:19:04] i made this just for test. [19:20:03] ok [19:20:12] is it a is it a lot of work to change the pivot point? [19:21:20] well the way I do it, yeah :D Each switch one by one... [19:21:31] but there might be an easier way I guess [19:21:44] still have to research [19:22:50] how do you calculate he pivot point? [19:22:54] *the [19:25:25] so 1st thing is I take the coordinates of the face at the bottom of the switch (inside the cylinder) [19:25:28] https://www.dropbox.com/s/zxac1i538f3ah3n/Screenshot%202020-05-23%2013.24.05.png?dl=0 [19:26:50] and then convert the coordinates to Orbiter: X is reversed, Y is reversed and Y & Z switch places [19:27:54] so IE in the picture, it becomes -0.31706, 0.36534, 1.62387 after converting [19:29:04] and the coordinates are placed at the top of LEM.h in the respective PX_TOGGLE_POS brackets [19:36:10] hmm, ok, there are not to many variation of switches. so if you create one with the origin in the pivot point then it would be easier. [19:37:13] there will be a need of python programming to export them in orbiter coordinates [19:37:39] im sure this is possible [19:38:54] blade the creator of orbiter mesh tools for 2.8 can maybe help in this [19:39:48] that would be nice indeed [19:40:10] so you need to make a switch with the origin in the pivot point and copy that over to the others. [19:40:46] i will send a message to blake. hope he can help us. [19:40:59] ok [19:41:16] right now I am working on windows and walls of VC [19:42:06] if you make the basics i can later add details [19:44:22] sure thing [19:45:02] hmm [19:46:30] would it help if I send you the blender files I have? [19:46:59] dont know if it would be easy to merge our work that way though [19:48:10] not really. i can make the details and you can join them to your mesh [19:48:29] ok sounds good [19:50:04] ok message send to blake. hope the best. [19:50:36] awesome [19:51:41] can you program in python? [19:51:53] its a bit like c++ [19:53:35] oh, thrusters are also not moved by ShiftCG [19:54:23] havent tried yet, I guess it should be straightforward [19:55:00] https://blender.stackexchange.com/questions/161276/saving-and-loading-object-name-location-and-rotation-of-a-selection [19:55:38] this maybe help to [19:57:48] hmm, ShiftCG should actually move thrusters :D [20:03:45] okay, I think I finally made it out of the nightmare that was P57 [20:12:13] what's next? [20:15:44] LSPOS [20:15:51] which so far is back to identical to Luminary [20:16:26] oh shit, and it is the last thing in bank 15 [20:16:35] bank 15 is very empty in Sundance 292 [20:16:48] only filled up to 15,3347 [20:17:10] bank 16 begins DAP stuff [20:17:12] which I am afraid of lol [20:20:10] I think once we have Sundance working as it was intended in NASSP [20:20:16] we should enable P57 and try it out :) [20:21:59] https://i.redd.it/sjwsh9s5jnvx.jpg [20:22:50] alex do you know this pic? its a 360 degree panorama of the lm cockpit. useful as reference. [20:23:09] oh thanks! Ive been looking for a picture like this [20:23:25] which LM is that? [20:25:22] i don't know,found it here https://www.reddit.com/r/cockpits/comments/5b5j3e/neil_armstrong_and_buzz_aldrin_lifted_off_from/ [20:28:46] LM-5 and later didn't have the LR warning light [20:28:53] so it's not the later configuration [20:30:17] it has the RCCA switch [20:30:22] which only LM-3 and earlier had [20:30:25] is this LM-2? [20:31:04] https://airandspace.si.edu/multimedia-gallery/lm-interiorjpg [20:31:31] I think the answer is yes [20:31:33] ah yeah, looks like it [20:31:49] okay so LM-2 no longer has its AGC. I wondered that, haha [20:32:29] very interesting that it has ALT and VEL lights on its DSKY [20:32:37] which looks real [20:34:06] AlexB_88, the link I posted is the same panorama I think, but you can move around and it's probably better quality [20:34:11] Probably the source of that picture actually [20:34:42] did they steal the original LM-2 DSKY for other purposes maybe? [20:35:54] its definitely better quality. i try to download it [20:36:09] "The computer’s Display and Keyboard unit (DSKY) located at the lower center of the control panel was missing and we replaced it with an identical unit from our collection." [20:36:16] heh, makes sense [20:36:23] almost identical :) [20:36:43] close enough [20:36:49] ah, thanks [20:38:21] I wonder if it is possible to look at a picture of any LM and figure out which one it is [20:38:34] I think you can figure out most of them [20:38:39] Apollo 15-17 might be hard [20:44:37] time to try a PDI with a proper center of gravity for the LM :) [20:45:39] not the right touchdown points though [20:45:43] that might be interesting [20:54:38] :D [20:58:27] little to no RCS activity [20:59:25] to really make the tapemeter less jerky I have to give it some inertia I think [20:59:37] so an acceleration not constant speed [21:01:45] well, it's not so bad [21:01:51] probably close to the actual behavior [21:02:21] nice! [21:02:36] alex i tried the script i mentioned earlier, it seems to be working [21:02:41] also woohoo! Sundance 302 DAP document comes through with a variable name and description for this erasable that is different from Luminary :D [21:03:32] this is the test results. i have only two objects [21:03:35] >>> import bpy>>> import os>>> ob_active = bpy.context.selected_objects>>> for obj in ob_active:... print(obj.name,obj.location,obj.rotation_euler)... Cylinder Cube >>> [21:04:46] Jordan, great! [21:05:14] you can export only the location with the name and you got only the data you want. but you still need to convert them to orbiter coordinates. i think thats not so hard to do [21:05:53] script run in 2.8 don't know if it works in 2.79 too [21:06:08] the visual is no-go. Can't do LPD, as the view position didn't shift correctly with the CoG [21:06:36] also, this is my first LPD with the new monitor. I was quite confused for a moment. But then I remembered: ah right, I have 16:9 now :D [21:07:05] i will try it with your mesh [21:09:55] haha [21:10:25] so the moment arm of the DPS is 1.1 meters at igniton [21:10:31] 2 meters at T+10 minutes [21:10:38] and 2 meters is what we currently use [21:10:48] very little RCS activity throughout, definitely liked that a lot [21:13:10] and with that, good night! [21:16:21] 0150_Sw_P3_14 0149_Sw_P3_13 0148_Sw_P3_12 0147_Sw_P3_11 0146_Sw_P3_10 0145_Sw_P3_09 0144_Sw_P3_08 0143_Sw_P3_07 [21:16:22] 0142_Sw_P3_06 [21:18:07] AlexB_88 tested some of your switches. i set the origin of the objects in the center of the meshes (this is easy in more objects simultaneously) and run the script. this is the result [21:18:44] btw. i tested this in 2.79 ;-) [21:20:42] wow not bad [21:21:46] you have to select only the object you need to export [21:25:15] try it out. open your mesh in blender. select the switches. select in blender /objects/transform/origin to geometry open the python console in blender. run the first script [21:26:14] if you delete the ",obj.rotation_euler" from the 5th line the output will be only the position(object origin) [21:26:37] the 5th line in the script [21:50:20] great. I am in the middle of windows right now but as soon as I can I will give it a test, thanks for finding this! Once I get to the CSM switches it will be much better lol [21:53:12] also, onmy latest mesh, I pushed the panels forward a bit so I will use the script probably to recalculate the switches location [21:53:41] I pushed the panels forward exactly 5 cm [21:54:05] so all you have to do with any of your changes is push them forward 5 cm [21:55:21] Blake sent me a message. He has already integrated this into his exporter. An include file is created with the coordinates in orbiter format. [21:55:39] wow that was quick [21:55:43] But his exporter is only 2.8 [21:55:54] right [21:56:25] Im planning on making the transition to it of course [21:56:33] its already installed on my PC [21:56:34] hi have this feature already in his exporter. i didn't know that [21:57:44] 2.8 has far better editing possibilities [21:59:14] you get something like this [21:59:21] I ran it a few times already, I was a bit lost in the new UI, but Im am sure its just a bit of time to get used to it [21:59:27] you get something like this [21:59:36] const VECTOR3 CylinderLocation = {-1.2853, -0.3211, 0.0000}; const VECTOR3 CubeLocation = {-0.7784, 0.8394, 0.9412}; [21:59:55] oh thats perfect [22:02:22] for example the CylinderLocation ist the mesh Cylinder the word Location is additional and it can be left out [22:03:10] "Cylinder. The word Location" forgot the point ;-) [22:04:09] do you have an update of your mesh in github? [22:04:39] the newest one with the 5cm difference? [22:07:45] not yet, but I will upload it soon [22:16:05] ok nice. good night. its late in german. [14:47:27] hey [14:49:40] hey Niklas [14:52:49] I managed to fix the view position with the variable center of gravity [14:52:58] but for some reason the touchdown points are still off [14:53:15] I do move them somewhat, but not enough which is weird [14:53:26] it should be enough that I apply the CoG offset to them I would have though [14:53:29] thought [14:56:20] oh and I was going to complain that the error needles and the G-Meter are jittering [14:56:42] but I was using an old scenario where the DPS propellant wasn't vented yet [14:56:49] and as it was venting the CoG was updated [14:57:04] and when it does that then it induces a little bit of error needle jittering [14:57:10] but nothing more, so all good [14:57:56] ah, right [15:00:37] next I'll look at staging [15:00:45] maybe I can simplify it a bit [15:13:31] ok [15:15:39] what, so you mean changing the center of mass 3 times for staging is a bit over-kill? :D [15:16:58] oh I just introduced a lot more center of mass changes than you ever did [15:18:05] but in the Saturn class the discarded stages are created at an offset. That should be quite possible in the LM as well [15:18:21] and I need to deal with it anyway because at staging the COG is already different than before [15:18:24] well, for a better reason then mine though [15:18:39] yeah, it's very noticable during early PDI [15:18:46] almost no RCS activity [15:19:08] and as I had hoped I could make it a very simple function that calculates the COG [15:19:17] only moved on the LM Y-axis [15:19:30] and the DPS moment arm is almost exactly like the LGC assumes [15:19:56] it's simulates as two mass points, DPS propellant and rest of the LM [15:20:06] that's already enough [15:20:37] I will have to update the RTCC a bit, but for the LM the DPS gimbal angles are still centered [15:27:26] very nice [15:27:34] looking forward to test that [15:32:36] what I have never checked is if the ascent stage COG is also a bit off [15:33:02] maybe RCS activity during attitude hold can be improved [15:43:05] if we ever make a new LM mesh please use the actual LM coordinate system :D [15:43:25] but it's not so bad, I figured the correct offsets when I adjusted the RCS thruster positions [15:44:22] hmm, did they not line up correctly when I made the mesh? [15:47:03] oh I just meant that using the actual LM coordinate system would mean a bit less math to do every time we adjust something [15:47:16] the origin is somewhere below the LM [15:47:33] but it's ok [15:48:11] ah I see [15:48:49] I know the distance from that origin to the center of the ascent and descent stage meshes [15:49:00] so I just need to add that value sometimes [16:06:19] pretty simple fix for those ShiftCentreOfMass calls actually [16:08:02] one line of code. I just need to apply my new COG offset correctly to both descent and ascent stage [16:08:07] and then check what happens when landed [16:35:11] RIGHT [16:35:18] oops sorry caps lol [16:35:34] I am fixing the back of the LM interior [16:35:48] "fixing" [16:35:51] more like [16:35:57] implementing for the first time :D [16:37:25] true [16:37:36] well, it was there, just the wrong shape [16:37:42] I mean the outline of it [16:38:00] it was square, but it should be circular [16:46:25] right [16:51:01] still can't figure out why the touchdown points aren't right [16:51:11] I added this in your function for it [16:51:11] for (int i = 0;i < 12;i++) [16:51:12] { [16:51:12] td[i].pos -= currentCoG; [16:51:13] } [16:51:39] so it just applies the COG offset to all the points [16:56:55] hmm, what is the behavior of the touchdown points? [16:57:43] it's sunk into the ground too deep [16:59:22] but less so than when I don't apply the offset [17:00:46] if I multiply the offset by 2 then it works :D [17:09:10] pretty much exactly 2x [17:09:18] that shouldn't be necessary [17:09:27] I wonder if something happens in a different order than I expect [17:36:38] morning! [17:50:21] hey Mike [18:09:14] https://www.dropbox.com/s/kebkz3293kedt2j/Screenshot%202020-05-24%2012.08.32.png?dl=0 [18:10:46] ooooo [18:22:04] it's taking shape [18:22:17] I'm pretty sure we have the drawings for this kind of stuff [18:23:13] systems handbook has some pretty good images [18:32:51] we don't have a lot for the interior [18:33:23] we have stuff like this for the exterior: https://archive.org/stream/apertureCardBox523NARASW_images#page/n515/mode/1up [18:33:43] https://archive.org/stream/apertureCardBox523NARASW_images#page/n529/mode/1up [18:37:18] ah yes [18:37:50] https://www.ibiblio.org/apollo/ElectroMechanical.html#LEM_Engineering_Drawings [18:38:01] LDW280- is structural [18:38:42] LDW280-2X is LTA-X, LDW280-5X is LM-X [18:39:16] you might be able to find some useful things [18:40:46] thanks! [18:49:16] making good progress on Sundance [18:49:26] got through bank 16 last night, which is a solid chunk of the DAP [18:49:38] after the misery of P57, the DAP is a lot of fun :D [18:50:17] plenty of differeneces but they all make sense, and pretty much all match up with the Sundance 302 DAP study guide [18:50:40] which has so far given me the name of every erasable that Luminary doesn't have [18:59:58] ah good, you were already fearing that the DAP could be quite difficult [19:01:06] haha yeah [19:01:12] also, I was reflecting on this last night [19:01:26] and knowing what I know right now about Sundance, I think our mix of versions is quite good [19:02:03] if I had to pick a single module for us to have 306, module 6 would be a good choice because one of the few known for sure differences between 302 and 306 is the addition of some extended verbs, and changes there [19:02:53] and if I had to pick 2 to be only 292, modules 1 and 5 would be good choices, since module 1 is so heavily referenced that it's relatively easy to pick out changes just from address offests, and module 5 is mostly descent/ascent stuff :) [19:04:00] then we got lucky [19:04:07] not as lucky as getting a full 306 [19:04:10] but lucky :D [19:04:13] haha yeah [19:04:52] I may have already said this but I'm now completely confident we'll be able to get our version mix to work for the full mission in NASSP [19:05:02] it may not have perfect restart protection or off-nominal stuff [19:05:06] but the normal mission should work fine [19:06:13] awesome [19:06:33] banksums for Sundance would help... [19:11:10] haha yeah [19:16:00] really anything would help lol [19:16:55] I checked transcript and checklists for it already haha [19:18:39] yeah sadly I don't think we're going to find them anywhere [19:25:50] GSOP section 1 talk about the banksums and it's usually for a specific AGC version [19:26:01] so why didn't they just add the banksums there... [19:31:02] heh yeah that would be convenient [19:31:09] sometimes they even scanned a page from the listing... [19:41:22] 19690080218 Final results of the supplemental testing and analysis of the SUNDANCE /revision 306/ flight program for the [19:41:22] Apollo 9 mission [19:41:30] ever thought of requesting that from NARA? [19:41:31] uhh [19:41:32] NTRS [19:42:15] oooh no [19:42:19] that sounds promising though [19:43:35] ...I don't even remember how to do that lol [19:44:09] 19680081045 SUNDANCE test plan in support of the Apollo mission D flight software verification 1968 [19:45:02] I think the old form where you could enter NTRS IDs is gone [19:45:28] so, NASA STI contact form? [19:46:42] yeah I guess so [19:46:49] worth a shot [19:47:42] yeah [19:58:21] Hello [19:59:49] AlexB_88 this is my new test with better switches https://1drv.ms/u/s!ApTRgF_OsQUFgUukiY0DKhUStXYm?e=VlXchC [20:00:14] AlexB_88 you need also this new texture https://1drv.ms/u/s!ApTRgF_OsQUFgU0DO2cQ21UO7lkn?e=RFhkdU [20:00:44] AlexB_88 i also made some tests with screws https://1drv.ms/u/s!ApTRgF_OsQUFgUzGqo3to_lZLy1i?e=7yi9XI [20:01:48] AlexB_88 and this is the LM2 360 panorama in higher quality for offline viewing https://1drv.ms/u/s!ApTRgF_OsQUFgU78AXFhwwXr0E-U?e=Xf3mzX [20:03:00] Here is a link to a windows panorama viewer if don't have one http://www.fsoft.it/FSPViewer/ [20:06:01] hey Jordan64 [20:06:06] hey Jordan [20:06:12] hello [20:06:14] Ill check it out right now [20:06:29] btw I have updates on my LMVC branch [20:06:54] AlexB_88 its your old mesh tha one without that 5cm difference [20:07:08] ok [20:07:20] ok thanks i check your new mesh [20:09:34] very nice [20:09:50] the red is a bit bright but I am sure that is adjustable [20:10:44] its the texture can be changed easy [20:12:10] ah, here is the linear RHC control [20:12:15] definitely different from Luminary :) [20:14:39] hey Jordan [20:14:46] hi indy [20:14:57] yeah they even changed the ACA controls in the ATCA, so both software and hardware :D [20:15:16] made it a bit finer control [20:21:58] oh interesting [20:23:54] I could only implement that behavior thanks to a page on the LM-1 Systems Handbook [20:24:16] but then I had to tweak it to match the behavior in LM-4 and later [20:27:51] man I am so happy we have this DAP study guide [20:27:54] this thing is awesome [20:28:09] and then later I did find the same page in a mission report supplement but I was close enough before and I didn't bother changing it anymore :D [20:28:17] hahahaha [20:30:08] I honestly couldn't say what attitude rates result from it though, it's been a while since I implemented it [20:30:25] if the ATCA and LGC are close in their behavior with the same ACA deflection or not [20:54:01] night! [21:04:03] AlexB_88 copying the new mesh doesn't work. i have compiled your branch and it runs fine. [21:04:32] yeah, there is a bunch of code changes for the new switch positions [21:05:37] Im am continuing work and should push updates to the VC every day for the next while [21:05:45] can i use this mesh do add the details or do you have any plans to change it again? [21:05:47] but for the panel, the position is final [21:06:16] I wont be changing the position of the panel itself, so I think its fine [21:06:46] my work is concentrated now on the interior of the VC [21:07:48] so yeah, if you want to add the detail to the panel part of the mesh (panel 1-4) that is quite finished on my part [21:08:08] is it a problem when the details are a new group. what about the orders of the groups? [21:08:46] no its not too much of an issue, I just used meshc to rebuild the indexes [21:08:52] very easy [21:09:06] all then animations reference the group names [21:09:10] all the* [21:09:29] oh ok that's perfect. [21:09:46] i start tomorrow adding the details ;-) [21:10:19] awesome [21:11:36] actually, there is one more small change I did to the panel mesh, and I will push that later today [21:12:13] (y) good night [21:12:26] I didnt change the position though, all I did was extrude the outer edges backwards a bit [15:51:07] good evening [15:52:33] hey [15:52:52] butting in the side panels now [15:52:56] putting* [15:54:11] great [15:54:38] I still don't know why I have to apply twice the amount of COG offset to the touchdown points, but I'll try to figure that out today [16:10:40] uhh [16:11:05] it's sunk into the ground a bit when I don't even use any CG shifting or touchdown point changes [16:12:52] so that must be the current behavior [16:14:24] AlexB_88, does the LM currently appear a bit sunk into the ground for you? [16:14:48] no [16:14:51] because I think I just commented all the code changes I did [16:15:04] perfectly on the footpads [16:15:21] I fined tuned that already [16:15:57] do you have that linear interpolation set? [16:16:03] yes [16:16:59] try the Apollo 11 before lunar liftoff prep scenario [16:17:28] I'll commit my changes in a branch, to see what the current Orbiter2016 branch does for me [16:21:10] sunk into the ground [16:21:19] with the current Orbiter2016 branch and no local changes [16:21:30] not a lot [16:21:41] but enough for me to try weird things with my code :D [16:22:06] and sinks even more into the ground if I fire a thruster [16:22:30] do you have a screenshot? [16:22:33] sure [16:23:36] the end of the DPS nozzle is basically level with the ground [16:23:40] https://www.dropbox.com/s/xixbnjc6gzix3c8/Screenshot%202020-05-25%2010.23.21.png?dl=0 [16:23:43] https://i.imgur.com/LyqskYP.png [16:23:56] taht is my Apollo 12 pre-ascent scenario after firing a thruster [16:24:05] hmm [16:24:11] that is weird [16:24:18] try our current Apollo 11 before lunar liftoff prep scenario [16:24:26] maybe this just happens in old scenarios [16:24:34] I will test for that [16:25:41] landed scenarios (old ones?) save an altitude parameter [16:25:42] ALT 3.835 [16:26:05] https://www.dropbox.com/s/5olrqol81ylot2u/Screenshot%202020-05-25%2010.25.49.png?dl=0 [16:26:25] that is the Apollo 11 scenario? [16:27:00] that is Apollo 11 - 16 - Lunar Liftoff Prep [16:27:04] how strange [16:27:10] some setting? [16:27:35] what D3D9 version are you using? [16:28:03] R28.8 [16:28:12] I'm also a bit behind in Orbiter revisions I think [16:28:28] I think there was some recent work on the linear interpolation [16:28:40] Im on 29.1 [16:28:48] ok, I will update [16:35:53] it's not perfect, but it's better with cubic interpolation [16:36:13] I changed to linear because you said so, didn't know that was tied to a specific DX9 Client release :D [16:38:20] the 1st 2 pictures I sent you was with linear [16:38:25] when I set mine to cubic: [16:38:26] https://www.dropbox.com/s/7ibln0mrlcvklug/Screenshot%202020-05-25%2010.37.54.png?dl=0 [16:39:42] yep, that looks the same to me [16:41:19] and does linear interpolation look like before? [16:41:34] and you are on the latest now? [16:41:48] latest version of D3D9* [17:34:19] was afk for a bit, just upgraded [17:34:27] one rebuild to be safe [17:34:38] but I definitely expect to get the same behavior as you now [17:35:58] also make sure "mesh resolution" in the advanced D3D9 settings is at least 32 or 64 [17:42:43] works great now [17:48:53] nice [17:50:49] now to see if that also fixes the issue with the variable COG [17:52:19] it does [17:52:25] one less problem to deal with :D [17:52:32] back to testing staging then [17:58:41] glad to hear [17:59:45] these cb panels in the LM are quite the workout to implement, they have a pretty steep incline [18:03:40] yeah, definitely are steep [18:04:16] morning! [18:22:20] hey Mike [18:25:18] what's up? [18:26:26] turns out I just had to update to the latest DX9 Client and a problem I had with the touchdown points of the LM (using variable center of gravity) went away [18:26:46] oh weird [18:26:58] well that's an easy fix, heh [18:27:34] yeah [18:42:21] AlexB_88, in SeparateStage [18:42:31] vs2.vrot.x = 2.32; and vs2.vrot.x = 5.32; [18:42:40] I know this gives the vessels an altitude [18:43:01] but I am a bit confused about the values [18:44:23] yeah I had to fine tune them all for it to work [18:44:52] that was when I updated the touchdown points a few weeks ago [18:51:09] I think they are still correct, just something messes up the center of gravity when landed [18:54:24] oh not only when landed [19:32:21] https://www.dropbox.com/s/rvnqgtb2h232vbr/Screenshot%202020-05-25%2013.32.09.png?dl=0 [19:41:41] very nice [19:44:36] thanks [19:46:41] don't bother fixing view points yet [19:46:47] I had to change that quite a bit [19:51:43] also [19:51:54] in the VC the ORDEAL can be in its correct place now :D [19:55:43] yep :) [20:04:05] hmm, nearly done with the variable CoG for the descent configuration, now I need to decided if there is much to gain for also implementing it for the ascent stage [20:05:39] probably more the moments of inertia than the center of gravity [20:18:43] Sundance checks the "staged" bit of channel 30 all over the place [20:18:50] this is the fifth place or so [20:18:59] must have been a pain to remove all of it, haha [20:24:11] and again, haha [20:26:10] Tindall didn't like it so it had to go :D [20:26:25] but hopefully it was mostly replaced with the stage flag as set in V48 [20:31:49] oh I used the wrong empty mass in my CoG calculation for the descent configuration [20:31:52] yep [20:31:57] I can get even closer to what the LGC assumes [20:32:09] maybe even less RCS firing during descent [20:32:15] oh nice! [20:38:17] https://i.imgur.com/9OdtXKt.png [20:38:24] not bad an approximation with two mass points [20:38:28] for an* [20:39:27] not at all! :D [20:42:33] I forgot to include one "curve" [20:43:19] https://i.imgur.com/hSz7Izr.png [20:43:33] hahahaha oh wow [20:43:37] why it behaved nicely during hovering in p66 becomes obvious [20:45:17] and empty DPS tank is not the left limit [20:45:24] that is an incredible improvement :D [20:45:37] the curve also applies to missions like Apollo 10 that didn't have full APS propellant [20:45:50] DPS fuel all gone is more like 7000 kg than 5000 [20:48:02] the center of gravity in the ascent stage seems to high up [20:48:21] have to check how far off our CoG is for it [20:50:54] the RCS is struggling to keep an empty ascent stage steady [20:51:00] might be worse than it should be [21:18:17] night! [00:05:52] bank 20 done! [00:06:16] which finishes the majority of the DAP, just a little bit of it left in bank 21 [00:13:38] nice [14:52:20] hey [14:57:07] hey Niklas [14:59:21] I have worked out moments of inertia for the ascent stage, but we shouldn't use them yet [14:59:42] what we would need is better RCS minimum impulses [14:59:55] I would just make things worse with realistic PMI [15:00:35] thinking about using a better CoG for the ascent stage, but nothing more than that for it [15:00:55] right [15:01:07] what about CSM? [15:02:24] I think the main improvement for the CSM would be a variable moment of inertia around the roll axis [15:02:40] as that is quite different for full vs. empty [15:03:18] next I have to check if everything works right with docking and LM creation [15:03:29] and then the RTCC updates [15:03:47] then I can push the update I think [15:05:06] and at some point in the future I'll also do CoG shifts on more than one axis [15:06:03] I've been using a vector anyway [15:06:09] so that would be possible [15:07:17] that should be quite interesting, as the APS/DPS/SPS are not nice and centered anymore throughout a burn [15:15:59] yeah, and I guess the need for more pronounced SPS trim angles [15:16:13] DPS/SPS* [15:16:41] oh I guess for the DPS, the +00600 we use might change? [15:17:11] not right now, but if the center of gravity becomes off the y-axis then yes [15:17:45] I'll make some changes so that I only need to fix this stuff in one place in the RTCC [15:18:16] right now e.g. the Maneuver PAD calculation uses a different function to calculate the gimbal angles than the MPT mode CSM burn sim for example [15:19:53] I guess I'll implement it the right way [15:19:58] using RTCC COG tables [15:32:34] nice [16:49:32] morning! [16:53:34] indy91, bank 21 has our first glimpses of landing code [16:53:47] the ROD and redesignation interrupts are already identical to Luminary [16:53:57] the landing analog displays are.... not quite there yet lol [16:55:04] hey [16:55:09] haha [16:55:58] that will be fun to watch if we get those programs to work [16:56:15] hehehe [17:00:43] Hi [17:01:23] hey Jordan [17:06:11] hey [17:09:49] AlexB_88 check this https://1drv.ms/u/s!ApTRgF_OsQUFgU-pgQnElRlXEEbe?e=g8CV43 [17:10:09] AlexB_88 https://1drv.ms/u/s!ApTRgF_OsQUFgVB9voHYozL2IIVx?e=bpcMYc [17:19:36] looks good [17:19:53] the colors might need adjusting though, like the red is a bit too bright [17:20:54] also some of the screws have a bit of a bluish hue to them, maybe they can be corrected to match the gray background better? [17:21:56] the LM close-out photos give nice views of the switches/screws and the color they have [17:21:57] https://www.hq.nasa.gov/alsj/alsj-LMCloseoutPhotos.html [17:26:44] the screws are textured and can be changed easy. take a look at new new Colors.dds [17:28:26] i don't like this red color either. it is only rendered in one color even though I've made more details [17:30:25] ok sounds good [17:30:39] right now I am working on the overhead window [17:34:01] by the way, i moved the switches in panels 1 and 2 a little towards the interior, but they still work [17:37:51] ok [18:35:21] AlexB_88 Check the new texture [18:35:23] https://1drv.ms/u/s!ApTRgF_OsQUFgVB9voHYozL2IIVx?e=GJIdlK [18:47:07] hey Jordan [18:52:36] Jordan, looks good [19:32:27] AlexB_88 (y) [19:32:34] hi indy [19:41:36] AlexB_88, preliminary RTCC results with the new CG of the full LM, 0.1° difference in pitch and yaw trim angles [19:41:47] both larger values, which makes them closer to 0 on the centerline [19:42:09] makes sense, during TLC the LM CG is now about 1 meter further away [19:42:12] from the CSM [19:42:29] and SPS gimbal angles of course [19:45:42] interesting [19:46:19] so not a very significant change [19:47:21] one more thing I have to take care of is exhausts [19:47:36] while thrusters are shifted with ShiftCG, exhaust definitions are not [19:48:39] exhausts are directly attached to a thruster [19:48:42] so that's a bit odd [19:51:04] ah, but you define a separate position for exhausts [20:40:16] night! [21:18:46] good night [12:52:33] good afternoon [12:52:43] good morning [12:52:51] think they will scrub the launch today? [12:53:55] hmm, I'd give it 50/50 at the moment I think [12:54:13] I think they have a meeting in an hour about it [12:55:45] and of course they could go all the way to before liftoff and scrub then [12:56:01] that would be annoying [12:57:14] remember when most Falcon 9 launches were scrubbed just before launch? :D [13:06:48] haha yeah [13:07:17] probably will err on the side of caution with this one [13:10:29] on the other hand, the tropical storm is having landfall quite soon [13:10:38] by T-0 the weather might be good enough [13:10:56] true [13:11:05] still have a lot of time [13:23:16] man I havent been able to play with the LM, honeydo stuff all weekend and work piled up because of the short week lol [13:23:24] I want to get back in there soon [13:24:10] I'm working on giving the LM a variable center of gravity [13:24:18] at least along the x-axis [13:24:31] makes a lot of different for RCS activity during descent [13:24:35] basically none anymore [13:24:55] oh excellent [13:25:02] the issue with our current behavior becomes obvious when you look at this [13:25:04] https://i.imgur.com/hSz7Izr.png [13:25:13] did we put that cant angle on the APS bell? [13:25:30] lol [13:25:33] not yet, mainly working in the full LM [13:25:52] we also will need to fix the AGS padload when that is in [13:26:09] yeah [13:26:10] I think we put it at zero right now [13:26:52] well the problem with the ascent stage is if I give it realistic moments of inertia the RCS has a lot of trouble [13:27:08] the RCS needs to be able to do minimum impulse bursts [13:27:24] so for now I'm only doing the full LM and only on one axis [13:27:29] so no trim angles yet either [13:27:47] that's already enough trouble. I need to shift touchdown points, exhausts... [13:28:20] currently working on exhausts. I can directly attach it to a thruster position and then it gets shifted automatically [13:28:26] but not correctly it seems [13:28:34] I'm smelling an Orbiter bug, but I have to investigate more [13:33:13] haha you are good at finding those [13:33:25] and I can even get them fixed [13:33:31] but this isn't one [13:33:46] also, just out of curiosity, is exhaust impingement simulated on the LM with the deflectors? [13:33:55] I would assume no [13:33:56] the exhaust position is the thruster position [13:33:59] ok [13:34:14] oh no, that was related to what I am working on :D [13:34:26] the exhaust position is the thruster position, so GetExhaustSpec() is returning that and not the exhaust offset I am giving it [13:34:31] so I was just reading the number wrong [13:34:35] no bug [13:34:43] exhaust gets shifted with the CG currently, yay [13:34:54] and no, we don't simulate that [13:35:55] we could maybe [13:36:03] I know how MIT was simulating it [13:36:49] for the 4 thrusters that are affected by that it gave an additional thrust vector [13:37:01] we could implement something like that as well [13:37:51] seems to make a large difference for one of the jets [13:37:56] not so large for the other 3 [13:41:03] I would imagine it was taken into account [13:41:27] but maybe it was offset shallow enough to not matter [13:44:06] hmm, MIT simulator seems to treat thrust and torque separately [13:44:28] well anyway, we can try that eventually [13:45:10] exhausts are good, so not much left for me to check [13:46:18] APS exhaust is weird [13:46:36] exhaust position further up than the thruster position [13:46:52] uh that is weird [13:48:08] I can't even give it a negative offset [13:48:24] just wanting to prepare the ascent stage, even though its CG offset from the mesh will stay 0,0,0 for now [13:50:06] I'm doing everything with vectors, so in the future I can place the CG everywhere I want [13:50:11] oh good [13:50:29] oh I can use a negative offset, all good then [13:50:34] exhausts are solved [13:54:10] sweet [13:54:51] tropical storm has already made landfall [13:55:35] still chance of tstorms from the convective area [13:55:38] yeah [13:56:13] oh, and I think quite soon I am going to be annoyed enough about the SPS being at at offset position that I will fix that [13:57:09] then the SPS will always be centered, which is equal to trim gimal angles of about 2° pitch and 1° yaw [13:57:26] unless I shift the CG off center, then it will be more realistic [13:57:38] RTCC is already prepared for that [13:58:58] I am looking forward for those engine gimbals to make a difference [13:59:41] yeah [14:00:00] I'll give us all some time to fly the LM a bit with that shifting CG [14:00:23] but then I can go a step further [14:01:39] I think I have some pretty good sources for realistic CG behavior [14:02:14] Also need to test it in a docked DPS as well [14:03:31] oh yeah, docked DPS should also behave better with full DPS propellant now [14:05:00] definitely makes a big difference. When you look at the rate needles the DPS gimballing is really controlling the LM now. Didn't really look like that before [14:05:05] RCS had to help out a lot [14:05:32] I'll test that Apollo 9 docked DPS burn right now [14:06:24] sweet [14:07:29] hey [14:10:10] hey Alex [14:10:53] docked DPS burn works really good [14:11:14] perfect [14:11:23] AlexB_88, we used fixed positions for thruster exhaust. I changed it so their position is attached to their thruster and now they get automatically shifted with ShiftCG [14:11:46] oh nice [14:13:02] so the only thing so far I have to "manually" update with each CG shift is the touchdown points [14:16:04] which is probably just a missing feature [14:17:50] I don't think I had a single yaw or pitch thruster firing during the whole docked DPS burn [14:18:19] impressive [14:18:38] even with the slow gimbal? [14:18:42] thats pretty good [14:19:05] well you have seen the graph of how wrong the DPS moment arm was :D [14:19:20] next problem, tracking light didn't get shifted [14:19:26] I guess the LM VC still works alright with all those changes, like switch click spots etc? [14:20:25] I think it did, I'll try now [14:20:58] uh oh [14:21:59] but the fix can't be too difficult, as SSU has the same issue [14:22:16] oh is the tracking light view distance an orbiter limitation? [14:26:45] https://www.dropbox.com/s/uaqnyi1h513km7x/Screenshot%202020-05-27%2008.26.10.png?dl=0 [14:27:02] think I have the overhead window looking like I want it [14:27:44] very nice [14:27:59] no idea with the light [14:28:11] but shifting their position with the CG shift is easy, luckily [14:29:36] hmm [14:29:37] or not [14:29:52] or yes, if you actually shift them :D [14:31:37] AlexB_88, talkbacks aren't working yet in the VC, right? [14:31:54] they should be [14:31:59] hmm [14:32:06] everything on panel 1-4 is working [14:32:06] am I not at the latest state [14:32:59] it was all part of my phase 1 PR [14:33:23] hmm unless I forgot some textures [14:33:45] they all show their halfway state [14:34:08] let me check if that is also the case in the Orbiter2016 branch [14:34:19] or an issue in my ShiftCG branch [14:34:37] as I can't move any switches that could well be [14:34:43] DSKY works right though [14:34:46] and other lights [14:35:03] ok I found out why [14:35:14] I forgot to add some textures to my PR [14:35:38] let me do that now to the Orbiter2016 branch [14:35:54] ok [14:36:13] you probably dont have the master alarm working either [14:37:14] affirmative [14:38:22] talkbacks not working in Orbiter2016 branch, but switches are working [14:40:03] yeah, its just 3 files that are missing [14:41:26] brb [14:42:38] SSU has code in their switch classes for the CG offset, but all commented out [14:43:48] they still use it in their panel definition functions [14:44:05] which can't be enough as that wouldn't be called each time the CG is updated [14:49:26] hmm [14:49:50] it's applied in clbkLoadVC [14:51:10] you already have an ofs variable in RegisterActiveAreas [14:51:21] what's that exactly for? [14:51:24] PR sent [14:51:42] all the switch click spots will be on the floor if I leave that out [14:52:08] ah [14:52:17] I think I can add the CG offset to that variable [14:52:23] and everything should work [14:53:01] merged [14:53:20] the mesh is shifted automatically and I am taking care of the view points [14:53:30] so just the click areas need that CG offset [14:53:44] yeah [14:54:49] yep, it's working [14:55:10] easy :D [14:55:25] great [14:58:16] sometimes I still have a little trouble finding the right spot to click on the switches in the VC [14:58:23] but I'll get used to it [14:58:40] talkbacks and master alarm light working now [14:59:01] oh [14:59:15] is the click area for switching a toggle switch up and down the same? [15:00:07] and three position switch it is left and right click for up and down [15:00:11] but also the same area? [15:01:41] its all the same area [15:01:47] middle of the switch [15:02:07] ah ok [15:02:12] different than the 2D panel [15:02:16] but I can deal with it :D [15:02:29] and the left/right click is what decides the action [15:02:41] yeah [15:02:42] the only exception is the RR slew switch [15:02:54] I was clicking further up and down, that explains why it sometimes didn't work [15:03:02] should be clicking right in the middle of it [15:03:03] that one is quadrilateral mode and it works same as 2D panel [15:03:12] well, on it [15:05:23] what else do I have to take care of... [15:05:27] airfoils [15:05:42] does the LM have an airfoil defined? :D [15:06:29] nope, just the basic drag model in Orbiter [15:06:41] but I will have to take care of that if I shift the cg in the CSM [15:10:18] LM has no attachment points, but they should be shifted anyway [15:10:28] docking port looked good [15:10:38] animations didn't look messed up either [15:10:55] I gess they belong to a mesh anyway [15:17:10] right [15:18:01] alright, now for something more interesting then making windows... the AOT section :) [15:19:24] ah nice [15:19:32] I think I need to change the light definitions a bit [15:19:43] their position is a static [15:19:48] but now I need to modify that [15:19:54] have to figure out if that is safe [15:20:09] might have to make them separate variables, that's how SSU does it [15:20:16] for the lights that are CG shifted [16:37:40] 60% chance of scrubbing according to the livestream because of precip and visibility [16:44:32] morning! [16:45:33] hey [16:46:36] what's up? [16:47:06] watching the livestream between teleconferences lol [16:47:36] :D [16:57:41] watching the livestream between testing LM things [17:00:08] The suits look pretty slick I must say [17:06:25] the most exciting part of every webcast, looking at tweets [17:09:07] lol [17:09:10] riveting... [17:09:24] some good rain there still it seems [17:09:32] https://twitter.com/NASASpaceflight/status/1265690330193711106 [17:09:48] "We're going to need some more all weather testing" [17:10:41] or we just make the flight rules stricter, so that we scrub more often [17:11:07] I hope they have an SCE to AUX switch ;) [17:11:51] Haha they are riding to the pad in a tesla? [17:12:13] yep [17:12:16] I hope they have no SCE [17:12:40] Haha good point [17:13:12] but I guess they still have non-digital electricity, so some amount of signal conditioning is required :D [17:14:26] not sure how I feel about the teslas... [17:14:38] But they have GSE built in for the suits [17:14:44] So no suitcases/ac packs [17:15:58] Astrovan is for Orion and Artemis I guess [17:17:11] lol I saw a parking spot sign "astronaut electric vehicle parking only" [17:27:38] hehehe [17:28:10] so they have GSE in the car, the elevator, and the white room [17:29:47] Am I watching a NASCAR pre-race show or a rocket launch? [17:30:11] haha [17:30:15] I know right? [17:30:30] I hope to fuck they locked up all the "management caps" [17:32:02] the difference is that there will probably be no flyover [17:32:24] not likely [17:32:31] but I heard there is a national anthem [17:32:36] there was [17:32:51] and I was like 'wtf' [17:33:08] yeah there was [17:33:17] Kelly Clarkson sung it from home [17:33:36] ah [17:34:38] launchpad looks wet [17:35:31] I heard it has a toilet now. [17:35:38] maybe it's leaking [17:35:44] yeah it does [17:35:51] part of the orbital checks will be using it [17:36:01] so that's what the breakfast was for [17:36:34] haha [17:36:43] steak eggs and metamusel! [17:39:40] crazy how small LC 39A looks now [17:40:01] And how big the concrete slab looks [17:40:14] they are pulling an alan shephard! [17:40:36] they posed for an alan shephard pic staring up at the vehicle [17:41:28] sure did [17:41:38] yeah, no huge RSS [17:42:02] white room crew in all black? [17:48:34] my god these announcers [17:48:38] wtf are they smoking [17:48:52] "it's from the future, it's something like you would see on the george jetsons" [17:49:41] Ok I wasnt the only one feeling a wtf moment there [17:49:50] no you were not rcflyinghokie [17:50:18] Guenter! [17:50:22] your successors are at work :D [17:50:27] its crazy how spartan the inside of the vehicle is [17:50:32] yeah it is [17:50:33] I am still looking for the future that was 2001 [17:50:52] thewonderidiot, I was just thinking about Guenther [17:50:53] Haha just recently watched BTTF again and saw how 2015 should have been [17:51:02] no flying cars [17:51:04] thankfully [17:51:14] people can't drive worth a damn, and computers suck at it too [17:51:31] I hope this ride has good computers [17:51:33] guess we will see how well they fly the spacecraft [17:51:44] don't even need FIDOs anymore [17:52:01] I think all the maneuvers are autonomous? [17:52:09] I am sure they will do manual checks [17:52:29] I hope we get a stream during orbital checks [17:53:27] someone was already asking for an MFD for that on the Orbiter Forum [17:53:35] hahaha [17:53:40] if I knew more about the rendezvous profile I could do it. I just know the last part is coelliptic [17:54:00] There was a simplified plan of it on their website [17:54:25] https://www.spacex.com/launches/ [17:54:31] scroll down a little [17:55:03] looks like 2 phasing burns [17:55:10] Dragon evokes these images of the disagreement on the Apollo design for me: [17:55:10] https://wehackthemoon.com/sites/default/files/styles/hero_extra_large_1x_2000x_/public/media/graphic-illustration/32413.jpg?itok=gTPRPuow [17:55:11] https://wehackthemoon.com/sites/default/files/styles/hero_extra_large_1x_2000x_/public/media/graphic-illustration/32412.jpg?itok=U6VLYPGq [17:56:05] ohh, I've never seen those drawings in such a detail [17:56:13] yeah they arent bad [17:56:37] its very similar to a lunar ascent [17:56:51] Apollo ended up more like the first one [17:56:59] Dragon is definitely the one with the one abort button :D [17:57:03] lol [17:57:03] hehehe [17:57:58] look at the entry burns, I guess they lower it in stages due to the lower ISP of the engine? [17:58:17] not isp, thrust [17:58:31] or both idk the specs of the engine [18:02:13] maybe 2 phasing burns after the departure [18:02:19] https://twitter.com/SpaceflightNow/status/1265702942725849089 [18:03:36] fun [18:06:45] better pad comm than during Apollo [18:11:51] oh seat rotation [18:11:53] interesting [18:11:56] that angle makes much more sense [18:17:50] go to close the hatch! [18:27:30] https://www.youtube.com/watch?v=3ZEnDFIkq_E [18:27:47] Scott Manley is on the NSF stream, and is more interesting to listen to than Elon :P [18:28:58] also this: https://www.youtube.com/watch?v=nA9UZF-SZoQ [18:29:06] alternative shots on the NASA TV Media Channel [18:29:33] showing cabin closeout right now [18:30:05] looks a bit simpler than previous hatches [18:34:47] Special Notice – NASA Technical Reports Server (NTRS) Upgrade [18:34:48] The NASA Scientific and Technical Information (STI) Program is upgrading the NASA Technical Reports Server (NTRS) to enhance discoverability of, and access to, NASA funded STI. As part of this process, updates to the collection will be on hold from May 23, 2020 through late summer. [18:35:40] either you can find nothing anymore after that upgrade or they might put back up some documents [18:35:51] whoa [18:35:53] interesting [18:36:22] some many emails did you sent them Mike? :D [18:36:32] I haven't sent them any yet lol [18:38:08] well I don't have much hope that they make currently restricted documents available again. But we will see [18:43:17] https://www.dropbox.com/s/ppavbgvlj80q2hh/Screenshot%202020-05-27%2012.42.25.png?dl=0 [18:43:24] those handles took all morning lol [18:47:03] nice job [18:47:09] oh, we do get out flyover after all [18:47:11] Yay, the President has arrived! He'll fix the weather and everything will be fine. [18:48:49] well it just started raining [18:49:21] Stupid Democrats trying to sabotage Trump's launch [18:49:43] They waited right until he showed up, just to attack him personally [19:00:41] one thing I am hoping to do is make the eye piece of the AOT a click spot that takes you straight to the 2D AOT view [19:01:29] and then maybe if it know you came from the VC, ctrl-down takes you back to it [19:01:30] ah, yeah that makes sense [19:04:45] I guess you can't really stay in the VC in the AOT view [19:05:32] maybe a flag can be set [19:05:40] or we might already have one [19:05:56] InVC [19:33:58] 1 hour [19:39:46] weather still bad? [19:40:11] Also, why can't the AOT work in VC? [19:42:08] weather still bad but getting better [19:42:51] Alex seemed to assume it can't work, but I am not so sure [19:43:38] hmm, I dont know for sure, maybe it is possible [19:44:14] but I am thinking in the short-medium term, using the 2D AOT view panel is not a bad solution [19:44:59] at the end of the day, what you see through it is not going to make any difference in 3D vs. 2D so I dont see why doing it twice is needed [19:46:00] That makes sense; I thought it was some unexpected orbiter limitation or something like that. [19:46:51] I mean it may be possible at some point to do it in 3D, more investigation will be needed I guess [19:47:11] can you do a system of mirrors or prism or whatever the AOT uses? [19:47:15] probably not [19:48:10] the AOT controls I will definitely have working in 3d from the start though (reticle angle display, detent selector) [19:48:52] yeah, those should work no problem [19:49:51] bye bye white room [19:50:09] been a long time since I've seen that view [19:50:25] ok, I guess DM-1 had it as well, but before that :D [19:50:54] Did they say when the next window is if they scrub? [19:51:16] Saturday [19:52:13] go for pyro arm :D [19:52:34] we wont get a go nogo callout :( [20:14:54] not looking good for a launch today [20:15:31] nope [20:16:56] scrub [20:17:34] scrubbed [20:17:41] continuing a Shuttle tradition [20:37:44] night! [13:41:43] hey [13:42:48] hey Alex [13:43:33] I thought all my variable CG stuff was working great... until I just got a CTD at staging and then ascent stage and descent stage being thrown out of their orbits, without CTD [13:43:44] and now I can't reproduce either [13:44:41] oh damn [13:50:04] I have tried a technique for making the LPD markings in the LM VC [13:50:16] and it seems to work good [13:51:27] ah nice [13:51:49] just got it again. Only in release mode so far, I couldn't debug, just an access violation [13:52:39] oh and with the APS engine on delay takeoff is a bit slow [13:52:58] that's because it was only allowed to ramp up thrust after staging [13:53:08] but the engine on signal is sent before staging is done [13:53:22] so I'll let most of the APS timestep run during any stage now [13:53:27] should help [13:53:50] we can't currently have both DPS and APS [13:55:38] right [13:55:58] I guess it will start at near 100% thrust then [13:55:59] which is ok [13:59:55] I can't get it in debug mode, very frustrating [14:10:01] I bet it is [14:10:48] for the LPD, I have used the 2D LPD markings we have and saved it as a scalable vector graphic (.svg) [14:11:15] and then I can import that into blender and make a 3D mesh out of it [14:12:44] and I position my view in blender in front of the window, to the same eyepoint as in LPD view, and place the 3D LPD mesh in front of me so it lines up correctly [14:12:59] then I project the LPD mesh onto the double windows [14:13:35] so it has the effect that if you are looking straight at it, they are super-imposed and look the same as the 2D LPD [14:13:54] but if you at a different position, the LPD looks warped, like in reality [14:15:07] yeah, sounds realistic [14:17:04] the hard part is finding the right eye-point and placing the LPD correctly [14:20:38] ok, it's not the moving of the lights with the CG [14:20:45] just got a CTD with that commented [14:21:01] I can fairly reliably cause the CTD in release mode with a full rebuild [14:21:09] it could be touchdown points [14:22:32] I think right now I set them twice in the timestep when staging happens [14:22:37] could be an issue [14:25:59] yeah [14:26:06] I think they have to be static [14:26:19] they aren't but it wasn't an issue before as I didn't change the values [14:29:12] yep, that's probably memory unsafe [14:29:22] Shuttle A has some code manipulating the touchdown points [14:39:32] please be fixed, please be fixed, please be fixed [14:42:50] no, can't be fixed yet.. [14:50:10] but I think the issue is that the touchdown point definition was memory unsafe [14:50:13] has to be static [14:51:31] right [14:52:02] I'm also no expert about what static means [14:52:11] but in any case we had it memory unsafe... I think :D [14:52:54] not fixed :( [14:53:10] damn [14:54:01] next theory, calling settouchdownpoints twice in a timestep is bad [14:54:13] it's called when the ascent stage is created [14:54:26] and there everything should be shifted correctly CG wise [14:54:41] and then it is called again to give the ascent stage a CG offset [14:55:10] I'll try disabling that second call, so only make the CG shifting work for descent stage [14:55:36] and full rebuild, which makes this a bit of a lengthy process... [14:55:40] at least it's quite reliable [14:56:17] the only time I didn't have a CTD was with the touchdown point function commented out [14:56:32] but that is strange, I thought it was all working fine before even with that... [14:57:49] no CTD [14:59:42] now with all the CG shifting code intact, but no touchdown point definition in SetLmAscentHoverStage [15:01:02] do they even need to be in SetLmAscentHoverStage? [15:01:28] hmm [15:01:31] now that they are updated by the CG stuff [15:01:47] yeah, but that is done in clbkPostStep [15:01:57] ideally the touchdown points would be applied in PostCreation [15:02:06] and then whenever it needs updating [15:02:08] https://www.dropbox.com/s/848u1e9ibenht8l/Screenshot%202020-05-28%2008.49.43.png?dl=0 [15:02:20] and this is from an angle: [15:02:25] https://www.dropbox.com/s/fhao8bs48qx39hb/Screenshot%202020-05-28%2008.50.17.png?dl=0 [15:02:55] ah great [15:03:27] its not quite lined up right yet as you can see, still need to tweak it [15:03:46] and might have to be adjusted with the right CDR position [15:04:35] yeah, well I have been using trial and error for that right now [15:04:42] do we have actual figures for that? [15:20:07] can't find anything [15:23:00] I think I have found a view point that is quite good [15:24:15] I cant say for sure, but the size and placement of the projected LPD scale on the windows looks close to real pictures [15:24:30] got a CTD even with the touchdown point definition in SetLmAscentHoverStage commented [15:27:15] so I don't think it's that dual touchdown point definition in one timestep [15:29:23] very weird [15:30:11] so must be contained to the shift CG code [15:30:27] where I am also manipulating the touchdown points when the CG changes [15:32:10] I think it might be something very simple and stupid [15:32:17] not even touchdown point related [15:32:43] I have a function that calculates new PMI and CG [15:32:52] and returns them to the main CG shift code [15:33:05] and only then does it calls SetPMI and ShiftCG [15:33:36] but instead of setting the PMI variable there I was directly calling SetPMI [15:33:43] so the PMI variable was never set [15:33:54] and then the main shift CG code was calling SetPMI again [15:34:07] with a PMI variable that was never giving a value [15:34:44] I had seen that and fixed it, but I think I reverted something [15:34:52] and I never looked at that function again [15:35:07] if that's the only issue then I would be very annoyed but also very happy :D [15:35:19] basically undefined PMI, only for the ascent stage [15:35:29] which would make sense that it causes an issue at staging [15:37:10] and wouldn't have happened before I reverted some code [15:37:28] no CTD [15:40:23] such a dumb, dumb bug [15:45:50] if that explanation was too complicated, it's equivalent to this code: [15:45:53] VECTOR3 pmi; [15:45:59] SetPMI(_V(2,2,2)); [15:46:03] SetPMI(pmi); [15:50:54] glad ou found it [15:50:57] you* [16:11:13] same :D [16:11:29] but after that I will take a few more days for testing [16:12:16] makes sense [16:12:36] in any event I am too busy in blender to try anything new :D [16:15:59] right, no problem [16:16:21] I guess the only issue we will have at merging is the view position [16:16:29] as I had to change some things there [16:16:39] but shouldn't be too much trouble [16:16:46] but I doubt it's an auto merge [16:17:24] well, I havent played with the views yet [16:17:42] I only did a small change for my LPD test [16:17:56] but I am already reverted back [16:18:27] I am going to keep the actual adding of the LPD for the end [16:18:35] ok [16:18:35] today I just perfected the technique [16:19:28] what is the view behavior now on your end? [16:21:33] SetView was changed [16:21:42] SetCameraOffset is only called once, at the end [16:21:53] for all the options above it only does e.g. v =_V(0, 0.35, 1.5); [16:22:07] and then in some cases v.x += ViewOffsetx; [16:22:20] where it jitters around during engine thrusting [16:22:34] and the one call fo SetCameraOffset is [16:22:36] SetCameraOffset(v - currentCoG); [16:23:22] so no major change, but if you changed one of the values in SetView there will be a (fairly easily fixable) merge conflict [16:23:29] right [16:23:41] I will not change anything there until you merge [16:24:03] that prevents this issue, thanks :D [16:24:18] I am not there yet in my work anyway so all good [16:24:45] had some fun issues if I didn't do that [16:25:04] on my first landing attempt the view was looking directly at one of the meshes you see from the 2D panel LPD view [16:25:23] could hardly see anything [16:25:44] I think that's all fixed, I guess I should check if all the meshes from inside and outside view are correct [16:27:09] right [16:28:15] once I get to the views, I would like to make it so when you change positions in the LM, you get a smooth transition [16:28:50] yeah, and we can remove some of that old code that uses ALT + some key [16:29:05] we can once again take SSU as an example [16:29:12] they have a looot of view positions [16:29:14] and directions [16:29:58] yep [16:35:56] the LPD view should be quite possible with the right direction [16:36:06] same for e.g. COAS [16:40:23] for the LPD view, the SetCameraDefaultDirection needs to set the proper downward view angle (30 degrees) [16:40:36] like the 2D panel does [16:41:14] I did that in my test, and slightly adjusted the view position and it worked great [16:41:39] the mesh is also 30 degrees downward before I project it on the window [16:43:55] right [16:49:14] morning! [16:49:55] hey Mike [16:50:25] what's up? [16:50:42] thought I had a terrible bug, turned out to be a dumb and simple bug, crisis averted [16:50:51] haha nice :D [17:01:13] thewonderidiot, I managed to get realistic LPD markings in the VC [17:01:51] looking straight at it: https://www.dropbox.com/s/cvahovsxd44khe8/Screenshot%202020-05-28%2011.00.26.png?dl=0 [17:03:11] but from a bad angle, its gets warped: [17:03:12] https://www.dropbox.com/s/fe62dfn6uued3m2/Screenshot%202020-05-28%2011.02.53.png?dl=0 [17:03:36] nice! :D [17:04:04] I think they're printed at slightly different scales, though, aren't they? so you'll only get one line at a time that completely lines up or so [17:04:18] next step? :D [17:05:54] hmm interesting, ill have to research that [17:06:47] for now it was just a test I am doing, and Ill revisit it when I get near finishing the VC [17:07:04] but that shouldnt be hard to do I think [17:08:11] one thing though is we cant easily move our heads to look at different lines [17:08:50] unless you manage to run it in VR I guess [17:43:02] or get headtracking working... but yeah that makes sense [17:45:21] you can have as many view directions as arrow keys [17:45:28] not quite enough for a lot of LPD views :D [18:00:48] oh wow [18:01:07] the main reason that the LM center of gravity is not on the X-axis is the astronauts [18:01:41] for mass computations they are considered to be at 43 inches on the z-axis [18:02:02] 469.7 lbs for LM-7 [18:02:29] which roughly causes a CG shift towards plus z of 0.6 inches [18:04:11] enough to cause 1° in pitch DPS gimbal trim [18:07:13] so I guess I have to consider the astronauts if I make the CG model more complex :D [18:07:53] it's like they perfectly balanced the CG of the LM and then realized "oh right, we have astronauts standing on one end of the LM"