[14:29:12] NASSP Logging has been started by indy91 [18:10:18] morning! [18:29:59] hey [18:30:58] I finished making Solarium into punch cards last night :D [18:31:09] https://github.com/thewonderidiot/pyul/blob/master/SOLRUM55.R0.deck [18:31:20] 23,651 cards, ignoring the assembler setup [18:31:37] and here's the listing that's printed out: https://gist.githubusercontent.com/thewonderidiot/75130d1905012fdeb71a6bc1c484a7e6/raw/053ff455afa2ecb656e34f23a51da445177eeab2/SOLRUM55.R0.lst [18:31:57] correct number of pages, and all of the checksums are correct, at least :D [18:32:17] looks pretty clean [18:32:24] now that there's no assembly errors I need to give it a once over to make sure all of the page boundaries are happening in the right places, but solarium and block 1 assembly are pretty much done [18:32:37] awesome :D [18:33:17] have you thought about actually printing the punch cards? Having an AGC version as punch cards seems strangely appealing, haha [18:33:43] hell yeah I have, haha [18:33:48] I need to talk to Marc about the feasibility of it [18:33:57] the other thing we could potentially do is reprint listings [18:34:39] I'm really curious how many cards Luminary is going to be [18:35:54] many [18:35:56] https://www.ibiblio.org/apollo/ScansForConversion/Solarium055/0776-P1140706.jpg [18:36:01] what's that below LXC [18:36:36] oh [18:36:43] it separates per letter [18:37:20] interesting alphabet [18:37:36] "G", "H", "I", ".", "-", "J", "K"... [18:38:41] I just saw that separator in your listing and thought it might be some error, haha [18:55:10] hahaha yeah, the honeywell character set is funky [18:55:21] I don't know why they put symbols in between letters at various points [18:56:20] because I have to sort by it in a few places, I put it into the code... one sec [18:56:32] https://github.com/thewonderidiot/pyul/blob/master/pyul/yul_system/types.py#L8 [18:56:34] there you go [18:56:44] all of the characters of the H-1800, in "alphabetical" order [19:16:37] 9 letters of the alphabet, some other stuff, 9 letters, some other stuff, 8 letters [19:17:54] probably some numeric reason to have it like that [19:19:08] https://raw.githubusercontent.com/jimlawton/h800/master/docs/prm/images/table_I.png [19:19:43] yeah [19:19:47] but I'm not sure I see it :P [19:24:10] well if I start with / instead of S for the third block there is a bit of a pattern [19:24:23] so Z is the 9th symbol in the last block then [19:24:27] haha yeah, the / really throws it off [19:25:21] now that I'm thinking about it -- there's no checks whatsoever in Yul for something to be strictly alphabetic [19:25:37] there's plenty of numeric checks (which is easy, all characters < 10) [19:25:51] but I guess determining if something is just letters is too tricky to bother with [19:33:45] right [19:41:14] I do wonder if some of these weirder characters (triangles and squares and things) were used for some off-line program names :P [20:02:26] haha [20:02:42] that would be some weird program names [20:03:56] lots of triangles with "Illuminati" and "Kubrick" mixed in probably [20:43:34] hahaha oh man [21:20:04] good night! [17:36:52] hey [17:47:26] hey Alex [17:47:54] I have a plan on how to get out of the development branches and back to the main branch [17:48:13] working on TLI again now, and that branch will be merged first, hopefully soon [17:50:06] and then I'll move the new TLMCC stuff in [17:52:38] step by step [17:58:44] nice [17:58:57] makes sense [18:01:41] I had to put a factor on the DV optimization in TLMCC option 2, to make the optimization weaker [18:02:04] it overpowered the other constraints, like having the lunar orbit at 60NM [18:02:28] not really sure why that is, I think I have implement it correctly [18:02:33] but it works quite well with that [18:03:13] and also made one big step on the C++ side, I had trouble putting the Generalized Iterator outside of the new TLMCC class [18:03:20] morning! [18:03:30] but that is now solved, so it's a general method that will work for other processors as well [18:03:41] so I saved all that stuff and it will wait there until I merge it [18:03:44] hey Mike [18:03:49] what's up? [18:04:17] testing the new TLI simulation in the RTCC [18:09:28] one fundamental thing with it I haven't 100% figured out yet, although it sounds so simple [18:10:07] "4. A maneuver is presently considered to have a seven phase thrust profile of which four are considered to have fixed-time durations, while the other three are variable." [18:10:31] what are the 7 thurst phases? :D [18:10:44] hahahaha uhhh [18:11:22] I have a lot of hints, but they don't get me to 100% [18:11:40] so like, ullage, ramp up, steady state, tailoff [18:11:44] that's only four [18:11:46] yeah [18:11:57] there also is a mixture ratio shift [18:12:05] so at least two phases for the main burn phase [18:12:13] I have no idea, but I expect all 7 in perfect detail Niklas :D [18:12:18] hehehe [18:12:38] oh yeah, I have implement it basically 1:1 from the IBM RTCC documentation [18:12:45] but that doesn't give numbers [18:12:56] and doesn't even name all the phases [18:13:32] and one other RTCC document has numbers, but it has the second full thrust phase as the 5th phase [18:14:00] so until now I thought this [18:14:28] 1. vent and ullage, 2. chilldown, 3. buildup, 4. pre MRS, 5. in MRS, 6. after MRS, 7. tailoff [18:14:44] that sounds pretty reasonable [18:15:25] but that makes the 2nd main thrust phase the 6th phase, not the 5th [18:15:42] oh hmm [18:15:46] found another hint [18:15:57] phase 7 might actually be post tailoff venting [18:16:21] ah, so maybe "in MRS" isn't a phase and is just assumed to be roughly instantaneous? [18:16:27] yeah, could be [18:16:47] the IGM treats it as a separate phase (1 second) [18:17:00] but that doesn't mean it actually simulates a separate thrust [18:17:21] 1. vent and ullage, 2. chilldown, 3. buildup, 4. pre MRS, 5. after MRS, 6. tailoff, 7. more venting [18:17:55] that must be it [18:18:12] the IBM has high and low thrust values for the 5th phase [18:18:39] and that lines up with the numbers in the Apollo 11 RTCC Preflight Information document [18:18:49] has separate numbers for that, also fifth phase [18:18:57] that would be 1st and 2nd TLI opportunities [18:19:10] thrust is not 100% the same for those [18:22:00] 592 seconds post TLI venting phase [18:22:15] quite a bit, and would also be mission dependant [18:22:29] oh wow that is long [18:22:42] what are they venting there? [18:25:52] LH2 [18:26:19] LOX is vented later, for a slingshot or lunar impact maneuver [18:28:01] they have more than one method to vent LH2 though [18:28:28] not sure where this 592 seconds number is coming from, probably an approximation [18:28:56] all valves on the S-IVB are closed when the S-IVB starts maneuvering for sep, at 900 seconds after TLI [18:29:24] ah, gotcha [18:32:49] on later missions they did even more venting just after TLI and let the accelerometers running, so that the IU state vector is more accurate [19:52:31] Ocean of Storms has now got some higher resolution surface texture, like Hadley did [19:52:50] You can definitely see the snowman very well now [19:55:50] maybe we can include these in NASSP, 4throck seems to have indicated that this was allowed [20:38:23] yeah, sure [21:05:32] night! [15:37:49] hey [15:42:24] hey Alex [15:46:09] any luck on the 7 thrust phases? :D [15:49:11] well I have implemented it as we talked about yesterday, with tailoff and tailoff vent phases after cutoff [15:49:18] debuggin my way through the code right now [15:51:57] so the TLI pad will now be very accurate with this work I assume? [15:53:30] yeah, this simulates a whole TLI, timestep by timestep, while the old method just used the conditions at ignition to get a cutoff state vector [15:53:46] although this will end up with all the other maneuvers on the Detailed Maneuver Table [15:54:05] I'll have to check if the DMT has all the numbers for the TLI PAD [15:54:11] and if not, where else they got the numbers [15:59:35] I see [16:00:11] I'm not sure about the TB6 time [16:00:38] that time is definitely saved in the MPT [16:00:54] but on the DMT it always displays the main engine on time [16:02:28] maybe they manually subtracted 9m38s? [16:02:36] possible [16:02:43] that time would probably be displayed as the ullage time [16:03:01] TLI attitude is on the DMT [16:03:22] very accurate burn times, DV for the EMS and inertial velocity at cutoff are on the DMT [16:03:48] sep and extraction attitude require an extra step [16:04:13] the FIDO put a 0 DV maneuver on the MPT at the time when the S-IVB starts maneuvering [16:04:31] and specified a LVLH attitude for that maneuver [16:04:38] that gets you the sep attitude [16:05:12] alternatively I could change the TLI PAD calculation to be MPT compatible [16:05:29] so it takes the SV from the MPT and calculates all the PAD values in one go, as it does it right now [16:05:49] sure [16:08:00] I mean in the long term I want to completely move to the MPT concept of adding maneuvers [16:08:17] but I'll probably win over people more easily by keeping the one-button-click PAD calculations :D [16:10:30] and that will be even nicer if you can calculate Maneuver PADs for all the maneuvers in the MPT whenever you want [16:10:48] instead of just the latest maneuver that was calculated anywhere in the RTCC MFD [16:13:44] I think I am with you on getting it as realistic as possible, but I guess the the pad crowd wouldnt be happy [16:15:01] I mean, I doubt the FIDOs were overly happy with this system, haha [16:15:13] they had it better on Shuttle [16:17:31] I guess if you want to be as hard-core as possible, you calculate everything you need for maneuver pads, without ever going to the maneuver pad section? [16:17:55] just using the DMT, etc [16:20:18] sure, only tools that were available to the flight controllers and their staff [16:22:42] and I can write some guides for that [16:22:48] based on the Apollo 11 MOCR audio [16:24:41] in most cases you can follow along, as ever interaction the FIDO has with the RTCC goes through the person with the callsign Dynamics, so we have the audio of it [17:11:45] off to work, cya! [18:39:03] hello? [18:39:27] hello! [18:40:40] wondering if you could give me a hand. I'm struggling to get my joystick set up with NASSP. specifically the TTCA throttle/jets controller on one joystick [18:41:42] sure [18:41:59] so you have one joystick, set up as the TTCA? [18:42:20] I have one joystick that runs as a combined aca/ttca [18:43:05] ok [18:44:18] so, on the Controls page [18:44:43] THC/TTCA enabled should not be checked, I think that is only for a 2nd joystick [18:44:58] RHC/ACA enabled should be checked [18:45:07] and then the "If only the RHC..." should be checked [18:45:52] there all checked and the id's are set [18:46:10] what does aca with throttle slider do? [18:46:33] gives you a throttle slider when the joystick is an ACA [18:47:09] the TTCA has the throttle control in the pitch axis and the lever is the control for throttle/jets [18:47:54] right. so it should now register the throttle slider on the joystick as the throttle/jets controller? [18:47:59] but I am not sure right now what "ACA with throttle slider" does in the combined ACA/TTCA mode [18:49:04] yeah, the throttle slider should be the controller for throttle/jets [18:49:48] and that is not working? [18:50:00] thanks. thats all i needed help with. [18:50:04] bye! [18:50:07] oh [18:50:10] ok, no problem [19:41:15] morning! [19:46:24] hey Mike [19:48:42] what's up? [19:50:21] untangled some coordinate system issues in the RTCC TLI code [19:50:24] always "fun" [19:50:28] but I figured it out [19:50:40] haha yeah that is always fun [19:52:10] the IBM documents were quite inconsistent there [19:52:41] I just replaced it with the code from the actual LVDC equations [19:53:46] hahaha that works :D [21:37:12] night! [19:18:21] morning! [19:22:15] hey [19:23:33] what's up? [19:25:51] made good progress with the TLI sim [19:26:07] I thought to myself: why solve something we already solved? [19:26:43] so I flew an Apollo 11 TLI, saved the debugging log from that, and I basically had a huge file of all the expected numbers [19:26:53] that was very, very helpful for debugging [19:27:54] I expected to get everything up to ignition right today, but I almost got to TLI cutoff even [19:28:11] there is some weird instability at the end, so probably some more bugs, but it's looking good [19:29:27] oh man, awesome! [19:32:03] coordinate systems keep being fun, as the RTCC version of this works a bit differently [19:32:15] than the actual LVDC code [19:35:16] somehow I am not surprised :P [19:36:58] oh, also fun is atan vs atan2 [19:37:16] when the expected value is 120° and it says to use atan and not atan2, then something is not right :D [19:37:58] but I've been through that with our actual LVDC code, so I trusted whatever we used there [19:41:18] oh yeah [21:03:05] night! [18:34:19] morning! [18:41:46] morning Niklas [18:42:15] hey, good evening [18:42:25] hey guys [18:42:54] RTCC TLI guidance is basically done [18:42:56] buuuuut [18:43:21] I'm not so sure about the last few burn phases anymore :D [18:43:37] the code indicates quite strongly, that the phase just after cutoff is the last phase [18:44:37] as opposed to tailoff/venting as we were thinking? [18:44:48] yeah, I'm not so sure about that anymore [18:44:51] hmm [18:45:40] most of the remaining issues I had with the IGM equations were unitialized variables being used. I had them as local variables and they were actually global (class wide) [18:45:51] they got set to 0 once in the code, but not on the following timesteps [18:46:15] so simple to fix. Works all quite well up to cutoff now [18:46:40] so the last obstacle is just the phases thing [18:46:45] right [18:48:04] it's not a difficult issue over all, but I would like to find the solution that requires the smallest number of modifications to the program flowchart in the IBM RTCC documents [18:49:38] Im thinking of maybe flying Apollo 12, to test the new RTCC stuff [18:50:36] well it won't be long until the TLI stuff is ready [18:50:46] and some new TLMCC stuff will follow a bit later [18:51:04] ok [18:51:47] main objective for me is to get the new MPT (with TLI) merged in the main branch [18:51:57] im sure all that will need some testing, maybe ill wait [18:52:25] right [18:57:56] I can't even check the 501/502 TLI guidance to figure out the phases [18:58:05] as those were still different [18:58:10] only 5 phases for some reason [18:58:20] and closed loop propellant utilization [19:04:01] 5th phase has two possible thrust values. And that is definitely for the post MRS phase [19:42:30] hmm, as written in the flowchart it would actually jump from phase 5 directly to 7 [19:42:53] I think that's what I will do, we don't simulate propulsive venting yet anyway [19:43:22] I'll ignore what phase 6 might be, I'll ignore tailoff venting and will use phase 7 for the normal tailoff thrust [19:44:14] is it possible that they planned for having up to two mixture ratio shifts? [19:44:26] if they normally skip past the 6th phase? [19:48:07] not a second mixture ratio shift, but maybe some other thrust change if the burn goes very long [19:48:22] that doesn't really correspond to the RTCC Preflight Information numbers though [19:48:28] but that never talks about phases 6 or 7 [19:48:38] only up to 5, which is the main burn [19:48:42] post MRS [19:50:05] ah, haha, now I run into the hopefully last issue [19:50:13] a "goto" that doesn't actually go anywhere :D [19:50:36] hahaha [19:53:49] I'll ignore that as well [19:54:04] and with that I get to the break point of the TLI simulation loop [19:54:18] \o/ [19:54:32] so the last task is writing out all the outputs of the routine [21:04:23] does the TLI simulation still use the LVDC presttings, or is it a new scheme altogether? [21:06:35] it does load numbers from the LVDC++ [21:07:57] although that is not the complete answer [21:08:29] the RTCC has global system parameters for anything that might be mission specific, but not launch day (or even TLI opportunity specific) [21:09:21] I have loaded default numbers for those, but they should probably also be different for each mission [21:10:22] and then there is a large table in the RTCC with all the numbers for the daily launch window [21:10:33] those would be identical to what is loaded in the RTCC [21:10:36] LVDC* [21:10:56] and those are copied from the LVDC++ right now, basically as it was done before, just a few more [21:11:22] I still need to go through all these constants and make sure the LVDC++ and RTCC are fully consistent [21:13:45] and the other half to that is the values the RTCC simulation uses for the e.g. actual S-IVB thrust [21:14:09] those are all system parameters and they should of course be as consistent as possible to our S-IVB [21:14:52] I have a few mission specific RTCC documents with these numbers, for now I have loaded those and not necessarily exactly what we use in our S-IVB [21:17:31] it gets a bit complicated talking about these things, it's a simulation within a simulation :D [21:18:16] but after TLI there is only one big guidance program of the RTCC we don't have yet, which is reentry guidance [21:18:39] which we would need for a few more Entry PAD numbers [21:19:23] ah yes [21:19:38] what about the PDI simulation? [21:19:52] we have that [21:20:09] you can put a powered descent on the MPT [21:20:16] ah ok [21:20:19] and it's also used in the descent abort program [21:20:37] I was thinking of the one in the decent planning processor [21:20:47] descent abort constants program* [21:20:50] says N/A on it but maybe thats not the same thing [21:21:05] I only need to make the descent and ascent simulation store more state vectors in an ephemeris [21:21:15] oh right [21:21:18] the LDPP [21:21:21] hmm [21:21:45] I think that should use the same PDI guidance to calculate a few display parameters [21:22:23] it should do that for any LDPP option involving PDI and of course the "PDI only" option you mentioned [21:23:44] that will get implemented [21:24:14] I need to make some space on the lower half of the LDPP display, that's where a bunch of PDI numbers should appear :D [21:29:45] https://i.imgur.com/hmavyOa.png [21:31:51] ah I see [21:32:08] so that display would be in the LDPP [21:35:03] yeah, that is the display of the descent planning processor [21:35:45] and while the PDI simulation program of the RTCC would be used in a few places (in the RTCC internally), the main way the FIDO or so would interact with it would be on that LDPP display [21:36:17] the LDPP init page has an option to calculate a PDI or not [21:37:03] so that will definitely be implemented soon [21:38:06] also, with the TLMCC changes coming up, will the non-free burns in Apollo 12+ now be much closer to reality? I believe we got them close but with lots of tweaking of the lunar TOA and other variables which I am guessing the real thing would optimize automatically? [21:41:09] hard to say right now if it will be closer [21:41:57] I haven't been able to fully figure out the whole LOI/DOI geometry calculations for Apollo 14 and later [21:42:32] but I would expect results very close to actual for any maneuver that used the TLMCC before that change [21:42:53] right [21:45:21] Apollo 12 might be a good test case for the TLMCC updates I guess [21:46:01] yeah, probably [21:46:17] although that mission probably has one of the worse LVDC presettings [21:46:24] worst is Apollo 10 for some reason [21:46:57] Apollo 12 had a fairly bad TLI due to an inaccurate accelerometer [21:47:12] and I had to use the actual trajectory to get the LVDC presettings for that mission I think [21:51:59] good night! [15:28:28] hey [15:28:57] good news, TLI can be put on the MPT now. Bad news, it only works in debug mode :D [15:35:52] hey Niklas [15:36:05] bummer ;) [15:37:11] that usually means some unitialized variable is used [15:37:45] trying to find where it fails right now [15:38:07] it fails before the TLI simulation itself [15:40:49] a bit annoying to debug obviously, haha [15:40:57] would be better if it only failed in debug mode [15:43:15] I might have found it. Simple case of unitialized variable. Was 0 by luck so far in debug mode, but now it has a random non-zero number [15:43:24] which is bad [15:43:53] yessss [15:47:18] got it fully working [15:48:08] https://i.imgur.com/VIAZX2l.png [15:48:17] might have to work on formatting that page a bit more [15:48:36] it didn't need so large numbers so far [15:50:56] the numbers here are within 1 second of the burn time on the flown Apollo 11 TLI PAD [15:50:58] and with 1 ft/s [15:51:02] within* [15:51:35] I'm using more of the actual RTCC parameters than numbers that are adjust to our current S-IVB [15:54:28] nice! [15:55:11] can you also generate useful numbers in the case of a manual TLI? [15:55:53] not sure what you mean [15:56:09] how would they be different? [15:56:29] oh you mean the different attitude profile? [15:56:37] yes [15:56:48] no, it doesn't simulate that [15:56:57] what the tables show [15:57:09] but the final orbit for the manual TLI is the same as automatic TLI [15:57:25] it's just less efficient to have a constant yaw [15:57:42] what can be simulated is an early TLI cutoff [15:58:23] and a constant attitude maneuver of some kind [15:59:27] the cue cards for manual TLI were probably generated with some other tool [15:59:48] some non real-time program used to simulate before a mission [16:00:48] right [16:01:02] those work very well anyway [16:01:09] yea [16:01:28] I guess if we want to generate some of our own we would use some average yaw angle [16:02:18] ah, the early cutoff functionality is for TLI maneuver confirmation [16:02:34] before TLI you put that maneuver on the MPT [16:02:48] and if you had an early TLI cutoff you can then confirm the maneuver by saying how long the burn was [16:03:12] and that gives you a pretty good estimate of where you ended up on the executed partial TLI [16:03:51] that is usually done after a maneuver was executed, to get an initial estimate of a new state vector, before new tracking data [16:08:41] the other program that would use the TLI simulation is the TLI Planning Display [16:09:19] basically like our TLI calculation on the TLMCC page [16:09:55] although the TLI Planning Display input MED doesn't appear anymore in the Apollo 11 MED list... [16:54:24] haha [16:54:44] fixed a few bugs and now I can also plan maneuvers after TLI [16:54:54] so I gave it TLI and the evasive maneuver [16:55:09] resulting MCC-2 is: -5.7 -0.3 -18.0 [16:55:28] and in our Apollo 11 pre MCC-2 scenario the DV on the Maneuver PAD is: [16:55:41] -4.5 -0.2 -18.7 [16:55:46] pretty amazing [16:57:25] great [16:57:35] so I guess its working pretty good now [16:57:50] yeah, seems like it [16:58:12] I can probably push the update to the testing branch [16:58:19] and then in the next few days get it ready to be merged [16:59:05] sure [16:59:18] IO can give it a test [16:59:21] I* [17:00:03] oh, if you couldn't make sense of some of the numbers on the DMT I posted earlier [17:00:09] some of them don't make sense yet :D [17:00:35] mostly the ones that need a REFSMMAT [17:00:42] OR, IP, MY are the IMU angles [17:00:58] for Outer/Roll, Inner/Pitch, Middle/Yaw I guess [17:01:06] outer gimbal etc. [17:01:17] and YB, PB, RB are FDAI angles [17:01:23] should be the same as IMU for CSM [17:01:34] which it isn't right now, haha [17:06:13] ok [17:07:44] let me give you the reference document [17:07:54] https://web.archive.org/web/20100519051814/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740075028_1974075028.pdf [17:08:14] PDF page 58 to end [17:08:25] full description of the DMT [17:08:33] and that will of course end up in the RTCC MFD manual as well [17:10:35] that document also has descriptions of a bunch of other displays [17:10:48] one of my better sources for displays, I don't have that many [17:11:40] although it isn't even about the RTCC, but the RTACF [17:11:57] thanks [17:12:25] "Most of the output is in the form of displays which are similar to the displays in the Real-Time Computer Complex (RTCC) program. The displays vary from the RTCC displays in that no Greek symbols can be [17:12:25] used and the displays are static while the RTCC has dynamic displays." [17:16:01] does the TLI simulation work with all missions yet? [17:17:21] I have only tested Apollo 11 so far [17:17:26] but I would hope yes [17:17:40] all missions should have enough presettings for it to work [17:17:45] ok [17:17:53] I have some scenarios I can use to test [17:18:33] sound good [17:36:04] AlexB_88, using the onboard method to calculate a preferred REFSMMAT [17:36:10] so P30, P40, P52 option 1 [17:36:17] is that heads down or heads up? [17:36:45] hmm, good question [17:36:47] I was thinking down, but not sure [17:38:28]