[16:54:14] NASSP Logging has been started by indy91 [16:54:16] hey [17:57:25] hey [17:58:22] I requested that system parameters document from UHCL last night [17:58:37] morning! [18:20:56] hey Mike [18:35:14] ah nice [18:36:58] I'm trying to make RCS deorbit burns actually feasible [18:37:16] the Earth Entry PAD so far has assumed all burns are with the SPS [18:37:37] and the reentry profile is different so you have to give it the data for that to produce correct entry data [18:38:02] normally you fly lift vector up until 0.2g or until you trust the CMC or so [18:38:20] but RCS deorbit the entry is very shallow, so instead the profile is lift vector down until 1.0g [18:40:57] and I'm at least partially trying to implement the correct workflow in the RTCC for all this, but that will require a bunch more work. Mostly pushing data tables back and forth haha [18:56:37] how much "internal state" does our RTCC have? [19:01:14] what do you mean with internal state? [19:04:50] results of calculations stored in tables/ intermediate results stuff like that [19:05:41] already a decent amount in a lot of parts of the RTCC I would say [19:06:01] we have that RTCC Operations Support Plan with the full list of RTCC functions and tables [19:06:32] and the IBM documents will mention the tables very often and where things are stored and coming from [19:08:50] that has been a lot I am doing. Figuring out where something was actually stored and then move it from RTCC MFD code to the right place in the RTCC class [19:30:27] I went down a rabbit hole last night trying to think of a good way to do plotboards and charts [19:37:17] I didn't get any closer to that conceptually than we are right now [19:39:05] haha [19:39:17] well we already have the launch analog displays [19:39:29] which existed both as TV screen and plotboard [19:42:51] so thats the natural candidate for our first plotboard [19:49:26] that's a nice one [19:53:03] did the SM RCS deorbit, reentry still coming up [19:53:12] lots of issues in the RTCC still, sigh [19:53:35] starting with the burn time prediction surprisingly [19:53:58] a while back I gave the SM RCS thrusters more realistic directions [19:54:06] they are canted by 10° or something like that [19:54:27] I probably need to adjust the RTCC system parameters (ha) for the thrusters [20:13:28] so our RTCC has a different angle? [20:16:50] I think it's the total thrust value [20:16:57] X vs. X*cos(10°) [20:17:34] but that is less difference than I thought [20:17:46] in the end it was actually not so bad [20:18:14] EMS range calculation got confused somehow. 1200 NM on the pre burn PAD, suddenly 2000 NM post-burn [20:18:29] but actually it was fine and 1200 NM would have been about right [20:19:42] so just two issues, burn time longer than predicted and EMS range [22:03:42] night! [02:09:41] .tell indy91 https://ntrs.nasa.gov/api/citations/19710001851/downloads/19710001851.pdf this is an interesting read. was not expecting to find it on NTRS. [15:22:07] good morning [15:25:38] hey [15:29:38] I think I have seen this document, but couldn't find much use for it haha [15:41:53] I figured out why the SM RCS deorbit burn took longer than predicted. RTCC values and NASSP thrust did a little bit, but mostly it is because of the offset CG [15:42:22] it doesn't burn all 4 RCS +X jets all the time, because every second it needs to stop firing one of the thrusters for a moment to keep in attitude [15:42:53] the CSM Data Book lists "effective thrust" for various CSM weights, which can be quite a bit lower than all 4 jets together normally [15:47:42] oh. ha. I wouldn't have thought of that. makes perfect sense though [15:48:39] about that document, I just thought it was interesting, that in some ways producing those display formats was probably slightly easier for them that it is for us, contrary to most of the other programming tasks [15:49:58] easier maybe, but very laborious. They had to produce 1000s of background slides [15:50:35] I would also like a better system for creating MFD pages that resemble displays... [15:51:49] like a "DFL" wrapper api for all the oapi::sketchpad calls [15:52:51] or some kind of interactive "pyDRAFT" program that lets you lay out the format and automaticially produces the output [15:54:38] yeah. Definitely something I want before I ever start implemented 100s of telemetry displays [15:54:46] implementing* [15:55:16] yeah that would be hell otherwise [15:57:23] class displayFormat{ [15:57:26] public: [15:57:35] void refresh(); [15:57:39] etc... [15:58:09] load from kind of config file [15:59:28] my ratio of suggesting good ideas, to implementing good ideas is getting a bit skewed lately... [16:02:53] I am implementing many good ideas, very few of them getting us closer to a NASSP 8 release [16:03:37] and many more ideas go like: I want to improve X, I find that I probably need document Y for that. Document isn't available right now (restricted NTRS, NARA), so I postpone the idea [16:11:04] the other issue I had, the EMS range, probably was some lift vector confusion. There are separate variables for CMC vs. backup techniques. Didn't have the issue again after fixing some stuff there. [16:11:20] So I'm making a PR soon, basically the "SM RCS deorbit" enhancement update haha [16:12:12] I should probably add a SM RCS deorbit example to the manual though [16:27:29] nice [17:22:38] morning! [17:52:44] hey Mike [18:05:21] what's up? [18:22:31] throwing CSMs back to Earth with the RCS [18:22:51] and you? [19:03:08] Hey [19:06:47] hey there James [19:06:52] indy91, mostly meetings lol [19:07:06] going to make some more changes to my test board and hopefully send it out for fab this weekend [19:56:23] heyo, about to submit that PR to correct the FC configs on A8-11 [19:56:57] just gotta do some preliminary testing to make sure all the SCNs still work properly [19:58:52] Nice. I'll be out in a bit but will take a look when I get back [20:39:29] CaptainSwag101, what's wrong with the fuel cell configs? [20:50:28] Apollo 8 through 12 connected FC 2&3 to MNB, but checklists and mission state SCN files only connect FC 3 to MNB, which was only done from Apollo 13 and onward. [20:51:50] ah, so you get to edit some scenarios. Have fun haha [20:51:51] I noticed it while reading through the pre-launch checklists for Apollo 12 and verified that it is the case as far back as Apollo 8 and even mentioned in the AOH from 1967 [20:52:13] yep, it should be all set, I submitted the PR moments ago [20:52:56] I will also be creating an issue shortly, since the "just before launch" SCN files for Apollo 9 and 10 immediately trigger a pad abort upon loading in. This was not caused by my changes, however. [20:54:26] hmm [20:54:42] I can verify that [20:55:02] very strange, that can't have been the case for too long [20:57:07] but I might just never use those scenarios so I didn't notice [20:57:34] shouldn't be too hard to figure out what's causing that [20:58:51] although it is strange, auto aborts shouldn't work at all before launch [20:59:15] even if the conditions for an auto abort are present, auto aborts are enabled at commit [20:59:51] but maybe that is part of the problem [21:02:04] can't say for sure, I'm also getting a "Liftoff!" notice in the top corner at the A10 T-20m scenario but not lifting off, naturally [21:03:50] the CMC also immediately loads P11 [21:06:01] yeah, seems like some liftoff signal is present [21:06:04] and all engines off [21:06:12] so two engines out abort logic is thinking [21:06:18] abort, abort, abort [21:06:57] probably some small scenario edit required in the EDS or mobile launcher, but not sure yet [21:07:31] oooooooh [21:08:06] we changed the names of the Apollo 9 and 10 CSM [21:08:41] from AS-504 to Gumdrop and AS-505 to Charlie-Brown [21:09:01] and there was probably something missing for the mobile launcher [21:09:15] yeah [21:09:17] LVNAME AS-504 [21:09:35] so the Mobile Launcher doesn't know about the rocket and everything gets confused [21:09:41] ahhhh [21:11:56] a bunch of signals from the ML to the CSM and IU are permanently active signals that do something once they get removed [21:11:59] like liftoff [21:12:08] umbilical gets removed, liftoff signal is now present [21:12:18] hahaha, amazing [21:12:27] so this kind of works like umbilical being immediately removed [21:12:41] because the ML doesn't even know the Saturn is still there [21:13:41] look at that, no abort [21:14:16] so just have to fix all LVNAME in Apollo 9 and 10 prelaunch scenarios [21:16:10] That early Liftoff! message will have the same cause [21:19:06] gotcha [21:19:09] that's rather silly [21:27:36] although I feel like maybe there shouldn't be an abort if you just removed the umbilical [21:32:38] yeah I think there is something slightly wrong in code as well, but only under these circumstances did it lead to the abort [21:38:10] should I create an official issue or is this already being taken care of? [21:39:06] I have created the issue in my head :) [21:44:56] hahahaha [21:44:58] good enough [22:25:18] night! [22:48:14] night [22:52:03] CaptainSwag101, you lost the race [22:52:29] Niklas likes to say "night!" and then almost immediately log off -- it's very difficult to manage to tell him goodnight back before he's gone :P [22:52:47] at one point Thymo automated it with Guenter lol [22:57:52] lmao [23:28:06] 2 seconds is a tight window haha [23:29:46] UHCL appears to have filed my email in the "not a Friday problem" catagory [23:40:43] heheh [23:46:54] lol [01:36:59] my thread pool kinda works, except that it thinks it's done when one of the workers pulls the last job off the queue, not when the last job is actually done [01:41:58] what thread pool? [02:10:59] I'm writing one to improve our systems simulation [02:15:20] it refreshes each tank, valve, pipe, heater, etc. sequentially [02:37:02] oh neat! [02:37:21] that sounds like it might also improve performance in timewarp as well [02:40:17] it should [02:41:36] and it should let Ryan and I add all the systems we want to add without condemning us to 5x max [02:45:47] nice! [02:45:52] that sounds great [03:03:09] part of the reason that the systems bog down performance so much is that with larger time steps, the system timestep functions insert more and more substeps. eventually your CPU realizes it isnt magic [03:48:56] interesting [06:21:08] good night everyone [13:25:42] Thymo, made a few PRs for you to review :D [13:31:15] Looking at them now :) [13:32:40] the first one is a bit more extensive, the others are probably quick to review [13:33:32] thank god that scenario files are something git can work with. Or else keeping them in a good state with multiple people working on it would be as bad as the checklist Excel files... [13:38:09] the AOH says that auto aborts are enabled at "thrust commit". I'm not sure if that is the same thing as the normal "commit", which is the decision point where a launch can't be stopped anymore and the command is send to retract the umbilicals [13:38:40] of it that is some separate process when all engines are running, which would be a few moments earlier. Oh well, would only be a second or so difference :D [13:38:43] or* [13:39:50] But that's why the liftoff/no auto abort is a button and not just a light. If that liftoff signal at "thrust commit" isn't coming through then you need to tell the CSM manually that you have launched. Like pressing enter on the DSKY to start P11 [13:43:02] Aside from the scenario fixes this should forever prevent that there can be automatic aborts before launch :) [13:43:18] That sounds like a good idea haha [13:44:22] the problem with the scenarios was a missing change from the CSM naming change we did for 9 and 10 [13:45:04] I wonder if, without the fix, you could press the liftoff/no auto abort button before launch and cause an auto abort... [13:48:21] hmm, doesn't look like it. have to understand that better... [14:00:52] ah there is an inhibit for the two engines out auto abort coming through the umbilical. Of course that was the whole bug in the scenarios, that it appeared like the umbilical had already been removed [14:01:13] I like this from the Saturn Flight Manual though: "If the NO AUTO ABORT pushbutton is depressed at [14:01:14] T-0 and a pad shutdown occurs, a pad abort [14:01:15] will result." [14:02:08] is there any harm in deleting the branches on Github that I used for the PRs? Or should I keep those around [14:13:45] No, if they've been merged and you don't use em for something else feel free to delete them [14:14:44] ok great. At some point it will be a few too many [14:18:16] Did you add ReentryOutputTable intentionally? [14:18:21] It's an empty unused struct [14:18:28] As far as I can tell atleast [14:19:27] yeah, at some point I will add a lot of data there. Started working on some of these RTCC tables but didn't end up really using them quite yet [14:20:09] that is the table that a bunch of reentry displays in the MOCR are based on. Basically all the data they needed to compile an Earth Orbit Entry PAD. [14:21:20] Okay so it needs to be added when that gets implemented then. [14:22:00] yep, I'd say let's keep it in. I will use it. [14:24:12] Alright [14:25:45] it all needs more work (what doesn't) [14:26:23] Never a shortage of work, always a shortage of time. [14:29:15] I'm not a fan of having so many structs, but it seems like the best method to replicate the input/output data to a lot of real RTCC routines. In Fortran it would be a lot of COMMON and EQUIVALENCE [14:47:49] we could use unions for the EQUIVALENCE statements. [14:55:05] ...there's also a chance that this is the worst idea I've ever had [15:58:22] uh oh, I think I scared him off [16:00:08] haha, I was afk, just my computer going into standby [16:00:19] in fact I already am using a union in a RTCC table [16:00:58] in the table for an MPT maneuver. I have the format for that and the same location in the table is used for two integers (TLI maneuver) vs. a double (all other types of maneuvers) [16:04:39] oh cool [16:05:42] other way around actually [16:05:45] union [16:05:46] { [16:05:47] //ExtDVCoordInd and [16:05:49] int Word67i[2]; [16:05:50] //R_N or P for TLI [16:05:51] double Word67d; [16:05:53] }; [18:37:44] So I'm a little lost on this project and could use some advice or help: https://gist.github.com/n7275/c6e84964fc44006576c368795943ca96 [18:39:18] I'm not as C++11(and later) literate as I should be. [18:53:40] Anything specific you're having trouble with? [18:55:46] specificially the wait before "work done". it does not seem to want to wait. either I'm not notifying it or i'm confused about the lambda or something [19:08:18] I suspect a deadlock somewhere. [19:08:46] I tried running it and I never get "Done Work" unless I set a breakpoint on notify_all and wait a while [19:17:12] hmm [19:17:55] that makes sense. [19:52:41] You're doing a cv.notify_all() on ln 119 without locking RunningLock, you probably want to merge those two blocks. [19:53:37] I inserted an extra notify_all where you check if the queue is empty or the program is being terminted. That way the main thread is woken up so it checks the state of working being false. [19:55:49] Now you get "Done Work!" as soon as the first thread finishes. You might want to have a flag for each thread instead as now working is set to false even if other threads could be doing work still [19:57:18] You already have numThreads. You could create an integer idleThreads and decrement this when a worker starts a job and increment it when it is finished. [19:57:39] Then you know work is finished if the queue is empty and all threads are idle. [19:59:40] Disregard my comment about notify_all on line 119. I was not aware you can do that without locking. [20:10:50] ooo that's a good idea about the idle threads. [20:59:55] I feel like I stand a better chance debugging this by opening up my computer case and peering inside, than I do with anything else [21:09:03] just remember, nothing will be as bad as an EQUIVALENCE of double and integer in Fortran [21:09:31] that's the ceiling for frustrating code [21:16:05] hahaha yeah [21:56:57] Well, it's not finished, but I feel like I've made progress. [21:59:12] oh great! [22:00:34] Are there any known issues when saving a scenario with average g runnung? [22:05:03] yeah, our accelerometers don't like it [22:05:22] switch on the EMS, save/reload, and it will have jumped a little bit [22:05:50] Is it purely loading in that causes the issue or is it also the action of saving [22:05:56] hmm [22:06:01] probably loading [22:06:08] Gotcha. [22:06:15] Maybe it's something fixable, can't remember if I have ever looked at it [22:06:37] Maybe large simdt in the first timesteps? [22:07:02] no I don't think it's that. I think it actually always starts with 0.01 seconds [22:07:23] when I have tried debugging that is the timestep I saw [22:07:58] there is also some bad NASSP code still that prevents certain code from being run on the first timestep [22:07:59] I'm writing a plugin that automatically saves a scenario every X interval. If it's a big issue I might need to build a way for NASSP to signal it's unsafe to safe. [22:09:11] I think it tends to be a small jump. And luckily the accelerometers aren't being used all that often [22:09:22] this affects all of them btw. EMS, IMU, LV IMU [22:09:48] and the LV IMU keeps using its accelerometers until after the ullage thrusters have stopped [22:10:02] until about 100 seconds after orbital insertion [22:11:46] and from TB6 start to 10 seconds after TLI cutoff [22:23:19] https://github.com/ThymoNL/StateSnap [22:25:30] I got frustrated by my constant CTDs. This plugin saves to "StateSnap.scn" every 10 minutes. Next up is keeping a rolling sets of saves so you can choose which one to revert to and exposing the interval through a config file [22:26:14] CTDs still happening? [22:26:50] I forgot if we talked about that, but Orbiter Sound is responsible for all my CTDs [22:27:06] when typing tabbed out and using some key combination [22:28:03] Yes. It's always happening in OrbiterSound or the DX9 client, not NASSP. [22:28:50] Hard to debug [22:30:08] Not a great way to end your evening when it happens. Spend 3-4 hours doing stuff and you lose it all if you don't remember to save often. [22:30:11] There is one key combination that starts a Orbiter Sound debug display [22:30:23] So now there is StateSnap :D [22:30:41] and then when you press the wrong key Orbiter Sound tries to do something which causes a CTD in NASSP [22:30:48] that is what is getting me occasionally [22:30:58] but I try to save often [22:31:00] wishes for XRSound [22:33:29] Yeah, I would prefer that, too [22:36:05] I don't see a future for orbitersound [22:37:27] I'll take any other open source sound addon over OrbiterSound. It's done it's job these years but it's starting to annoy me. [22:45:37] agreed [22:52:07] yep [22:52:53] that might be one of those projects that actually helps with progress and not just some tiny detail like SM RCS deorbits. I'll look into it. [22:53:16] tomorrow. Good night! [22:53:19] Night! [22:54:59] if msg.text.contains("night!"): guenter.say("Good night indy91!") [22:55:58] haha [12:23:01] Hey Nik [12:27:02] hey [13:08:48] ok before I look at XRSound there is a few odds and ends I want to finish. Like the CSM aerodynamics without singularites. Already tested that a lot, just a few more checks. [13:37:58] sounds like a good plan. XRSound could be a lengthy project [13:46:24] I wished I had a second source for the CSM aerodynamics. There are some strange things with the CSM Data Book numbers converted to an average CG location [13:46:46] up to 90° angle of attack there is basically no lift with free flow [13:47:10] and then suddenly from 90 to 120° there is a lift coefficient of -0.8 [13:47:22] If that is realistic it must be some weird interaction with the SPS nozzle [13:47:52] no lift until 90° is something I have seen for the CM, too, I think that is correct [13:48:18] well the CM basically doesn't have any lift with free flow conditions, in any attitude [13:49:44] and the second thing that leads to a bit weird behavior is that the moment coefficient is negative up to 150° angle of attack [13:50:04] so if you are at 150° then it will eventually try to rotate the CM to 0° [13:50:47] if you are a little bit out of plane and facing retrograde then that will try to torque you completely out-of-plane through gimbal lock [13:52:11] other than that the behavior I am seeing matches what I have read about it [13:52:55] this doesn't contradict anything I have read of course, it's just a bit weird [14:12:22] that has to be SPS bell interactions. that thing is a huge scoop when facing "into the wind" [14:38:00] and free flow isn't very intuitive for me anyway. The continuum flow (the normal flow regime for e.g. aircraft) looks a lot more normal [17:03:43] morning! [17:17:01] hey [18:51:27] hey Mike [20:23:30] n7275: FYI my waster water dumps are taking a long time on my 8 mission and now my 9 mission so it's not just Miriam [20:32:40] the question is, is there more water that is coming in or is it a pressure issue that not enough goes out of the CSM [20:38:20] Next time I need to dump I'll close the waste tank inlet and see how long it takes [20:39:00] good idea [20:40:00] What even happens if I let the water back up into the fuel cells? Does SPSDK even simulate that? [20:40:07] I think the issue is that dump rate is based on pressure. because of the new systems code, the water dump/drop in pressure causes a drop in temperature [20:40:17] not yet ;) [20:41:03] in my branch it will cause a steady drop in hydrogen partial pressure [20:41:27] So the fuel cells would just practically shut down then [20:51:47] would still be good to maybe have a temporary fix [21:12:46] increasing the dump valve size would work [21:16:03] Where's the clickspot for the CSM docking target? [21:16:27] Ah [21:16:34] It's the switch [21:20:25] oh haha. I know why my waste water dumps were faster [21:21:08] I increased the size of the valve in my scenerio, and then forgot to make an update to the config [21:21:49] changed from 0.001 to 0.05 [21:22:18] Why is that even in the scenario? It's not supposed to change is it? [21:25:48] it wouldn't normally. there are a lot of SPSDK parameters that get saved, but don't normally change [21:26:27] I think the intent was probably to allow them to be changed by code external to the SDK [21:27:21] lots of valve sizes change dynamically [21:27:54] like hatch valves with the lever [21:29:05] oh whoops [21:29:13] what Nik said [21:29:25] most are being synced to some switch though [21:29:32] some are automatic [21:31:50] if that weren't saved/loaded then in most of these cases the valve size would be wrong on the first timestep, but correct afterwards [21:32:14] it is quite annoying that it's being saved of course [21:32:26] any update has to have a lot of scenarios being edited [21:37:17] I wonder if it would be possible to make the saving/loading of that optional [21:37:26] would also save on a bunch of scenario lines [21:37:49] a lot of tank valves probably never change in size [21:43:02] it's also very hard to tell what is and is not okay, because most of these systems have all public methods and variables, so at any point any other code could reach in and change something [22:00:25] yeah [22:12:23] good night! [22:12:41] night [15:15:25] .tell indy91 I have not had a chance to checkout and build your PR yet, but the code looks good. hoping to get to that tonight when I get home [15:45:08] hey [15:45:54] yeah it's the same sort of scheme as the CM, I've already had it for a bit in a testing branch and it doesn't change the CSM behavior except for getting rid of the singularities near 90° [15:46:07] I'm pretty confident in it [16:00:17] were you planning on scalling the forces back to 100% or is there still more to do on the RTCC side of things [16:03:44] not necessarily much to do, but I wanted to fly Apollo 7 with 100% drag to test it. But I always get distracted haha [16:04:14] and then there is a chance that something on Apollo 9 breaks, so I probably should first fly Apollo 9 as well before this update gets pushed [16:05:19] and I was going to make some long necessary Apollo 7 MCC updates at the same time [16:05:37] but I guess that already is feature creep as I never seem to be able to make much progress [16:06:18] and every time someone makes a change to the Apollo 7 checklist file I kind of have to start from scratch [16:06:30] at the same time I don't want to block all updates to that forever [17:14:25] I have a weird solar eclipse [17:14:27] https://i.imgur.com/s13iVAd.png [19:50:41] that's an interesting view [20:11:45] it might not be a bad time to fly 7. I think we've finially convinced people that 8 is the one to start with [20:14:10] haha, yeah [20:14:32] I'll give it another go soon [20:15:12] afternoon! [20:16:58] hey Mike [20:17:08] what's up? [20:17:15] was just flying a bit of Apollo 12 [20:17:16] finding bugs [20:17:18] the usual [20:17:31] hehehe [20:20:08] I was trying to be clever with some code, when a system is completely off it wasn't running through all of its code [20:20:42] but it wasn't resetting variables read by other places [20:21:16] ahhhh yeah [20:21:19] TVC Servo Power 1 switch up, it shows gimbal angles [20:21:24] to off, still shows gimbal angles [20:21:29] that can lead to super weird behavior haha [20:21:31] power 2 switch up, doesn't show anymore :D [20:22:51] just need to null a bunch of things and then it's fine [20:23:08] in the code that does still get run on every timestep [20:26:08] as so often I had to understand a system again that I myself implemented for NASSP... [20:26:21] lol [20:26:34] "what the hell was this Niklas guy thinking" [20:29:47] oh yeah, at first I thought "why is there so much duplicate code from another part of the SCS" [20:30:26] but different parts of the SCS usually get the same switch+power inputs [20:30:45] and have to do the logic themselves [20:31:13] it helps when you have a detailed training manual that mentions exactly what sort of inputs go into the box [20:33:10] how is your rope reader progressing [20:37:52] it's going very well! only 20 more traces to be routed on the test board and I'm getting a better feel for how I want to lay out the full thing [20:41:06] sounds great [20:47:56] I'm definitely going to put in the order for the test board this week [20:50:02] then the real fun begins [21:02:12] yeah, lots of soldering, and then lots of testing [21:02:40] and I need to weave my own little core rope to test against :D [21:18:25] n7275, you wanted to give the aerodynamics some testing, right? I'd say in general it should be exactly as it is right now, just at e.g. 90° angle of attack will it not have a random sideways moment [21:20:26] I'll wait until tomorrow with merging [21:44:40] Hey indy91. I got a report on Discord that calculating a TLI PAD is causing a CTD. Mind taking a look? [21:44:58] sure [21:45:07] MCC or MFD? Which mission? [21:45:09] https://puu.sh/IM4lO/0e6f8a8676.scn [21:45:24] Apollo 12 RTCC MFD [21:45:39] He's doing this after MCC-2 though [21:45:55] uhh [21:46:07] I guess that could cause problems haha [21:46:27] probably just need to add something that prevents CTDs [21:46:30] He tried recalculating the LM/LV sep attitude [21:46:52] Scratch that. N22 angle to monitor the evasive maneuver [21:47:34] well the TLI PAD calculation simply won't work after TLI [21:47:51] all I can do is prevent the CTD [21:48:33] it's funny, I just did all that today, Apollo 12 TD&E to the P23s [21:48:35] Yeah, that makes sense but the CTD is definitely a thing haha [21:49:43] I could maybe implement something like the Earth Orbit Entry PAD has [21:49:47] preburn vs. postburn [21:50:45] but not really after TD&E [21:51:06] angles to monitor the evasive maneuver are in the flight plan [21:51:20] if you command the right things to the S-IVB at the right time then it all works out [21:51:35] not flight plan [21:51:40] launch operations checklist [21:52:10] https://history.nasa.gov/afj/ap12fj/a12loc/a12-loc-l3-08.jpg [21:52:57] you need to send two commands. Shortly after ejection you have to send (PAMFD, IU page) the evasive yaw maneuver command [21:53:12] and then at 4:25h, as in the flightplan, Timebase 8 Enable [21:53:34] for the TLI PAD, the calculation simply gets a pointer to the LVDC, assuming that it still is in the current vehicle [21:53:41] SaturnV *SatV = (SaturnV*)g_Data.progVessel; [21:53:46] LVDCSV *lvdc = (LVDCSV*)SatV->iu->GetLVDC(); [21:53:51] no checks... [21:54:03] second line causes the CTD then [21:54:57] I'll add some code preventing the calculation [21:57:44] Good info. Thanks [21:58:03] as I said, by chance I did all that today with Apollo 12. The attitudes worked out quite well [21:58:21] hatch window in the VC worked great to observe the S-IVB [21:58:44] https://i.imgur.com/s13iVAd.png [21:58:45] like that [22:03:08] We don't even have a manual for the PAMFD for something like that [22:03:16] maybe a wiki article? [22:03:49] That would be the perfect spot [22:04:25] I can write something things, the LM ECS stuff in the PAMFD can also be confusing with the number of astronauts in the cabin etc. [22:04:30] some things* [22:05:47] I'll have to quickly re enable account creation so you can create an account and then disable it before the bots start again [22:05:55] uhh ok [22:06:17] should we do it right now then? [22:06:52] Yep. It's enabled [22:07:20] hmm [22:07:26] It's restarting [22:07:28] maybe I F5'ed too often [22:07:31] aaah [22:07:51] Back up now [22:09:04] I'll make fixing the wiki my priority after I finish my thesis. [22:09:23] account created. No confirmation email? [22:09:47] No I haven't set it up yet. [22:10:02] ah ok [22:10:25] well, I just got an email, but I guess it's not required for the account [22:10:39] Oh really [22:10:50] oh [22:10:52] I didn't know that works lol [22:10:54] and it had a confirmation link [22:11:11] Restarting again [22:11:16] there is an RTCC MFD article [22:11:20] who made that [22:11:30] ah, me [22:11:33] 5 years ago [22:11:43] slightly outdated [22:11:54] https://i.kym-cdn.com/entries/icons/mobile/000/024/965/well.jpg [22:12:07] https://nassp.space/index.php/ProjectApolloMFD [22:12:25] Last edit 2007 lol [22:12:50] and we expect AGC developers to remember if ther was a last minute ephemeris fix for Luminary 99 or not... [22:15:20] shouldn't be too much work getting that PAMFD article updated [22:15:35] doesn't have 100+ ages like the RTCC MFD [22:15:38] pages* [22:16:07] good night! [22:16:16] Night! [16:08:47] hey [16:56:22] hey [17:11:07] just flew a 2500NM range reentry [17:11:32] it just barely made it to the target [17:11:58] didn't skip enough, lift vector up all the way after the skip and got the crossrange to 0 in the last minute :D [17:13:21] morning! [17:13:45] nice :D [17:13:54] hey [17:14:09] not really sure why it was so close, I feel like it should do a bit better [17:14:26] at least I could verify that the RTCC reentry sim can get a skip reentry to the target, too [17:14:37] and EMS range on the Entry PAD was spot on [17:17:52] they did simulations up to 3500NM [17:18:17] but 2500NM is the upper limit normally, only used for extreme weather avoidance cases [17:23:21] lol and what you really have to get used to is pressing PRO in P65 [17:23:36] normally the reentry programs (from 0.05g) are all automatic [17:23:52] but if you get P65 you need to check two values against the Entry PAD and then press PRO [17:26:10] but I don't think it stops steering before the PRO, it's just a display [17:34:41] hmm [17:36:09] or do I not understand the entry guidance as well as I thought... [17:46:50] nah, just a display [22:45:00] Man, this hunt for a source on "360/75s didn't use microcode" is frustrating. I found mailing lists from 1992-99 where people were repeating it, but no documentation... [22:48:21] are you looking for the source of a clearly incorrect rumor, or is there actually ambiguity? [23:00:04] the internet says they didn [23:00:13] 't [23:00:52] but I've talked to a few older IBM guys that say they thought they did have microcode [23:01:07] so not really a clear contradiction [23:01:56] do you have Ken Shirriff's contact info / do you want me to connect you over email? I'm sure he knows [23:03:12] I don't have it. He would be a good person to talk to. Sure! [23:12:31] okay email sent! [23:14:16] Ken has been kind of living in 360 land recently -- he's working on making LED driver boards to get Marc's 360 panel lit up again, and connected to an emulator [23:15:09] awesome. thanks! [23:15:51] sure thing! [23:16:03] I saw a blog post, I believe from him recently, really cool stuff [23:17:02] https://static.righto.com/360/ [23:17:12] he relatively recently put that together :) [23:18:11] The pdp-10 channel (which sometimes tolerates discussion about IBM hardware) has been discussing it recently [23:18:21] hahaha [23:19:01] sounds like an interesting channel [23:19:39] Rich Cornwell has also been working on a hardware emulator for 360/20-50/ models. [23:21:20] I bumped into dseagrav there a few days ago, lol [23:21:33] hah! [14:15:53] good morning [14:16:33] *runs away* [14:16:59] Thymo, which mission are these errors in? I am back home now and can go fix things [14:21:45] indy91, n7275, did those markers for 2016 beta get fixed? I see another post with the commenting out procedure. [14:25:28] https://www.orbiter-forum.com/threads/nassp-pgncs-surface-landmarks-for-tracking.40377/ [16:15:35] Thymo all 3 of those are fixed [17:37:06] i think we identified how to fix them but we have not yet [17:57:15] morning! [17:58:03] hey [18:09:27] rcflyinghokie, I haven't worked on the new landmark files yet [18:14:27] hey [18:14:52] indy91, UHCL emailed me this morning. they are working on scanning the document [18:15:03] ah very exciting [18:15:23] the whole thing or did you just request Apollo 8? [18:38:16] I completely forgot to specify that we only wanted Apollo 8 to start... [18:43:46] haha [18:43:52] I'll take it [18:45:29] if it's anything close to the Apollo 7 document I'll have RTCC updates for weeks I might be able to do [18:47:55] but too early for any real excitement, I always have the "AS-503 Operational Trajectory" document which turned out to be a 3 page distribution list of people the actual document went to [18:49:11] I was researching the last remaining things for the Lunar Entry PAD [18:49:17] DL and VL min/max [18:49:37] if you get P65 during reentry, you get the DL and VL on the DSKY and have to compare that to the PAD [18:49:41] if you can trust the PGNS [18:49:58] but sadly there isn't a calculation or chart I could find for the limits [18:51:22] but I read that there were curves to check against. Probably larger entry range means the tolerance is smaller to reach the target [18:52:03] the chart might be in a newer mission technique document... or it's some RETRO trade secret :D [18:56:10] those darn secretive RETROs [19:01:00] maybe I'll get something from the Apollo 11 RETRO audio [19:01:15] might be a topic of discussion as it's the only mission that got P65 [19:02:10] Tindall hasn't helped me either [19:05:26] so with the reentry simulation done for the Entry PAD calculation I can get the nominal VL and DL values (if the trajectory needs P65), but sadly not the limits which are actually on the PAD [21:08:08] indy91 ok thanks, i didnt know if they needed to be changed in depth or just that line changed [21:08:59] ah the line in the config? That is so it appears in the list of landmark types [21:09:30] but you still need to add a new file with the landmarks themselves [21:09:51] so why does commenting out that line work? [21:10:28] hmm, commenting out? Are we talking about the same thing? :D [21:10:44] https://www.orbiter-forum.com/threads/nassp-pgncs-surface-landmarks-for-tracking.40377/ [21:11:07] oh that [21:11:15] that enables the old style marker [21:11:22] the same we had in Orbiter 2010 [21:11:45] Are those landmarks correct? [21:12:03] I need to check for the Earth if they appear at the surface or always at the mean radius [21:12:20] the old lunar landmarks definitely won't do [21:12:39] a bunch of them are inside craters so their altitude is very wrong [21:12:48] shape of the Moon is correct [21:12:52] so Max Q's "fix" isnt actually a viable one [21:13:55] for the Moon it's definitely a problem with the altitude [21:14:01] you can use alt = 0 in P22 I guess [21:14:05] and only use the marker [21:14:12] and not try to mark on the surface [21:15:40] Ah ok, we might want to clarify that on the post [21:17:50] Also, I was thinking about default states in the RTCC MFD, would it be wise to have the maneuver pad page default to heads up or is heads down appropriate? [21:17:54] maybe we can make that change temporarily [21:18:07] the commenting out [21:18:27] and then when I add markers in the new style with altitude change it back [21:18:32] I mean it wouldnt hurt, as long as people know marking wont necessarily be accurate? [21:20:19] right [21:20:38] the Earth landmarks are visible, but I'm not sure quite yet what it does with the altitude [21:22:58] like in Africa [21:23:10] there are landmarks at 1 NM elevation [21:25:30] ah ok [21:25:36] it appears quite a bit under the surface [21:25:39] but it's visible [21:26:51] haha [21:27:01] ah, past me was smart [21:27:11] I have a table with all the Earth landmarks, including elevation [21:27:20] and then I had a piece of code that made the marker file out of that [21:27:33] so creating the new one in the new style could be very quick [21:33:31] nice! [21:36:56] done... in theory [21:38:34] hmm [21:39:22] naturally it's more complicated [21:40:58] at least I think I can mostly use the real elevations [21:41:16] but there is still a conversion to do because of the Fischer ellipsoid [21:41:45] for the CMC [21:42:29] landmark is an island [21:42:34] but the marker is not on the island [21:42:38] but neither was the old one [21:42:54] I wonder if that is only in Orbiter 2016 or if that was already an issue in 2010... [21:46:10] ah good question [21:46:22] did the earth shape change between the two at all [21:49:10] maybe the way the textures are applied did [21:49:16] I'll check with the same landmark [21:51:59] hmm [21:52:21] if I check against Google Maps then it seems the coordinates in the Apollo 8 Earth Landmarks book are off haha [21:52:28] in longitude, too [21:56:22] google has Daga Island moved since 1968 [21:59:00] haha some tectonic drift? [22:01:53] lol I doubt it, but it would be a fun answer [22:02:10] let's check another landmark, like a runway... [22:08:09] I think the coordinates are spot on this time [22:08:16] even if that airport doesn't exist anymore :D [22:08:35] if you know it was there then you can still see it [22:09:39] and that is with the same lat/long as in the landmark book [22:09:49] no geodetic vs. geocentric stuff [22:13:23] maybe they just got the coordinates of this one landmark wrong? [22:13:29] it's not super far off [22:13:35] maybe a mile [22:17:37] rcflyinghokie: Thanks for the checklist fixes [22:17:53] yeah the other landmarks seem fine [22:19:35] ah awesome, the elevation for Bogota is spot on [22:19:51] 2574.280 meters above zero [22:20:12] and the marker hovers only like 10 meters above the surface there [22:20:31] indy91: What's the story on ProjectApollo\\Saturn5 vs ProjectApollo/Saturn5? [22:20:33] so elevation data is definitely good, even if it's not elevation above the ellipsoid... [22:21:21] mostly this: I have always done it that way since I copied code from the PAMFD to detect class names :D [22:22:09] I'm sure there is a purpose to it, like different file systems or something [22:22:25] Right. I don't think I want to open that can of worms tonigh. [22:22:31] yeah haha [22:22:55] approved & merged :) [22:23:12] thanks! [22:25:55] I'm sure the old forum would have an answer [22:30:04] rcflyinghokie, I guess I have the marker file itself ready now. Just need to work on color and appearance [22:30:09] and of course documentation changes [22:30:14] because of the elevation [22:34:55] might get that done tomorrow [22:35:00] good night! [22:59:08] awesome [14:09:43] good morning [14:10:10] hey Matt [14:26:48] the new markers have fewer options [14:27:05] can't make it a cross [14:27:22] the way it is displayed I mean [14:27:33] I guess a square is the best option [14:27:45] I'll keep it light blue [14:29:19] thats better than nothing [14:30:58] yeah [14:31:13] the elevation is a nice improvement, but of course still not an ellipsoid [14:31:42] especially near equator, high elevation was quite off in Orbiter 2010 [14:32:43] like Bogota in Colombia [14:33:02] +1.39 NM above ellipsoid in the landmark book [14:33:23] for P22 [14:33:35] in Orbiter 2010 we had that at -2.53 NM [14:33:46] and now at -1.14 NM [14:34:04] so exactly that 1.39 NM better haha [14:34:22] the old marker was quite far below the surface for that [14:34:48] the new one hovers 10 meters above the surface [14:35:01] so very close [14:37:00] so I need to edit the Label.cfg file that comes with Orbiter [14:37:18] so during installing NASSP that gets overwritten [14:37:54] you can also specify which type of markers are on or off by default [14:38:18] I'm thinking about enabling our Apollo landmarks and disabling all others [14:48:45] that makes sense [14:49:09] iirc they have a bit of a performance impact with huge numbers of them [14:50:41] indeed [14:51:21] that's why it took so long to tackle this issue [14:51:36] I thought we had to add our markers to that standard marker file [14:51:51] which is huge [14:52:00] and we then had to distribute that with NASSP... [14:52:12] luckily we don't [15:09:47] oh well that saves a headache lol [15:10:29] So we have a volunteer (swag) who has started making a more user friendly RTCC guide based on his learning of RTCC during 12 right now [15:26:27] an updated input guide? [15:27:38] well its kind of a user friendly manual to do things I believe is the concept [15:28:04] But it would be an input guide/users manual [15:28:21] hmm [15:28:37] He just started the concept [15:28:53] then we would have three documents for the MFD, that's not very user friendly haha [15:29:09] it's probably best to integrate it all in one document [15:29:25] That would be the idea with this [15:29:36] with the input guide being a sort of appendix to the MFD manual [15:29:53] this would replace the input guide [15:30:08] https://docs.google.com/document/d/1qRIh8lAxMBnaDaPhgdWNluIEoTXAemahdykoXNxpNiw/edit [15:30:17] Just a skeleton right now [15:30:30] But I think the first goal of this would be to replace the input reference guide with updated data and avoid MPT use [15:30:39] And then another section for MPT use etc [15:34:32] I see [15:35:16] but yeah, as long as it replaces the input guide and isn't a third, additional document then I think the idea is good [15:36:20] ah yes, that was the goal [15:38:40] ok, so, while checking a bit of P22 I noticed one thing again [15:38:53] the scanning telescope drive (slaved to sextant) sucks [15:40:06] how so [15:40:39] it overshoots and in general makes tracking more difficult than before [15:40:54] I'm looking at our source for it again [15:41:19] we have a idealized transfer function, the gain is in decibel [15:41:31] but you can interpret decibel in two different ways [15:46:22] https://i.imgur.com/TLcB60d.png [15:46:42] Orange is what we have right now [15:46:54] Blue would be with the current gain we used squared [15:47:37] use* [15:49:03] Oh yeah haha I have seen that [15:49:32] the squared function looks a lot smoother [15:51:31] https://i.imgur.com/2RYgtGH.png [15:51:47] That would impact driving to stars as well, correct? [15:52:01] yes [15:52:14] As it stands it typically overshoots then comes back [15:52:29] manual and CMC commands drive the sextant [15:52:44] "ideal version" lol [15:52:58] telescope is slaved to sextant [15:53:18] what is S in this context? [15:53:31] transfer function variable [15:53:45] https://en.wikipedia.org/wiki/Transfer_function#Linear_time-invariant_systems [15:53:55] the kind of voodoo you learn with a mechanical engineering degree [15:54:15] the ideal version is very simplified [15:54:39] the rest of the page of that screenshot is the full version haha [15:54:59] haha [15:55:15] the nice thing about this ideal version is that it's just about simple enough to directly solve the differential equation [15:55:28] so even if it was very stiff, no problem with large timesteps or so [15:55:41] I guess thats analogous to the voodoo we learn with a chem e degree :P [15:55:56] but yeah the crucial part is "17 DB" [15:56:12] how to interpret that [15:56:25] gain constant? [15:56:59] yeah basically [15:58:02] I wished we had some sort of graph in MIT documentation how the SCT following the SXT looks like [15:58:21] but I think Mike and I looked for it when I first implemented the new SCT drive, didn't find anything [15:59:14] would they drive differently even though they are supposed to be co-located on a point? [16:00:16] only in trunnion [16:00:34] there is the switch for that [16:01:05] "TELTRUN" [16:01:16] SLAVE to SXT, 0°, 25° [16:01:56] it felt weird when it was only following the SXT in this way in trunnion [16:02:15] so it's using the same method for both shaft and trunnion [16:02:35] even if SCT shaft is always following SXT shaft [16:03:09] ah [16:25:32] Oh could you take a look at a scn, someone was flying 11 and it seems an uplink came 22 minutes late....not sure if the mission state was messed up somehow or what caused it [16:25:50] https://www.dropbox.com/s/46vrn7kww0p192p/103_28_33_.scn?dl=0 [16:26:04] LM on the surface [16:26:43] I'll take a look. Maybe the mission was late into lunar orbit [16:29:07] ooooh [16:29:23] we had this before [16:29:43] there is some weird timing in the lunar surface checklist [16:30:56] I think that's what it is at least [16:31:23] how so [16:32:23] 103:38, PDI+1:02, TIG-50 [16:32:38] 103:43:, PDI+1:07, TIG-45 [16:32:53] so far so good [16:33:07] 104:07, PDI+1:12, TIG-35 [16:33:16] 104:12, TIG-30 [16:33:25] now explain that :D [16:33:37] haha [16:33:46] Well that shouldnt impact the uplink should it? [16:34:13] but our checklist [16:34:27] and the only time in the checklist MFD is the 103:38 [16:34:54] and then 103:43 [16:35:12] the uplink comes at MoonRev >= 15 && MoonRevTime > 5.0*60.0 [16:35:32] so 5 minutes into rev 15 (for the CSM) [16:35:46] and that's taken from the flight plan [16:36:01] yeah [16:36:16] so the surface time for it is incorrect? [16:36:30] that should match the TIG-X times [16:36:43] because location of CSM drives liftoff time [16:36:56] Hmm ok [16:37:13] the uplink came shortly after TIG-50 [16:37:23] which should be 103:38 [16:37:35] but clearly isn't [16:37:51] in that scn I got it at I think 104:00 [16:38:01] yep [16:38:13] liftoff time 104:47 [16:38:33] so maybe slightly late following the TIG-X logic [16:38:48] Hmm so what would be the best time to use for that uplink in this case? [16:39:06] 103:57:12 Duke: Roger. Rl is plus 0538, and we have a load for you. Will you please give us P00 and Data? Over. [16:39:22] that was in between ascent and CSI PADs [16:39:50] hmm now I wonder [16:40:11] if that isn't a discrepency [16:40:26] the timing shift happens when they get the Ascent PAD [16:40:47] that ascent is T3 [16:41:00] is maybe the T3 PAD they got before landing different than that Ascent PAD... [16:41:29] T-3: 104:39:41.00 [16:41:49] 103:54:42 Duke: Rog, Tranquility. Tig, 104:39:47:00 [16:42:09] hardly [16:42:42] I think I am going to remove the time hack in there and use another marker like "Wait for MCC Update"" [16:42:59] That way its not a specific time [16:43:18] makes sense [16:43:34] it's roughly TIG-50, but not exactly [16:43:50] really just looking at the flight plan, when begins rev 15, when is the uplink relative to that [16:44:01] that method is definitely +/- 5 minutes [16:44:16] Just after it [16:44:41] for the crew timeline I think it's more important to have that at about TIG-50, so a checklist change makes more sense to me than changing it in the MCC [16:45:04] all I would do is slightly tweak the timing to get closer to TIG-50 [16:45:36] Yeah I wasnt planning on an MCC change [16:45:54] Just a better time hack in the MFD [16:46:07] I just wanted to confirm it wasnt an MCC or mission state issue [16:46:24] right [16:46:35] just the surface checklist being off, apparently [16:47:16] could have been very late in lunar orbit, but for Apollo 11 that would be surpising to be so far off [16:48:39] I removed all the mission times from that section and added holds relative to TIG or PDI [16:48:51] I think that will help [16:48:58] yeah [16:49:08] MCC department yet again shifted all the work to the Checklist department :D [16:52:00] Haha [16:52:11] Easier fix anyhow [16:58:23] PR up [17:02:48] merged [17:03:08] something is off with the colors of the labels [17:03:20] to get light blue I have to use RGB 255, 255, 0 [17:03:38] it should be 0, 255, 255 [17:03:47] cyan [17:03:57] yeah 255 255 0 is yellow isnt it? [17:06:42] morning! [17:07:09] some things (like OpenCV) do BGR instead of RGB... [17:07:21] look at that [17:07:36] it's yellow in the default graphics client [17:07:52] oh weeeiiird [17:08:05] maybe DX9 client bug or something [17:08:19] hey Mike :D [17:08:29] there is a function called RGB, probably used to convert [17:08:40] I see it used like [17:08:54] pe[i] = RGB( GetBValue(pe[i]), GetGValue(pe[i]), GetRValue(pe[i]) ); [17:09:08] in one place [17:14:15] so its inverted lol [17:21:04] hmm [17:21:16] where even is the DX9 client source code [17:21:35] I think it's MIT license [17:25:23] didnt jarmonik create it? [17:25:36] oh thats d3d9 [17:27:56] same thing [17:28:13] I think [17:28:53] the code seems to exist in a branch of the Open Orbiter repo [17:29:09] not surprised [17:34:28] well, not sure where the issue is, not my problem to fix :D [17:34:44] But I'll write about it in the DX9 client thread [17:41:51] yeah probably wise [17:42:02] workaround seems simple enough [17:47:54] I guess my PR for the landmarks will stay a draft until that is resolved then [17:48:06] I wanted to stay consistent and we had used cyan befor [17:48:13] e [17:49:42] Yeah that makes sense [17:49:58] Could we just invert for now and then fix it if the d3d9 code gets changed and updated? [17:50:10] Or would you rather wait [17:50:34] If nobody answers or fixes we can go with the current version and fix it later I guess [17:50:43] if you want to have a look the branch is up [18:14:30] sounds good [19:03:39] indy91, saw you guys were talking about optics transfer functions. there is some 16mm video shot through the eyepiece. Apollo 16 I think [19:05:15] oh that might be interesting [19:05:43] I just tried the updated behavior, I like it a lot better. But I am not sure it's correct haha [19:24:04] n7275, I couldn't find that footage. Where did you see it? [19:27:15] https://www.youtube.com/watch?v=MsxGmDktkUo [19:27:19] this? [19:34:03] yes [19:34:48] there are a few more. I found it once by accident [19:35:18] looks pretty jerky to be honest, difficult to tell of course [19:45:36] the first thing I thought when I saw it was "wow, I guess our transfer functions are right" [19:45:59] but with the lower framerate its very hard to tell [19:46:55] our current behavior is how I would expect "17 DB" to appear in a transfer function [19:47:03] so from that point of view we probably have it right [19:47:11] at least this idealized version [21:14:26] Thymo finally got around to updating the optics powerup to be OFF ZERO OFF per your observation [21:14:31] PR in a moment [21:28:30] Ah right [21:28:55] This won't cause desync issues since it doesn't modify the flightplan right? [21:34:38] It shouldnt, no [21:34:46] Unless a save was in that group [21:35:14] I have started reflying 10 to address issues found as well [21:57:57] night! [15:11:27] good morning [15:13:37] hey [15:17:18] We dont have any TDE procedures for 10 do we? [15:17:29] I am trying to figure out which technique it used [15:19:35] not aside from the flight plan which has some details [15:21:08] yeah thats what i was looking at and the technical deprief says they docked in CMC auto [15:21:57] however those flight plan procedures mirror Apollo 9's a but more than say 11s [15:22:06] So I am wondering if it was a hybrid of sorts of the two [15:23:21] probably [15:23:32] TD&E procedures varied a lot [15:23:38] partially crew preference I think [15:23:46] I am just kind of hybridizing them [15:44:29] indy91 regarding thermocalcs post, I also am getting the OPR ERR in entering V63 [15:47:33] hmm [15:47:46] OPR ERR lt - on if P00 is not in process [15:47:58] OPR ERR lt - on if another extended verb from R76 is active [15:48:02] Poss OPR ERR lt - on [15:48:06] Key RSET, exit R04 [15:48:13] Key V37E00E, and repeat step [15:48:24] R03 = V63 [15:48:34] and R67 is... [15:51:33] no idea [15:51:45] oh, 76 haha [15:52:03] extended verb interlock [15:52:14] just prevents certain verbs from running at the same time [15:52:47] so I cannot figure out why I am unable to free V63 [15:53:12] V37E 00E doesn't do it? [15:53:13] And I just tested his MCC1...took about 3 minutes for the final passthrough to finish [15:53:18] That seems high [15:53:37] what's the DV? [15:53:46] dvs 0, -0.9, -2.3 [15:53:54] maybe N55 was entered wrong in P34 [15:53:59] what does N55 say? [15:54:22] +00001 +02660 +16562 [15:54:34] shouldnt R3 be 130 [15:54:44] Or did that change due to P35 [15:54:50] it could change [15:55:07] have to check that [15:55:43] one thing we have to keep in mind is that Luminary 69 does hardcoded precision offset calculations in p34 and P35 [15:56:01] so P34 and p35 always feel slow [15:56:12] that got changed afterwards to be optional [15:57:04] but it shouldn't run into time issues [15:57:13] Still, slow is one thing, but 3 minutes is a bit much especially when you are supposed to do the final passthrough at MCC -3m [15:57:29] So maybe somethings wrong with the trajectory [15:57:32] is there a scenario from before P35? [15:57:40] where N55 is already loaded [15:57:52] that angle definitely has an impact on how quickly it calculates [15:58:08] TPI+8min [15:58:34] https://www.dropbox.com/s/jty5hkyw8i3u0lz/T%20%2B105h%2026m%20TPI%20%2B8%20min.scn?dl=0 [15:58:45] P35 is running [15:59:20] I still cannot get a V63 to work in any of those for whatever reason [16:00:21] ok R3 of N55 might be overwritten [16:00:30] so that's probably not the issue [16:02:40] so loading the presave CSI (which I believe he started from?) V63 works fine [16:04:01] ah [16:04:10] LR spurious test is still running [16:04:12] do V79 [16:04:20] then V63 works [16:04:34] maybe that is also why P35 is slow [16:04:37] Ohh [16:04:52] So he missed that step I suppose [16:05:55] Can confirm its in the procedures and checklist MFD [16:06:52] I will see if P35 works properly [16:07:30] am just checking that, too [16:08:54] Ah I wonder if marking is still ongoing? [16:09:10] You are supposed to V93 before the first P20 mark for the P35s [16:09:33] is there a bit to check if marking is happening? [16:09:57] ah yes there is [16:11:48] Ah how to check it is eluding me [16:12:12] v1n1E ADDRESS? [16:15:32] it still takes more than 2 minutes [16:15:39] and I got the alarm because I was a bit slow [16:15:48] but I think that was my experience in the past with Apollo 10, too [16:16:28] U want to check and see if its trying to take marks, that could be an issue [16:16:30] *I [16:17:29] I'm not following [16:17:35] V93 re-initializes the W-Matrix [16:17:40] doesn't directly have to do with marks [16:18:00] and marks are always disabled if you PRO (instead of V32E) on the 16 45 [16:18:21] Oh duh [16:18:25] Not enough coffee [16:18:39] marks are also disabled with V32 actually [16:18:51] re-enabled when you get back to the 16 45, or maybe one step before, not sure [16:21:06] Unrelated but interesting: "During this time, after the alignment and P52, during the Z-axis track, the spacecraft maneuvered from one deadband limit to another in a far more rapid fashion than had been observed in the simulator. in the simulator, it would be indicated by one or two thrusters firing, at most. [16:21:41] Then over a period of time of maybe 3 to 4 minutes, another one would fire. In flight, it was just 20 seconds between thruster activity and they continually went back and forth through the deadband" [16:22:35] I mean that's likely a wrong mass for the DAP in the LGC, but still. This is probably I need to revisit. Trying to get minimum impulse firings working right... [16:23:13] of course I already did a bunch of work on this, but what still doesn't happen is pulses being recognized that are so short they are enabled and disabled on the same timestep [16:23:23] at 144 Hz it's basically a non-issue [16:23:33] 60 Hz it's ok, below it gets bad [16:25:18] huh interesting indeed [16:25:28] that's the main reason why Thermocalc ran out of RCS [16:25:36] it still not behaving quite right [16:26:19] And can confirm that I am still slipping TIG in P35 [16:26:30] yeah, but it's better [16:26:34] I am going to fly a rendezvous from the beginning on 10 and see if maybe it was the trajectory [16:27:17] n7275 just flew Apollo 10 [16:28:11] maybe he noticed anything [16:29:11] I think he would have called out tig slips if noticed [16:29:16] but yeah I am curious [16:29:32] well I got the TIG slip, but if I had done PRO a bit quicker I wouldn't have [16:34:03] I am starting where he started Before CSI save and see what happens [16:34:16] at the very least it's not unusual to get these long calculations [16:34:27] they had already approved the change to that in February [16:34:47] Tindall says the change saves 80 seconds with every P34/P35 recycle [16:34:55] but that can of course vary a lot [16:35:43] TIG slip is also not a big deal [16:36:11] could still be something with trajectory that makes it take especially long [16:36:22] Yeah thats what I kind of want to cross check [16:36:35] because when I did the checklists I never got them last flight on 10 [16:37:09] oh btw, that's why there is an optional DAP update after TPI [16:37:17] to update the LM weight [16:37:22] it can't keep track of RCS burned [16:37:51] and with the ascent stage you really want an accurate weight, helps RCS usage with attitude hold a lot [16:41:52] hey guys [16:42:11] Was a new weight read up? [16:42:26] hmm, or is there just a DAP change [16:42:31] you call up V48 right after TPI [16:42:35] might just be the config [16:42:38] hey Matt [16:42:45] I didn't have any issues with the rendezvous that weren't associated with my being our of practice [16:42:56] don't think there was a weight update, not until after docking [16:43:00] *out [17:00:38] I do see some potential for finer RCS control for the PGNS in the LM [17:00:59] when the AGC cycles are done it keeps track of the current (I think mission) time [17:01:04] after each cycle [17:01:23] so maybe if a command is send to the RCS it just needs to send the current time, too [17:01:48] and then it somehow calculates the thrust based on that [17:10:28] so you think its over firing in PGNS? [17:12:00] I know it is [17:12:13] the minimum pulse length for the RCS is 14 ms [17:12:20] for comparison, 60fps is 17ms [17:12:34] so the normal timestep length can't resolve a 14 ms command [17:13:09] I have implemented a bunch of logic to better simulate short RCS firings [17:13:12] and it helps a bit [17:13:31] but it doesn't change the fact that most of the time a 14 ms firing command is seen as 17ms at 60fps [17:13:51] because the command comes in, the command time is stored [17:13:56] next timestep [17:14:02] command to stop firing comes in [17:14:10] and is processed that one timestep later [17:15:46] damn timesteps [17:16:15] what I had implemented is that if you get e.g. a thruster on command for 17ms (on on one timestep, off on the next one) that it won't have 100% thrust for one or two timesteps [17:16:25] but the appropiate amount of impulse for a 17ms firing [17:16:57] because it doesn't get the chance to get to 100% thrust [17:17:49] see LM-10 AOH Volume 1, PDF page 317 [17:20:34] using thruster on and off time would be good [17:21:18] might allow us to use modetate ammounts of time acceleration too [17:21:28] yeah [17:21:53] morning! [17:22:04] hey mike [17:22:06] and it should go somewhat hand in hand with the logic already in place [17:22:08] hey [17:23:26] ah found one [17:23:35] 000027.778: ch 5 val 16 simt 379559.689531 [17:23:39] 000027.796: ch 5 val 0 simt 379559.705082 [17:23:55] val 16 sets some thruster on, val 0 all off [17:24:02] and the time difference is 15.5 ms [17:25:38] yeah, I am seeing a bunch of 15.5 ms pulses in that debug [17:25:51] that's definitely what the DAP wants there [17:27:33] thewonderidiot i ran into an old airforce programer, one of my 360/75 contacts actually, who has a collection of old electronics that he's looking to part with. some of it is aerospace (possible LVDC) related. can i put you two in touch if you're interested [17:27:57] yeah sure! [17:30:00] haha, that was always my secret intention if I manage to turn up a bunch of RTCC documents from some programmer. Let them send the stuff to Mike! [17:30:22] my scanner is always available and free :D [17:31:07] great :D [17:31:46] rcflyinghokie, so did the V79 not make any difference in the P35 computation time for you? I thought you mentioned 3 minutes and for me it took a little more than 2. So I thought doing V79 mostly (if not fully) resolved that issue as well [17:36:40] Yeah mine went from 3 to just under 2 I believe [17:50:50] what distance to vessel markers come in again? [17:51:52] 60nm? [17:52:34] the Orbiter markers? I doubt that is in nautical miles :D [17:53:20] but I don't know [17:54:32] seemed to appear right at 60 [17:55:56] you mean the yellow box, right? [18:01:39] cant really tell from the Orbiter code what the distance would be [18:08:21] yeah [18:08:38] seemed to pop on right at 60nm in the CM optics [18:09:04] about to hit TPI, so far no surprises with this save [18:09:26] even the AGS TPI hit 26.60 pretty much right at T-21m per the procedures [18:09:56] so I think the trajectory is good, we will see what the MCCs do [18:12:46] Man these computations do take a while in general on 10 [18:18:00] yes but they are like 0.1 ft/s more accurate than on later missions :D [18:21:40] :P [18:24:06] in Earth orbit it would be important due to non-spherical gravity [18:24:22] but for the Moon it makes sense to have the precision offset calculations be optional [18:33:24] coming up on TPI+12 [18:34:35] if I find a better solution for the LM RCS then it will only improve the PGNS [18:34:46] the AEA just outputs an attitude error [18:35:01] and if the simulation state doesn't change then attitude error won't change [18:35:16] so no point in trying to capture some precise timing of that AEA output [18:36:36] 1m40s [18:38:34] still slipped tig [18:38:50] maybe I didnt pro fast enough lol [18:38:55] and ENTR [18:39:03] that ENTR on 50 18 is where the time matters [18:39:07] ahh yeah [18:39:19] bet that was it [18:39:23] I was focused on boresighting [18:39:25] that's when it checks how much time left until TIG and it wants a certain amount for integration, starting Average G [18:40:23] faster enter was fine [18:41:40] so its just tight as it is [18:42:55] and that's pretty normal [18:43:20] and I think with Lambert aimpoint guidance TIG slip really doesn't matter at all [18:48:36] True, just harder to clarify in the checklist MFD for when it does happen [18:50:16] yeah [18:54:57] MCC2 happened about 25 seconds faster [18:57:02] makes sense, less integration time to the intercept point [21:46:03] night! [14:47:44] good morning [14:57:57] hey Ryan [14:58:09] working on this: https://nassp.space/index.php/ProjectApolloMFD [15:00:31] Oh sweet! [15:00:45] I need to get in the wiki at some point as well [15:01:40] Quick question to distract...I was going over the dap orb rate procedures and I am trying to figure out where I got the values for the Apollo 11 checklist MFD DAP orb rate. They dont seem to match the AOH or the 11 Ops checklist [15:01:51] I of course remember adding the procedure but I cannot find my reference [15:02:27] maybe Apollo 9 checklist? [15:02:37] Oh perhaps [15:02:43] we found several CMP Checklist pages online [15:03:04] Bingo [15:03:09] Yeah I have them in a pdf [15:04:03] I forgot about that [15:04:16] I am going to change them to 11's but that leads to my next question: [15:04:45] I know each set has a corresponding rate, but what is the CDUX angle [15:05:14] Is that which part of the spacecraft is facing down? [15:07:45] which part sets the CDUX angle? [15:09:25] oh I see now [15:09:27] that is just roll [15:09:43] so depending on which roll angle you have the orbrate needs to happen in a different body axis or direction [15:11:08] I guess that assumes in-plane alignment [15:11:26] which you of course always have when attempting to use orb rate... right Apollo 9? :D [15:24:30] Haha ;) [16:00:21] so it seems like there might not be a quick fix for the markers in the DX9 client [16:00:38] depends when Jarmonik gets to it I guess [16:01:13] so I would say we merge my marker update as it is [16:01:25] and then change it when the DX9 Client gets fixed [16:03:04] it overwrites the Label.cfg that comes with Orbiter and disables the other markers by default. Is that ok? [16:03:27] the alternative would be to require during installation to manually add a line... [16:05:14] Hmm we might want to make sure a disclaimer is in there [16:05:20] Or in the release work thread [16:05:43] I personally have no issues with it, but I dont know what people use markers in other mods or orbiter etc [16:07:24] right [16:07:34] I can leave them enabled as they are [16:07:42] and also enable ours [16:08:20] There are: Airport, City, Moutain, Forest, Water Body [16:12:53] So would they all show up? Or can you select [16:54:58] i dont think having them all enabled is the end of the world [16:55:33] would be nice to have the option for only apollo. but having them all is okay [16:56:40] For the moon at least I think it would be just fine and not overloaded [17:30:22] I dont know if this was actually an issue but one thing I am noticing now is when doing transposition in CMC AUTO, it doesnt pitch around cleanly, it imparts a lot of yaw [17:30:44] What is CMC AUTO doing without say a V49 running [17:47:18] https://www.dropbox.com/s/7fr6pmbr0v8en97/Screenshot%202022-03-05%20104548.jpg?dl=0 [17:47:26] https://www.dropbox.com/s/hyhsgpgsuvdgplm/Screenshot%202022-03-05%20104603.jpg?dl=0 [17:53:50] I dont remember this happening before on a CMC transposition [18:03:40] Am i missing something? [19:43:30] sorry, something came up mid sentence. It's really just the markers that are on by default that I changed. [19:43:38] you press F9 to enable/disable planetarium mode [19:43:54] and then what Orbiter seems to save is if you have landmarks vs. celestial markers on [19:44:16] and then in the selection menu for the landmarks some are on by default and others have to be enabled [19:44:36] and that's where I disabled everything except my newly added Apollo landmarks file [19:45:18] just personal preference, I am mostly using NASSP and all the others markers are distracting for landmark tracking [19:45:56] and for overwriting the Label.cfg file, I'm not aware of any other addons adding markers in the same way, but I haven't looked for them [19:49:44] marker file is in the texture folder, that is probably going to be another nightmare with where everyone has their textures saved [20:33:09] rcflyinghokie, Apollo 11 T-30s scenario has an offset checklist position somehow [20:33:28] it's at tower jettison roughly when you load it [21:23:20] yeah many of them are offset now [21:23:39] did you catch my comment on the transposition procedure by chance? [21:24:32] now I have [21:24:51] which mission was that? [21:25:42] 10? [21:25:45] Well its not the mission its procedures [21:26:03] Basically the Apollo 11 procedures, [21:26:05] our J-type missions have a different CG location [21:26:08] CMC AUTO [21:26:21] doing a pitch around imparts a lot of yaw [21:26:34] what's the DAP config for that [21:26:50] I used 11102 and 11103 [21:27:10] ok, 0, so not drifting in a large deadband or so [21:27:24] See the images I posted? [21:27:40] Doing manual att pitch and pitching up 2 deg/s thats where the CM ends up [21:27:56] it keeps firing in yaw and I do not know why nor do I remember this happening before [21:28:46] so CMC Auto but with Accel Cmd for pitch? [21:31:53] are you letting it do the auto maneuver at the same time as the pitch up? [21:35:31] ah now I get it [21:35:44] 11103 is a must [21:35:46] the CMC Auto [21:35:47] sep [21:35:54] you already have the V49 up [21:35:57] PRO to the 50 18 [21:36:01] Accel Cmd in Pitch [21:36:21] start pitch up 1.5°/s, because it could choose any direction for the 180° maneuver [21:36:28] then PRO to also start the auto maneuver [21:36:49] and then quickly Rate Cmd for pitch again, which gives the CMC full control [21:37:00] I am missing the step back to Rate Cmd in Pitch in the Apollo 11 Checklist MFD [21:37:54] it's a bit of a weird procedure [21:39:06] it feels like such a strange order of steps in the Apollo 11 launch checklist [21:39:43] like, where in there are you doing the 180° maneuver actually [21:40:08] just after the + pitch step, or after PRO, or after back to Rate Cmd... [21:41:06] but I think the one thing you shouldn't do is pitch up manually in Accel Cmd and at the same time let it do the auto maneuver, because that will also want to do the 60° roll [21:44:06] lol, looking at the debriefing, Mike Collins had problems [21:44:10] with the procedure [21:51:29] sorry this time I had to run out...catching up [21:52:15] Well I dont auto maneuver [21:52:26] Thats only done after the pitchover [21:52:32] which leaves me with an odd yaw [21:53:07] good catch with it missing a rate command [21:54:31] but I want using V49 in this case [21:54:34] *wasnt [21:54:46] I simply pitched around in pitch accel command [21:54:49] I don't know about the yaw, but I would expect it having difficulties controlling the CSM with Accel Cmd [21:55:12] hmm, that is probably not a good procedure [21:55:25] CMC Auto but overriding it in pitch for 180° [21:55:34] I thought thats what 11 did [21:56:13] And 9 [21:56:33] yep CMC auto, accel command for pitch [21:56:38] the 180° maneuver comes later in the checklist than you think [21:56:57] then the second PRO, which starts the auto maneuver, still in Accel Cmd [21:57:04] and then already Rate Cmd [21:57:21] so by that point it has becomes a V49 auto maneuver, CMC Auto, with 3x Rate Cmd [21:58:38] the CMC takes the shortest direction to the new attitude, that's why you manually initiate the pitch up [21:58:48] and then that becomes the shortest way to the target attitude [21:59:00] and then you let the CMC take over completely [21:59:57] technical debriefing page 5-5, Collins explains it in detail [22:00:54] but the checklist is still confusing, I don't know why it has the "null translation and rates" in that place [22:01:12] that must already be after it has reached the docking attitude [22:01:13] Well what about the 9 procedure then [22:01:17] same results [22:01:39] Remember this is all no V49 [22:02:08] I'll check 9 [22:02:11] Apollo 11 is using V49 [22:02:14] I know [22:02:16] I am not [22:02:51] might be the problem, the CMC might still want to hold the old attitude that is 180° away [22:02:59] which you override with Accel Cmd [22:03:06] maybe it runs into problems with aces [22:03:09] axes* [22:04:57] Apollo 9 seems to be doing just that though, hmm [22:06:14] yeah I am basically doing the 9 procedure [22:06:42] I am fairly sure it is because of Accel Cmd [22:07:30] I can replicate it using that procedure [22:07:33] Hmm the 9 transcript says they switched to SCS (like 8) [22:08:09] yeah I feel like the DAP wouldn't like this [22:08:36] I agree [22:08:49] so much for trusting that shiny new flight crew abbrevated checklist... [22:08:57] I think I never noticed this before because I either did a V49 or an SCS procedure [22:09:04] haha [22:09:13] well at least it was good in some areas [22:09:46] and the RCS thruster directions I modified [22:09:49] and the offset CG [22:09:55] I'll have to go through and test some things, I might put that SCS back in for 9 and 10 [22:10:01] all those go together to do this I guess [22:10:02] and let 11 use V49 [22:10:17] and quickly Rate Cmd after starting the V49 auto maneuver [22:11:15] yeah I will probably add those [22:12:34] definitely needed if the CMC wants to stop the pitch rate at some point [22:13:03] Now for 9 and 10...I think I will have it SCS for the pitch and roll and then CMC [22:14:06] They changed the behavior of RHC inputs with CMC in control at some point [22:14:23] how so [22:14:49] maybe if you do small RHC inputs it resets the attitude hold even with Accel Cmd [22:15:08] but that doesn't fix the yaw angle, the CMC doesn't know exactly where you want to go I think [22:15:46] they definitely changed CMC Free [22:15:51] worked like Accel Cmd before [22:15:59] and like minimum impulse afterwards [22:16:25] but CMC Auto didn't change, so not relevant [22:16:49] Yeah I think the best course is to use SCS for 9 and 10 during transposition [22:19:14] yeah I guess [22:19:24] and only Collins liked the CMC maneuver it seems [22:19:39] afterwards they did 180° with the SCS and then the rest with the 60° roll in CMC [22:19:51] I like that mixed procedure best, too [22:20:34] as do I [22:21:11] but maybe only because we have a better SCS than the actual ones :D [22:22:13] in any case the SCS use for the pitchover should resolve the yaw issue for 9 and 10 [22:24:36] TD&E is a bit of an oversight in the mission techniques documents [22:24:46] doesn't get covered in the EPO and TLI document [22:24:52] but also not in the TLC one [22:25:25] Tindall would have come up with the "correct" procedure by 1967 [22:26:08] haha indeed [22:26:34] Funny how with how important of a maneuver it was, how little specific detail there is on it outside of transcripts/debriefs [22:28:38] Separation Procedures, MSC memo, covers it in good detail [22:28:46] actually, for which missions do I have that... [22:29:00] Oh please share :) [22:29:59] there is about zero guarantee that is what they actually did though [22:30:35] I don't have the document for 11 [22:30:38] I have it for 10 [22:30:43] https://web.archive.org/web/20100524032612/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740072928_1974072928.pdf [22:32:33] only a summary document for 9, not helpful [22:33:35] I'll take a look at 10's see if anything helps [22:34:56] probably not a lot [22:35:20] well i haven't been here in a while [22:35:43] alias on Discord is CapitanCrash [22:35:58] Hey welcome! [22:36:03] hello! [22:36:12] <-Folgers on discord [22:36:26] hey hey [22:36:27] So yeah this is where the dev chat goes on [22:36:29] ah ha! [22:36:32] hey indy [22:36:58] nice work getting the whole uplink/downlink stack with marc [22:38:01] I'm not up-to-date on those videos sadly [22:38:06] ah [22:38:20] am behind a few, I know thewonderidiot makes the occasional appearance :D [22:39:31] hey, thanks! :D [22:39:42] well I don't have much time due to real life commitments but i'm happy to help out with 3d models [22:41:26] Just PRd a few checklist fixes including those transposition tweaks [22:41:47] And the DAP orb rate for 11 per the operations checklist values [22:41:56] hmm, which of our 3D models need the most work... [22:43:13] I like to do some modeling in my free time to relax. I was working on LZ-129 for X-plane but the project was a bit too big to code all the systems, model, and texture for one person [22:43:17] or for me rather [22:46:08] well I don't know if it's something what you were thinking of, but the launch escape tower has a canard, a simple aerodynamic device to cause it to flip over in the case of an abort [22:46:26] we simulate the canard in an aerodynamics way, but we don't have it on the escape tower animated [22:46:39] I don't know if that requires much model work or mostly animations though [22:47:40] it also looks ugly all one color, but then so did the real thing mostly, tower and boost protective cover haha [22:48:42] https://imgur.com/a/kWZFAtE [22:48:50] thats some of the work i did [22:49:10] looks great [22:50:15] If you have the specs and documentation for it I can get a model going for it, as well as any source models [22:50:22] for the LES [22:53:34] https://github.com/orbiternassp/NASSP/blob/Orbiter2016/Meshes/ProjectApollo/BoostCover.msh [22:53:36] that's the mesh [22:54:54] I'm seeing something on there that looks like the canards [22:55:13] but I don't know if it's like a separate mesh group that could be animated already [22:55:21] ok, is there a known method for importing msh files into blender? I can try and find one but i'd rather use a known workflow [22:56:46] I've never done much with that myself, but I think there is a plugin [22:56:49] for importing [22:58:06] I think I installed this? [22:58:08] https://github.com/BMCDad/orbiter-blender [22:59:40] https://www.ibiblio.org/apollo/Documents/HSI-481260.pdf [22:59:48] PDF page 205 [22:59:52] has a nice view of it [23:00:52] but as I said, it might be as simple as making that part of the existing mesh a different mesh group for animation or something. [23:01:59] have a look at it, if it's too boring or there is nothing to do, all the better then there is only animating left to do. Or make the mesh much nicer looking. Up to you :D [23:04:59] and why is your Hindenburg chasing an Arleight Burke class destroyer, or am I seeing that wrong :D [23:05:05] Arleigh* [23:06:04] ah I am seeing that wrong, slightly different ship [23:18:21] lol [23:18:44] xplane has AI ships floating around [23:18:53] and i was looking to get a shot that conveys scale [23:19:15] I'll take a look and try to get something going. [23:21:39] great! This was just the first thing that came to my mind, I'm sure there is more model work to be done for NASSP [23:24:38] good night! [23:24:46] night! [14:08:21] good morning [14:08:55] good afternoon [14:22:12] haha. what's up today [14:28:00] noticed that I hadn't added a dedicated Entry Update uplink page [14:28:16] last one of the standard uplink types that I hadn't added yet [14:29:09] I've gone through this process many times, also the opportunity to have only one function calculating the uplink data. Previously I had separate ones in the RTCC MFD and in the RTCC class for the MCC [14:53:03] would you mind checking out my branch with the new Earth landmarks? [15:01:54] oh sure. id be happy to. [15:06:16] how about a trip to Mexico City [15:07:30] I didn't check that landmark, but if the marker is near the correct elevation it's another confirmation that the coordinate calculation works right [15:21:12] hmm. I'm not seeing any markers at all [15:21:36] other than the base markers that we already had [15:23:24] did you locally change your Earth config file to see the old markers? [15:23:47] nope [15:24:51] F4, Display [15:24:58] Surface is checked? [15:25:03] yes [15:25:45] and I'm testing this on a NASSP scenerio [15:25:55] and if you press Config, is there anything in the list? [15:28:27] Airport, City, ..., Apollo Earth Landmarks [15:29:38] and Earth Landmarks is highlighted? [15:29:43] that's what I added [15:29:47] yes [15:31:10] and if you zoom out very far you see no cyan markers? [15:31:24] not a single one [15:32:42] ok, one thing to check [15:32:52] Orbiter launchpad [15:32:54] DX9 advanced menu [15:34:30] top left [15:34:35] Tile Archive [15:34:45] does that say Cache & Archive? [15:34:56] yes [15:35:19] back in a minute [15:36:00] then it's probably the issue with the texture folder [15:37:43] I added a new file [15:37:46] Textures/Earth/Label/03/000000/000000.lab [15:54:38] happy to report the SCS technique (as seen in the transcript) works really well for Apollo 10 [15:58:10] indy91 for the Apollo 10 updates, did you base them on the actual flight or the flight plan? [15:59:48] mixture of both I guess. You do normally get a scrubbed MCC-1 I think [16:00:11] which is not zero DV on Apollo 10 [16:00:25] and that alone already leads to all events in lunar orbit being 10 or so minutes late [16:01:41] After TLI I should be looking for an SPS evasive maneuver pad, correct? [16:02:47] yes [16:03:39] comes at 55 minutes after TLI cutoff [16:03:51] ok [16:52:42] does the SIVB get commanded by MCC or do I need to initiate it? [16:54:41] automatic [16:55:24] so MCC [16:59:49] great [17:32:09] is it a fixed time or based on another event? [17:32:16] As mine isnt doing anything at 4h49m [17:33:39] ah there it was just later [17:39:31] would be fairly exact relative to TLI cutoff (TB7 start) [19:29:40] rcflyinghokie, are you also getting program alarms and restart in the scenario from grummanonewire? [19:32:28] I havent tried it [19:33:01] one sec [19:33:38] yep [19:33:40] somehow his Apollo 11 mission is using Artemis, I am quite sure [19:33:49] 1102 and 1107 on the N09 [19:33:50] but how, no idea [19:34:04] yeah typical reaction using the EMEM of a different rope [19:34:30] if I let it use Artemis no alarms [19:34:43] I have never seen that and I have launched a lot of the Apollo 11 missions [19:35:04] it defaults to Artemis, so if you delete the Apollo 11 mission config for example you would get that behavior [19:36:08] bad nassp install maybe? [19:37:53] maybe [19:38:18] it just works with relative paths for loading the file [19:38:40] if he has the file and didn't move any folders it should work [19:47:37] Yeah I am at a loss unless something for corrupted or installed incorrectly [20:00:42] I think Apollo 10's first PTC REFSMMAT update needs some clarification [20:01:02] Basically if MCC1 was scrubbed, or could be made with PTC REFSMMAT, it was uplinked then [20:01:24] However if MCC1 was not scrubbed and could not be made with PTC REFSMMAT it was not uplinked then [20:01:57] Not sure how to best approach it but all you get is ready for uplink there, so it might not be as clear [20:02:36] Trying to figure out if there is better wording I can use in checklist MFD [20:10:37] our MCC logic never uplinks the PTC REFSMMAT for MCC-1 [20:10:52] so it's only MCC-1 scrubbed vs. not scrubbed [20:11:19] if scrubbed, REFSMMAT comes early [20:14:38] Ahh ok [20:15:17] The issue is how does one know if the REFSMMAT will come or not without just waiting for something to happen [20:18:07] oh another thing, where is the speed the auto checklist controller is adjusted? I have been thinking we should increase that a little bit if possible [20:21:33] And when the MCC1 decision time comes up I dont get a scrubbed message just a SV update [20:24:44] that sweird [20:26:30] there should be a scrubbed message [20:28:07] wait, there is no SV update [20:29:12] rtcc->calcParams.TLI + 3.0*3600.0 + 20.0*60.0 [20:29:19] that's where the MCC-1 decision is made [20:29:27] no uplink or anything, just a message [20:29:37] so at like 6h GET [20:29:55] at 6 hours it just says "ready for uplink" [20:30:05] and I got the PTC REFSMMAt [20:31:19] at 6h GET? [20:31:32] yes [20:31:34] that should be at 7h [20:31:38] 7 [20:31:41] when the maneuver is scrubbed [20:31:50] I dont get a scrubbed message [20:31:59] just a ready for uplink [20:32:04] at 7h [20:32:23] yes [20:32:28] that is correct [20:32:32] sorry 6 should have been 7 [20:32:41] but more than one hour earlier there is the MCC-1 decision [20:32:47] maybe you missed the message? [20:33:04] Hmm possibly [20:33:09] is it still there in the list [20:33:13] no [20:33:16] hmm [20:33:18] only my last 2 uplinks [20:33:29] let me go back [20:33:58] there would also be the usual thread started [20:34:29] TLI cutoff at about 2:39h [20:34:50] so the MCC-1 decision is at 5:59h [20:37:34] yep I had missed the message [20:37:42] I will add a placeholder in the MFD there [20:38:06] I guess you werent looking for a message there [20:38:27] and unless it throws you out of time acceleration one might not notice [20:41:25] yeah I didnt have anything telling me to expect one [20:41:33] So I have remedied that [20:42:52] great [20:43:48] Have someone trying an Apollo 11 rendezvous, got a 611 during CDH computation (I am waiting on a scn) but since only a tig is input there what would cause it? [20:44:53] bad trajectory? [20:46:28] ouch [20:46:44] muscle memory V66? :D [20:47:01] yeah hard to tell without scenario [20:47:12] vector comparison display will help [20:47:16] to debug [20:47:46] Haha yeah certainly an odd one, though the G&N dictionary has 611 procedure for P33 [20:55:52] could be side lobe lock on, but P20 would throw alarms earlier [20:57:00] yeah he has had a lot of those before for sure [20:57:08] But this run it seemed solid up to CSI [20:57:15] used orbiter hud to verify [22:02:13] night! [15:37:29] hey Ryan [15:37:39] morning [15:38:47] regarding the side-lobe lock problem that people keep having. the signal strength meter should read accurately and if the range is known it can be used to double check [15:39:15] Oh i know [15:39:38] Its more of not reading/understanding in general [15:40:23] Basically lack of RTFM [15:41:14] like blindly incorporating marks when the computer is throwing alarms [15:42:16] yeah that gets old after a while [15:42:44] have you tested Niks marker PR? [15:44:25] I have not [15:44:31] I saw you guys were having issues? [15:44:46] I planned on testing them when I get in LPO [15:46:32] yeah, it just didn't work at all for me [15:46:55] it was like I was in the wrong branch...except I wasn't [15:47:02] well [15:47:14] not exactly [15:47:30] I had the markers showing in the F9 menue [15:47:43] they just wouldn't show up on the Earth [16:33:20] was it a distance thing maybe? [16:58:39] I don't think so. I put a deltaglider right on top of one and couldn't see it [17:01:48] ah [17:34:54] morning! [17:41:21] hey Mike [17:41:32] what's up? [17:43:11] working on cleaning up the Apollo 10 checklists a bit [18:03:29] phone test [18:03:59] phone works! [18:04:29] and IRC on it [18:04:41] nice! [18:05:07] n7275 where do you have your hires textures? [18:05:29] maybe you need to move the marker file there [18:09:43] back later [19:01:48] oh indy91, as I suspected, those 611s were the result of a bad CSI burn and bad SV (user error it seems) [19:02:15] Almost looked like CSI was burned while not in avg g and the orbit was like 60x45 lol [19:02:26] Had him go back to CSI and repeat and all good since [19:03:12] ah good [19:03:20] I've done the opposite of that a few times [19:03:23] after TPI [19:03:29] still was in translation mode [19:03:35] wanted to do a manual attitude maneuver [19:03:43] did translations instead, no Average G of course [19:04:01] that's when I started switching off the Trans/TTCA switch [19:11:13] hah I do the same [19:16:40] following mission rules sucks, I was flying more Apollo 12, did MCC-2, had 0.5 DVZ residuals, rules say trim DVX only [19:17:10] that gets me a 5.4 ft/s MCC-4 that I can't skip because of low pericynthion [19:17:15] oh well [19:17:53] indy91 ...in my Orbiter 2016 textures folder... [19:18:10] that's almost certianly my issue [19:18:38] yeah, I guess you also have to copy the NASSP textures there for it all to work [19:18:39] ? [19:19:31] so I guess you have to copy over that Textures/Earth/Label folder [19:21:47] makes sense. not sure why this didn't occur to me yesterday haha [19:26:18] this might need an edit to the installation instructions [19:26:28] "IMPORTANT: If you are re-using a texture directory from another Orbiter installation (as outlined in step 1), copy the "Textures/ProjectApollo" folder over to the actual Texture directory that is being used by your Orbiter Beta/NASSP installation" [19:26:49] except this marker file is not in Textures/ProjectApollo [19:27:18] when using the NASSP releases you just have to copy the whole Textures folder from it, no big change [19:33:08] If no one makes any noise about releasing an OpenOrbiter build by the end of the year, I vote that we just release our own "Orbiter Distro", and make everything 10 times easier. [19:50:51] yeah, it might end up going that direction [19:56:20] indy91: I have one question about your PR. What's the purpose of that Labe.cfg file? Am I guessing corrcetly that it defines the color of the label? [19:57:54] it defines the types of labels that exist, and if they are on by default, and its color [19:58:00] it's an Orbiter file that I modified [19:58:44] Gotcha. My only concern is that it might clash with other addons [19:58:55] Not sure if anything can be done about that [19:59:08] https://github.com/orbitersim/orbiter/blob/main/Src/Celbody/Vsop87/Earth/Config/Earth/Label.cfg [19:59:12] that's the original [19:59:27] I disabled the non-NASSP labels (made it o instead of x) [19:59:36] otherwise I just added the line for our markers [19:59:53] and yeah, that was my main concern, too, I don't like overwriting Orbiter files [20:00:01] I quite dislike it when Orbiter addons do that [20:02:23] I haven't come across any addon that added custom markers in this way [20:02:28] only the legacy method [20:02:49] which doesn't have altitude data [20:03:41] I guess the only thing that can be done is to add a note to the installation guide letting people know [20:04:07] oapiRegisterLabels would be nice to register it from a module [20:04:26] or make them add the Apollo Landmarks line manually in the installation process [20:05:15] the problem is also, if there was an addon adding markers in this new method, it would likely use the exact same file as I am adding [20:06:04] it's really not an ideally implemented feature [20:06:29] the old markers were better, you just had to add a new file, Orbiter was reading it, done [20:07:19] Yeah, might be good to open an issue, until then overwriting with a note in the install guide sounds like a fine solution. [20:07:41] aren't we already overwiting some lua file or am I imagining that [20:07:57] Script/oapi_init.lua [20:08:13] but beyond that I am not sure if we overwrite anything, I don't think so [20:09:16] I don't know what the default script even is. [20:09:22] Maybe it's empty? [20:09:56] Oh run_global is modifed [20:10:25] It doesn't appear to do anything usefule (anymore) [20:10:45] we do have some lua support, but I'm not sure I ever even tried it [20:11:37] I can it seeing used in the day of SimpleAGC and using Orbiter MFDs to calculate burns. It doesn't really have a usecase anymore in the current state of NASSP [20:11:55] I suppose you can still script flipping switches but the ChecklistMFD can do that too [20:12:09] Might as well remove the Script folder from the repo TBH [20:15:01] probably yeah, we might want to check if really nobody is using it [20:46:41] I had an idea for my never-going-to-merge-it Apollo 7/Aerodynamics branch. The Apollo 7 MCC was the first one I implemented and it isn't really set up in a good way future expansion, like adding any new calculations [20:46:55] which I started doing in the branch, like the PAD for the retro orientation test [20:47:33] I think what I will do is, make the changes that allow for better expansion of the MCC, edit the mission states in the scenario and just write in the release thread "if you fly Apollo 7 right now, don't update" [20:48:34] scenarios* [20:49:32] that should help me finally getting the Apollo 7 MCC into a state that I would call release ready [20:49:42] and doesn't have to wait for the day I merge that branch [20:51:45] that seems like a good approch [20:55:32] pick that feature creep of a branch apart, one piece at a time [21:00:44] rcflyinghokie, I have a CSM ECS question [21:00:53] Sure [21:00:54] cabin purge [21:01:07] we do have to do that now, right? [21:01:12] Yes [21:01:31] It gets rid of the N2 in the cabin atmosphere remaining after boost [21:01:35] right [21:01:37] Apollo 12 has a scheduled second purge [21:01:48] Yeah it was to ensure more purity in the LM [21:02:17] "the length of the second CSM cabin purge will be determined real time based on the LM leak rate insuring LM O2 purity requirements on the lunar surface" [21:02:37] how do I go about determining that [21:02:42] Haha good question [21:03:02] I think it was all done based on simulations [21:03:13] They could determine cabin leak rate via TM as well as O2 flow [21:03:39] higher LM leak rate, less time to purge the CSM [21:03:53] right, leak means mini purge [21:04:56] essentially [21:05:20] You wont notice ill effects really, an 8 hour purge I think was nominal though [21:07:02] 8 hour second purge? [21:07:41] I think the normal mission purge was 8 [21:07:49] Not sure about 12 need to look into it [21:08:44] I think I stopped it at 12:15h [21:09:19] in terms of mass I have 1% N2 left [21:09:42] 99% O2 [21:09:48] trace amounts CO2 and H2O [21:10:05] in the cabin [21:10:34] more relevant amount in the suit loop tanks [21:11:04] about 10% [21:15:00] yeah they dont exchange with the cabin as well as they should [21:15:14] but that low N2 is good [21:17:10] roger, Houston, no second purge [21:17:44] although my very next step is H2 purge line heaters - on :D [21:17:53] so much purging [21:18:29] but regarding the suit circuit, I will have the suit connection valves functioning so they flow into the cabin from the suit circuit when suits are disconnected [21:18:45] which of course is proper behavior [21:32:40] On another topic of future implementation, I would love to somehow see ullage behavior (or rather effects of not performing it) [21:33:11] APS interconnect for example has a warning to only be performed with +X ullage force or in a gravity field or He from the APS tanks could damage the RCS [21:34:06] Also indy91, while you are on 12, see if you can figure out those photo REFSMMATs ;) being able to compute those properly would be nice [21:34:49] yeah I will take a look at that [21:36:40] rcflyinghokie, you could impliment the effects of not performing an ulage burn with a derived valve/pipe class that "filters" substances based on an acceleration vector [21:37:01] could be interesting to play with [21:37:02] *ullage [21:37:26] I've been looking at the mission simulators they had a bit [21:37:40] I think I need to finish my threadPool class before we add too many more systems [21:37:43] not much documentation to find, mostly 1967 and earlier [21:37:56] I wonder if it simulated lack of ullage [21:38:09] pretty sure the NAA and MIT simulators didn't [21:38:26] yeah those were mostly procedural in nature I would think [21:39:50] yeah, mission simulators did stuff like playing a sound for RCS firing [21:40:38] Right I have read a lot of debriefs comparing the sim sound to RL [21:54:13] "The engine thrust is inhibited by an excessive off-nominal mixture ratio or by insufficient time to [21:54:14] settle the propellants." [21:55:01] in the sim? [21:55:20] yes, that's from the LM Mission Simulator Instructor's Handbook [21:56:29] Hmm interesting indeed [21:56:49] Could be a starting point [21:57:50] I don't think I have any calculations for that though [21:58:23] it might simply be looking at acceleration and tank content [21:58:59] and not necessarily different phases of the tank simulation [22:01:00] Could simply use the charts for 2jet and 4 jet ullage and put in some sort of check based on that [22:01:35] MSC had a quite detailed LM descent hybrid simulator [22:01:50] there is a fuel pressure equation with thrust acceleration as input [22:03:21] hmm, but that's not really what ullage does I think [22:03:41] that's fuel injector pressure [22:03:43] its to settle the propellants against the feeds [22:04:28] yeah I think this calculation is just the influence of acceleration for the chamber pressure [22:05:03] hmm, or is it [22:05:35] would make sense as there were no pumps [22:05:47] ok, this is what the document says [22:05:51] just gas pressure and gravity field [22:06:06] PIF = PU(144) - DPTF - FLD*(ATIB)*(HIF - HTF)/12 [22:06:19] PIF = fuel injector pressure [22:06:27] PU = tank pressure due to internal pressurization [22:06:55] DPTF = ? Some calculation on that page [22:07:11] FLD = fuel line density [22:07:23] ATIB = total acceleration along the X body axis [22:07:42] HIF = 17 inches (?) [22:07:58] HTF = height of fuel in fuel tank [22:08:00] fuel injector height maybe? [22:08:11] or that yeah haha [22:09:01] don't think this is what ullage does even if it involves the height of fuel in fuel tank [22:10:24] that acceleration factor could play a role though in fuel pressure [22:10:43] it does, yeah [22:11:00] just so I get this right, let's say you stop the ullage burn early [22:11:13] no acceleration for a few seconds [22:11:22] the propellant is still settled in that case [22:11:32] it hasn't randomly drifted of (yet) [22:11:40] due to random or other accelerations [22:12:01] or do you really need to do ullage until ignition [22:12:33] it would probably stay against the feeds [22:12:49] surface tension and inertia would keep it there [22:13:14] any rotation or acceleration in a different axis and all bets are off though [22:13:22] right [22:14:06] so it's more the integral of acceleration that matters [22:14:12] not the presence of acceleration [22:14:20] well [22:14:38] you could treat the tanks like a damped 2dof pendulum [22:15:21] length would be 0 when they're full [22:16:17] would be kind of neat to figure out how they simulated that [22:16:39] I think we can learn a lot from the AMS and LMS if we find more documentation [22:16:57] even the APS interconnect has a warning about helium ingestion if the tanks arent ullaged or otherwise in a gravity field before opening before opening [22:17:01] maybe I'll get to dust off the 7094 emulator again [22:17:27] https://www.dropbox.com/s/gy0vo8g8t2ywcdq/unknown.png?dl=0 [22:20:14] https://ntrs.nasa.gov/api/citations/19700011112/downloads/19700011112.pdf for a slightly larger application than the LM, but still, there's code [22:20:20] n7275, might have to add DDP-224, that's what the mission simulators ran on [22:20:54] oh for slosh and bending we have a lot of sources [22:20:57] oooo okay [22:21:00] MIT and NAA sims used that [22:21:18] we could implement some moments caused by that if we wanted to [22:28:32] this one has some good graphs at the end https://ntrs.nasa.gov/api/citations/19630003755/downloads/19630003755.pdf [22:32:44] no code, but a good start: https://ntrs.nasa.gov/api/citations/19650014214/downloads/19650014214.pdf [22:35:04] hmm, but is propellant slosh really what is relevant for this? [22:35:29] I thought that was more about the forces or torques create by it, so relevant for the dynamics of a burn [22:35:38] that's why MIT simulating it, to qualify the DAP [22:38:28] hmm [22:40:04] I think the best solution for NASSP is something simple, that keeps track of x-axis acceleration and then causes some issues or not [22:40:21] I think you're right [22:41:34] the slosh dynamics really only apply under acceleration [22:43:01] oh damn, where has the time gone. uhh, good night! [22:43:19] night haha [15:08:05] good morning [15:18:01] hey [15:20:26] 50x makes TLC quite quick [15:23:27] Doesnt it? [15:23:32] I just did my 10 in about 50x [15:23:50] one thing I noticed in the LM VC [15:24:04] I didn't know where to click for closing the overhead hatch :D [15:24:26] and then you couldn't really see the position of the valve [15:24:30] Oh can you keep an eye om something for me? I am noticing some hiugh RR temps in scns people have sent me for troubleshooting...I want to see if it needs to be tweaked or if its a result of timestep heating [15:24:41] sure [15:24:43] Oh haha thats not good (I dont VC enough) [15:24:56] LM ECS is very nice looking in the VC [15:25:04] Yeah it is [15:25:05] takes a bit getting used to [15:25:20] valves and buttons all over that ECS box haha [15:26:24] Yeah they almost seem cobbled together in there dont they [15:26:40] Probably designed the system and the valves went wherever they ended up [15:27:16] For P35/P41, the tig set by the final PRO of P35, correct? [15:27:27] I know I stated that before but I want to verify [15:28:25] yes [15:28:32] with a padloaded Delta T [15:28:33] 3m? [15:28:36] Ah [15:28:39] yes [15:28:42] Where can I check that [15:30:33] padload worksheets [15:30:35] ATIGINC [15:30:57] Reason I ask is the LM Timeline for 11 has T-3m but the G mission rendezvous procedure has T-2m [15:31:04] waaat [15:31:20] must be an error [15:31:34] it's 90 seconds in Sundisk and 3 minutes ever since in all versions [15:31:43] TPI+13 COMPUTE MCC1 BU [15:31:50] TPI+28 COMPUTE MCC2 BU [15:32:13] is that the final revision of the document? [15:32:29] that is LM procedures? or CSM [15:33:23] LM [15:33:33] I see PRO at +12 [15:33:35] Final Rev A [15:33:52] ah, Orbiter Sound CTD got me again :( [15:34:10] Ohh [15:34:21] Never mind I was looking in the AGS section [15:34:23] Derp [15:34:25] always being careful [15:34:29] and still... [15:34:39] Disregard haha [15:34:40] oh, the AGS procedure is different, right [15:34:59] Scrolled too far and just looked for MCC TARGETING :P [15:35:05] haha [15:35:13] I guess the backup charts need TIG-2 [15:47:42] I cleaned up 11's rendezvous a bit since I had GET based times instead of maneuver based ones it could become behind [15:48:03] PR is up, but hold off on merging for a few I need to add a few others I missed [15:53:08] Ok I think it should be good [16:07:22] ok [16:33:01] q [16:39:23] hey Matt [16:39:33] have you finally seen the markersß :D [16:39:35] ? [16:40:32] I may have found a better solution for the texture folder issue [16:43:14] ah and it would also not require overwriting the default Label.cfg [16:45:15] hmm [17:11:50] no, I can't fix the issue with the texture folder I think [17:12:07] but, I can change it so that we don't have to overwrite Orbiter's own Label.cfg [17:32:09] did git delete that file when I switched to Orbiter2016... [17:33:23] Thymo, is git supposed to delete files that are tracked in a different branch? The file Label.cfg was already there, but untracked. I switched to my branch, added the file there. [17:33:30] Then returned to Orbiter2016 branch [17:33:31] morning! [17:33:40] is that supposed to delete the file or did I somehow delete it myself... [17:33:42] hey Mike [17:34:10] yeah that would remove the file, if it is tracked in one branch but not the other [17:34:36] hmm I see [17:34:51] well good that I found a solution without having to use the file from Orbiter itself [17:35:03] or at least potential solution, haven't tried it yet [17:36:37] you can do `git checkout Label.cfg` to pull over the file from a specific branch [17:47:12] right [17:47:26] it's a very simple file, I just got the original back from my Orbiter Beta folder [18:03:34] ok now I somehow get the same issue as Matt, labels simply not appearing... [18:05:08] and now they appeared without changing anything [18:13:01] ok, landmark branch updated. Could use testing. Doesn't require overwriting any file from Orbiter anymore [18:17:40] so I sent out my rope reader test board for fab last night, and it is currently in production :D [18:17:55] should hopefully be able to start building it up late next week [18:20:42] awesome :D [19:54:59] hey [19:55:27] the random 'q' was an accident earlier [20:13:36] haha ok [20:14:10] I made an update to my landmark PR, doesn't have to overwrite the Label.cfg that comes with Orbiter now [20:14:17] could use a test [20:24:18] I can give it a test [20:25:36] building now [20:28:47] not that there are code changes :D [20:29:38] right but I had to switch branches :P [20:29:43] From ECS [20:29:47] yeah, I know, I know, haha [20:29:58] Ok so I am loaded, is it in Surface? [20:30:50] Which labels am I looking for [20:33:07] Apollo landmarks [20:33:48] are you also using a separate texture folder? [20:34:43] then you would need to copy something [20:45:50] No mine is all in one orbiter folder [20:47:31] But I do not see apollo landmarks [20:52:35] do you have a list with Airport, Cities etc. [20:52:46] should have "Apollo Earth Landmarks" [20:52:58] or do you have [20:53:02] Oh I am looking at the moon [20:53:04] Antarctic Stations [20:53:05] Cities [20:53:08] Tracking Stations [20:53:26] I have Apollo Earth Landmarks [20:53:30] haha [20:53:31] ok [20:53:53] do you see the markers? [20:53:59] on Earth [20:54:28] I do [20:54:49] well great [20:55:09] squares? [20:55:22] yeah, the cross was removed as an option for some reason [20:55:28] with this type of marker [20:55:37] the old style markers still work the same as they always did [20:55:40] wonder if a circle is better, easier to denote the center? [20:55:46] can I do circle... [20:55:51] moon has them [20:56:50] right [20:57:05] let me check how that looks [20:57:26] if you want to see [20:57:28] Config/ProjectApollo/Earth_VirtualAGC/Label.cfg [20:57:44] make the "S" in the third column to a "O" [20:57:53] for the Apollo landmarks [21:00:16] when I switch branches the landmarks don't load for me for some reason [21:00:27] second time I try then it works [21:01:37] hmm [21:02:16] Orbiter saves between sessions the checkmark on the Surface or Celestial [21:02:30] the markers only show up for me if I load Orbiter having previously enabled Surface [21:02:49] if I had it disabled and enable Surface in-sim then none of the markers shows up for me [21:03:26] is that the same for you? [21:06:07] Let me try [21:07:08] must be an Orbiter bug, it seems to only load something when Surface is enabled when you launch Orbiter [21:08:56] I dont have markers now when I loaded again [21:10:29] Oh there they are [21:10:48] And they are circles [21:10:58] But I also loaded with surface enabled [21:14:52] great consistent behavior... [21:15:12] I replicated your results [21:15:27] launching a scn with surface off and then turning it on wont show them [21:15:40] hmmm [21:15:51] with the default Earth I can't replicate it [21:15:56] only with our modified one [21:19:41] it seems related to the MarkerPath [21:20:36] where you can specify a custom folder for the Label.cfg file [21:24:56] such a weird issue [21:25:14] oh wait [21:25:28] it seems like my Apollo Earth Landmarks are somehow responsible [21:26:02] or did I load the wrong scenario... [21:30:24] now I somehow have a case where all landmarks in the list work, except my Apollo ones [21:36:21] Huh [21:51:35] yeah I don't get it [21:51:55] maybe it's something with loading labels from the Cache in general [21:52:19] All the other markers are in the 100MB Label.tree file [21:52:50] but I haven't been able to identify the part of the Orbiter code that could cause this [21:59:02] hmm it seems to work when I change the render level from 3 to 4 [21:59:30] I think then you have to be closer for the markers to appear [21:59:38] but if that fixes it [22:00:08] I'll look at it more tomorrow [22:00:35] night! [16:06:12] I can't figure out the issue with the labels not appearing [16:06:49] they seem to appear at resolution level 4, only downside is that I need to split the markers in two files [16:06:57] -180° to 0° and 0° to 180° longitude I think [16:16:43] that is a very odd problem [16:21:55] I did just find an error in one of the landmark locations [16:22:07] I doubt it, but maybe there is a landmark with latitude > 90° and that breaks it [16:22:50] nah [16:24:40] and there is one landmark with & in the name [16:24:48] would that do anything bad? [16:28:30] well for some reason it works reliably on resolution 4, so I'll just change it to 2 files [16:30:51] distance at which the landmark appears seems more than sufficient [16:30:59] although I am not sure about P23 landmark option [16:35:36] Think its an orbiter thing? [16:36:29] must be [16:36:38] well great [16:36:45] Apollo 8 MCC-scenario [16:36:52] it loads the default level 3 markers [16:36:55] but not level 4 [16:37:08] so without the change from 3 to 4 it would have shown them... [16:37:16] MCC-1* [16:37:23] in the sextant [16:39:58] it would have been so easy to include support for elevation in the old style markers, I could change the Orbiter code in 5 minutes... [16:41:17] Sooo tempting with the open orbiter :P [16:49:48] I have figured out how to unpack and re-pack the Label.tree file that comes with Orbiter [16:49:56] but I don't think that is an option [16:50:57] ok it doesn't actually come with Orbiter [16:51:08] it's part of the high res stuff to download [16:51:28] so some maybe use that, others not [16:51:30] may* [16:57:36] rcflyinghokie, RR temperature is normal during LM checkout after LOI-2 [17:10:45] Let me know what it does during ascent and rendezvous/docking [17:11:03] Thats where it seems to creep high for some [17:12:52] sure [17:13:28] I think might not be getting rid of enough heat [17:13:46] Which would also help improve LM heater current as well if I let it reject more [17:19:29] morning! [17:32:43] hey Mike [20:11:04] rcflyinghokie2, my Apollo 12 astronauts in the LM are freezing [20:17:09] Oh no :( [20:17:18] LM might be rejecting too much heat not [20:17:19] now [20:17:29] I have noticed the way the heat behaves has changed [20:25:25] it's not terrible, PAMFD shows critical for a while but with hatches to CSM open and LM being activated it will recover [20:25:46] at least it doesn't kill them just with normal operations [20:46:48] Yeah [20:47:12] It will need more tweaking after some of those substance updates were pushed a bit ago [20:47:30] But yeah it warms up properly when activated [20:49:21] come back from the CSM, LMP, I need your heat [20:53:00] Haha [20:56:40] I hope to get back to tweaking those [22:04:26] night! [15:25:31] hey [15:31:25] rcflyinghokie, I can answer the Apollo 16 abort questions if you haven't already started replying [15:31:44] I started but go for it I had to jump on a work meeting [15:32:07] By started I just multi quoted :P so no response generated :P [15:37:55] Which documents are you going to reference though, I think the best one I have is the H mission abort techniques one [15:37:56] ok, I'll answer [15:38:00] thanks [15:38:19] well it seems like he hasn't discovered the second half of the timeline book with the abort charts yet [15:38:36] we have the LM Rendezvous Procedures for J-2 and J-3 thanks to Mike [15:38:39] Haha also true [15:39:09] aside from mission techniques there is also the operational abort and rescue plan [15:39:17] although I think we only have that for Apollo 13 [15:39:24] not any later ones [15:39:58] 14 technically but it probably is the same :P [15:55:17] I also have 13 [16:19:21] hmm, ggalfi's website with the landing site scenery is down [16:19:26] could have used that for 12 [16:23:43] The site with all the Apollo 15 docs is also today it seems [16:24:03] I have 13 as well, I just meant 14 is a "later" one ;) [16:25:44] right, I think the 14 one isn't complete though [16:25:59] the 13 one is complete, 14 is changes from 13 [16:37:50] Ah gotcha [17:12:25] every mission I fly I ask myself where the exact desired landing site is [17:20:08] as opposed to? [17:23:40] actual [17:23:47] but also where the LGC wants to take it [17:24:03] looking at the mission report I am seeing maps, but not where the pre-mission landing site was [17:24:29] I am interested in the smallest scale, so where the onboard RLS is located relative to the craters near Surveyor [17:34:32] Ahh i see what you are saying [18:09:34] morning! [18:10:41] Thymo, I need some more time to think about the landmark PR anyway, but why did you want me to squash the commits. Is it because I added a file and then removed it again? [18:10:47] hey Mike [18:10:58] Hi [18:11:31] hey [18:11:35] Yes, you added something and then immediately undo it. It makes more sense to squash them into one so it only logs the addition [18:13:00] ok [18:13:21] well as long as that doesn't cause any issues with branches like the rebase I am fine with that :D [18:15:44] Thymo, so the labels are loaded like texture and elevation data. There are different resolution levels. [18:15:59] at level 3 it's still one file, one texture, one elevation data set, etc. [18:16:15] from level 4 on it's split in 2 files [18:16:20] 4 at level 5 etc [18:16:23] labels go down to level 12 [18:16:37] so those you can only see when it loads level 12 data, if you are quite close to it [18:16:55] with resolution level 3 there is a bug it seems like [18:17:15] and when I change it to level 4 you can't see it from below Earth orbit for e.g. P23 with landmarks... [18:17:36] so not really any solution I am completely satifisied with... [18:18:54] Sigh.. And it does work when you modify the Orbiter file? [18:19:34] I don't think so, need to try that again [18:19:42] not the Label.cfg file from Orbiter I modified [18:19:59] the actual Label data is stored in a Label.tree file [18:20:07] that's the "archive" format [18:20:20] 100MB for the high res download [18:20:43] that's basically a lot of files combined that it would normally have with the different resolution levels [18:21:08] in the Orbiter code it treat the .tree data differently from the multiple .lab files [18:21:17] I can only assume that the bug is related to that [18:22:13] Orbiter saves if you have checked Celestial, Surface in the Planetarium mode (F9) [18:22:39] and my added Apollo landmarks only load if you had checked that option in the last Orbiter session [18:23:04] if you load a scenario and then enable the Surface markers they don't show up [18:23:06] that's the bug [18:24:07] so it's not terrible, but quite incovenient [18:24:28] I have already looked a lot for it, but I need to do more testing if it's anything I am doing wrong [18:24:44] or if that is really a general probably with this format for the labels [18:27:19] general problem* [18:35:36] as I thought, if I use the Label.cfg from Orbiter or my own (using the MarkerPath) doesn't matter [18:46:52] seems to be a general issue with resolution level 3 [18:48:12] Orbiter doesn't even load its own level 3 labels if you had Surface disabled before loading a scenario [18:48:36] it has a bunch of major cities in level 3 so that you can see them from afar [18:48:43] New York City and such [18:52:00] is that issue purely fixed by orbiter code? [18:54:04] I assume it doesn't even try to load the level 3 data in this case, and jumps straight to 4+. So maybe it's an option somewhere [18:54:17] I think I've seen it in both DX9 and default graphics though [18:56:41] but I think it's graphics code and not like "core" Orbiter [18:59:49] you know when you load the LM on the Moon, the elevation data is slowly coming in? [18:59:57] one resolution better than the next [19:00:19] that's how Orbiter seems to load all data for planets [19:00:23] bodies* [19:01:00] but if it skips some low resolution levels [19:01:05] it might not be loaded those labels at all [19:01:35] loading* [19:10:20] hmm [19:10:22] "// TODO: render full sphere for levels < 4" [19:14:39] well I don't know [19:14:52] we have three options [19:15:29] 1. use old markers. For landmarks with high elevations they are being rendered way below the surface (at mean radius). Work reliably. [19:16:09] 2. use level 3 new markers. Can be seen from far away, but there is a bug that requires you to have Surface markers enabled before loading a scenario or else they don't work. [19:16:47] 3. level 4 new markers. Requires two files instead of 1, seems to work reliably, can be seen from far enough for all P22s, only from beyond LEO they aren't showing up anymore. [19:20:52] Honestly I am leaning towards 2 with it being noted, seems to be the best compromise [19:21:07] because they will work [19:28:08] my preferences was going 3 > 2 > 1 [19:28:31] I have to check at what distance they are disappearing at level 4 [19:29:03] probably at a distance where you wouldn't be realistically be able to identify the landmark still [19:29:53] I mean, Apollo 7 used P23 lunar landmark option [19:30:14] surely you would roughly point the sextant at the area where you think the crater is... [19:30:36] does this impact the moon labels at all [19:30:46] no, was just an example [19:31:31] or do you mean for the next step [19:31:36] when I look at Moon landmarks? [19:31:39] hmm [19:32:01] I would expect it to be the same as Earth [19:44:39] visible beyond 10,000 NM [19:44:41] at level 4 [19:44:43] altitude [19:45:14] I'd say that is good enough [19:45:52] the markers are cheaty helpers to indentify landmarks. But at this distance you can't really indentify them at all without the markers [19:47:44] right makes sense [19:47:58] if 3 can be done pretty easily I see no issues with it [19:48:08] And yeah I dont think the distance will be a factor will it? [19:49:06] nah, never for P22. At lunar mission distances you need a different kind of map really for landmark identification [19:49:10] so I think I'll do 3 [19:49:14] option 3* [19:49:38] the nice thing is the landmarks (in the order they appear in the Earth landmark maps document) are already sorted by longitude [19:49:56] so I just have to copy over the second half of the file to the file for 0° < longitude < 180° [19:51:01] oh nice [20:18:25] Thymo, I'll have a third commit, basically removing the resolution level 3 file and adding two level 4 files. I'm also changing the marker symbol from square to a circle. [20:18:31] Should I squash all three commits? [20:18:45] And what will people have to do when they want to test my branch then [20:19:18] because for the Orbiter2016 branch this might appear as one commit, but I think this will cause issues with people testing as they already have the two-commit version [20:19:37] so this might not be such a good idea... [20:19:52] causing us headaches again for a cleaner git log [21:40:40] rcflyinghokie, I am so confused about the Apollo 12 landing site haha [21:40:47] Haha how so [21:40:52] the target point is quite a bit away from the crater [21:41:09] and with everything I am reading is that they wanted the target point in the Surveyor crater [21:41:10] Didnt they update the landing site at some point? [21:41:28] yeah, I guess they must have done that pre-landing [21:41:47] also difficult to compare to the actual flight path, they had a decent amount of crossrange [21:42:20] so the approach direction was slightly perturbed [21:43:15] the thing is, they didn't do P22 exactly on the landing site [21:43:22] but a spot a few kilometers away [21:43:37] but maybe that was enough to correct errors [21:43:38] They did a N69 during PDI also right [21:45:01] yeah [21:45:09] downrange [21:45:42] the difference is mostly crossrange really [21:46:11] actual location: 3.01239°S [21:46:21] pre-mission: 2.9822°S [21:47:13] that alone is 900 meters [21:47:23] takes quite a big re-designation [21:52:09] need to look at more maps :D [22:09:54] ok the landmark update should be done tomorrow and finally getting merged [22:10:10] night! [14:17:38] good morning [14:20:58] hey [14:21:21] when did you fly Apollo 12? [14:21:29] remember any P57 trouble? [14:22:26] https://github.com/orbiternassp/NASSP/pull/738/files [14:22:34] left detent is unusable [14:26:09] I think I did have some and just used a different detent? [14:26:11] Its been a bit [14:26:23] I do recall having to change the detent code for some P57s though [14:26:26] yeah, that would of course work [14:26:59] I was trying to use the original stars and what was confusing me is that it gave me a 404 alarm for a clearly visible star [14:27:04] Other than 7 and 10 its been the longest since I flew 12 though lol [14:27:18] Ahh I think I remember that and thought it was user error somehow [14:27:45] I was also using RTCC for the first time so I probably downplayed that issue in my mind [14:28:26] Oh on Apollo 11, it seems the MCC6 P27 comes way early [14:29:18] At about 160h, the MC6 decision comes up and gives an uplink of SV and entry target, however this shouldnt happen until about 171h [14:30:48] I have a preliminary MCC-6 update [14:31:02] at TEI + 24h25min [14:32:10] but the flight plan has no uplink there it seems [14:32:17] but our MCC has [14:34:14] I can remove that I guess [14:34:17] yeah [14:34:22] but that's just a preliminary update [14:34:27] There should just be a decision there [14:34:32] there is the proper MCC-6 update at the right time [14:34:33] And pads if not scrubbed [14:34:42] Entry PAD in any case [14:35:00] If its scrubbed you get the SV and entry target at both of those times [14:35:18] as it's currently set up [14:35:45] yeah [14:35:55] I say remove the uplink there at the 160h and have an entry pad if scrubbed and all the other pads if not [14:35:59] real mission got an uplink there, but just a clock update [14:36:03] Ah [14:36:13] yeah I'll remove that uplink [14:36:26] Maneuver PAD there is already optional [14:36:35] and Entry PAD is not optional [14:36:40] so just the uplink needs to go [14:36:56] I should add some clock updates to the MCC everywhere [14:37:14] as I figured out when I added the clock update uplink pages our AGC clocks do have a drift [14:37:23] probably due to timestep issues [14:37:40] basically using the "predicted" length of a timestep for the AGC timestep [14:37:56] and not the actual length which can be like a nanosecond longer haha [14:38:14] but it accumulates, can be as bad as 0.6 seconds during rendezvous which violates mission rules [14:42:01] on my Apollo 12 mission I did one 0.14 second update so far, just before LOI-1 [14:42:15] and will do another one before rendezvous and reentry [14:42:55] flight controllers obviously don't read the mission rules, I know from Apollo 15 that they already did clock updates for a lot smaller errors [14:43:21] Haha [14:43:33] If you do add clock updates let me know I will add them as appropriate [14:44:17] If MCC6 is scrubbed do you get a second entry pad at 171h? [14:44:24] Or should that just be an uplink [14:44:27] I might make them optional, only uplink them if mission rules are violated [14:44:42] they wouldn't be standalone uplinks but just be included with state vector uplinks and such [14:44:50] so no checklist changes required [14:45:05] but I'll include it in the uplink message [14:45:29] ok [14:45:36] second entry PAD [14:45:48] ok cool thats how the checklist currently looks [14:46:14] And where all do you get entry target updates? [14:48:21] with all MCC-X calculations except MCC-7 decision [14:48:26] and MCC-6 decision will be removed [14:48:40] and also with final lunar entry PAD [14:49:40] the MCC messages don't specifically say it, but if you have to execute a TEC MCC then it will uplink a "target load" [14:49:45] which is Retrofire External DV [14:49:53] TIG, DV, lat and long of splashdown [14:52:47] Right I know it comes with those [14:53:04] I mean if MCCs are scrubbed do they get uplinked [14:53:16] Right now you get an entry target twice for MCC6 scrubbed [14:53:39] yeah [14:53:49] it does recalculate the optimum landing point based on the current trajectory [14:53:59] even without a maneuver that might very slightly change [14:54:18] although the landing point selection is still a bit of a mystery to me [14:54:36] when do you stop refining the landing point that is best for CMC guidance and tell the carrier "that's where we will land" [14:55:16] the reentry mission techniques document has only helped a little bit with that [14:57:50] So I should include entry target in all the scrubbed uplinks as well? [14:57:59] that one uplink for the preliminary MCC-6 uplink will of course go away, but entry updates despite scrubbed maneuver still make sense [14:58:06] got it [14:58:09] MCC-6 update* [14:59:23] I updated the branch for the Earth landmarks, hopefully for the final time [14:59:37] so one last test would be good, no rewriting of history done yet [15:00:08] when you give the ok I'll look at combining those commits as Thymo requested [15:00:46] Ok cool I will give it a check [15:08:19] Look good in LEO [15:08:32] Anything in particular you wish me to check? [15:09:52] if there are landmarks in both hemispheres haha [15:10:25] Seemed that way [15:10:32] west vs. east [15:10:38] Want to give me 2 to check to be sure [15:10:45] ok [15:11:05] Cape St. Ann (214) [15:11:13] Benue & Niger River Junction (215) [15:11:16] both in Africa [15:11:31] east and west coast I assume [15:12:15] ok [15:12:32] they have nearly the same latitude [15:14:46] might bee a bad scn to see them lol [15:15:01] haha [15:15:11] I can give you Pacific ones [15:15:15] better? [15:15:20] Probably haha [15:15:36] Oahu (1) [15:15:40] My orbit takes me over the southern tip of Africa right now [15:15:42] Hawaii obviously [15:15:52] Cape Ford (536) [15:16:05] ok [15:16:21] Australia [15:20:57] I have the 2 in africa [15:21:29] missed cape ford though but got oahu [15:22:45] got cape ford [15:22:48] all 4 are present [15:23:17] great, that means it works [15:23:35] and I already tested that the bug with the Surface checkmark doesn't apply to these [15:23:45] so I am happy [15:25:16] oh awesome [15:33:18] Added my approval [15:37:43] and I broke your approval haha [15:37:53] I think I successfully merged those 3 commits into one [15:38:02] I'll let Thymo look over it and merge it [15:39:17] haha ok [16:41:42] P22 workaround procedure, hmm [16:43:05] they ran P22 in the LGC on Apollo 12, but while it already was running they were changing the octals of some time in memory, a workaround procedure apparently [16:43:10] I wonder why that was necessary [16:43:40] G&N Dictionary has that, too [16:43:42] must be a bug [16:45:52] mike might know [16:46:56] https://www.ibiblio.org/apollo/Documents/LUM109_text.pdf [16:48:03] ah ha [16:49:03] but that's only the first part of it [16:49:10] wait until range is below 400 NM [16:49:57] not loading octals [16:51:21] 112:24:30 is the time they load as octal [16:51:33] 111:38:59 Carr: Intrepid; Houston. We have an update on the P22 Acq time for you. (Pause) [16:51:35] 111:39:06 Conrad: Go. [16:51:36] 111:39:07 Carr: Okay; figure on 112:24:30. [16:51:51] so that's just the same as the acquisition time they got [16:59:03] would this have occurred on 11 had they done a P22? [17:43:30] hey [17:50:50] i seem to remember something about 400 nm being the maximum value for RR range [17:52:06] sime type of overflow detect was added for "later"? missions so that it could track above 400nm [17:52:31] *some [18:08:27] no I think the 400NM is a general issue and they are just monitoring it [18:08:37] loading that octal time seems to be another issue [18:08:48] we have the 11, 12 and 13 G&N Dictionaries and only 12 has that procedure [18:10:20] ironic as 11 and 13 didnt do it I believe :P [18:26:52] well I still think it's that Luminary anomaly, so related to the range, but I don't know why they did this workaround [18:27:32] the part with loading some octals that P22 uses [18:29:25] wow [18:29:31] has to be a separate bug [18:29:41] N38 shows coasting integration time tag [18:29:54] and it propagated to current time but then was kind of stuck [18:29:57] cycled between two times [18:30:10] and entering those octal gives it a time for AOS [18:30:30] and after entering those N38 propagated to that time, so not stuck anymore [18:30:43] so entering them in octal got it moving? [18:30:59] Oh might have found a battery bug in the CM [18:31:08] Trying to charge C, goes up to 1A [18:31:18] Switch panels and come back and its zero [18:32:32] I was looking at charging behavior the other day actually [18:32:46] https://www.dropbox.com/s/aztm0pxhdukq6g3/Apollo%2012%20BAT%20C%20Charge.scn?dl=0 [18:33:05] reproducible here [18:33:12] near fully charged the current quickly drops [18:33:22] yeah but if you watch it it doesnt move [18:33:28] even on time accel [18:33:35] but if you switch panel and come back its zero [18:35:08] 2D or VC? [18:35:24] 2d [18:36:22] seems to behave normally in VC [18:40:52] oh really [18:40:55] so a 2D panel bug? [18:41:36] yeah, can you replicate it? [18:41:45] not while doing P22 :D [18:41:54] just got done, worked great [18:41:56] Haha I mean in that scn to start [18:42:06] let me take care of the CSM and I'll check the scenario [18:42:09] Or drain bat C a bit then try [18:45:59] I can replicate it in other scns [18:50:35] Let me know if you see it and I can put an issue up on git [18:53:31] ok [18:55:23] I can replicate it [18:55:28] Looking at FC flows it looks like charging stops and its not just the display [18:55:31] only battery C, interesting [18:55:44] YEah [18:55:52] I remember that I had to do some weird stuff with wiring [18:55:58] can't remember what for :D [18:56:07] but I have the suspicion it's that code [18:56:37] https://github.com/orbiternassp/NASSP/issues/740 [18:57:50] yeah I added some special Battery C code to the Battery charger [18:59:11] ah there is some two way power flow [19:00:57] and I bet something gets reloaded when switching panels [19:01:10] and that disables battery charging to bat C [19:03:30] Ahh [19:04:08] yeah the BatCCHRGCircuitBraker circuit breaker is two way [19:04:29] Charger -> BatCCHRGCircuitBraker -> Bat C Main Braker -> Battery C [19:04:38] and when Battery C powers things [19:05:27] Battery C -> Bat C Main Breaker -> BatCCHRGCircuitBraker -> An EDS Bus [19:05:49] full name of BatCCHRGCircuitBraker is "Bat C Bat Chgr/EDS 2" [19:06:10] and I was probably working on the SECS and noticed that EDS bus 2 wasn't correctly wired [19:06:27] that charger CB was probably only set up for charging [19:09:40] yeah [19:10:23] and the wiring gets redone (for some reason) when switching panels [19:10:38] hm why would it be switching panels [19:10:43] and why not switching in VC [19:11:05] 2D panel load function [19:12:00] who thought it was a good idea to do this wiring in the Init function (which gets called on 2D panel switching) and not Register (only done once) [19:14:13] Yikes is that just that battery or more wiring [19:14:30] morning! [19:16:26] Good afternoon [19:16:59] hey Mike [19:17:59] most of the circuit breaker are being wired together there [19:20:48] would moving them be a solution? [19:21:31] one good thing is, the Init function doesn't rewire it if the power source is NULL [19:22:23] hmm [19:22:32] but how is it wired after switching panels [19:22:42] BatCPWRCircuitBraker -> BatCCHRGCircuitBraker [19:22:52] is what reloading the panel does [19:23:13] ah of course, BatCPWRCircuitBraker also gets rewired there [19:23:57] hmm [19:24:07] n7275, did you implement the battery diodes? [19:24:43] the battery charger code is rewiring stuff when you switch to a different (or no) battery [19:24:47] and it's not using the diode [19:28:27] only for Battery C I guess [19:28:38] I think we can set some stuff to NULL in the code that gets called every time you switch panels [19:28:51] and then do the initial wiring in Saturn::SystemsInit [19:29:10] and when the Battery Charger gets loaded from scenario it also already configures everything correctly [19:30:47] a bit more code would be need to take care of wiring Battery C vs. DiodeC [19:30:54] DiodeBatC* [19:32:07] n7275s domain there? [19:33:16] well we did forget to wire the diode for battery C correctly when the diodes got implemented [19:33:26] otherwise it's my special battery C code causing the issue [19:35:12] at least it was not hard to identify [19:35:32] Random question, for an 11 flight, would having all TEC MCC's scrubbed be unusual [19:36:40] somewhat, but not impossible [19:36:50] I'd give it a 1 in 20 chance for that to happen [19:37:02] Haha well someone got it apparently :P [19:37:25] I can look at the scenario of course just to check on MCC-7 [19:37:40] I checked it around MCC5 time it was like 0.4fps [19:37:47] But let me find one [19:38:18] maybe did some lucky uncoupled thrusting [19:38:43] MCC-5 gets scrubbed below 2 ft/s [19:38:45] https://www.dropbox.com/s/uz8q1w5wc5fgbd3/159_hours_.scn?dl=0 [19:38:48] MCC-6 and 7 below 1 [19:38:55] Thats around MCC6 time [19:39:03] well decision time [19:40:25] yep [19:40:34] MCC-6 gets a 0.09 ft/s [19:40:59] MCC-7 0.46 ft/s [19:41:03] scrubbed below 1 ft/s [19:42:27] just weird that MCC-5 had more DV already [19:44:02] maybe some uncoupled thrusting and got lucky is my best guess if MCC-5 wasn't done [19:45:13] I just hope that nothing breaks from this unusual situation :D [19:45:20] but TEC is set up well for that [19:45:34] TLC on the other hand did have some bugs I think, if both MCC-1 and 2 got scrubbed [19:45:37] but fixed now [19:50:23] this was his post TEI https://www.dropbox.com/s/u4lk1tok7omy9vb/Post_TEI_.scn?dl=0 [19:52:03] literally [19:52:07] still in P40 :D [19:52:48] 0.51 ft/s for MCC-7 [19:53:00] congrats on the best residuals nulling of all time [19:53:05] sadly no price [19:53:20] well the price is no TEC MCC at all [19:53:37] so yes, this is the 1 in 20 chance I guess [19:54:08] Haha thats what I got for 7 also [19:54:27] Guess he had to get lucky somewhere [20:01:05] oh. I forgot I implimented those diodes... [20:01:49] I think all they do is simulate the forward voltage/bias effect iirc [20:06:41] Do either of you have an issue with the cabin noise? I've never had a problem with it. [20:07:05] Well the suit compressors are loud [20:07:17] Even Thymo made an issue about it a while back [20:07:25] I think a quieter SC is a good thing [20:07:46] I wouldnt think that they were that loud IRL [20:11:58] weren't there complaints about noise, especially near the end of the missions? [20:12:12] Cabin fans mostly because of bad bearings [20:12:31] Cabin fans could be turned off though [20:12:38] the SC was needed for the ARS [20:12:44] right [20:15:07] I dont recall anything specifically about the compressor sounds though [20:15:29] At some point I'll add an option to the launchpad configurator that makes the cabin fans slowly increase in volume and slowly drift out of tune with eachother as the mission progresses, but for normal users we could probably make them quieter [20:15:39] yeah I think thats a good start [20:16:48] actualy, does orbitersound have any pitch shift functionality? [20:17:12] indy91 for your AOT detent PR, would that fix saves as well or only fresh missions? [20:17:26] fresh missions [20:17:27] I would assume the latter [20:17:54] Ok, so the EMEM change is needed for all others (or editing the scn) [20:18:21] yep [20:18:49] in theory also another erasable is affected by the typo, but it's insignificant [20:18:59] you know that time delay in P35, the 3 minutes? [20:19:05] there is a separate padload for P75 [20:19:16] and that would then have a slightly bad time [20:19:25] so... not really a big deal :D [20:20:01] Ahh [20:20:05] If P75 was used [20:20:12] which is never is hehe [20:20:13] it* [20:20:23] definitely not in the LM [20:24:07] P75 in the LM was to give the CSM burn data for TPM correct? [20:24:29] yeah, all the P72-P75 programs where to calculate CSM rendezvous burns [20:24:38] if LM has good computer and CSM has good engine [20:24:41] Right [20:24:43] but not much else is good... [20:24:47] I have never experimented with those [20:25:04] I need to play with more rescues I think [20:26:18] internally there is probably very very little P7X specific code [20:26:29] just a flag which vehicle is active [20:26:40] so P72-P75 work exactly the same as P32-P35 [20:32:58] okay, I am going to go ahead and submit my Suit Compressor SFX pull request [20:35:04] sounds good [20:35:29] about the cabin fans, I think it's bad if you disable both of them for longer periods of time [20:35:33] at least in NASSP [20:36:05] but one should be fine and is a good noise reduction [20:36:06] Right, with the current ECS implementation it means that cabin temperature is totally unregulated [20:36:21] I found that out the hard way, ended up with a 45 degree cabin [20:36:28] yeah, I did that once, too [20:37:18] in my experience the cabin fans, while loud, are not a terribly unpleasant noise. It's the whine of the suit compressor that is most taxing on the ears [20:37:42] so I have no problems with keeping the cabin fans as they are or just disabling one to reduce the volume [20:39:46] suit compressor for the ears, sextant split line-of-sight for the eyes [20:40:20] indeed [20:46:27] yeah, I like it. [20:46:34] in the direct comparison [20:55:48] awesome [21:00:26] no issues here [21:05:12] an issue I've noticed, nasspsound.h references "aircond.wav" as the "POSTLANDINGEVENT_SOUND" but no such WAV file exists as far as I can tell. [21:05:30] it also seems unusual that an air conditioner sound would be used for post-landing? [21:06:13] its just the blower motor for the PL vent [21:06:35] So it has a "fan" sound I guess lol [21:11:06] right but the audio file seems to be missing? [21:16:29] ah I think it comes with Orbiter Sound itself [21:16:32] not NASSP [21:16:54] ahh roger, you're right [21:32:00] put a Surveyor in my scenario [21:32:05] sadly has no touchdown points [21:36:31] bummer, could be neat to see when I land my Apollo 12 mission [21:39:42] yeah [21:39:45] it's below the surface [21:39:53] and of course an external addon, not from NASSP [21:39:56] must have landed too hard [21:40:01] :P [21:42:46] haha [21:43:08] I'm kind of tempted to write an elaborate guidance system for the Surveyor for landing... [21:50:23] don't make it too elaborate, iirc one of those had a few "touch and goes" [21:51:26] right [21:51:31] I have a bunch of documentation about it [21:51:56] I think we know someone with a bunch of drawings too :) [21:53:04] that sounds neat [21:53:26] but wait, are we planning on adding support for actually landing the Surveyor? [21:54:14] nah, I am thinking about auto landing the Surveyor for fun [21:54:20] ah okay [22:01:44] good night! [22:01:50] night [22:01:58] damn too late again [22:01:59] lol [22:27:11] .tell indy91 "And what will people have to do when they want to test my branch then" > They will just have to pull it again. It's your personal dev branch so others should not rely on it being in a stable state. [22:35:16] whoa that was weird [22:36:01] there we go [23:12:14] irc trouble? [23:13:45] yeah apparently lost connection due to a timeout, which is weird [23:38:17] happens sometimes I have seen [00:14:47] .tell indy91 something else noticed on 11, the entry pad does not come up with the MCC7 scrubbed uplink, apparently it comes up on the next state. Shouldnt the pad come up with this uplink? [14:19:06] good morning [14:22:48] hey Matt [14:49:13] did you check the new suit compressor sound? [14:49:18] the PR [14:50:05] I guess it already has 3 people approving it, so I'll just merge it :P [14:54:58] I had not yet. I'm sure it's fine. [14:56:17] yeah [14:56:24] what was the latest you heard from UHCL? [15:06:45] "Thank you for your inquiry. We are working to process your request and will have your document to you as soon as possible." [15:06:59] on 2 March [15:08:41] ah ok [15:09:00] well hopefully next week we will hear something [15:11:32] Hopefully it's taking a long time because there are a lot of pages, rather than a large backlog, and like 5 pages... [15:12:03] I'm sure it's the backlog and they haven't even started haha [15:34:52] Thymo, yeah you are right, in this case it wouldn't have been all that complicated. [15:47:11] rcflyinghokie, you will be amused to hear that I got the LOPC-1 roll and REFSMMAT wrong, heads up vs. down [15:47:24] Hah! [15:47:35] I do it more often that I admit ;) [15:48:21] While its fresh, do you know the specific reason the TM has to be in HBR for an PGNS AGS downlink? Is it the speeds of the downlink itself? [15:50:04] did that mistake once, too, this mission [15:50:25] PGNS doesn't send anything on downlink in low bitrate in the LM [15:50:41] neither to Earth nor to the AGS [15:52:06] Ah thats why [15:53:15] and about your MCC question, it's not that flexible [15:53:43] there is a calculation, followed by showing PAD (or not) and uplink (or not) [15:53:56] then some condition to go to the next calculation, PAD and uplink [15:54:23] at best I could abuse the logic that leads to different paths, like with the Apollo 10 PTC REFSMMAT [15:54:34] make the wait from uplink to Entry PAD 0 seconds [15:54:43] that is after the uplink is done [15:54:50] Ah ok I will add another placeholder there [15:55:03] No problem at all [15:56:40] how is it right now? [15:57:04] does the checklist say there will be an entry PAD with uplink if the maneuver is scrubbed? [15:59:07] Yes [15:59:28] Right now you just get the uplink with no pads then a few minutes later the pads [16:00:58] Thats why i was assuming you could give the pad with the uplink [16:01:48] But I think this would be correct as the pads were given shortly after the uplink [16:01:57] So I think it should be fine the way it is [16:02:06] I will just amend the checklist MFD [16:02:43] Now for MCC7 not scrubbed do you get a pad with the uplink currently [16:02:50] A maneuver PAD [16:05:11] the only flexibility is if a Maneuver PAD is shown or not [16:05:26] so there is a Maneuver PAD with uplink. Then a bit later Entry PAD without any uplink. [16:05:44] if scrubbed it doesn't show that Maneuver PAD, but there is still the uplink [16:06:03] what it can't do is decide on the spot to show either a Maneuver PAD or an Entry PAD [16:06:38] Right [16:06:53] I have spaced it out so it lines up with the current implementation and clarifies it [16:07:36] I could only make it so the Entry PAD comes without delay after the uplink, if the maneuver was scrubbed [16:07:45] the delay is so you have time to write down the Maneuver PAD [16:07:56] but if there is no PAD there isn't really a need to wait [16:10:41] I think it should be ok as it is [16:10:51] As there was a delay between the uplink and the pads on the flightplan anyways [16:12:45] yeah, the flight controllers were always intently listening when a PAD was read up [16:12:59] and someone like GUIDO probably also wanted to monitor the uplink [16:13:13] although usual there was actual a second GUIDO at the console handling uplink stuff [16:13:26] and let GUIDO take care of onboard computers etc. [17:53:54] morning! [18:38:56] hey mike [18:39:33] what's up? [18:51:00] flying Apollo 12 [18:51:37] partway in EVA 2 [18:51:43] not that there is a lot to do [18:51:50] nice :D [18:51:58] I could go to the Surveyor but it's underground [18:52:05] lacking touchdown points I guess [18:52:41] sounds like a pretty rough landing [18:52:48] haha [18:53:08] the LM at least landed pretty well [18:53:38] needed a hard correction with LPD, padloaded landing site vector is a bit off the actual landing site somehow [18:53:54] oh huh [18:54:17] that's weird [18:54:19] but it's pretty consistent with all preflight documentation [18:54:49] I haven't managed to understand their process with the landmark tracking yet [18:55:06] they did P22 on some feature near, but not the landing site itself [18:55:28] maybe they used differences in latitude and longitude of that landmark vs. predicted and applied that to the landing site itself [18:56:22] speaking of P22, but in the LGC. There is a quite weird procedure. It seems like a workaround for a bug, but it doesn't exactly fit to the known anomalies in P22 [18:56:51] in any case it's Luminary 116 only [18:57:31] hmmm interesting [18:57:32] you wait until range is smaller than 400 NM, that is normal. Well, also related to an anomaly [18:57:53] https://www.ibiblio.org/apollo/Documents/L-1B-01.pdf [18:58:41] but then what you are supposed to do is monitor N38 [18:58:54] which is the time of the currently being integrated state vector [18:59:14] and when that reaches present time it start to cycle near present time, seems kind of stuck [18:59:31] and then you load, in octal, the predicted time of acquisition [18:59:48] in REPOSTM [19:00:09] V24N01E, 3424E [19:00:28] and that seems to allow the integration to proceed, to that time loaded [19:00:34] and then P22 works normally [19:00:37] oh weird, that does sound like a bug workaround [19:01:15] the workaround for L-1B-01 is already waiting for range < 400 NM I think [19:01:39] so this might be unrelated? But I don't see it in any of the anomaly reports [19:02:09] https://www.ibiblio.org/apollo/Documents/LUM109_text.pdf [19:02:20] this is a different workaround procedure that is also realted to L-1B-01 [19:02:22] hmmm [19:02:37] yeah, this is starting V83 [19:02:41] which shows range [19:02:55] and then wait until < 400, PRO, PRO [19:03:22] hmm [19:03:23] but [19:03:34] the graph shows a lot smaller ranges [19:04:13] mode II is RR facing backwards [19:06:36] well [19:06:52] mostly [19:07:00] yeah I'm not sure [19:07:41] maybe it prevents the P22 logic to try acquiring before that time you load [19:07:54] preventing it to even run into the bug [19:08:16] I should try it without loading those octals [19:08:25] maybe it isn't stuck integrating but will throw the 530 alarm [19:09:44] then it would be related to this bug [19:09:49] just a different workaround [19:10:45] have a good scenario saved, trying it right now [19:11:34] which Luminary didn't have some drama with bugs found late in the game... [19:11:41] just check what Luminary revisions 117 and 118 are [19:11:56] aha [19:12:09] yeah after a while of N38 oscillating it did throw the 530 alarm [19:12:43] interesting [19:13:01] so a more clever workaround than Luminary memo 109 [19:13:33] ohhhh I didn't know Luminary 117 and 118 were implemented as single-module patches [19:13:36] that's very interesting [19:13:44] clearly not flown haha [19:13:47] yeah :D [19:13:50] as they did this procedure [19:13:54] on the actual mission [19:14:58] just inconvenient, but scaling is easy [19:15:06] and converting to octals isn't hard either [19:44:22] sounds like another Marc Youtube series if you get it [19:44:52] haha 100% for sure yeah [20:04:16] that sounds exciting [20:04:39] q [21:55:33] night! [04:48:32] .tell indy91 seems the Apollo 9 maneuver pad is missing VR [14:44:26] good morning [14:50:58] hey [15:39:43] one thing I would like to do with the VC is add cue cards [15:39:49] I tried that in the 2D a while ago [15:40:05] have a click spot where they put the V48 cue card in the CSM [15:40:09] but it's too small [15:40:19] but in the VC you can zoom in [15:40:54] so basically where we already have the velcro patches in the VC, add click spots which switches on/off or cycles through the cue cards they put there [15:41:01] I think that would be quite helpful and immersive [15:42:15] https://history.nasa.gov/afj/ap14fj/pdf/csm_cue-cards.pdf [15:42:17] as an example [15:42:28] it shows the locations, too [15:53:36] oh that would be awesome. i think the pannel textures already have the velcro. [16:21:37] I wonder if a texture is enough [16:21:46] or if that has to be another mesh [16:21:57] I don't really want it to be a bitmap that get's blitted [16:26:32] i think it would look best as a mesh, with a small offset normal to the pannel [16:29:51] could probably be the same meah for every card, just scalled to the right dinensions. [16:35:25] I feel STS's comment in the SPS evasive thread is a bit gatekeeping with the tone, so forgive my retort [16:36:34] Feels borderline gatekeeping [16:41:12] i doubt he was trying to gatekeep, but it could be read that way. [16:42:03] yeah thats why I wanted to clarify [16:42:23] Just seemed a little rude to interject on that thread, and came off a little pompous to me [16:45:22] So again forgive my counter answer :) [16:47:37] i think its worth replying to him, and saying that starting with 7 or 8 can be helpful for beginners, but we want to encourage questions. afterall thats more or less the whole point [16:48:27] particularly the encouraging questions part [16:51:20] Absolutely [16:52:45] Thats kind of what I said [17:28:35] 8 is the best to start I think. You get a somewhat short and easier mission and you can admire the Moon [17:28:54] rcflyinghokie, Apollo 7 and 9 Maneuver PADs for the CSM are nearly identical [17:29:02] just that 9 has the total DV [17:29:04] the DVR [17:29:20] so I was just reusing the Apollo 7 PAD for Apollo 9 MCC [17:29:41] Ah [17:30:45] I could add DVR to it in general [17:30:50] then Apollo 7 also gets that [17:31:06] Couldnt have it's own for more accuracy? [17:31:15] I could make it optional [17:31:36] but that's a bit more work [17:32:20] Then probably adding DVR to both might be the better option [17:33:46] I am seeing more differences [17:34:00] Apollo 9 doesn't have HA and HP [17:35:16] nope lol [17:35:49] and they included a nav check [17:36:48] both have that [17:36:54] but Apollo 9 just says TIG-30 [17:37:03] while Apollo 7 has a TIG to write down [17:37:48] what I should really do is have one function calculating the Maneuver PADs [17:37:56] and only for the MCC format them differently [17:38:07] right now it's different functions for the Apollo 7 and 11 formats [17:46:45] oh, I am not sure if I had tried that before (probably), but when doing P22 on the landing site with the LM there then you can easily see the shadow of the LM [17:46:56] not so much the LM itself, but it's easy to mark on it [17:47:02] Haha yes I saw that when I flew 12 [19:21:06] I wish I had any idea how to handle meshes and textures [19:29:06] Hey guys [19:29:34] Been a while, was on the simulator, going to the moon. Yesterday completed training for Apollo 8 [19:29:49] rcflyinghokie Sorry for the post on O-F [19:29:57] Did´nt want to discourage anyone! [19:36:42] good afternoon [19:39:52] hey Turry [19:41:36] completed training already, nice [19:41:56] Seen a lot of releases since december [19:42:01] I am finally at the point where I can do some Apollo 7 MCC updates that you could have used haha [19:42:11] indy91Now preparing for the second one :D [19:42:29] (second training run) [19:43:15] Apollo 8 MCC is also somewhat out of date [19:43:19] not as bad as Apollo 7 though [19:43:45] For me it went fine... [19:43:46] Is there a quick way to know wich release I have installed on my Orbiter? [19:43:55] I think I am on 17xx something [19:44:11] But don´t know wich one, and I want to know what changed... [19:44:48] I think if you check the Orbiter log it has a build date [19:45:01] for stuff like "ProjectApolloMFD.dll" [19:45:20] Yes, yes there is a way, my modules are from december 17th so i should be on... 1771 [19:45:44] Yes I am on that one, I remember that number [19:46:50] you can safely update I think, there weren't many simulation breaking updates since december [19:47:00] n7275 and rcflyinghokie do you agree? [19:47:03] 000000.000: Module ProjectApolloMFD.dll .. [Build 211217, API 190914] [19:47:04] 000000.000: Module ApolloRTCCMFD.dll ..... [Build 211217, API 190914] [19:47:05] So yeah. 1771. Many noticeable changes since then? I know about the waste dump rate one... [19:47:19] CM and CSM aerodynamics [19:47:30] CM hasn't changed too much [19:47:37] CSM you will hopefully not experience [19:47:52] Aha [19:47:53] oh, FDAI update [19:47:57] looks really nice [19:48:08] Yeah correct [19:48:30] Didn´t saw it yet in person [19:48:46] my ORDEAL init now takes longer because of it [19:48:54] because you can see each degree on the new FDAI [19:48:59] and I want to align it properly :D [19:49:11] Nice :D [19:49:28] Quick question, I flied 7 and the training of 8 with Gravity-Gradient torque off [19:49:37] I read that it should be off... [19:50:07] There is a rare, random chance that it can lead to a CTD [19:50:16] Aha [19:50:24] So, it´s not safe and I am good [19:50:59] some vessels in NASSP that aren't defined in a dll module but only as a config seem to somehow cause it [19:51:10] I think I had it when my S-II impacted the ocean [19:51:20] And now that I see it... Why is my Damage and failure simulation set to off? [19:51:52] Turning that on......... [19:53:17] I'm not sure that does anything right now [19:53:19] it used to [19:53:30] but at the moment at least the failure simulation is in the PAMFD [19:53:36] which has a random failures button [19:53:38] i have always had gravity gradient torque on, and have never noticed a ctd from it. it is a rare but possible bug [19:53:44] I remember it was required for the 13 accident [19:53:53] if i remeber correctly... [19:54:11] Back on NASSP 7 and my younger days... [19:54:50] not seeing GetDamageModel() checked in the NASSP code right now [19:54:54] "which has a random failures button" Let´s hope that Mr. Smith doesn´t mess with it [19:54:59] we have a separate scenario for Apollo 13 with failures [19:55:29] one or two engine failures won't hurt [19:55:35] "Scripted" failures, yeah... I believe it was that way [19:55:55] Something on the works for 12? [19:56:10] (or on the plans) [19:56:53] not really [19:57:05] although you can kind of simulate it by taking the fuel cells off the main buses I guess [20:00:11] are the failures that are implimented through PA mfd done in a way that would be expandable? or is that older hacky code. ive never really look at that much. [20:01:54] I moved it out of the Saturn class to the PAMFD class at some point [20:02:05] ok, TurryBoeing i fixed the slow wastewater dump that my systems update introduced. you have that to look forward to in the new version. [20:02:10] so not too old [20:04:20] the dificulty I see with properly implimenting system failures is that you need a failure mode for every system...and we have more than a few of those [20:05:26] yeah [20:06:29] there is something I discovered a few weeks ago [20:06:32] https://www.hq.nasa.gov/alsj/a410/A07CrewTraining.pdf [20:06:40] check the last few pages [20:08:16] BRB [20:08:34] n7275 Thanks! I knew about that one [20:11:29] ooooooo [20:13:08] a lot of the mission simulator failure modes [20:13:27] the Block I Instructor's Handbook also talks a bunch about failure simulation [20:13:43] but this is of course better [20:17:01] the only hesitancy i have towards more detailed failure simulation, it that i worry about it looking like a bug with a system. we have a massive amount of public members. "what opened this valve, random failure or random bug?" [20:17:29] but there is probably a good way to get around that [20:24:48] Apollo 8 is more generous about lunch and dinner times [20:24:56] As far as I see... [20:25:12] Got it a little bit wrong last year... [20:33:23] that day in lunar orbit will be exhausting, everything else should be managable [20:33:31] Correct [20:33:35] Many naps [20:33:57] But 20 hours of activity on the lunar day [20:34:16] (More than that actually) [20:34:28] that is just lunar orbit yeah [20:34:45] but there is a bunch of hours before with MCC-4 and LOI-1 already [20:35:27] From 67 to 93 [20:35:52] 26 :) [20:36:19] on the real flight Borman at one point made the decision to stop Lovell from doing more P22s [20:36:34] Because he was tired? [20:36:39] yeah [20:36:44] I see that the rotated moreless like in 7 [20:36:56] But in 7 there was the flu... [20:38:37] 082:42:01 Borman: We're scrubbing everything. We'll - I'll stay up and point - keep the spacecraft vertical and take some automatic pictures, but I want Jim and Bill to get some rest. [20:39:08] 082:43:15 Borman (onboard): I want you to get your ass in bed! Right now! No, get to bed! Go to bed! Hurry up! I'm not kidding you, get to bed! [20:40:27] So we know who Santa was [20:40:36] It was Frank Borman [20:51:47] Well guys, going to bed [20:51:52] See you next week! [21:48:23] night! [23:33:08] sorry I have been away I agree with updating should not have any impact on a fresh launch [02:58:09] cd ../ [02:58:36] not again... [16:12:36] hey [16:19:28] morning! [16:20:12] what's up? [16:20:49] I think all parts have been ordered for the rope reader boards, barring design changes [16:21:26] also trying to get firm answers to some CDU questions lol [16:23:03] like what? [16:29:03] well, for one [16:29:13] assuming that for some reason somebody had their hands on a CM CDU [16:29:36] could the 1202 issue be replicated on the IMU channels? i.e. are there any significant between the RR and IMU channels in the LM CDU? [16:31:36] ah right [16:33:50] all goes back to figuring that alarm out :D [16:36:26] I've been trying to find out more about simlators [16:36:40] the mission simulators for Apollo, but also Shuttle [16:36:45] and also the MIT digital simulation [16:37:18] because with digital simulation you get the problem of simulation RCS fire that is as short or even shorter than the simulation interval [16:37:34] Apollo mission simulators ran at 20 Hz [16:38:04] I have that user's guide for the MIT digital simulation, I guess we don't happen to have actual code of it... [16:38:34] unfortunately no [16:39:17] I just found a Shuttle document that seems to deal with this topic of simulating RCS thrust [16:39:43] maybe that can help me a bit [16:40:14] but I will probably need to rewrite the ATCA code a bit to be able to simulating minimum impulses properly at any framerate [16:45:56] that would be great [16:52:37] hey [17:04:00] yo [17:04:54] the other CDU question I need to figure out is how big of a difference ECPs 515 and 609 are going to make [17:18:04] indy91, do you know of any RR / IMU CDU differences offhand? [17:45:45] well there is that read counter to error counter feedback that only ICDUs and OCDUs have but not the RR CDUs [17:46:05] I think we looked at that and concluded it wasn't really a mechanical difference between the CDUs but done with jumpers or so [17:56:52] ohhh right [17:56:56] okay I need to look at that again [17:57:28] probably won't have an impact on the 1202 thing though since that doesn't involve the error counter at all [17:57:48] not in Slew no :D [18:00:57] 110:05:40 Conrad (on-board): 45 minutes, perilune altitude checks, Rendezvous Radar CB (circuit breaker), for the 99th time, they're both open (laughter). [18:01:29] lol [18:01:51] that poor innocent CB that has nothing at all to do with the issue, but got blamed so many times :D [18:03:11] well you wouldn't want to open the ATCA breaker [18:03:43] which would ensure the RR gets no voltage in slew [18:04:03] neither does much of the control electronics [18:04:15] the reference voltage I mean [18:05:04] hahaha yeah [18:05:33] so really RR in LGC or the software fix are the only workarounds... nothing you can do with breakers will help [18:08:49] right [19:17:46] it's astounding how much inaccurate info there is about the whole "1202" thing [19:17:56] it really is isn't it? [19:18:31] even during the missions mission control read up inaccurate workarounds [19:19:03] and it's only gotten worse (much worse...) since then as people have tried to make sense of it and re-explain it.... largely basing their analyses off of other incorrect analyses [19:20:57] when was the correct cause of the issue identified? [19:22:58] George Silver knew immediately [19:23:05] and was fully correct [19:23:16] but it's a complex problem that got lost in translation very quickly [19:24:11] Grumman also replicated it in the FMES laboratory using a CDU and resolver tester box in late July / early August [19:24:22] ahh that makes sense [19:25:31] speeking of George Silver, we still have some lny77 notes to transcribe dont we? [19:25:48] oh you mean his personal notebooks? [19:26:30] yes [19:26:41] yeah. I also need to actually fully scan all of those [19:27:49] i have someone that can type those up for us if you want [19:28:25] awesome [19:28:42] I hope they like hard-to-read cursive :P [19:28:56] thanks! :D [19:29:38] Hello guys [19:30:31] Just updated NASSP (1853) and D3D9 client (30.7 for beta R90) [19:30:59] On the 2D panels I see the 8 balls as white [19:31:11] On the 3D cockpit, they show the new texture correctly [19:34:06] What may I have done wrong? [19:36:42] Hmm [19:36:54] How did you update? [19:37:48] bad NASSP code [19:37:49] https://www.orbiter-forum.com/threads/nassp-8-installation-guide.36801/post-584117 [19:37:59] "So, you must have the "Textures/ProjectApollo" folder both under the Orbiter Beta (for the 2D FDAI only) and under the configured actual Texture directory (for everything else)." [19:38:54] Well, I unzipped into my orbiter directory :P [19:39:47] Reading the post [19:43:10] it's just that the 2D FDAI texture is loaded always from the NASSP install [19:43:28] and not from the specified texture path [19:43:44] mmmm [19:43:56] Don´t quite understand... [19:44:24] I have an Orbiter installation here: [19:44:25] D:\Orbiter 2016 Beta (Apollo)\ [19:44:33] With everything on it [19:44:55] No different texture directory or symbolic link for textures [19:45:11] And so I have: .\Textures\ProjectApollo [19:45:43] And there: FDAI_Ball.dds [19:45:52] and FDAI_Ball_LM.dds [19:46:43] so you just have one Orbiter install [19:47:10] with both e.g. Textures\Earth\Archive [19:47:13] and NASSP [19:47:30] Yeah, one specific "instance" with everything [19:47:41] (I have other Orbiter instances) [19:47:45] "instanced" [19:47:49] right [19:47:54] but also with everything in them [19:47:55] there is an option to disable the FDAI [19:47:58] No symlinks [19:48:11] Orbiter Launchpad, Extras [19:48:18] Project Apollo Configuration [19:48:28] is FDAI disabled there? [19:48:34] Correct [19:49:04] correct as in, that solves it? [19:49:07] you had it disabled? [19:49:23] I had it enabled [19:49:32] Not I disabled and the texture appears [19:49:37] (old one) [19:49:48] *now I [19:50:04] wait when you disable it the texture appears??? [19:50:15] but it doesn't actually work then [19:50:30] it's just the background texture from the panel bitmap, right? [19:52:27] Let me check [19:54:48] Just the texture background texture from the panel bitmap [19:54:53] Correct [19:57:35] Cannot share pictures? [19:58:52] best to use an image host of sorts for IRC [19:59:04] I just usually use dropbox [19:59:06] https://prnt.sc/X6zuS0QSAW24 [19:59:07] https://prnt.sc/KKYAg39m0s4v [19:59:39] well yeah, that is FDAI disabled [19:59:57] because you disabled it. The real problem of course is why it is white when it's enabled [20:00:13] it doesn't find the texture [20:00:21] which usually means it's looking in the wrong place [20:00:36] Maybe something on the log? Let me check... [20:00:50] (yes, I love logs :) ) [20:02:47] Nothing on log [20:02:56] (for missing file or problem loading...) [20:03:17] By the way, did the Cabin Fan or Suit Compressors sound change? [20:03:18] let's look at your Orbiter.cfg [20:03:20] yes [20:03:27] does Orbiter.cfg have a line with [20:03:31] TextureDir [20:03:40] Orbiter_NG.cfg, right? [20:03:44] uhh [20:03:55] yes [20:05:16] https://pastebin.com/9Yr5g5hV [20:05:22] Not finding TextureDir [20:05:44] right, so you aren't using a different folder for them [20:05:59] have you done a complete reinstall? Or just installed the new NASSP [20:06:06] Sounds did change, yes [20:06:49] Just dropped contents of the new zip (NASSP-V8.0-Beta-Orbiter2016-1853.zip) into my Orbiter directory [20:07:06] weird. I don't think the texture name has changed [20:07:14] "Sounds did change, yes" [20:07:15] I hear :) [20:07:27] Dinner, BRB [20:07:32] if something went wrong installing the new NASSP it should find the old texture and not no texture [20:07:56] does dseagrav's autobuild, autobuild if its just a texture commit? [20:08:43] yes [20:10:22] that really was just a change of texture, no code changes or anything related to that [20:11:03] so how can updating that break anything... [20:11:48] some different texture format that needs a different setting somehow... [20:24:20] Maybe I updated wronwgly [20:27:13] But I always dropped the zip contents like that... [20:28:54] very odd [20:30:30] indy91 for some reason i was thinking that all 2d pannel textures needed rebuilds, but thats only yhe bitmap blit stuff [20:30:41] *the [20:33:26] well all pushes trigger auto builds, change in code or not [20:35:41] so definitely something else. [20:36:17] TurryBoeing, this is how it looks, right: https://i.imgur.com/R0lZeYd.png [20:38:48] and the same problem happens in the LM? [20:42:44] Correct, looks like that [20:42:50] Let me check on Spider [20:43:58] on LM works! [20:44:00] :S [20:45:08] that is even weirder :D [20:45:28] do you have smooth scrolling enabled? Does that change anything if you switch that [20:52:55] indy91 https://github.com/orbiternassp/NASSP/pull/745 [20:53:12] https://prnt.sc/di7Zqyye4A1G [20:53:20] Smooth scrolling is disabled [20:54:00] oh that looks nice [20:54:02] Nice picture! [20:54:07] Yeah that's sharp [20:54:10] enhancement for your Apollo 8 mission hehe [20:55:13] TurryBoeing, that it works in the LM is very weird. [20:55:39] is somehow something wrong with the FDAI_Ball.dds file [20:55:40] might be a botched install at this point [20:55:59] I don't see how if it works in the LM [20:56:15] it would have to be a botched auto build at that point [20:57:03] TurryBoeing, CSM and LM texture are the same size? [20:57:53] it's like the CSM texture doesn't exist and everything else works correctly [20:58:52] Let me see the size [21:01:00] FDAI_Ball.dds -> 4.63 MB (4.860.054 bytes) [21:01:03] FDAI_Ball_LM.dds -> 1.5 MB (1.572.918 bytes) [21:01:11] iiiinteresting [21:01:13] they should be the same [21:01:24] did you manually update the texture from the FDAI thread? [21:01:29] FDAI_Ball size 1800*900 px [21:01:48] https://github.com/orbiternassp/NASSP/blob/Orbiter2016/Textures/ProjectApollo/FDAI_Ball.dds [21:02:00] it's not the same filesize as in the current state on Github [21:02:03] FDAI_Ball_LM size 1024*512 [21:02:13] indy91, just pulled his branch it looks good from what i can see [21:02:17] The LTA [21:02:29] that high-res texture doesn't work in the 2D panel, only in the VC, that's why we have two different files [21:02:31] "did you manually update the texture from the FDAI thread?" that is negative [21:02:36] I would encourage a few people to test it of course [21:03:11] TurryBoeing, I just downloaded release 1853 from Github and both files are 1.5MB [21:03:36] did you test the texture a few weeks ago and not overwrite during updating NASSP or something [21:04:18] Nope... [21:04:26] Redownloading the zip [21:04:34] Let´s see... [21:04:44] the VC textures are 4.63MB [21:04:49] they are in the VC folder [21:05:09] and the 2D panel textures are in the main folder [21:05:12] 1.5MB [21:05:33] that's what we release. When I tested the textures before they got into the NASSP releases I had the same issue as you [21:05:38] Wow, you are right! [21:06:18] I don´t know what happened... [21:06:36] Maybe I did put the texture, but I honestly don´t remember doing it [21:06:45] rcflyinghokie, yeah, let's check it in the sim first, but I am sure it's great [21:07:00] I just did on an 8 LV sep [21:07:09] looks so much nicer than the previous one [21:07:29] I put a few reviewers on there to be sure though [21:07:38] TurryBoeing, but then you must have also not allowed it to overwrite during installing release 1853? Weird... [21:08:24] https://prnt.sc/2UYT5C7ygI1l [21:08:29] Well, the it is [21:08:34] *there [21:09:01] "TurryBoeing, but then you must have also not allowed it to overwrite during installing release 1853? Weird..." [21:09:02] Yeah, but the sounds changed [21:09:46] Unexplainable... things of computers :) [21:10:16] let's blame Windows [21:10:50] Ah, another thing I wanted to ask. I saw that now the CSM/LV sep is done by rotating the THC CCW (IIRC) instead of the CSM/LV SEP PB [21:11:00] Just curious, why is that? [21:11:10] As the behaviour is different [21:11:31] both methods work [21:11:35] Apollo 8 did it with the THC [21:11:55] just an update based on the actual Apollo 8 checklist I guess [21:12:04] Aha [21:12:27] Saw it on 9 also (and killed myself on the first try as didn´t expect the CSM behaviour) [21:12:36] what behavior? [21:12:38] (started rotating) [21:12:49] and unexpected +X thrust [21:12:51] that's why you need att hold [21:13:33] Wich dodn´t knew how to stop as I didn´t expect the +X at all :P [21:13:45] THC back to neutral stops it [21:14:10] Correct. But i was destroyed already when I discovered it [21:14:38] The keyboard commands helps there [21:14:49] Got to test NASSP with joystick... [21:15:15] Yeah many methods were experimented with for LV sep [21:15:16] well I think you always separate with SC Mode - CMC and CMC Mode - Auto [21:15:27] so that should prevent the rotation [21:15:28] Initially the THC was used instead of the sequencer button [21:15:47] and it's probably worse, too, because I updated the SM RCS thruster directions a few months ago [21:15:53] sequencer was used as a backup similar to ELS functions [21:16:40] THC is very powerful, can stop Saturn engines, separate from the S-IVB, ullage burn [21:16:43] start event timers.. [21:17:14] Initiate a wild rollercoaster ride.... [21:19:12] 9 used the LV SEP [21:20:16] I have never ridden a rollercoaster [21:20:43] Well guys [21:20:46] Haha bad context then...I was implying a LES abort :) [21:21:17] That could be a real rollercoaster, yeah [21:21:24] Thanks for the help as always [21:21:28] Going to sleep [21:22:20] that was a quick sleep [21:22:31] LOS and AOS :D [21:22:34] See you tomorrow with more questions about Apollo 8 PAD´s and P23´s [21:22:43] ok haha [21:26:19] I would wager your 8 flight will be less intense than 7 ;) [21:27:26] about the THC, the +X does override the thrusters for attitude hold [21:27:46] so it will only be able to do attitude hold after returning it to netural [21:27:48] neutral* [21:28:10] "I would wager your 8 flight will be less intense than 7" Let´s see if I can orbit the moon with one single hand on the wheel for 20 hours [21:28:16] Cya [21:31:15] I need to look at the control logic for that again, doing +X with the THC for longer periods of times will spin you out of control [21:31:28] off to bed for me as well, good night! [21:33:15] night! [17:00:59] hello [17:06:23] morning! [17:40:11] Hey guys [17:40:18] hello! [17:40:26] How is it going? Sky is strange today... [17:41:02] haha going good. strange how? [17:42:13] This southern dust :) [17:42:45] Haze, I believe it´s the translation [17:45:48] Got a question about maneuver PAD´s on Apollo 8 [17:46:14] Ullage time or number of jets are not specified on them [17:46:29] How to determine ullage time and number of jets to use? [17:49:42] hey [17:51:20] Hey indy91 [17:51:31] What color is the sun at your location? [17:51:33] morning! [17:53:22] hey guys [17:53:24] everything is super gray here today, which is a bit unusual for california [17:53:43] normal sunset [17:53:53] but I read that there is a Sahara dust cloud [17:54:05] doesn't quite reach up to Northern Germany though, only south [17:54:23] it's gray and overcast in Maine, and that unfortunately is normal... [17:54:38] in March at leadt [17:54:45] *least [17:54:48] you must be getting quite a bit of that Sahara dust in the atmosphere at the moment, TurryBoeing [17:54:56] Correct [17:55:12] And for this northern part of Spain it´s not normal at all [17:55:25] The sun is white, but the sky is orange [17:55:39] And the lighting conditions are disturbing [17:55:50] Because everything is orangeish [17:56:15] We are breaking up the planet :C [17:57:40] Northwest of spain to be more precise... [17:57:48] 42ºN -8ºW [17:58:04] yeah those dust clouds can reach quite far [17:58:14] I am sure I have seen signs of it [17:58:17] but not today [18:09:16] just reading the chatlog, you had questions? [18:09:31] here is one chart for ullage: https://history.nasa.gov/afj/ap15fj/csmgc/5-10.gif [18:12:40] Yeah correct [18:13:00] Ah didn´t saw that chart... [18:14:16] Knew the SPS vs RCS on the G&c Checklist on the Word Checklists folder [18:14:18] for the SPS there were two fuel and two oxidizer tanks [18:14:32] and when one tank gets empty they start doing ullage [18:14:42] normally LOI-2 already needs ullage [18:14:43] 50 % fuel? [18:14:52] nah, the tanks aren't equal in size I think [18:15:12] It´s based on weight, i see [18:15:16] yeah [18:15:23] Apollo 8 didn't have a LM, didn't need as much propellant for LOI-1 [18:15:37] so LOI-2 is just above the threshold for when you would need ullage [18:15:41] so they didn't do it [18:15:45] so only TEI [18:17:01] So if I weight  35000 lbs and I need 15 fps, I am right on the edge for ullage [18:17:31] Ah, sorry [18:17:53] I would need an 13 seconds 4 jet ullage... [18:18:00] yeah, it's two charts in one [18:18:23] SPS vs RCS and ullage time [18:18:27] yep [18:18:34] for 35000 lbs it's about 12 ft/s for RCS vs SPS [18:19:25] Ullage required if I weight 45500 lbs and 12 fps [18:19:59] And it would be 7 seconds [18:20:06] I i am reading properly [18:20:10] *if [18:20:15] yeah I think normally you then do 2 jets 2x7 seconds [18:20:27] but the fps isn't correct [18:20:48] you have to look at the Vg curve for the ft/s [18:20:56] and the y-axis scales are different [18:21:20] 45500 lbs is the threshold for ullage, above that it's 0 seconds [18:21:45] but DV there is like 6 ft/s for SPS vs. RCS [18:22:10] there is of course a jump in the Vg curve as no ullage is done then [18:22:35] !Vg curve confuses me... [18:22:37] :D [18:23:59] which part? [18:24:25] if I understand correctly [18:25:30] !Vg line tells me, based on CSM weight the DV that I will gain with a 0.5 seconds SPS burn [18:25:37] no [18:25:45] you look at the total DV of the burn [18:25:54] and then decide based on that curve if you use RCS or SPS [18:26:09] for SPS burns that curve is 0.5 seconds of SPS but also the ullage [18:26:18] And based on weithy also right? for SPS vs RCS [18:26:34] well indirectly, based on 0.5 seconds of SPS burn [18:26:35] *weight [18:26:47] if you are very light weight then the ullage is already a significant DV [18:27:08] so the threshold to use the SPS is higher then to get 0.5 seconds of SPS [18:28:30] so the curve is whichever amount of DV you get with ullage plus then 0.5 seconds of SPS [18:28:44] Ahhhh [18:28:47] OK [18:28:53] That makes sense [18:29:11] that's why we added some DV to your Apollo 7 minimum impulse burns [18:29:20] Sure, ligther, more DV gained with ullage [18:29:25] so we get 0.5 seconds of SPS despite doing ullage [18:29:51] We added the DV that i would produce with just the ullage [18:30:08] Ok [18:30:22] So, let´s see... let me think of it [18:30:34] For example [18:31:29] I weight 38000 lbs and... I need 72 fps [18:32:36] haha 72 ft/s is always SPS, not even close [18:32:45] 10 seconds ullage, and !Vg would be 5.5 [18:33:12] Yeah yeah but the ullage time would be that, rught? [18:33:15] *right [18:33:40] yes [18:34:02] this chart is mainly meant for loss-of communication [18:34:13] so if you have to use P37 and then decided to use SPS or RCS [18:34:16] and ullage [18:34:33] actual Apollo 8 TEI was 4 quads 15 seconds [18:34:37] at 45597 lbs [18:34:41] But the ullage is not on apollo 8 PAD´s... [18:34:44] so they didn't stick to that [18:35:33] And then having the ullage time and !Vg you have to modify the P30´s DVX? [18:35:35] there is ullage on the side of the PAD [18:36:00] https://history.nasa.gov/afj/ap08fj/pics/a8teipad.jpg [18:36:18] no you don't need to modify the DVX in P30 [18:36:51] accelerometers start when DSKY blanks at T-35s [18:37:18] aha, so it knows that I am thrusting [18:37:23] before the ignition [18:37:26] whel I +x [18:37:27] and the logic is even so clever to detect if you are doing an ullage burn. Which for short burns updates the fixed burn time [18:38:06] for burns that are shorter than 6 seconds the AGC doesn't have enough time to update the burn time based on actual thrust, versus predicted [18:38:17] So on 7 we added the !Vg because the burn was very short [18:38:21] so it already pre-calculates a time to cut off [18:38:22] I understand [18:38:48] yes, the way I had implemented those burns in the MCC was simply 0.5 seconds with the SPS to calculate the DV [18:38:54] but I didn't include the ullage DV [18:39:06] so we added the ullage DV to get back to 0.5 seconds SPS even if you do ullage [18:39:49] The reason I asked was because on the practise I did of 8 a few weeks ago (finished this saturday) I received no ullage information on the maneuver PAD´s [18:40:24] So I don´t know if that is issue or feature [18:40:45] and wanted to learn to calculate the ullage time to do it right [18:40:51] just me not taking ullage into account when I implemented the MCC [18:41:08] Aha [18:41:15] there is no ullage information yet for Apollo 8 MCC [18:41:30] but you can do what the real mission did, do ullage for only TEI [18:41:32] But I can apply as you showed me [18:41:38] 15 secs [18:41:45] and no need to change the DV in P30 as it's a long burn [18:41:54] or 13 secs? [18:42:01] real mission did 15 [18:42:13] Maybe because it was safer [18:42:14] too much doesn't hurt [18:42:15] yeah [18:42:24] just wasting RCS [18:42:33] And saves risks [18:42:41] Failure is not an option! [18:43:06] So I made a friend that is called P23 [18:43:18] ha friend [18:43:19] But seems that he doesn´t like me [18:43:22] more like foe [18:43:30] but we have been getting more friendly lately [18:43:37] I like him, but he doesn´t like me ;D [18:43:49] so one big upgrade for that is the "new" sextant reticle [18:44:09] Oh! [18:44:36] So when I finish the auto maneuver to look at Earth or Mun with optics [18:44:49] I have a new friend for you [18:44:51] https://www.ibiblio.org/apollo/Documents/E-2448-REV0.pdf [18:44:59] Blue marble on cheese ball moves around a lot [18:45:05] It doesn´t stop moving... [18:45:13] Sometimes if I wait it stops [18:45:33] so i take the chance to complete the P23 succesfully! [18:45:39] P23 starts on PDF page 78 [18:45:43] But sometimes i can´t [18:45:47] Let´s see... [18:46:00] and I found especially PDF page 103 useful [18:46:26] But it´s from the future! we are on 68 :D [18:47:04] this is the earliest version of this document haha [18:47:21] Oh! so Near horizon is north and far horizon is south! [18:47:24] later revisions are a lot more complete and extensive [18:47:25] Eureka! [18:49:42] I'm flying Apollo 12 at the moment, I have tried more P23s this way. I still get inconsistent results, but I haven't bothered to adjust my attitude for marks [18:50:02] Got SCE in AUX? [18:50:09] nah [18:50:20] but I think it's quite possible with the new reticle and these user guides to get good P23 [18:50:22] "What the hell is that?" [18:50:41] don't think anybody has tried to get back home with only P37 and P23 yet using the new methods [18:50:52] Thymo has done a bunch of P23 though and report success [18:50:59] Well, will read this carefully [18:51:00] reported* [18:51:11] Many thanks for this docs [18:51:41] Final question [18:52:14] On Apollo 8 you have to do landmark tracking. I did it without markers [18:52:19] Using imagination [18:52:23] Good results [18:52:43] AGC didn´t get stuck as I reported last year when I was on nassp 7 [18:53:19] but is there a map or document or description of what the 8 crew was supposed to be looking at? [18:53:37] I saw documents but also for '70 or '71 [18:53:53] I wish there was for 8 [18:53:54] https://www.si.edu/object/maps-lunar-landmark-apollo-8:nasm_A19770578001 [18:54:03] maps like this for each landmark [18:54:07] would be nice to have [18:54:33] yeah [18:54:41] Just for launch day right? [18:55:39] launch day? [18:56:01] Yeah on the document it sayd december 21 1968 [18:56:08] That is launch day [18:56:18] yes [18:56:28] different launch days had different target sites [18:56:37] so they probably needed pages like this for each launch day [18:56:43] Pictures taken with some kind of sattelite I suppose... [18:57:04] could be from [18:57:05] https://en.wikipedia.org/wiki/Lunar_Orbiter_program [18:57:18] yeah [18:58:04] I've implemented Earth landmarks in the new format recently [18:58:11] I'll get to lunar landmarks, too [18:58:19] the new format supports elevation data [18:58:28] Yeah, I have seen... [18:58:31] which would be useful for the Moon [18:58:41] most Earth landmarks are on coasts [18:58:59] but something like Mexico City was 2 kilometers below the surface with the old markers [18:59:15] when are you starting your Apollo 8 real-time attempt? [18:59:21] When I was practising this days, as it´s very easy to spot features on the surface on Orbiter 2016, I was like... "Must be that crater..." [18:59:30] So I tracked that crater [18:59:34] And good results [18:59:48] yeah I think if we had these landmark maps for all landmarks it would be quite possible without markers [18:59:49] That is what I meand with "I used imagination" [18:59:59] Definitely [19:00:09] you just need to study the maps a bit and then you can spot all the craters [19:00:59] Houston, Apollo 116, radio check [19:01:01] :D [19:01:35] there is one document [19:02:11] https://web.archive.org/web/20100407234224/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19710002567_1971002567.pdf [19:03:58] might help with learning about the landmarks [19:04:06] Yeah [19:04:18] Could use that one to study the maps [19:04:45] On 7 you provided me a document for the Earth landmarks [19:05:01] Cound you send the URL again, so I bookmark it? [19:05:14] (new PC, formatted and lost it :( ) [19:08:06] https://www.ibiblio.org/apollo/links2.html#FlightData [19:08:17] here you have most of the Apollo 8 flight data file [19:09:01] https://www.ibiblio.org/apollo/Documents/A8-Landmark%20maps+photos-1004.pdf [19:09:15] Wow [19:09:21] Lots of reading [19:09:24] :D [19:09:27] Many thanks [19:10:18] Are there update forms to fill on 8? [19:10:52] yeah look at the link "Apollo 8 Updates" [19:11:24] I don't think we have a nice cleaned up version just for NASSP though [19:12:05] but basically all of the forms in there are the same as in the reformatted Apollo 11 flight plan [19:12:25] when I flew Apollo 8 properly for the first time I printed a lot of Maneuver PADs from it [19:14:26] Oh! Star charts! nice! [19:15:24] But in that document there are no "systems/status/tests" forms like on 7 [19:15:45] They didn´t do that kind of forms as it was already done on 7 right? [19:16:12] I guess so yeah [19:16:20] Good [19:16:57] it could have been written down in the crew log [19:17:03] I was thinking on doeing the pre-sleep checklists (cryo stir, waste dump) and post sleep checklists [19:17:05] but we only have incomplete versions of that [19:17:12] and waste dumps on discretion [19:17:29] I understand [19:24:55] when are you doing your Apollo 8 flight? [19:26:41] I am thinking on may 18 [19:26:52] May 17 is holiday here on Galicia [19:27:13] May 18 would also be good for an Apollo 10 real-time attempt :D [19:27:16] and 16 is monday but want to go to job cause I want to save holidays [19:27:33] Apollo 10 may be on may 2023! [19:27:40] So I take note [19:28:09] Is we get there... ¬¬ [19:28:20] *if [19:28:48] and how much of Apollo 8 have you practiced. Just individual scenarios or (not in real-time) a complete mission [19:29:02] Complete mission from T-4 hours [19:29:12] But in sessions of a few hours [19:29:24] per day [19:29:37] Started on december [19:29:44] finished last saturday [19:29:47] at least that means there isn't something broken with the MCC or so :D [19:29:53] unlike some previous Apollo 8 mission... [19:30:07] Well, but last year it was because I didn´t close orbiter right? :D [19:30:14] Nah I think it is OK [19:30:33] And no stuttering... [19:30:47] Did sessions of 4 hours minimum [19:30:55] Maximum of 12 hours [19:31:30] An no stuttering on the way to the moon, back or on orbit on earth or moon [19:31:46] With the old PC (the one I used for 7) and the new one [19:32:22] So I don´t know if we can confirm that the stuttering was 100% caused by waste particles around the spacecraft [19:33:35] hmm right [19:34:04] there is definitely something making framerates a bit random [19:34:20] I notice it in the 2D panel where I don't get 60 fps at all times [19:34:43] What I have to figure out is how to kill possible boredom on the way back from the moon :D [19:35:40] Dinner [19:35:42] BRB [19:36:43] TurryBoeing I suggest entering P01 while performing a P23 ;) [19:37:27] :P [19:37:46] indy91, you mentioned yesterday that the IMU CDU channels have read counter -> error counter feedback but the RR CDU channels do not. do you have a document that mentions that? I can't find a source -- the schematics all seem to apply that that is the same between ICDU and RCDU [19:39:40] look at the Delco Manual [19:40:16] like Apollo 15 [19:40:37] pages HW-38, HW-41, HW-42 [19:43:53] hmmm [19:45:13] hmmmmmmmmmmmmmm [19:45:14] interesting [19:46:33] are there any other documents or just the Delco books? [19:55:32] Systems Handbooks shows it too [19:56:04] I only know about it because of our previous, cheaty implementations for the ICDUs and OCDUs [19:56:51] error counter content for OCDUs was directly applied to sextant angles and then subtracted [19:57:15] that was all there before me. But when I implemented a CDU class just for the RR I saw that there was no such feedback [19:58:30] hmm, do you know which page of the systems handbook? [19:58:49] sure [19:59:38] I'm looking at LM-8 [19:59:45] PDF page 108 shows ICDU [19:59:48] uhh [19:59:49] 190* [20:00:44] hmm [20:01:39] haha, I guess that shows CDU in general [20:03:29] yeah I don't see a RR CDU section in there [20:05:02] but you can see in there the Delta 2^2 overflow [20:05:11] yeah [20:05:17] it's _DEL2H in the CDU schematics [20:05:27] and in the pulse select logic it needs C_A to do anything [20:05:29] coarse align [20:05:49] which is an input [20:05:59] ohhh and that might not be connected for RR [20:06:03] further left there is [20:06:06] ESS EEC, ISS CA [20:06:12] RR EEC [20:06:16] RR Z and ISS Z [20:06:27] zero, enable error counter, coarse align [20:06:40] and I think there is simply no equivalent to an ICDU coarse align signal [20:07:01] in the RR [20:07:09] for* [20:08:04] so I guess mechanically the RR CDUs is the same [20:08:07] but that just isn't used [20:08:23] hmm [20:09:09] how does that work in the OCDU then [20:09:29] it seems to create the CA signal internally [20:09:52] TVC Enable && Enable Optics Error Counter = CA signal [20:11:12] yeah these signals are ECA and DCA [20:11:30] and there is a backplane jumper just upstream of them called JMPA [20:11:38] that could disconnect them from being generated [20:11:46] suspicious.... so does anything I have show JMPA in the digital mode module... [20:12:15] my code for this is [20:12:20] //Coarse align logic [20:12:21] if (CDUType == 0) [20:12:23] { [20:12:24] CA = (val12[3] == 1); [20:12:25] } [20:12:26] else if (CDUType == 2) [20:12:27] { [20:12:28] CA = (val12[ErrorCounterBit] == 1) && (val12[AltOutBit] != 1); [20:12:29] } [20:12:31] else [20:12:32] { [20:12:33] CA = false; [20:12:34] } [20:12:37] type 0 is ICDU, type 1 is OCDU [20:12:41] type 2 is RR CDU [20:12:56] I forgot I even implemented this for the OCDUs [20:13:10] I was just wondering how our TVC works properly without the feedback [20:13:16] but there is the feedback [20:13:44] just my inferior version compared to the very good, very complex CDU class that ggalfi wrote [20:14:23] rcflyinghokie, I forgot you had a pending checklist PR that just gets bigger and bigger :D [20:14:28] I'll merge that [20:15:44] Back from dinner [20:15:56] Can I ask a controversial question= [20:16:32] of course [20:16:52] On Apollo 7 I kinda simulated the TV transmissions, just for the show, and also because that it was part of the mission :) [20:17:10] What do I do with the TV transmission from the moon? [20:17:27] read Christmas poems? [20:17:40] because: 2022, modern times, Youtube, Internet... political situation right now... [20:17:47] Should I read the bible? [20:18:11] Or should I read the beggining of... The lord of the rings, Jurassic Park... [20:18:13] well I certainly don't mind [20:18:19] Something like that [20:18:21] you could read the AOH but that would be more boring [20:18:27] ahahaha [20:18:46] The thing is that if I read the bible, of course, I could offend people [20:18:47] not Jurassic Park, hadn't been written in 1968 [20:19:03] And if I don´t, I will offend people too... [20:19:05] xD [20:19:25] Another think I could do is just queue the original audio [20:19:31] and that´s it :D [20:19:47] What you think is the best? [20:20:00] I'm not sure, let me think about it [20:20:32] About Apollo 7, were you synchronized with the time of day, so GMT? [20:20:42] Because I seem to have missed all your TV transmissions [20:20:52] but maybe they were targeted for prime time in the US [20:20:54] that would explain it... [20:21:00] Yeah [20:21:29] It was on Christmas´s eve, dinner time [20:21:53] "About Apollo 7, were you synchronized with the time of day, so GMT?" I believe I was using EST [20:22:12] So if for me if it was 3 PM, it would be 3 PM EST [20:22:28] hmm ok [20:22:30] I lifted off at 11:02:45 local time [20:22:36] yeah [20:22:58] My local time was 11:02:45 and I believe EST was also 11:02:45 [20:24:01] EDT* [20:24:20] indy91, found it!! https://i.imgur.com/3udpV81.png [20:24:39] aha! [20:24:54] it is indeed this jumper in the digital mode module that prevents the coarse align inputs to the pulse selection logic from being generated [20:25:22] thanks for the help :D [20:25:32] that explains the "flg_csm" flag in ggalfis code [20:25:47] I am pretty sure we had this figured out and just needed to figure it out again :D [20:25:56] https://github.com/ggalfi/NASSP/blob/agcio/Orbitersdk/samples/ProjectApollo/src_sys/cdu.cpp [20:26:07] hehehe yeah probably [20:26:15] so a jumper in the CSM [20:26:24] and for the RR there is simply no coarse align input [20:26:33] even if you use V41 N72 [20:26:37] so the astronauts are being lied to [20:26:44] yeah [20:27:04] and all of the wiring is still there, even for the coarse align enables and the delta 2 feedback [20:27:12] which is what was throwing me off [20:27:18] it's just this upstream jumper [20:27:32] right [20:27:51] I was just looking at it from the perspective of the difference in behavior [20:28:13] so I didn't have much of a clue of it's a jumper or a different CDU model or so [20:28:22] I'm actually a bit curious if these jumpers are going to be more exposed than other wiring or something, to make changing a CDU from LM to CM more simple [20:28:31] right yeah [20:36:18] yeah I'm definitely going to need to put together a CDU backplane viewer [20:36:43] haha [20:36:51] in your ongoing series of backplane viewers [20:37:51] :D [20:43:47] Well guys [20:44:04] Bed time, as always thanks for the help and patience :) [20:44:22] cya! [20:44:29] Tomorrow or on thursday I will start another run of practise of Apollo 8 [20:44:35] I´ll keep you posted [20:52:14] indy91 thanks ;) [20:52:54] I'm up to the point in Apollo 12 where I need to think about LOPC-2 [20:53:01] and the Photo REFSMMAT [20:53:40] for LOPC-2 I checked our conversation last year, I think they made Descartes the new landing site and calculate the descent planning plane change [20:54:28] and for the time of overflying the site they chose the stereo strip photography, about 10 hours after LOPC-2 [20:54:36] that gives a really good TIG and DV [20:55:07] the Apollo 13 flight plan has a definition for the Photography REFSMMAT and it also talks about the stereo strip photography [20:55:26] it seems to be a landing site REFSMMAT for Apollo 12 [20:55:55] close enough so that I would say it's still for the Apollo 12 landing site, not Descartes [20:56:50] just with a much later time tag, so accounting for Moon rotating [20:57:10] but not 100% sure about that yet. But I am quite sure about LOPC-2 targeting [21:40:43] night! [21:40:49] I think I used a LS when I did it [21:40:52] night! [14:25:16] .tell indy91 few Apollo 9 queestions, first the LM pad loaded weight is about 500 lbs different than actual, would this impact the DAP? And second, I am noticing seemingly high residuals on SPS cutoff (1-3fps in all axes) both with and without a corrected LM weight...any thoughts as to what could be causing it? [15:03:12] hey [15:03:39] morning\ [15:04:21] 32401? [15:04:37] that's the LM mass in the LGC padload [15:04:51] maybe the one in the CMC isn't consistent with that [15:05:18] Thats the mass in the CMC as well [15:05:33] But RTCC shows 31953 [15:05:57] Even with that change I am seeing high residuals [15:06:08] Would the fact that its a 300fps burn make a difference? [15:06:14] (SPS 4 is the case here) [15:07:09] padload seems a bit high [15:07:28] of course with these masses there is also the astronauts [15:07:38] at liftoff the actual mass was 32132 [15:07:47] and the docked DPS burn it was 32500 [15:08:02] RTCC will show the actual [15:08:37] so that should be updated but wouldn't make a big difference [15:09:08] and that is using the Before SPS-4 scenario? [15:09:43] the scenario has the tailoff thrust [15:09:49] in the CMC erasable [15:09:52] so that should be good [15:10:10] long docked SPS burns should have nice and small residuals [15:10:11] This is from a fresh Apollo 9 [15:10:17] RTCC shows 31953 [15:10:37] Yeah the long burns seem fine [15:11:18] 300 ft/s docked is quite long [15:11:30] I can check the scenario if I see anything unusual [15:11:36] Well I was referring to SPS 3 haha [15:11:39] Sure one sec [15:12:07] https://www.dropbox.com/s/1rclmgukng4v4yu/10_minutes_before_SPS-4_.scn?dl=0 [15:12:30] I think thats the one shared with me I was able to replicate the residuals [15:17:30] I'll try it [15:21:27] did you perform ullage? [15:22:19] yes [15:22:49] 4 jet 18s [15:25:41] right [15:25:50] got some residuals, not huge [15:25:57] +1.6 in Y, +1.3 in Z [15:26:10] I just saw in the mission report that the actual mission got even higher ones [15:26:40] Ahh ok so expected [15:27:03] even same sign [15:27:13] I bet it's the ullage and the attitude excursion caused by it [15:27:24] that's actually what I was looking at, because it seems quite strong [15:27:40] like, direct ullage (or using the THC during S-IVB separation) [15:27:49] that disables pitch and yaw attitude hold [15:28:01] and if you let it do ullage that way for a few seconds it builds up a large rate [15:28:07] because of the CG location mostly [15:28:35] and everything I have read about it seems to suggest we get realistic behavior. But I have still some more reading and calculating to do [15:28:58] Sounds good [15:29:10] ah the mission report supplement for GNC talk about SPS-4 [15:29:15] Also, that 500lb discrepancy in LM mass, is that a cause for concern? [15:30:00] "No external torques were apparent in any of the periods of attitude hold investigated except the torque due to the cg offsets during the ullages. The effect of the 20 second 4-jet +X ullage prior to burn 4 is seen in these figures. The cg offset in pitch which was present during this ullage was about 3.4 inches and resulted in a pitch disturbing acceleration of about 0.024 deg/sec2 forcing the pitch phase plane trajectory to an attitude error of [15:30:02] about -0.62 degrees." [15:30:18] oh wow [15:31:13] and docked TVC DAP is kind of slow to correct that [15:31:22] maybe that's why the residuals are larger for this particular burn [15:31:29] and even worse than we get it [15:32:07] I already had a debug string open for investigating this [15:32:23] I am seeing 0.02°/s^2 pitch angular acceleration [15:32:26] when doing 4 jet ullage [15:33:12] which is still really small compared to CSM alone [15:33:41] 500 lbs difference will make a bit of a difference, but not a lot [15:33:58] it's longer than a six second burn, so for cutoff it takes actual acceleration into account [15:34:02] not predicted with total mass [15:38:13] yeah so residuals were 0.2, 3.9, 2.7 for the actual burn [15:38:35] and it must be the fairly short burn connected with the attitude error caused by ullage at ignition [15:40:27] largest residuals of that mission [15:40:39] except for SPS-5 which had some unique circumstances, haven't finished reading [15:40:57] Well that makes me feel better that the residuals were on par, I hadn't gone to the MR yet to see haha [15:42:41] Was just reading the right supplement to the MR for the ullage thing haha [15:43:15] https://www.ibiblio.org/apollo/Documents/19750064219.pdf [15:44:11] Thats what i am reading now haha [15:44:37] Interesting SPS 5 excursion [15:48:13] I wonder if Comanche would perform better [15:48:29] there were quite a bit of changes to the TVC DAP after Apollo 9 [15:49:32] yeah even for us SPS-5 might be worse now than before [15:50:03] although a big part seems to have been LM propellant slosh [15:53:26] Thats interesting, even with full tanks I guess there was free space for prop to move around [15:53:39] And of course no He bladders [15:54:03] well for SPS-5 the tanks in the LM weren't full anymore, that's after the docked DPS burn [15:54:11] Ahh yes true [15:54:21] Lots of space to slosh even with He pressure [15:54:33] yeah I guess so [15:54:52] so if you do +X translation with the CSM only [15:55:06] you get -0.16°/s^2 pitch angular acceleration [15:55:11] with a heavy CSM [15:55:46] so if you override attitude hold with direct ullage or separation ullage you already have 1.6°/s after 10 seconds [15:56:09] but it seems like that is correct [15:56:32] The CSM Data Book only shows numbers for vehicle configurations that happen during the actual missions sadly [15:56:49] so it shows the moments induced by +X translation for heavy CSM+LM [15:57:08] and then CSM alone with weights from before and after TEI basically [15:57:32] but they roughly fit with what I am calculating what we are getting [15:57:35] and can confirm in the sim [15:57:53] for a middle heavy CSM the rate is lower because of a more centered CG [15:58:04] but then with the CSM getting quite light it gets worse and worse haha [15:58:16] up to -0.3°/s^2 [15:58:45] in yaw it switch from +0.1 with a heavy CSM to -0.1 with a very light CSM [16:03:53] With a heavy or light LM [16:04:19] all that is CSM only [16:04:22] 4 jets +X [16:04:53] for Apollo 9 SPS-4 it said 0.024 deg/sec2 in pitch in the Mission Report supplement [16:05:01] that is of course docked [16:05:06] and I saw 0.02, so that lines up [16:05:44] Hmm I need to find it I thought I read all CSM alone ullage burns were 2 yet [16:05:46] for 9 [16:06:14] I was doing a general analysis of what happens with 4 jets +X, not any particular maneuver [16:07:58] because Turry mentioned he spun out of control because he didn't know about the behavior with the separation ullage using the THC [16:08:44] ahh [16:10:30] Ah "Ullage Management: In general docked SPS burns requiring ullage will be preceded by a four-jet ullage; undocked SPS burns by a two-jet ullage. Two jet ullage will be used whenever necessary to improve SM-RCS propellant capability." [16:10:33] Mission rules [16:11:14] yeah, there were definitely CSM alone 4 jet ullage burns, but you don't really need them, 2 jets are enough [16:12:35] And 2 jet CSM/LM ullage burns like LOI2 on 10/11 [16:13:45] ah true [16:15:10] Wonder why they went for 2 jet there [16:15:27] Balancing RCS propellant maybe? [16:16:02] Or could it have helped mitigate a light CSM/heavy LM wrt transients [16:16:40] balancing RCS makes sense [16:19:28] and of course I find a heated argument about 2 vs 4 jets in the Apollo 7 transcript [16:20:00] Heated argument and Apollo 7...why am i not surprised ;) [16:20:38] they didn't want to do 2 jet ullage on the SPS-3 done with the SCS [16:20:43] Interesting in Apollo 11's mission rules, that statement from 9 is slightly different "Ullage management: In general, SPS burns requiring ullage will be preceded by a two-jet ullage" [16:23:18] I wonder what the problem is with 2 jet ullage and SCS [16:23:35] I wonder if they didnt like the idea of having some of the auto rcs jets off [16:23:45] Which would be necessary for a 2 jet ullage in SCS [16:23:52] ah true [16:24:07] Capcom mentions a different method, pulling one breaker [16:24:20] pitch main A [16:24:22] Yep and you could put it back in [16:24:49] yeah, that will have been it, disabling those thrusters [16:24:50] This technique was used later for CM RCS ring tests I think on 16 or 17? [16:26:46] but yeah that's definitely easier than switching on two Auto RCS jets while the SPS is already burning [16:27:20] or right before ignition or so [16:27:27] yeah absolutely [16:31:54] if I don't do ullage I am not getting any better residuals on that Apollo 9 SPS-4 burn [16:32:13] tiny bit better [16:32:29] it's probably the CG shifting and TVC DAP being slow to adjust [16:33:02] I find it encouraging that the sign of the residuals is the same as on the actual mission [16:33:09] I think they were getting the exact same effects [16:37:56] that is certainly a good sign [16:52:55] because it's not like a burn with a light CSM only. There I would call the residuals mostly random [16:53:05] but here you can see the attitude errors build up on the FDAI [16:54:39] curious what impact adding slosh would have if we could model it properly [17:02:33] we have good sources for it [17:02:53] we can't directly apply moments, but with a bit of AddForce trickery we could simulate extra moments [17:25:24] morning! [17:40:00] these arrived yesterday :D https://i.imgur.com/PozYXYs.png [17:41:27] yay, that looks great [17:42:58] lots of soldering in the days ahead lol [17:45:23] I bet [18:04:38] I wish I could help! I quite enjoy it [18:34:06] i can work something up in matlab for the model i'm thinking of [18:52:52] Hey hey [18:53:12] Good afternon [18:53:18] afternoon* [19:25:05] How is it going? [19:32:21] hey [19:32:28] going good over here :) [19:32:32] how's the sky today? [19:36:07] Today it´s fixed [19:36:29] But they said that it was going to be worse than yesterday... [19:38:42] *worser [19:39:09] huh, weird [20:07:26] hey Turry [20:17:44] Weird mountain weather here...it was 50 yesterday, 45 today and between tonight and friday we are due for a foot of snow [20:24:56] Hey indy91 [20:25:19] Snow? is that cold? rcflyinghokie [20:25:31] Nver saw proper snow in my life :D [20:25:34] Is snow cold? [20:25:39] Haha [20:25:41] Or is it very hot? [20:25:56] Well snow is cold [20:26:34] But just weird to have 50 and sunny then in the 20s and a snowstorm back to back days [20:26:55] I also live in the mountains at about 10000ft [20:31:32] snow is first cold, and then you feel nothing [20:31:43] when it starts feeling hot you are close to death [20:38:02] And when you feel nothing, your skin color changes [20:38:37] to red yes [20:40:51] hmm have any changes been made lately that would impact the SPS line temperature? [20:41:09] I have had a lot of people report high temps, and my Apollo 10 flight post LOI2 has about 120F [20:42:06] I just put on the heaters because mine is below the scale cold [20:42:34] so for me it behaves like usual [20:43:17] I used heaters for my MCC but thats the last time [20:43:39] I'll keep an eye on it further [20:45:49] yeah [20:48:19] Updating now to 1855 [20:48:32] And tomorrow I will practise the prelaunch [20:48:40] (T-4 to T-60 seconds) [20:48:55] *-4 hours to T-60 seconds [20:49:11] Want to give another practise run to Apollo 8 [20:49:49] Shouldn't be any surprises there [20:49:55] Yep [20:50:07] Well, last time I practised was withour Gravity gradient [20:50:20] And Apollo 7 I am afraid that I did with that off... [20:50:33] Shouldnt have much impact on prelaunch [20:50:35] Got the sleep cycles and lunch and dinner times [20:50:57] Lunch and dinner times are very regular on apollo 8 [20:51:02] Even on lunar day [20:51:32] That could be said for sleep times too [20:51:46] And I think that on 9 they are even more regular [20:51:52] correct me if wrong [20:51:54] They slept in shifts on 8 [20:52:03] As in 7 [20:52:16] Yeah, starting with 9 I believe they removed that requirement [20:52:17] But as I saw they are more friendly times [20:55:25] Well guys [20:55:30] Bed time [20:55:38] See you! [20:55:43] good night! [20:56:24] night! [21:01:16] indy91 in that SPS 4 what kind of residuals did you see in dvx? [21:03:51] basically nothing [21:03:57] 0.2 or 0.3 [21:07:27] He keeps getting like -2 [21:07:30] 2.0 [21:07:36] Trying to figure out why [21:08:04] You did the 18 second 4 jet ullage and both banks? [21:08:30] I am getting -0.7 to -1.2 on my attempts [21:09:23] the DV that you get after cutoff signal is sadly a little bit dependent on framerate and/or time acceleration [21:09:34] but I've only really noticed it with e.g. TEI cutoff [21:09:39] Hmm well my framerate is pretty solid [21:11:30] I did the ullage and both banks, yes [21:11:35] second attempt without ullage [21:12:32] Got 0.5 that time [21:12:50] Thinking its his computer then [21:13:03] I get 48-51 fps cycling back and forth during that burn [21:14:08] and it's going to be somewhat random, like the exact moment you start the ullage will have an influence [21:14:16] just got -0.5 +1.5 +1.1 [21:14:38] good that I saved at T-40s :D [21:15:19] Ahh ok [21:15:26] Yeah same here about T-50s [21:15:37] looks like yours is fluctuating as much as mine [21:16:32] started ullage 3 seconds late that time [21:16:36] did it again on time [21:16:40] -0.2 +2.4 +1.2 [21:19:47] are you supposed to null residuals? [21:20:28] no [21:20:47] only rendezvous and deorbit burns [21:20:59] the crew is talking more about the unusual SPS-5 in the debriefing [21:21:44] "We ended up with residuals of plus 1.9 in X, plus 11.1 in Y, and plus 3.4 in Z, with a DELTA-V counter reading of 9.9. The resulting orbit was 129.6 by 127.7, I think. This was the greatest excursion that we saw in any of the burns during the mission, and we had expected it." [21:21:47] yeah I am thinking its either his framerate or not ullaging correctly causing it [21:21:59] " We had seen in simulations that this particular 40-second burn with the LM configuration attached always ended up with a fairly large dispersion in Y; sure enough, we got this predicted 11 ft/sec. We did not clean it up by burning out the residuals; this was not included in the flight plan, and we ended up with somewhat of a noncircular orbit for rendezvous." [21:22:26] so not even for that one they nulled the residuals [21:23:40] Looking at the residual chart, nope [21:24:04] SPS5 had a total residual magnitude of 11.7 [21:24:46] only SPS burn trimmed was 8 [21:24:59] yeah deorbit [21:25:39] there is a Tindallgram about "why do we have this complicated chart update if we can just null the deorbit burn residuals" [21:26:07] it's not like you are wasting SM RCS propellant :D [21:30:08] Haha at that point seriously [21:44:26] good night! [14:52:28] good morning [14:55:09] hey [15:03:25] trying to analyse the Apollo 12 photography REFSMMAT [15:03:45] it's definitely not a normal landing site REFSMMAT using the original landing site [15:04:21] it seems to be in-plane [15:05:04] it fits best 2 orbits after LOPC-2 [15:05:31] basically if you calculate the latitude when you are crossing the longitude of the original landing site [15:05:40] and then use that as latitude to calculate the LS REFSMMAT [15:09:00] so kind of a "landing site" that best suits the targeted photography? [15:10:27] yeah and is in-plane, even though you aren't in plane with the landing site anymore after hours of coasting and LOPC-2 [15:12:30] you could also do it with the LVLH REFSMMAT [15:12:52] but then you need to find the time when you cross 90° east of the landing site [15:14:32] or quite possibly they already decided to just uplink the REFSMMAT they had worked out before the mission [15:14:43] it's listed in the operational attitude sequence document [15:14:50] what they* [15:14:59] that* [15:45:51] we could use a few more VC view positions for photography [16:31:52] morning! [16:50:28] hey Mike! [16:50:37] what's up? [17:10:50] not too much. work keeps eating up too much of my time [17:11:40] yeah I feel that [17:14:56] indy91 did you try the REFSMMAT from the SCOT or that other doc and see if it gave you good results? [17:20:36] hey Mike [17:20:47] oh the SCOT also has that REFSMMAT? I must have missed that [17:21:54] maybe I am looking at the wrong revision, but I am seeing everything REFSMMAT except the photography one [17:21:59] every* [17:23:52] and I didn't try to uplink it, but I compared it with the uplink page [17:23:59] when I had calculated it on my own [17:41:27] Ahh I didnt look to see if that one was in there [17:41:35] I incorrectly assumed lol [17:49:06] well normally it would be in there [17:49:13] it must have been a late addition to the mission [17:50:50] makes sense [17:52:07] have I ever mentioned that the GUIDO displays make no sense [17:52:20] there is like 3 displays that sound like they are useful for landmark tracking [17:52:30] but they don't actually provide numbers that are on that PAD [17:52:49] like the T2 time, when you are at 35° elevation [17:53:02] I recently found the one display that can actually calculate that [17:53:11] and that is the star sighting display... [17:53:28] because the star sighting display "obviously" has a landmark option [17:54:37] actually it's not so much for the GUIDO but someone called "flight plan support". Which is not one of the MOCR audio loops, I just can him hear faintly in the background sometimes making calculation requests [17:54:51] and he definitely made a request for Apollo 11 landmark tracking [17:55:40] maybe they had more info in the back room? [17:55:54] or used other displays [17:56:36] yeah the main flight controllers were mostly involved in looking at the data and monitoring the landmark tracking [17:56:54] flight plan support seems to have been responsible to generate a bunch of data for stuff like P22, P23 and P52s [18:00:46] at least in the RTCC they didn't have better displays, I am sure [18:00:52] but the RTACF had some good ones [18:02:13] for all this photography stuff I could use a time of closest approach. The real displays are useful for that, although to enter a landmark I have to use a MED from hell... I haven't added a simpler method yet :D [18:05:50] hahaha [18:07:37] oh it gets better, I just successfully put a landmark in the table. Just to remember I had implemented the calculation for the landmark acquisition display [18:07:45] but never implemented that display itself for the MFD [18:14:14] I better do that right now then [19:20:21] Hey guys [19:21:05] Apollo 116 at T- 2 hours 48 minutes [19:21:14] https://prnt.sc/Ii006ZYpYoeu [19:22:36] Needles missing for Suit temp and cabin pressure [19:22:59] Maybe the setting for fixing that changed when I updated D3D9 client the other day? [19:23:18] could be, I think it's the absolute animation handling [19:24:35] About the relief on launch I reported months ago, I think I believe why it may be... [19:24:58] I let the LM/CSM DP indicator in LM/CSM... [19:26:02] https://prnt.sc/v4-o8iiIA2sy [19:26:14] This time I am leaving it off, let´s see what happens [19:28:44] LM/CSM setting shouldn't leak [19:29:23] Yeah, it´s just an indicator [19:29:30] But as there is no LM... [19:29:38] I am leaving it off [19:29:48] But let´s see... [19:37:00] It was left in dP normally even with no LM attached [19:37:40] Cabin relief is just not relieving fast enough right now partially due to substance changes...it will be fixed [19:37:55] Has nothing to do with the dP valve (though you should have the waste stowage valve open) [19:42:54] So, do I set LM Tunnel Vent to LM/CM DP ? [19:44:24] BRB [19:44:39] You can leave it in either [19:44:48] Apollo 9 had it OFF in boost, where Apollo 11 had it in dP [19:45:55] While I cannot speak for Apollo 10, looks like every mission 11 and on had it in dP during boost [19:49:38] It wont impact anything other than the gauge display [19:53:38] soon: https://i.imgur.com/KOZ600V.png [20:01:05] Alejandro will love that one, indy91 [20:01:27] (Didnñt manage to convince him to try NASSP 7, he is still on 6) [20:01:30] :P [20:01:37] *Didn´t [20:02:15] rcflyinghokie1And you don´t know if 7 or 8 had it on DP or OFF? [20:02:32] For me, it´logical to have it off, as there is no LM. [20:02:33] it doesn't matter as long as you don't have it in vent [20:02:57] I don't see why Apollo 7 and 8 needed to use it so I would expect it to stay in off for the whole mission [20:03:23] Then in orbit if on DP i have to remember to set it to off as I will get an O2 flow high light [20:03:32] As I posted around december.. [20:03:33] we do have Apollo 7 prelaunch procedures now [20:03:46] On the Checklist MFD? [20:03:57] mostly no [20:04:04] I am using the word checklist  for prelaunch, boost and insertion.... [20:04:17] but some documents that can be used to improve our checklists [20:04:31] It´s just me, but I feel confier with those... [20:05:35] haha [20:05:41] I am seeing it in "vent" [20:05:50] at the beginning of Apollo 7 backup crew closeout procedures [20:06:35] Interesting [20:06:46] on 7 and 8 the front is sealed off somehow, right? [20:06:54] So having that in vent might not even do anything bad [20:07:08] in the real spacecraft [20:07:10] Ugh this storm is really messing with my internet [20:07:35] Yeah... [20:07:41] TurryBoeing, LM on or off really didnt matter, Apollo 9 flew with it off and it carried a LM afterall [20:07:56] But I would fathom that 7 and 8 flew with it off as well [20:08:06] Aha [20:08:29] 10 is unknown, but 11-17 all had it in dP for launch [20:09:13] And so I understand, and for my knowledge... [20:09:40] Is the "O2 flow hi" light really dangerous? What doest it indicate? [20:10:08] it's the most common light you will get [20:10:10] Quick consumption of Cryo O2 tanks? [20:10:12] in NASSP and on actual missions [20:10:30] Yeah, that is also why I ask... [20:10:42] Cause it´s red and yeah, it´s common [20:10:46] just O2 flowing quickly into the suit loop? I know it's not working in exactly the correct way in NASSP [20:11:00] you will get it when configuring the ECS for orbit, that's normal [20:11:07] Aha [20:11:25] And... is it bad if it´s on for... let´s say 2 hours? [20:11:28] Mr. Disconnect here is the expert on it [20:11:36] What can happen? [20:11:37] yeah 2 hours would be unusual [20:11:42] wasting O2 [20:12:08] if you have Direct O2 on it will stay in O2 flow high forever [20:12:15] But could it mess the CM atmosphere, as to cause Hyperoxia or something? [20:12:30] potentially [20:12:45] So, red is the correct color :) [20:12:48] It´s bad [20:12:50] if Direct O2 is off and you still get O2 flow high for long periods then something is configured wrong [20:12:58] But can trigger easily [20:13:19] I think the bigger danger is that there is a leak [20:13:29] (Apollo 13) [20:13:50] well in the suit loop or wherever the sensor is for the O2 flow high [20:14:11] I see [20:14:16] There is a lot of safety features when it comes to the cabin [20:14:36] multiple emergency systems that kick in when the cabin pressure gets too low [20:14:42] Of course, it´s the most complex and safer plane ever built [20:14:51] and in the normal configuration it should also prevent pressure from becoming too high [20:14:58] (remember than the shuttle is yet on the drawing board) [20:15:01] some relief valves [20:15:04] And there is no Airbus [20:15:05] :D [20:15:35] and Boeing was still an engineering company and not accounting [20:16:09] Just lost the FDAI 1 "crosshair" [20:16:23] did you enable absolute animation handling? [20:16:32] Definitely my D3D9 config should have been reverted to defaults [20:16:46] Checking it in 7 minutes [20:18:22] LOS/AOS [20:18:25] :D [20:18:39] Does somebody know if Soyuz will launch tomorrow? [20:21:47] probably? All russian crew anyway [20:23:23] And SLS is going to roll out!! [20:24:19] that's why I posted that picture earlier :P [20:24:34] Yeah :D [20:24:37] old screenshot, that's a NASSP feature that is very old and has been barely kept alive [20:24:57] From NASSP 6 IIRC [20:25:02] or 7? [20:25:17] NASSP 6 should have it [20:26:33] Absolute animation handling was Disabled [20:26:54] yeah enabling it fixes animations [20:27:30] The O2 press, H2 press indicators on the VC are still misscallibrated [20:27:48] yep [20:28:27] it would be an easy quick and dirty fix, but there is a better, general solution which Alex didn't have time yet to implement [20:28:32] If you know that on the 2D panel they are correct, not a big deal [20:29:04] You don´t have to be looking at them all the time [20:30:41] Well guys [20:30:50] Tomorrow it´s friday [20:31:12] the day that bosses want to release things or put changes in production :D [20:31:19] Cya [20:46:51] indy91, I'm working on recovering some more 7090/4 code off of a tape image I found. interestingly enough, the guy that's helping me said that the tape is actually from a IBM 7094 emulator that ran on a Univac 1108. [20:58:53] if that's the case it would make some sense of our strange exponent, potentially [21:00:53] Mr Disconnect is back [21:01:19] So right now the current ECS implementation totalizes the wrong o2 flows so it actually comes on sometimes when it shouldnt [21:01:31] However you should not have it on for 2 hours [21:01:51] Ah he left, to be continued [21:09:42] n7275, you can emulate a 7094 on an Univac 1108??? [21:09:55] I would have put them in the same ballpark in terms of "power" [21:10:07] maybe it's not in real-time [21:10:29] rcflyinghokie2, yeah I think that just has to be some wrong ECS configuration, Direct O2 would be the common one [21:11:40] Yeah indeed, or a vent valve not in the correct postinsertion state [21:18:29] I think one S in SLS stands for senate. The other seems to stand for "shy" [21:20:08] Ive heard other people say this as well, maybe I just missed the punchline but I have not heard this [21:21:45] Senate Launch System. it's because the requirements for the SLS were written in such a way to optimize it as a jobs program. So only really your senate wanted it like this. [21:21:56] at least that's the joke :D [21:28:03] Ahh [21:28:28] I just hadnt heard it I guess [21:34:43] for Apollo 10's first P22, did you skip F-1 on purpose? [21:34:57] around 82:27 [21:35:01] I got B-1's pad [21:35:57] hmm [21:37:31] F-1 first, 3 minutes wait, B-1, 3 minutes wait, map update [21:38:12] so there should have been a PAD for F-1 [21:38:37] could you have just missed it? You can safely go back to the previous MCC state [21:40:24] 82:27 is when the tracking actually happens [21:40:41] the PADs would have come 1.5 hours earlier [21:41:37] Yeah I could have let me check [21:42:40] I was trying to screenshot them all so easily could have [21:43:02] yeah they come in rapid succession [21:43:12] 3 minutes time to write them down then the next thing comes [21:43:42] Indeed I did [21:44:33] Now to juggle these and the LM activation checks [21:45:02] yeah that's always fun [21:45:10] at least LM housekeeping isn't time critical [21:45:18] so you can do things too early or too late [21:47:53] Exactly [21:48:59] we do have the MCCPreAdvisoryData.log file [21:49:08] which writes all the MCC PADs to a file [21:49:22] I implemented that when people kept on missing time critical PADs :P [21:51:05] only works when "PAD auto show" is enabled [21:51:15] why ever you would want to disable that :D [21:53:42] Haha no idea [21:53:52] SLS is moving :D [21:56:21] plumbing first [21:58:31] is there any way to make the checklist MFD move a little faster? [21:58:37] When in auto [22:01:05] just tracked down the code for it [22:01:14] it seems to be hardcoded, but all in one function [22:01:45] so we can change it or customize it [22:02:19] ChecklistItem::getAutoexecuteSlowDelay [22:02:53] I would definitely support a faster (or even configurable) auto checklist :D [22:03:08] if it does flip a switch it takes 4 seconds between each step [22:03:20] if it's already in the right position it is 2 seconds [22:04:05] on DSKY and DEDA it "types" faster, 1 per second [22:09:44] Any way to change some of that? [22:10:30] yeah [22:10:51] do we want to customize or simply set the 4 second delays to 2 seconds? [22:11:20] I think thats a good place to start [22:11:51] you can change and test it if you want [22:12:04] checklistControllerHelpers.cpp [22:12:06] Yeah absolutely [22:12:13] ChecklistItem::getAutoexecuteSlowDelay [22:13:01] so the DSKY and DEDA stuff, I if "dskyIndex" is 0 that's the first button in a sequence of DSKY inputs [22:13:07] for that it waits 4 seconds "return 4" [22:13:12] the next buttons only 1 [22:13:35] if (position == -1) that is for things that aren't actually switches [22:13:39] like text [22:13:47] or EMS DV counter [22:13:56] if (conn->GetState(item) == position) [22:14:05] that is when the switch is already in the right position [22:14:14] so then it only takes 2 seconds [22:14:26] and the general case is the 4 second wait, the last "return 4" in that function [22:14:31] so that's how it works right now [22:14:34] now, be creative :D [22:15:16] there also is this option to not have any delay, right? [22:15:23] that just sets everything instantly [22:15:33] Yeah, the demonstration option [22:15:35] probably not a great way [22:15:48] Which I think we need to get rid of the option to turn it off anyways [22:15:56] instant does nothing good imo [22:16:08] yeah [22:16:38] it could be useful still for automating things [22:16:44] ah true [22:16:55] but not for going through the checklist normally, even if automatically [22:18:54] oh no no [22:19:44] oh this is much better [22:20:47] I guess we can never go back [22:20:51] still slow enough to read when already set [22:21:20] did you change that, too? [22:21:24] or only the 4 seconds [22:21:50] I changed them both [22:21:55] 4 to 2 and 2 to 1 [22:22:36] don't underestimate the auto checklist in first learning where switches are [22:22:49] for us it feels so slow, but not necessarily for beginners [22:22:58] so I am all in favor to changing 4 to 2 [22:23:00] which is why auto should be off and flash on for that [22:23:04] true [22:23:18] yeah I guess if you want to learn it auto checklist is mostly wrong [22:23:30] yes yes [22:24:42] ok, I am happy. I saw SLS moving. Might still be moving when I wake up. [22:25:03] Haha to be honest I was more excited to see the crawler itself [22:25:09] my experience as a complete beginner is that it was painfully slow watching the flash move from breaker to breaker on large checklists, when most of them were already set and I was waiting for it to stop on one I actually had to change. especially since I was usually running late on time [22:25:23] let's see what the others say about the auto checklis... ah already someone is saying :D [22:25:27] Yeah agreed Mike, I think this change will also help that as well [22:25:37] I have had this feedback from a few people [22:25:41] that makes me think [22:25:58] it's definitely veeeery slow when it comes to LM circuit breaker checks [22:26:11] but at other times the checklist items jump around in the cockpit [22:26:40] I wonder if we should try and implement a custom delay for checklist groups [22:26:44] is it easy to access what panel the switch is on from this code? [22:26:45] optionally [22:26:49] we could delay a bit longer if the panel changes [22:27:31] hmm it's kind of optional to tell it on which panel a switch is [22:27:43] and it's can't access that in the code really [22:27:56] boo [22:27:59] but there are checklist groups that are CB checks only [22:28:05] or stuff like that [22:28:15] maybe we could make that whole checklist group faster or so [22:28:51] in the hierarchy of switches we only really have switch row and then switches [22:29:03] switch rows are useful for bitmap, because they are located next to each other [22:29:07] easier code wise [22:29:29] when I was looking into improving performance I thought of organizing it per panel [22:29:34] but right now that's difficult [22:30:33] hmm [22:30:56] in the checklist file you can tell it the panel, but that is just so that it displays the number [22:31:11] but we could implement a check if that is different from the last panel [22:31:26] and if there are no panel numbers in the checklist file given it just advances fast [22:32:05] but that are some ideas for the future, we can make it a bit faster in general now [22:33:21] Auditing the checklist files with proper panel numbers would be a task [22:33:44] yeah. But it could just default to fast speed [22:33:58] and if it sees a panel change it could be slower [22:34:45] Yeah that wouldnt be a bad idea [22:36:00] sounds like something worth looking into. Good night! [23:08:41] .tell indy91 before I forget, are landmarks such as F-1/B-1 in the marker files? [14:10:21] hi Ryan [14:12:40] morning [14:16:05] This LM thermal data Mike shared is incredible, I think I can get the LM to heat more accurately [14:16:25] The only thing I need to figure out is how to keep the LM cabin more stable when unmanned [14:25:47] what causes instability when it is unmaned? [14:30:38] .ask indy91, do we have a copy of: J. A. Herbaugh, "Apollo Trajectory Design Program, " TRW No. 3832-H001-TU000, 11 December 1965. [14:57:10] Well it seems to just get really cold [14:57:26] But if I insulate it more, it gets too hot with a crew/lights on [15:10:36] hmm. [15:12:06] and I take it cooling off like this with no crew is in direct contradiction to documentation [15:14:23] maybe this is related to how the systems SDK does directions. it assumes everything is a flat plate with a direction. maybe we need a few different modes. omnidirection, cadtoid, etc [15:21:36] hey [15:22:25] rcflyinghokie, yes they are in our old style lunar markers [15:22:53] But they arent in the current version of NASSP [15:23:39] right we have the flag set in the Moon config file to use the new markers [15:24:42] n7275, sadly no [15:24:55] the user manual is listed in the restricted NTRS list [15:25:08] but not available [15:25:58] speaking of NTRS [15:26:18] either they have server problems or they got rid of everything that reminds them that the SLS isn't their best and tallest rocket yet [15:26:34] nothing RTCC related is there anymore [15:26:45] and it was already reduced from the pre 2013 version [15:26:51] hopefully it's only temporary [15:28:44] n7275, speaking of disappointments, any update from UHCL? [15:29:07] or have they just stopped scanning things :D [15:29:16] they already didn't do Ryan's last request [15:29:39] for my last request they just had to stich some PDFs together from already scanned stuff [15:29:49] indy91 how would that be set? [15:29:57] And yeah they left me hanging haha [15:30:07] LabelFormat = 2 [15:30:16] remove that line and you get the old markers [15:30:51] there are a lot of new markers, but these P22 landmarks tended to be small craters and such, so they wouldn't appear as named craters [15:31:43] So why isnt that set in the current NASSP version? [15:32:38] I think when we transitioned to Orbiter 2016 I just copied over most settings from the default Moon and Earth [15:33:15] So any way to add the old markers to the new list and have something similar to what was done with earth ones? [15:33:56] yeah, I would use the same method [15:35:06] I guess when I did landmark tracking in Orbiter 2016 I didn't even enable markers [15:35:24] because the resolution is so good, as long as you have some map as reference you really don't need it [15:36:57] Fair, still I think it would be helpful to be able to enable it [15:37:12] I have a copy of the user manual. I mistakenly filed it in my "to transcribe" folder... [15:37:53] No word from UHCL yet [15:38:18] rcflyinghokie, I'll work on the new style markers [15:38:25] n7275, oh do you have a link? [15:38:55] and where did you find it :D [15:42:23] ah I do have that [15:42:29] I didn't know it was related to the Apollo Mission [15:42:30] Trajectory Control Program [15:44:51] indy91 thanks, I think it would just be good to have, would they be selectable similar to earths in the surface list? [15:45:02] yeah [15:45:06] would work the same way [15:49:05] awesome [16:05:43] ok landmark acquisition display mostly done [16:05:48] however useful that is going to be lol [16:06:48] it has: AOS time, closest approach time, LOS time. [16:07:03] altitude at closest approach [16:07:13] viewing angle at closest approach [16:07:33] that's about it. But the closest approach time is useful for the photography stuff on Apollo 12 [16:07:54] the display also has local sunrise and sunset times at the landmark, but I haven't implemented that yet [16:15:19] morning! [16:24:13] those might be useful as they are depicted on many flight plans as well indy91 [16:24:36] that landmark tracking pictures [16:24:50] displaying the vehicle's orientation etc [16:27:51] hey Mike [16:29:13] what specifically do you find useful? closest approach time? [16:29:50] what I find a bit annoying with these displays is that usually you need to at least 2 displays to find all data for P22 PADs [16:29:58] the real displays I mean [16:30:11] over all they definitely have the capability to calculate a lot of useful stuff [16:31:30] and AOS and LOS are defined as 0° elevation, so just coming/going over the horizon [16:31:45] only one display has the ability to calculate the point when the CSM crosses 35° elevation [16:31:59] which is when you start pitching down with P22 [16:32:03] in one of the techniques at least [16:34:30] I just mean its nice to see those times with respect to the flight plan and how its visually depicted [16:35:46] speaking off, how far off the flight plan is your Apollo 10 mission [16:35:48] of* [16:38:01] Let me check [16:38:39] Using the F-1 P22.... [16:38:50] yeah that is a good reference [16:38:52] FP is T182:27 [16:39:00] T1 82:27 [16:39:19] pad is 82:30:13 [16:39:53] so 3 minutes? [16:41:25] uhh [16:41:28] that is very surprising [16:41:37] you did MCC-2, right? [16:41:38] not MCC-1 [16:41:56] flight plan has MCC-1, actual mission did MCC-2 only. [16:41:59] We also only do MCC-2 [16:42:13] and that alone leads to a 12 minute different of lunar orbit events [16:42:19] evasive and MCC2, yes [16:42:32] and previously our LVDC targeting was a bit bad [16:42:40] so that 12 minutes could grow to up to 25 minutes [16:42:55] LOI1 was 75:48:33.65 [16:42:58] but maybe with all those LVDC cutoff bugs fixed it's different now [16:43:23] so 3 minutes off [16:44:18] funny, so we actually sort of get a 9 minute error elsewhere [16:44:43] Any other data that you wish to have to compare? [16:45:30] nah, I think that's in the limits of what kind of errors we can expect [16:45:47] just surprised that it now goes in the other direction [16:48:02] Yeah everything seems to be consistently 3 minutes post MCC2 [16:48:13] what was your MCC-2 DV? [16:48:27] 37.2 dvt [16:48:50] actual mission had 48.7 [16:48:57] but I guess it's kind of difficult to compare [16:48:59] interesting [16:49:11] their trajectory might have been off after TLI from what was planned [16:49:13] evasive was 19.7 [16:49:23] evasive is always 19.7 :D [16:49:27] Ah :P [16:49:53] Always the same components? [16:49:54] flight plan has 57 ft/s, but for MCC-1 already [16:49:56] yeah [16:50:26] 00:30:55: 4:40:01 GET, direct input, SPS, 0 ullage, EXDV 5.1, 0.0, 19.0. [16:50:30] direct input to the MPT [16:50:38] that is Apollo 11 of course [16:50:49] so the MCC also has it hardcoded like that [16:51:05] So 10 and 11 used the same hardcoded evasives? [16:51:09] yep [16:51:32] I mean it's pre-determined DV and direction, I don't really know why it isn't fully DVZ [16:51:47] they let TLI overburn by 2 m/s [16:52:01] and the evasive maneuver corrects it basically [16:52:21] maybe that is the optimum "correction" for a TLI biased like that [16:52:44] I am surprised that wasnt a case by case computation [16:53:04] I guess it's a nice easy way to keep TLI targeting the same as if there was no evasive maneuver [16:53:21] and they had a specific requirement for the size of the evasive maneuver to get away from the S-IVB [16:53:51] And I supposed the MCC would clean up anything that wasn [16:53:53] so they came up with this sequence. 2 m/s TLI overburn, 5.1, 0, 19.0 DV 2 hours later [16:53:56] yeah [16:53:59] wasn't consistent* [16:54:18] and I heard the FIDO say that that TLI overburn plus evasive isn't completely exact [16:54:32] because before TLI, they put TLI and evasive maneuver on the MPT [16:54:45] and that did not lead to a free return trajectory [16:54:49] close, but not quite [16:55:24] so even the planned trajectory wasn't the same as if you did no overburn and no evasive maneuver [16:56:12] I guess the primary goal was to just not hit anything [16:56:24] so yeah the MCC had to clean it up a bit even if everything went perfect [16:56:26] be it the moon or the spacecraft hitting the SIVB [16:56:38] yeah on Apollo 8 they had planned to do a small evasive maneuver [16:56:44] but then actual mission did another, second maneuver [16:56:46] both RCS [16:57:53] so they just do this pre-determined evasive maneuver which is close enough and gets you far away from the S-IVB [17:01:30] I guess what would be interesting is to see some preflight study that does MCC-2 and not MCC-1 [17:01:36] if that also gives a 12 minutes difference [17:01:43] or if the 12 minutes is the actual mission only [17:04:06] hmm, can you give me a scenario somewhere between TLI and MCC_2 [17:04:12] ideally around the time of MCC-1 [17:04:18] but doesn't have to be very exact [17:06:50] Yeah let me look [17:07:07] Apollo 10 did a bit of a plane change maneuver with their MCC [17:07:15] to get to the Apollo 11 approach azimuth [17:07:35] but I could change the approach azimuth and check what the DV would be. Because that would nominally be 0 [17:07:49] This was my MCC2 padhttps://www.dropbox.com/s/sn6ew5kzbuyphx1/Screenshot%202022-03-07%20090531.jpg?dl=0 [17:09:10] interesting, the actual PAD was very close in DVX and DVY to this [17:09:17] but real DVZ was 25 ft/s [17:10:35] that could be TLI dispersion more than anything [17:10:43] https://www.dropbox.com/s/0gus4aftzcmxltt/Apollo%2010%20-%2010h.scn?dl=0 [17:10:53] Betwen 10 and 11 hrs [17:11:05] yeah that's perfect, thanks! [17:13:22] 740 NM pericynthion height [17:13:24] that's a lot [17:15:58] Actual was 907.7 after TLI [17:16:23] 286.1 after the evasive if I am reading this correctly [17:16:45] Hm this has 18.8 fps as the evasive dv [17:19:07] but the pad has the trusty 19.7 [17:20:38] Maybe due to residuals [17:20:39] 004:39:44 Cernan: Okay. We have - You see the residuals, plus one, two-tenths, and five-tenths. [17:21:51] 18.8 as VC? [17:22:23] No that was in the mission report [17:22:38] As the velocity of that burn [17:23:06] right [17:23:11] I have an idea what it could be [17:23:34] our TLI targeting parameters for Apollo 10 are based on the actual cutoff state vector [17:23:41] which overburns, as planned [17:23:52] and then I also have the same biased cutoff DV in the LVDC presettings [17:24:04] while our actual DV during tailoff is larger [17:24:15] so... doesn't that apply the bias twice :D [17:24:38] so your evasive maneuver just gets the perilune back to where it would be with TLI and overburn [17:26:16] have to look into that [17:26:25] Hmmm could be [17:26:33] I guess it's no big deal as it leads to better results than with the correct bias :D [17:27:18] Haha yeah its closer to the FP for certain [17:47:54] I'm checking with the MPT what the ideal trajectory would be [17:50:25] yeah it very much looks like we apply the bias twice [17:50:34] the MPT trajectory isn't far off from what you got [17:50:53] so what I need to do is re-calculate the Apollo 10 TLI targeting parameters with a 2 m/s lower velocity [17:52:23] should be easy to do [17:53:32] with TLI and evasive on the MPT, an optimized flyby maneuver at the MCC-1 time would be 20 ft/s [17:53:37] that should be a lot close to 0 [18:25:40] NTRS still doesn't have the lost documents back. Now I start getting worried they actually removed them. [18:25:56] because it's not like NTRS is broken right now [18:25:58] It works [18:26:09] but a lot of Apollo stuff is suddenly not there anymore [18:26:39] like if you google "RTCC Requirements". NTRS links still come up, but they are 404 [18:27:02] oh man has there been a second purge? [18:27:14] maybe? [18:27:54] I hope it's a bug or some server reshuffle or something [18:28:10] I'm sure someone else than me will notice it eventually [18:29:42] in these situations I always hope they put up some of the old documents up by accident :D [18:31:59] isn't there some different kind of link, I forgot how it is called [18:32:10] kind of a non-NTRS link, but pointing to the same document [18:41:20] ah I meant something like this [18:41:22] http://hdl.handle.net/2060/19700026434 [18:41:45] but that just links to NTRS of course [18:42:32] I'm glad I have a bunch of stuff archived [18:42:40] cd .. [18:43:14] I really need to type in the right window... [18:43:45] haha [18:43:56] well not much I can do. I hope it comes back on its own [18:46:31] I already have everything RTCC related from NTRS :D [18:46:39] but it's not just that missing of course [19:01:44] Hey good afternoon/morning [19:01:49] good evening [19:02:25] Apollo 116 at GET 57:40 minutes [19:03:16] Got a long O2 flow high alarm, went away inmediately when switching the Suit Compressors at ECS redundant comp. check [19:07:48] that sounds about right [19:10:06] Loved the ride [19:10:38] As I did not ride a Saturn V I don´t know how it is, for for me the vibrations looked right [19:10:51] *but [19:12:34] for me it seems very strong haha [19:14:43] Was a little bit hard to read the panel when on Stage 1 [19:14:50] But not really hard [19:15:29] Those F1´s should have given a nice ride [19:19:02] Hey! [19:19:10] 99.5% SPS oxid and fuel [19:19:15] yep [19:19:17] Is that right? [19:19:21] a bit more than on Apollo 7 :D [19:19:23] Ok... [19:19:28] :D [19:19:33] Thout I needed to... [19:19:36] Abort [19:19:42] *Tought [19:20:20] if you try to launch that on a Saturn IB then it wont make it to orbit [19:20:40] Now we have SLS :D [19:21:07] Wasn´t on the news ¬¬ [19:21:25] well it hasn't launched yet. Then it will be on the news :D [19:21:33] For 10 seconds... [19:21:36] ¬¬ [19:21:40] as always... [19:21:47] No good news since 2019 [19:21:53] And I am becoming crazy [19:22:13] Don´t want to watch the news most of the days [19:22:17] true, doing things like, flying all of Apollo 7 in one go [19:22:27] Exactly [19:22:54] I am flying 5 minutes of Apollo 12 and then notice something I want to implement for the RTCC for it... [19:23:27] Dinner! [19:38:47] GET 1:34:10 [19:38:57] All good aboard Apollo 116 [19:47:17] I'm always happy when the first abort Maneuver PAD appears [19:47:23] because a loooot of calculation take place for that [19:49:36] I have TLI + 90 amd TLI +4 [19:49:40] PAD´s [19:49:45] And the P27 Auto [19:49:58] Do I key something at the end of the P27? [19:50:26] To change slots or something? I saw the upllink was for CSM and LM [19:52:15] I think it just uplinks both SVs there [19:52:23] the uplink could also do V66 for you [19:52:28] or the astronaut could do it [19:52:48] but the uplink will have taken care of it there [19:53:16] Ok [19:54:28] TLI PAD :) [19:55:29] TLI PAD has gotten smaller since you did it the last time I think [19:56:10] Maybe... [20:04:07] I am scared about 2 things [20:04:12] Apollo 9 [20:04:30] And T&D in a few minutes :D [20:11:30] yeah controlling two spacecraft without ever doing 0.1x time acceleration is very hard [20:12:13] Wait [20:12:23] What is time acceleration? [20:13:27] a key you can never use [20:13:42] Excellent. You are quick :) [20:14:20] so when are you doing the Skylab missions [20:16:08] I don´t know if I will do them... [20:17:38] Did you think about the bible? [20:19:53] Skylab 4 took 84 days, no time acceleration :D [20:20:12] Ah... Very good... [20:20:16] :D [20:20:22] I still have a life [20:20:26] well it would be historically accurate to read the bible [20:20:32] I think it's fine to do that [20:20:42] Based on that yes... [20:20:46] but of course if you come up with something else, fun, to read [20:20:51] Based on internet... I don´t know [20:20:52] something that means something to you maybe [20:24:14] any fun spanish Christmas stories maybe? :D [20:28:45] Hmmm [20:28:48] Interesting [20:29:09] Yeah... [20:29:24] On Spain we do a lottery on December 22n´d [20:30:03] I can show a "decimo" (a participation) [20:30:16] and say that I won [20:30:31] but as I was not on earth I couldn´t claim it [20:30:43] And I don´t want anyone to claim it until I come back [20:32:15] Damn SPS heater. Left that on A for around 1 hour... [20:34:00] https://www.youtube.com/watch?v=0VIStKrCBHQ [20:41:32] thanks for reminding me, I also still had it in heating :D [20:42:02] Really isn´t there a MA? [20:42:07] for that... [20:42:18] You had Houston but... [20:48:20] no MA [20:49:13] FDAI is really cool [20:49:23] Gamechanger :D [20:57:40] yep [21:03:01] Going to the moon [21:03:27] !! [21:34:28] https://prnt.sc/QsPd5UYPnqIj [21:34:39] https://prnt.sc/AP8yioI8_kiz [21:42:43] looks great [21:45:39] https://prnt.sc/eJ4z0ApT-Ojs [21:45:57] Transposition went good (on AUTO) [21:46:04] Got to try on SCS [21:46:29] I believe actual mission did it on auto right? [21:51:42] I think so [21:55:49] good night! [22:33:36] Hey people. How's it going? [22:43:20] Hey Thymo [22:43:27] Practising Apollo 8 [22:44:52] Nice. I got a bit tired of writing my thesis so gonna do Apollo 9 for a little while before heading to bed. [23:37:51] Going to bed guys [23:37:55] Good night [12:09:47] good morning [12:13:21] hey Matt [12:20:25] how's it going? [12:20:53] doing Apollo 12 landmark tracking [12:21:03] finally want to make some progress there [12:21:07] and you? [12:22:49] you must just be getting up judging by the time :D [12:35:41] I've been up for a bit, but not too long. still in the "not enough coffee yet" part of the day. [12:39:58] I'm in the process of moving at the moment, but when thats done I need to get through some of my half finished projects [12:41:09] sounds good [12:54:11] my thread pool is working well with the one exception that it doesn't block until the work pool is empty... [13:17:17] hmm, I don't understand much about that [13:50:17] the pool is a collection of threads that are always running. when it comes time to call all of the refresh functions, each thread pops a function pointer off of a mutex-locked vector and runs it [13:51:48] what needs to happen is that when the current timestep work queue is empty AND all the threads have finished their work, it should let the thme step continue. the second part is hard [13:56:36] hmm I see [18:03:35] any thoughts on the the github discussion topic on thruster visability? [19:24:20] if that would mean it becomes completely invisible then I am against it, even if it was realistic [19:24:43] otherwise, I am sure we can make it look nicer, more transparent if that is more accurate [19:31:59] Oh I doubt its completely invisible. shuttle RCS for comparison https://images-assets.nasa.gov/image/S39-27-016/S39-27-016~medium.jpg [19:32:27] Shuttle OMS burn would be nice [19:32:31] as it's related to the SPS [19:32:37] quite similar [19:41:59] https://www.youtube.com/watch?v=6KeRaWaQTgA [20:00:33] could be something a simple as this http://mwhume.space/Files/NASSP_Stuff/J2effect.png [20:20:34] not really my area of expertise though [20:22:35] same [20:23:31] ooo Ill have this landmark thing a try later. looks very useful. [20:25:24] it was more useful to me than I thought [20:25:54] Apollo 12 did landmark tracking on 4 landmarks, 2 revs in a row [20:26:15] so I just added the 4 landmarks into the table once and got some good data for two revs [20:26:33] it doesn't have 35° elevation time [20:27:05] but the flight plan says that is 5 minutes between 0° and 35° elevation [20:28:52] this is a MPT only display [20:29:07] over all it's still not really more useful than our old landmark page [20:29:15] which gives the P22 PAD directly [20:30:17] but it reduced the number of times I had to enter the landmark dtaa [20:30:20] data* [20:31:29] there is a very similar display, experimental site acquisition [20:31:59] that gived: Rev, name, GETAOS, range, altitude, elevation at closest approach [20:32:02] GETCA, GETLOS [20:32:17] that display I had already implemented [20:44:08] might even be more useful actually [20:44:11] for P22 [20:44:38] landmark acquisition should be useful for landmarks you aren't sure about yet [20:44:50] because it shows local sunrise/sunset (when I get to implementing that) [20:45:19] experimental site acquisition display might be good for sites that are in the flight plan [21:54:41] night! [13:29:53] hello [15:12:09] could I get one of your Apollo 12 landmark scenerios to test with? [15:36:10] good morning [15:37:23] did Apollo 9 get a CSM docked dps pad? I cannot seem to find it in the transcript for what was loaded in P30 in the CSM [15:42:51] hey [15:42:56] n7275, sure, let me find one [15:43:08] rcflyinghokie, CMP wrote down the same PAD as the LM got and entered the same thing in P30 [15:43:26] bypass auto maneuver in P40, PRO at 5 seconds and you should get the same residuals as the LGC [15:43:32] or ENTR [15:43:34] not PRO [15:43:40] something like that :D [15:43:55] Thats what I thought [15:44:44] V49 for the maneuver and just bypass, dv are LVLH so they should come out the same [15:46:48] https://drive.google.com/file/d/1hUcGTFiF9TThYRC7zAtcV92OvpQPv9IG/view?usp=sharing [15:47:06] I'm finally adding the most anticipated RTCC update in years [15:47:18] the TEI REFSMMAT used for Apollo 12-17 haha [15:47:27] that gives you exactly 180, 0, 0 angles [15:49:23] Nice! [15:49:49] So we dont have to use a P30 anymore? [15:50:01] yeah [15:50:23] the operational attitude sequence for Apollo 12 actually says they can't calculate the REFSMMAT in the RTCC [15:50:34] but I bet they either added it late for Apollo 12 or for Apollo 13 at the latest [15:50:41] it will not be an option in the REFSMMAT menu [15:50:51] I've implemented it the "correct" way [15:51:06] you choose it as an option in the RTE digitals [15:51:27] and then there is a button to save that REFSMMAT as the current one for the CSM that is used everywhere [15:54:54] in the end it's actually a super simple calculation [15:54:56] Without MPT? [15:55:06] with or without [15:55:10] doesn't matter [15:56:10] but it does make use of the REFSMMMAT tables [15:56:25] initially it's saved in a RTE table together with the burn data [15:56:44] then there is a button where you can choose P or M for either RTE digitals column [15:56:58] and internally that does the MED logic to save the REFSMMAT in the DOD slot, deorbit [15:57:20] and then there is another button which internally does the MED logic to move the CSM DOD to the CSM CUR (current) REFSMMAT [15:58:29] so press one button, enter P. Press another button, done [15:58:44] and on the RTE digitals input page you change CUR to TEI [15:58:46] beforehand [15:59:46] that's probably how they actually implemented it [16:00:11] there are 3 other options already that give you specific IMU angles for the RTE burn [16:03:21] that is the exact same method I had implemented saving the deorbit targeting REFSMMAT [18:35:33] flying a full mission is always worth it for the view of the Moon after TEI alone [20:13:18] hmm. very strange. I'm getting a CTD loading that scenerio you sent me [20:15:16] oh wait [20:15:34] never mind. i figured it it out [20:16:26] it shouldn't CTD in either branch [20:19:09] I was missing a vessel [20:20:00] oooh sorry, I have the non-NASSP Surveyor in this [20:20:11] forgot about it [20:21:00] if you need an edited scenario let me know [20:21:15] I already took it out [20:21:38] ah good [20:21:47] it wasn't useful for me anyway [20:21:52] it appeared underground [20:22:13] touchdown points? [20:23:44] yep [20:25:56] So what do I need to do to enter a landmark? [20:26:18] MPT initialized? [20:26:59] press the ADD button on the display [20:27:24] right now it still needs the MED input format [20:28:00] so one example would be [20:28:53] P32,ADD,M,LDMK,CP1,-5.667,112.0,NM,0.0; [20:28:59] for CP1 [20:36:07] you can add up to 12 points [20:36:16] I added the 4 they tracked on two revs [20:36:55] the landmarks are saved/loaded, too, so when you add them you just need to generate the display again and not go through that P32 all again [20:39:05] I already have a section with MEDs in the RTCC MFD manual. I'll keep on adding some that are already implemented [20:40:57] it did not like my input, I think [20:41:12] I have "error 1" at the bottom [20:42:35] Error code 1 is "Input MED" [20:42:39] haha [20:42:53] enter P32 just adds the landmark [20:43:05] if that went ok can be checked on the online monitor display [20:43:19] then you need to press the other button and enter U17 [20:51:25] I had the format of delta time wrong, I think. [20:51:29] I have a list now [20:52:24] ah nice. Yean delta time also wants HH:MM:SS [20:53:05] yep. it doesnt like H.h [20:54:21] I was also getting an error 2, on the online monitor, because it looks like these were already saved. it threw me off for a minute. [20:56:18] oh great, I wanted to give you a scenario on purpose where the landmarks hadn't been added and saved [20:56:29] and what did I do, I went back one scenario further where I had checked that [20:56:46] or one scenario further forward rather [20:57:02] and of course I had already added all 4 landmarks by that point... [20:57:05] sorry :D [20:57:32] did it give you the [20:57:35] "P32, ADD...STA ALREADY IN TABLE" [20:57:41] yep [20:57:53] at least that worked [20:58:36] I can try deleting and re adding [20:58:50] yeah. There is a MED input to do that [20:59:12] P32,DEL,M,LDMK,ALL; [20:59:15] to delete all [20:59:32] it probably doesn't need the M [20:59:36] P32,DEL,,LDMK,ALL; [21:00:52] I guess what is really missing is section in the manual for this display. I've been kind of hesitant adding anything that requires the MPT though [21:01:24] because then I would to also need to add lots of pages about the MPT and people would expect it to actually work reliably... [21:06:48] yeah, the MPT is a bit more complicated than the other functions, but it probably would be *that* bad to document [21:07:10] ...I say not fully understanding it, lol [21:07:28] the delete and add worked great! [21:14:20] once you have the landmarks in there it's quite nice, shows you AOS/LOS times, all sorted and stuff [21:41:07] just when you think your done checking PRs I have another one [21:45:52] haha, that should be a fun one to have [21:47:05] my plan is to finish Apollo 12, then rcflyinghokie has found some bugs and issues that need fixing. And then I'll check my pending PR for Apollo 7 [21:47:22] mostly needs testing of all the mission scenarios [21:56:12] good night! [04:06:04] NTRS is missing a massive number of documents... [13:53:31] Exception thrown at 0x3AF485F2 (LEM.dll) in orbiter.exe: 0xC0000005: Access violation reading location 0x5487BE16. [13:53:40] Getting that CTD loading any Apollo 9 scn with a LM now [13:57:27] its something to do with a checklist fix I believe [14:09:56] and fixed [15:21:29] hey [15:22:46] hey guys [15:25:46] morning [15:31:56] I think the checklist issue was me goofing formatting somewhere to be honest [15:32:06] Because after reverting and adding my changes again from scratch it all worked [15:32:18] I think I may have copied something into an incorrect column [15:33:30] But in any case I tested each apollo 9 scn and no more CTD [15:34:22] yeah [15:34:38] it's unfortunate but not much we can do without a big revision of the checklist code [15:36:06] right [15:36:20] well the PR is all safe now [15:37:07] Speaking of code though, with VS2022 being out now for about 5 months, would it be prudent to think about updating NASSP for it [15:37:41] I have found even with the same packages I used in VS2019 for compatibility, VS2022 will not build NASSP [15:38:28] yeah I merged it [15:38:46] oh it doesn't build, interesting [15:38:50] yeah [15:39:12] that seems more like Thymo's department, when he has more time then we can do that update [15:39:23] Sounds good [15:39:28] I think he defends in a few weeks [15:40:10] But yeah I use MSVC v141 VS 2017 C++ x64/x86 build tools to build NASSP in VS2019 [15:40:40] Put the same one in VS2022 and it wont build [15:42:40] Wonder if its because it doesnt have the same windows 10 sdk [15:43:26] I have 10.0.17763.0 in my VS2019 but its not available in VS2022 that I can find [16:24:24] ok, let's see what this MCC-6 is going to be [16:26:25] ah [16:26:27] scrubbed [16:26:50] 1.8 ft/s for MCC-7 will be enough. I'll not do 0.5 ft/s for MCC-6 [16:42:53] rcflyinghokie, I have quite uneven CM RCS injector temps [16:43:00] 5C: 0V [16:43:09] 5D: 4V [16:43:48] on test position 6: 4, 0, 5 and 5V [16:44:12] Yeah ever since the substance changes I have seen those as well [16:44:18] I also get uneven heating in the LM [16:44:33] I will have to go back and retweak all the radiators [16:45:38] seems they dont heat/cool the same after those changes [16:45:43] Not sure why [16:46:14] Sucks I had them pretty solid haha [16:47:26] I'll not skip the pre heating then [16:50:58] What I need to do is start recording these temperatures from flights so I know where to start [16:51:16] I am going to start tabulating these in a spreadsheet [16:51:28] But I already know all radiators are impacted it seems [16:51:40] I have seen odd RR temps as well as spacecraft temps [16:54:59] how do substances even affect the CM RCS injectors [16:55:09] Ho ho ho [16:55:10] isn't that just tanks and stuff? [16:55:10] I think h made some radiator tweaks with it [16:55:13] *he [16:55:15] ah [16:55:17] I cannot recall [16:55:19] hey Turry [16:55:44] Dismantling my first PC, bought 16 years and some months ago [16:55:49] Wow [16:55:54] Anyone wants an IDE Floppy drive? [16:56:04] :D [16:56:16] Hah I have a few laying around somewhere I think [16:57:39] rcflyinghokie, it's probably the positions of them [16:57:55] in PTC everything on the "sides" gets even heating [16:58:05] but not stuff pointing elsewhere [16:58:27] well they were heating pretty evenly at one point [16:58:32] hmm right [16:58:37] I did a lot of tests with them [16:59:08] But of course I still dont exactly know where the position is measured from lol [17:22:38] indy91 which files need to be deleted to see moon surface markers? [17:22:49] replacing all apparently doesnt show them [17:25:02] I'm not sure what you mean [17:25:14] you mean our own, old style markers? One line in the Moon.cfg needs to be changed [17:25:25] nothing replaced or deleted... [17:27:59] someone just download and copied/replaces and still has no markers thats why I ask [17:28:27] told him to set up git :P [17:29:02] in the current NASSP version the lunar markers dont work [17:29:24] I've only done Earth markers [17:29:32] I was going to do lunar markers in the new style soon [17:31:30] They work for me [17:34:57] then you changed your Moon.cfg locally [17:35:39] they can't work because the old markers aren't even loaded if the new style markers are there [17:35:40] Oh thats not changed by NASSP? [17:35:57] and I have the new style markers that come with Orbiter [17:36:05] Hm I dont even know where that file is [17:36:26] Ah there [17:38:27] All of those cfg files were changed 2/5 [17:38:37] I dont recall ever editing it [17:40:52] What would need to be edited [17:44:12] I have LabelFormat = 2 [17:44:51] Config\ProjectApollo\Moon.cfg ? [17:44:58] Oh no [17:45:04] not in project apollo [17:45:11] that's the default Moon then [17:45:14] not the one we use [17:45:43] LabelFormat = 2 there also [17:45:46] LabelFormat = 2 without a ; before it means the new style markers are enabled [17:45:56] Yep [17:46:03] and the old style markers cant even be enabled [17:46:06] Funny I dont ever remember editing this one [17:46:08] including our marker file [17:46:22] so you have a ; [17:46:24] or not [17:46:26] no [17:46:36] then you are not seeing our old style marker file haha [17:46:49] Well I have tons of moon markers [17:46:55] oh yes [17:46:58] they come with Orbiter [17:47:05] Those are what arent showing up for Swag [17:47:16] oh that's we are talking about [17:47:18] hmm [17:47:19] Yes [17:47:27] I thought the file with landmarks [17:47:31] mostly for P22 [17:47:49] maybe he didn't download the file [17:48:01] Which file [17:48:08] http://orbit.medphys.ucl.ac.uk/mirrors/orbiter_radio/tex_mirror.html#moon [17:48:11] Label.tree [17:48:15] Ahh [17:50:02] Thats why [17:50:18] Apparently the "moon complete" torrent doesnt have it [17:51:41] Thats why [17:56:31] Thanks [17:59:12] Ok time to do some surgery, swapping out a 250GB M.2 for a 1TB [17:59:31] See ya [18:39:54] Hey all [18:40:43] hey Thymo [18:41:08] Regarding the upgrade to VS2022. I do want to tackle that soon-ish. I'd like to try to convert NASSP to a CMake project just like Orbiter. Then you could even choose to use a different IDE than VS as long as you have the proper toolchain setup. [18:41:39] right [19:02:05] Thymo, I always forget you can do that with pointers [19:04:38] but now I have to figure out how to cherry pick, never done it [19:05:43] You have my repo still set up as remote? [19:06:05] yep [19:06:23] Then you just need to do a git fetch on what you named mine and do a `git cherry-pick` plus whatever the commit hash is [19:07:52] so not even change to your branch, just that commit [19:08:16] Yeah it just pulls that single commit into the branch you're on [19:08:54] It's a fixup commit so also do a git rebase --autosquash onto Orbiter2016. [19:09:01] After you've cherry-picked [19:09:08] now you lost me haha [19:09:18] I was in the TEI branch [19:09:21] cherry picked [19:09:26] and it seemed to have worked [19:09:31] do I not just have to push now? [19:09:42] Yep. Do a gitlog. You;ll see my commit has "fixup!" in front of it. [19:09:48] yeah [19:10:34] That means that it is a commit that "fixes" a previous commit. A `git rebase --autosquash Orbiter2016` will merge those two commits together. [19:10:46] why Orbiter2016 [19:10:52] that is the branch we want to merge this into [19:11:14] You created your current branch from Orbiter2016 right? [19:11:17] yes [19:11:55] So with a rebase you tell git you want to base your current branch onto that. It already is, but you need to tell rebase where to start so it can squash those commits [19:12:50] is this only to have the two commits appear as one again? [19:13:00] Yep [19:13:02] why do you hate PRs that have more than one commit... [19:14:18] It wasn't too big of a change, figured might as well go into that commit. Feel free to just change the commit message if you want to keep it separate [19:16:40] let me have a look how the PR would appear now [19:18:06] I don't see the issue [19:19:07] one main commit, one fixup commit where it says "Thymo authored and indy91 commited" [19:19:15] I think that is pretty clear and tells the commit history [19:19:36] Well now my commit still is in fixup format. So if you want to keep it it at least needs to be describe what the commit does [19:19:56] it fixes up my commit? Seems pretty clear [19:20:01] if I make this one commit I am pretending I got it right on the first attempt :P [19:21:12] Only that you won't "see" your commit when you are viewing them through git blame. If I only see "fixup! blablabla" I first of all know that someone broke a fixup and secondly don [19:21:19] don't know what the hell is going on [19:24:28] ah fixup is an actual git command that goes with git commit [19:24:38] Yes [19:24:40] I thought it was some naming convention [19:24:43] No :) [19:26:58] Merged [19:27:20] ah, you now had me at the point where I was going to do the rebase haha [19:27:32] still needed to think about what you said. [19:27:50] Oh haha. Well I went ahead and renamed the commit. [19:27:53] You are a few steps ahead when it comes to git, never used or needed much of all this, rebase and such [19:28:54] Yeah, you'll be surprised how much stuff there is below the basic commands. It can be fun but overwhelming [19:29:21] Next time I'll wait if you still want to experiment [19:29:36] not so fun for me. Git is a nice tool, but it seems easy sometimes to break things [19:30:10] better than CVS and SVN at least [19:30:30] It's easy to dig yourself into a hole that can be tricky to get out of if you don't know exactly what happened. [19:31:51] speaking of holes [19:32:03] it now says the branch hasn't been fully merged when I wanted to delete it [19:32:40] I changed the commit title and you still have the old one in that branch, that's why. [19:33:48] Hey Thymo [19:33:54] right, your commit in my branch, so you can still rename it haha [19:34:28] but where was that renaming even done [19:34:32] If you open a PR there's a checkbox that allows maintainers to push to your repo, allowing me to do what I just did :P [19:34:45] Hey Matt :D [19:34:49] oh [19:35:08] maintainer of the main repo, my repo being a fork, correct? [19:35:18] Yes [19:35:23] ok then [19:36:02] well [19:36:15] I merged your update into my local TEI_REFSMMAT branch [19:36:22] I thought that would fix it [19:36:29] but I guess now it created a merge commit [19:36:36] I wanted to delete the branch "cleanly" [19:37:00] guess I'll just have to do the -D instead of -d [19:37:31] Yes, if you really wanted to do a clean delete you'd need to rebase. [19:37:39] -D doesn't hurt though [19:37:45] yeah, rebase over my dead body [19:37:56] deleted :D [19:38:09] Haha [19:38:43] Hey, how far did you get on the old version, scenerio check code? [19:41:14] scenerio check code? [19:41:19] I have not forgotten about it, I've just been too busy with my thesis to have had a chance to really sit down for it. Honestly, it's gonna be another month till I really have time to take on bigger stuff again. If you don't want to wait we need to come up with something that works in the interim. [19:41:40] rcflyinghokie, sorry, I was confused that we were talking about the Orbiter markers vs. the NASSP ones. We talked about our own marker files so often :D [19:44:31] Thymo, I have no issue waiting, I know you're busy. I have a big work project that is going to keep me busy on the weekends into May, so I'm not in too much of a hurry. [19:45:56] Thanks. I do want to get it in, I just feel it needs to be done well in one go. Scenario checking and the wiki are the first things I do when things calm down. :) [19:47:48] After that I have some more EPS/AGC related stuff pending and then I think I want to get into the whole VS update/autobuild/release model shenanigans. [19:48:59] I might need your help on my thread project at some point in there :) [19:49:55] Oh yeah that'll be fun [19:50:36] So many large project to do.... When will release 8 come... :P [19:53:48] Honestly when scenario checking, the wiki and after figuring out the future release model all that's left is some MCC checks and new mission scenarios and we might be good to just push 8 out officially. [19:54:19] Orbiter release be damned [19:55:23] no worries indy91 [19:55:35] Oh did you figure out anything with the Apollo 12 landing site? [19:55:56] RLS landing in the wrong spot or something [20:01:07] I think we should at least have a plan for an 8.0 release this year. Heck, I can release an orbiter version from my fork if we need it. [20:03:19] after I have landed with Apollo 12 I'll get the scenarios tested for that Apollo 7 MCC update PR draft I have up. That is really the biggest update that the MCC needs for an 8.0 release. Lots of smaller updates I want to do, especially for Apollo 7, but that should be the last update that breaks the MCC state [20:03:41] rcflyinghokie, sadly no, didn't find another source on that [20:03:53] Ah ok [20:03:56] Yeah, with Orbiter being MIT a binary release doesn't sound bad. We can just tag a version and only provide bugfixes. [20:04:51] Still I'd rather have someone else just maintain it but we might not have that luxury. We just need to be careful we don't become the defacto Orbiter maintainers. [20:05:28] yeah that would be a lot of extra effort [20:10:19] It doesn't seem like anyone on the forum wants to adopt it, unfortunately. [20:11:51] I would do it but I would have to divide what little time I have for NASSP to also work on Orbiter and I don't really want to do that. [20:12:07] I'm sure with me many other unfortunately.. [20:12:55] Are there even any other "large" team based project for Orbiter active besides us? [20:13:15] SSU is in indefinite hibernatiom, DX9 client is not very active. Are we "it"> [20:13:16] ? [20:13:40] I think we are... [20:14:54] We need to find a recruiter that is into open source lol [20:17:30] indy91 Apollo 7, SECS, and abort question all in one :P https://www.orbiter-forum.com/threads/apollo-7-launch-abort-mode-1.40402/ [20:17:46] yeah just saw that haha [20:19:08] There are plenty of projects out there are are fairly esoteric/arcane, and open source that have a larger following than Orbiter. Most of the "old guard" on the forum seems to expect the internet to continue to work like it did in 2004. [20:27:19] yeah I want to have certain features in Orbiter, but I don't really want to be the one that gets to implement them... [20:28:12] We should sit down for a chat with Doug Beachy at some point to get his views. AFAIK he's the only one besides Martin with maintainer access to the repo [20:28:38] In my eyes he's the current maintainer of Orbiter in Martin's abscence. [20:29:14] I think martins is even out completely [20:30:49] I didn't want to say it, but yes [20:37:49] Doug would be a good one to talk to. [20:54:43] rcflyinghokie / n7275: I'm doing the APS pressure check on 9. and my manifold pressures are at 10 psi while they should be 25 atleast. Probably not bad but maybe an issue in the APS? [20:57:40] All propellant pressures are hardcoded I believe [20:57:59] Which pressure are you checking [20:58:10] yeah [20:58:44] if the regulator shutoff and isolation valves are closed it will appear as 0 pressure [20:58:56] which should probably be raised to some slightly higher level [20:59:19] Temp/Press mon: FUEL MANF and OXID MANF [20:59:20] I didn't remember that it was actually showing so low before it gets pressurized [20:59:30] Sitting around 10 psi [21:02:43] yeah I guess that needs some higher default value [21:02:51] before pressurization happens [21:02:55] then it uses helium pressure [21:02:57] Those are RCS indicators [21:03:24] PRPLNT TEMP/PRESS MON switch is how you see APS pressure [21:06:38] FUEL MANF and OXID MANF are RCS [21:07:38] there it should have 30 PSI by default [21:07:41] without helium [21:08:19] but it depends on propellant percentage [21:17:01] when my last systems update gets merged we can transfer those over to actual tanks [21:18:17] Oh [21:18:23] I just bricked PA MFD lol [21:18:38] In the CSM. Go to LGC -> ENT. "Unsupported vessel" [21:19:13] If you reselect the MFD it works again but until then it just locks you out haha [21:21:12] cant you go back to the previous page from LGC? [21:22:45] All button labels are removed [21:24:58] normally it should say "Do this from the LM" [21:25:00] on the LGC page [21:25:23] hmmm [21:25:35] I hope this isn't another fallout from the name change [21:26:11] what's the name of your CSM? [21:26:22] is this an older Apollo 9 scenario? [21:27:27] Couple months old but my vessels are called Gumdrop and Spider [21:29:08] that should be fine [21:30:01] need to try that with our mission scenarios [21:31:36] doesn't give me unsupported vessel [21:32:06] oh sorry, I forgot to read that "ENT" haha [21:32:16] always the same with me... [21:33:44] yeah that sets the saturn point to NULL [21:33:56] because for some reason, in the LM, it doesn't keep that pointer around forever [21:34:06] but only for the duration of the processing happening for that button [21:34:34] and then you end up with the MFD not having any pointer to CSM or LM anymore and it think it's an unsupported vessel [21:35:13] I just need to make that button work in either vehicle. After all it does do something in both CSM and LM [21:40:20] of course beforehand you ignored the instruction "do this from the LM" ;) [21:47:15] I may have. :p [21:48:16] rcflyinghokie1: There may be a checklist error on the initial activation, or maybe I did something wrong. I turned my AGC on during the breaker activation checklist so it was on all the way till PGNS power on [21:48:50] Apollo 9 initial activation for the docked DPS? [21:49:09] Yeah, the very first one [21:49:58] Which procedure did you close the LGC breaker [21:51:04] I dont see it closed before PGNS Turn On [21:51:41] My guess is CB activation powerup chart? [21:51:50] It was a while back [21:52:37] Hmm interesting [21:52:43] I will investigate this [21:56:01] Looks like that is correct [21:56:21] But that is also based on the LM Rendezvous Activation [21:56:35] So I dont have an actual document confirming or denying that [21:58:24] that mission has too many LM activation checklists :D [22:01:35] 3 I believe haha [22:01:43] And I only have one of them [22:02:50] we have 2 [22:02:56] we have the EVA checklist [22:03:05] pretty sure I gave that to you haha [22:03:12] apollo-9-lm-eva-checklist-cdr-copy.pdf [22:04:40] [16:25:52] do you have the EVA checklist? [22:04:44] [16:27:25] and no I dont have a 9 EVA checklist it seems [22:04:48] [16:27:35] let's change that [22:04:52] [16:28:41] awesome! [22:04:54] haha [22:05:31] and I think we had the full rendezvous activation checklist for longer [22:05:41] but only a few pages of the systems evaluation checklist [22:07:38] Ah yes I have it [22:07:52] So I lack the initial activation/docked dps one [22:08:07] yep [22:08:11] I forget about the EVA because you power up very little [22:08:35] yeah, most of the stuff is really switch position checks [22:08:53] And powering up the ECS [22:08:55] I have 10 pages from the intial activation checklist (called systems evaluation checklist) [22:09:07] 10? [22:09:08] pictures when the flown one was put up for auction [22:09:10] I have 5 [22:09:30] I could use the other 5 haha [22:09:40] haha sure [22:10:11] I have 21, 31, 39-41, 55-56, 60-61, 64 [22:10:38] I have 21 31 39 56 and cover [22:11:02] I'll put up my folder [22:11:54] it's not much more, maybe it helps a tiny bit [22:12:12] ill take anything [22:12:55] I will make them into a pdf tomorrow [22:13:22] ok [22:14:10] good night! [22:19:42] Does RHC as THC not go for ACA as TTCA in the LM? [22:19:50] My stick isn't workng [22:21:25] maybe thats a vessim thing? [22:21:41] I don't have that set up [22:21:46] I probably should [23:05:05] .endlogging [23:05:05] Log ended by Thymo, total logging length 2182251 seconds