[16:52:42] NASSP Logging has been started by indy91 [16:52:44] dice have advantages [16:52:52] the science can continue without electricity [20:29:07] night! [13:52:56] hey Alex [14:14:04] hey [15:29:24] hi Nik [15:35:39] hey [15:45:14] hey Niklas [16:16:49] I'm doing my best to avoid some sort of "iterate to find the correct pressure" in my update script. hopefully I can make this function of density work [16:18:15] although I do have Matlab versions of some of our systems calcs that I could probably port over to Python... [16:32:08] morning! [16:32:19] indy91, how close is the Cue Cards branch to merging? [16:32:25] hey Mike [16:40:21] hey [16:40:29] AlexB_88, I think I'll just going to merge it as-is [16:40:37] not perfect, but stable haha [16:40:44] I'm* [16:42:01] most of the further improvements are not in my skill range, the meshes and textures [16:42:16] for more missions, tweaking the current positions etc. [16:42:25] the code is in a good state [16:42:37] maybe some click spots can still be improved [16:42:40] and then of course [16:42:41] the LM :D [16:42:45] next cue card project [16:43:38] agreed [16:44:47] just playing around with it now and I think its in a good state [16:49:01] I did some testing with it this weekend. I say merge it. [17:01:31] while I'm thinking of it. we should make a post on the forum about maxQs eva stuff. I think there may be a few other things we haven't added there recently. [17:07:15] oh yeah. like my ground station bug fix [17:09:06] yep, those all and also the cue cards deserve a mention [17:21:49] oh yes, definitely [17:22:19] the cue cards are what made me think of it [17:29:45] indy91, could we merge it right now? [17:35:15] uhh yeah I guess. Let me take a last look [17:37:28] ready for review :D [17:37:36] ... and now I need to write a post for the forum [17:38:17] and we do need some more cue cards, some of the defaults right now aren't as generally applicable as I would like [17:38:31] approved [17:38:53] yep I am actually trying out Apollo 17 cue card textures right now, for fun [17:39:59] ah [17:40:13] well I was mostly worried about the boost cue card showing 90 NM insertion :D [17:40:26] or did I make the Apollo 14 default, I already forgot [17:40:36] but there are some issues like that with the Apollo 15 cards [17:40:42] TLI with P15 etc. [17:41:09] right [17:41:43] if you wanted to make those "mission specific" I think it would be better to make some lines in the file that the LGC and CMC version are specified in rather than an if(Apollo 14) [17:41:53] etc [17:42:25] oh yeah that is already implemented [17:42:38] you can define mission specific ones in the mission files [17:42:45] oh awesome [17:42:49] we just don't have meshes and texutures for that yet [17:43:00] my main example was the boost card [17:43:06] we have 14 and 15 right now [17:43:20] wow i did not look as closely at the code as I thought it did haha [17:45:34] aaah I think by default we have no boost card at all [17:45:47] I guess I deleted that because of the wrong numbers for the early missions [17:46:01] so we have mission specific ones only, for 14 and 15 [17:47:02] AlexB_88, did you add a Apollo 17 card with that mission file feature? [17:47:50] I already forgot again how exactly you do that [17:48:52] but I guess it's rather simple [17:48:54] CSMCueCard1=1 SATURN_BOOST_A15 [17:49:20] that whole thing with CSMCueCard1, CSMCueCard2 etc. is a bit stupid, but I would have to rewrite the entire mission file loading code to make that better [17:49:23] will do eventually [17:49:37] oh [17:50:37] I guess that means no? :D [17:50:42] I was just backing up/changing the textures in Textures\ProjectApollo\VC\CueCards [17:50:55] but that was just to test [17:51:20] but I did not know the mission specific handling was already implemented [17:51:21] well you should be able to add it as separate mesh and texture and add a line to the Apollo 17 mission file [17:51:27] ah [17:52:13] PR as many cue cards as you like, this is the part where I am dependent on other people haha [17:53:54] so something like [17:53:57] CSMCueCard1=1 SATURN_BOOST_A17 [17:53:59] should work [17:54:03] if the mesh exists [17:54:59] ok btw, there was a forum post where you probably know the answer best [17:55:01] https://www.orbiter-forum.com/threads/lm-vc-debug-string-not-updating-during-p64.41153/ [18:01:58] ah yes [18:02:08] Ill take a look tomorrow [18:12:48] cya! [18:25:41] thewonderidiot, I'll do something scary now. git merge with my BlockI branch :D [18:26:11] just want to see how many conflicts I will actually get [18:27:02] ok, already an issue just with checkout haha [18:27:18] hahahaha oh boy [18:27:47] oh speaking of Block I, we don't have an AS-202 padload do we? are you expecting many changes there? [18:28:07] should be very doable [18:28:38] I know target orbit for the SPS maneuver and such [18:29:30] I don't want to work with Excel spreadsheets anymore, maybe I'll add very rudimentary support in my padload generator [18:31:33] about 30 files with merge conflicts [18:32:19] so... maybe [18:32:22] but a lot of work [18:32:27] not great, not terrible haha [18:35:10] lots in the LM. I should just get rid of the LM entirely in this branch [19:27:23] I'll try cherry picking the FDAI and DSKY updates [19:27:32] that's mostly what I am worried about [19:27:41] everyone asking "why is it the old textures" [19:42:22] you could claim you are using Block I colors :P [19:48:50] seems to have worked. I think I can finally appreciate squashing commits, would make this easier [19:51:37] I'll get started on understanding Block I padloads again [19:54:08] Solarium seems to be happy still [19:54:39] do you think the padload addresses moved around at all between 202 and 501? [19:55:14] curious how much of this thing I'm going to have to disassemble before you can fly it [19:58:36] I really don't know [19:58:47] ask me in a few days when I am a Block I padload expert again :D [19:58:52] hahahaha gotcha [19:59:16] https://www.ibiblio.org/apollo/Documents/Programming%20Changes%20from%20AS-202%20to%20AS-501.pdf [19:59:21] yep [19:59:24] this document is going to be our lifeline for this [20:00:10] I have no idea what WTRWD is. will be interesting to try to identify it haha [20:07:30] "New Re-entry Package" [20:07:31] uh oh [20:07:35] that sounds like entirely new code [20:09:27] yeah pretty sure it didn't behave very well during the AS-202 reentry [20:51:00] night! [12:39:59] hi Alex [12:42:51] hey [12:42:58] whats up? [12:44:11] I finished my scenerio update script last night so that should be ready to go. [12:46:23] ah nice [12:46:35] unfortunately it looks like my N2 pressurization project and liquidDensity project are a bit too interwoven to merge separately. I guess I could manually separate things but it seems like a lot of work for a slightly cleaner comit history [13:45:52] have you looked at the hatch normals PR, I meant too but was in the middle of some things that made switching branches a bit impractical [13:46:25] not yet but based on the pictures looks great [14:04:21] ughh [14:04:30] damn GitHub [14:06:39] https://www.dropbox.com/s/kbpvmrmc238as51/Screenshot%202023-04-20%2010.04.42.png?dl=0 [14:07:40] its has been ages though since I pushed from this laptop [14:16:14] something happened with GitHub recently, like all their SSH keys were hacked or something. so that's probably why. might need to log in again or something [14:53:47] hey [14:54:42] thewonderidiot, I don't think AS-202 will be so bad with address differences, but there are scaling changes which I always "love"... [14:54:53] morning! [14:55:05] lol yeah I'm sure those will be "fun" to deal with [14:55:30] Solarium support in the padload worksheet taking shape, might get that done today actually [14:55:33] padload generator [14:55:39] I already had a worksheet :D [14:56:44] Sunrise might help with the scaling being used [14:56:56] we had those difference to Solarium [14:57:02] we saw* [14:57:31] hey Niklas [14:57:34] hey hey [14:58:44] about the Cue Cards, can you overwrite the default cards (A15) or is it always the default ones + mission specific cards that you cycle through? [14:59:17] I think I had forgotten to push a commit for the cue cards branch actually, getting rid of the Entry attitude timeline one. oops :D [14:59:28] no big deal [15:03:21] AlexB_88, ok, I think I had encountered some issues with overwriting default cards and removed it again [15:03:46] which is annoying, I want that back [15:04:19] I think right now if you want to make something mission specific you have to start loading it in all mission files and remove it from the mission class code [15:04:57] right as I see how it works right now, you simply add another card on top of every position [15:05:26] ah right [15:05:41] I guess that will make for very long mission files :D [15:06:02] a lot of these cards are mission specific anyway, so that was always going to happen [15:06:09] right [15:06:18] but I will look at adding it back [15:06:22] overwriting [15:07:07] oapiReadItem_string [15:07:15] super dumb oapi function [15:07:18] I regret using it :D [15:07:33] it searches through files for a particular line [15:07:55] which is different from e.g. scenario loading, there it checks line by lines and looks if it should do something [15:08:41] so that prevents having the same item (e.g. "CSMCueCard") more than once [15:09:02] that's why the mission files have CSMCueCard1, CSMCueCard2 etc right now [15:09:28] and somehow the overwriting of files was related... [15:09:57] I had to revert a bunch of code when I found this oapiReadItem_string limitation [15:25:03] ah right [15:25:43] btw I I tried a launch abort and the cue cards disappear when the CM separates [15:26:00] they can be recovered by clicking again though [15:31:27] oh [15:31:36] I thought I had specifically implemented code to prevent that [15:31:45] it works with Saturn staging [15:32:26] pretty sure I also tested CM/SM sep [15:32:32] so not just what breaks at an abort [15:32:36] not sure* [15:33:15] how would you like the replacing of cue cards implemented [15:33:24] a number in the mission file? [15:34:04] or what would work a little better in code actually is the mesh name. So you give it a new mesh name and a name of the one to be replaced [15:34:11] not sure how intuitive that would be though... [15:35:02] you a number you would have to think things through [15:35:16] like, every time a card gets added the number would shift [15:35:41] so maybe giving both old and replacement mesh name is better [15:35:59] with a number* [15:40:21] uhh, and then again oapiReadItem_string gets in the way. I'll just rewrite the loading code entirely [15:47:03] maybe the easiest way is just to define every card in the mission file [15:49:03] hey Niklas, Mike [16:33:31] hey Matt [16:33:41] AlexB_88, easier yes, better probably not [16:33:58] how bad would it be if I make changes to the mission file format [16:34:11] as in, custom files would break and need an edit [16:44:36] hmm good question [16:53:53] indy91, btw Ive started a side project...one that I *promise* not to ever merge to the main branch haha...it will just always live in my own online repo if ever anybody wants to try it [16:54:05] Apollo 17 MCC [16:54:12] sounds like my Block I branch haha [16:54:21] ah interesting [16:54:26] well have fun implemeting that :D [16:55:12] it will take a while lol [16:56:11] the presettings inspired me [16:56:32] ah great haha [16:56:46] I want to see if I can make it handle liftoff time updates [16:58:12] shouldn't be that complicated really [16:58:19] not anymore [16:58:29] in the early days of the RTCC MFD it was very difficult :D [17:00:52] right [17:01:04] Im using the late launch scenario [17:01:38] after frantically looking for TIME0 I was able to launch :D [17:02:04] ARCore has them all [17:02:33] 41133.0 [17:03:05] TEPHEM0* [17:03:30] July 1st 1971 [17:04:03] Apollo 17 broke the "yearly" coordinate system [17:32:06] hmm [17:32:31] I am pretty sure I am seeing a really bad bug with the cue cards [17:32:51] I think I failed at merging a merge conflict [17:33:28] cya! [17:33:52] it lost a few lines and is now doing cue card loading code when it reads LMPSuitName from the mission file :D [17:35:33] not my greatest work [17:39:17] haha [17:50:20] my update script oddly worked on the first try and I'm veeeeeery sceptical that something isn't wrong and I'm just not seeing it. [17:53:05] haha [17:53:08] I've had that once [17:53:17] a very complicated thing actually [17:53:20] the DEDA [17:53:30] I just couldn't get it connected right to the AEA [17:53:34] nothing was working [17:53:45] until it just did [17:53:54] and I haven't change one line of code of that since then [17:54:20] so it wasn't first try [17:54:27] but there was no step in between [17:54:41] 0% working to 100% working [17:54:48] well, 99% [17:54:56] there is some scenario loading issue with the DEDA [17:55:11] AEA is pushing some data to it on scenario load that I don't understand [17:55:16] but 0% to 99% :D [17:56:43] so sometimes it can happen [17:58:38] I also have a few dozen hours into the math, and I copied and pasted a function for the parser that I knew worked, so there's that [18:00:53] that helps :D [18:38:01] I can't remember if or where I mentioned it, but I'm fairly certain that I can't untangle the N2 pressurization branch from the liquid density branch. so my goal is to get the other things merged first and then they can get merged together [18:38:38] to not create any more chaos I will leave branches as they are for the time being [18:51:52] hmm ok, sounds fine [18:53:48] what would you find easier to work with in the mission file. Let's say there is a cue card called SATURN_BOOST_DEFAULT [18:53:52] mesh and texture [18:53:57] and it gets loaded by default [18:54:14] I can imagine two options [18:54:16] ReplaceCSMCueCard SATURN_BOOST_DEFAULT SATURN_BOOST_A14 [18:54:21] to put in the mission file [18:54:39] the logic would then search for the mesh name SATURN_BOOST_DEFAULT and replaces it with SATURN_BOOST_A14 [18:54:50] so it would load the Apollo 14 one instead [18:54:52] or other option [18:55:07] ReplaceCSMCueCard 1 0 SATURN_BOOST_A14 [18:55:29] where 1 is the location of the cue card and 0 is the number in the cue cards of that one location [18:55:35] each location can have multiple ones [18:55:56] in the first case you would have to know the name of the default mesh [18:56:05] in the second case its exact location and number [18:58:04] part of me dislikes having default cards at all because on most of the cards is a specific launch date printed, even when the numbers or procedures on it would (roughly) apply to more missions [18:59:23] but for custom and fictional missions we would want something at least [19:12:44] for custom missions it could be more flexible if we allow fully definable cards. defaults could get in the way [19:13:22] the only real downside is longer config files and we have some documentation to do [19:14:31] right. I guess we can still e.g. load an Apollo 14 card in the Apollo 11 config file as long as the numbers and procedures roughly apply [19:14:48] mission file* [19:15:33] as a test I am just making a copy of the Apollo 14 boost card [19:15:35] calling it default [19:15:46] let it still load the Apollo 14 texture to save space [19:15:59] and then I would make all 100 NM missions load that one [19:16:40] and then we could add more mission specific ones when someone makes them [19:19:50] ah that just could confuse someone in the future if SATURN_BOOST_DEFAULT loads the SATURN_BOOST_14 texture... [19:20:03] I can just add SATURN_BOOST_A14 to the Apollo 8-14 mission files [19:20:15] and no replace option [19:20:24] and defaults would indeed go away over time [19:22:12] with custom missions people would probably start from an existing mission file anyway [19:22:22] so that's how you get "defaults" [19:33:17] I like it [19:34:07] it might make it easier if someone ever makes a "mission editor" [20:36:05] night! [12:42:39] good morning [12:45:40] hey [15:28:31] the mission sequence files are just a bunch of defines and a large switch-case right? [15:28:48] I wonder if we could load them from a text file? [15:29:04] hi Niklas [15:30:23] hey [15:31:28] hey Niklas [15:32:17] im trying to get a fixed GMT time and convert it to GET [15:32:24] that GMT time is the LOI time [15:33:23] what the time from the skeleton flight plan table? [15:33:25] maybe the* [15:33:38] I think the GETfromGMT can be used for that [15:33:46] let me check [15:34:56] yeah GETfromGMT uses the current RTCC liftoff time [15:36:00] trying to figure out how to send the GMT in that function [15:36:04] is it in seconds? [15:36:22] yes [15:36:42] sorry for the mixture of units in the RTCC, at one time it will be all hours. It is not that time yet... [15:37:39] but the GMT/GET conversion functions is definitely still seconds [15:37:47] even if the RTCC liftoff time is internally stored in hours [15:38:44] so like [15:38:47] GETfromGMT(320138.0 - SystemParameters.GMTBASE) [15:38:50] ? [15:39:15] hmm [15:39:19] what are you trying to do? [15:39:22] GMTBASE is a MJD [15:39:25] in days :D [15:39:33] you shouldn't need to access it directly anyway [15:39:40] ah right [15:39:54] just trying to get a get from a specific GMT [15:39:56] is 320138.0 your GMT in seconds? [15:40:14] you are trying to do it manually but still call the function for the conversion?? [15:40:15] 320138.0 is the GET of a nominal launch LOI [15:40:17] oh [15:40:20] uhh [15:41:30] I mean, the RTCC won't have a nominal liftoff time stored [15:41:34] only actual [15:42:20] I am trying to get the MCC to iterate to a LOI time that is not defined in a GET but in a fixed time no matter the launch time [15:44:02] as on Apollo 17, LOI happens at the same GMT no matter where in the launch window it is I think [15:44:14] indeed [15:44:45] SFP pericynthion time isn't close enough I guess [15:44:52] you want flight plan LOI TIG, right? [15:44:56] so I am looking to just convert that LOI GMT into a GET that can be used in F23 [15:45:20] the RTCC won't help you with the GET to GMT conversion if you want to account for liftoff delays [15:45:31] because the GET to GMT calculation uses actual liftoff time [15:45:37] ah [15:46:02] so you have to manually convert that GET to a GMT [15:46:08] and then in the code you can do [15:46:23] get = GETfromGMT(LOI_GMT) [15:46:34] and it will give the correct GET for any launch time [15:47:19] ok [15:47:27] you could also hardcoded the nominal liftoff GMT though [15:47:30] hardcode* [15:48:34] right [15:48:38] btw SFP says LOI 86:20:0 [15:48:57] +2:40 delay thats pretty close [15:49:33] original launch time was 2:53 GMT [15:49:46] so you could hardcode that for the MCC for conversion [15:52:55] then you could do [15:53:19] get = GETfromGMT(320138.0 + NominalLaunchGMT) [15:53:39] right [15:54:01] NominalLaunchGMT is just 2h53 converted to seconds? [15:54:28] yeah [15:54:40] ok [15:58:30] thanks [15:58:59] MCC-1 evaluation is ready for its 1st test [15:59:20] I also want to do a pericynthion evaluation along with it [15:59:34] my current PR is also ready for a test, I better make sure I didn't break everything [15:59:38] and then have an early flyby PAD if needed [15:59:41] I changed the way mission files are loaded [15:59:48] it's backwards compatible [15:59:59] but a bit of bad code because of it :D [16:00:15] important part is that I removed the limitation on how many cue cards can be loaded there [16:00:42] oh and I talked with Matt about it a bit and there will not be an option to replace cue cards in mission files [16:00:54] if it comes to replacing, we will remove it from the defaults [16:01:07] and then just manually load the "default" in all other mission files [16:01:30] and the non-default one for one particular mission [16:02:05] I think they are mission specific enough that it makes sense like this [16:02:42] and for custom missions you would probably start from some mission file anyway [16:02:48] so it would already have cue cards then [16:06:36] right makes sense [16:25:51] ok I actually created a mission file that contains every possible item, in the case of booleans (on/off switch for some mission specific thing) even twice because it has to load TRUE or FALSE [16:26:14] and aside from one tiny thing it all loads correctly [16:26:17] feeling better now :D [16:26:46] so pretty high confidence in my PR now [16:38:59] nice! [16:39:58] just casually changing the entire mission file code, no big deal [16:40:05] sweats profoundly [16:42:16] lol [16:43:24] at least you're not changing tank temperature in every mission scenerio. [16:44:22] yeah, please make sure to check every single line in scenarios for that lol [16:46:15] I'm working my way through that haha. [16:49:09] after proclaiming that my script worked on the first try I discovered that my regex was also matching part of the LMs OCHAN lines for a reason that I have yet to explain..but was able to fix [16:50:36] ouch [16:51:05] that could cause some minor, but untrackable weird behavior haha [16:51:43] it just obliterated the line and replaced it with CHM 0 ...... [16:52:00] and caused a crash on load, so very easy to find [16:52:43] all of my changes are hiding in this branch [16:52:46] https://github.com/n7275/NASSP/tree/liquidDensity3 [16:53:53] they can live there until we merge some of Ryan's changes and some of my earlier stuff [16:53:58] can't wait for the NASSP 8.0.0.0.2 release [16:54:15] Beta [16:54:37] I already have notes on the wiki for that with date and build number TBD [16:56:12] at the rate I'm going with those we will be forced to update to 9.0 in about 5700 years [16:58:46] so shortly before my XRSound update is ready [17:15:02] hahaha [17:30:32] indy91, just looking at the MCC-2 calculation with mode 4 TLMCC with F23 iterated by MCC [17:30:59] looks very good except the GETTEI seems to be one orbit too early [17:31:29] 234:26instead of 236:39 [17:31:33] ohhhh [17:31:35] of course [17:31:38] late launch :D [17:31:42] 2:40 [17:32:40] anyway with MCC iterating F23, I have an LOI TIG within 1 second of flight plan [17:32:50] great :D [17:33:03] yeah, so, one deficiency with the RTCC and late launches [17:33:09] our SFP file only really covers the nominal launch [17:33:19] they had SFP data for the whole launch window [17:33:30] GET LOI showing 86:15:36 and add the 2h40 delay that is 86:55:36 [17:33:33] and the RTCC interpolated them after liftoff [17:33:46] TLMCC is annoying with needing so much input data and initial guesses... [17:33:50] FP 88:55:37.5 [17:34:36] it still works quite good I think [17:36:12] yeah luckily [17:36:31] even converged when MrResiduals changed the Apollo 14 landing site to Marius Hills [17:49:13] oh btw [17:50:13] I thought I was using the new presettings...but actually I just noticed that the Apollo 17 delayed scenario doesn't have them yet :D [17:51:23] oh noooo [17:51:27] Ryaaaaaaan [17:51:34] I didn't want to have those delayed scenarios [17:51:39] and then I forget to update them [17:52:09] hahaha [17:52:12] I remember I wanted to do it last so that I didn't have to do any last minute fixes in two scenarios [17:52:23] I did it so last that it now comes weeks after the PR [17:56:12] ll be back later, cya! [17:56:38] https://github.com/orbiternassp/NASSP/pull/955 [17:56:40] aaaah [17:58:44] good Alex [19:15:54] indy91 I have a feeling vittguy on Discord may be a good person to ask if you have any shuttle questions [19:52:57] n7275, oh yeah? Why is that? [20:02:16] he apparently worked at JSC https://www.orbiter-forum.com/threads/support-for-multiple-monitors.41144/ [20:02:57] vitt = Vehicle Integration Test Team [20:03:52] I honestly had forgotten that was the same guy that I sent over to Discord [20:04:37] oh, yeah, that sounds interesting [20:55:04] night! [16:01:43] hey [16:10:28] hey Matt [16:45:21] good evening [16:46:57] hey [16:47:21] testing out your cuecard fix now [16:49:29] hey Niklas [16:49:36] got liftoff time update working [16:49:38] almost [16:49:58] just missing the actual uplink code :D [16:50:23] ah right, it's going to be hidden away in strange named uplink formatting functions :D [16:50:30] strangely* [16:50:36] n7275, great, thanks! [16:52:03] I used C08 CMC Liftoff time update function [16:52:11] that seems right [16:52:16] to figure ou the delta time octals [16:53:06] can those then be uplinked with IncrementAGCTime? [16:55:10] hmm [16:55:18] I think that is AGC clock only [16:55:51] right thats what I thought [16:57:08] I mean I can build a string for V7XUpdate manually I guess [16:57:32] but wanted to avoid that of theres already a function :D [16:57:33] I hadn't moved the function for that yet from the ARCore class to the RTCC class [16:57:56] ARCore::AGCLiftoffTimeIncrementUplink [16:58:45] ah [17:00:14] basically the RTCC needs a function just like IncrementAGCTime [17:00:42] except that it calls the liftoff time function and uses the data buffer for it [17:00:44] I guess I cant access ARCore directly [17:02:06] void RTCC::IncrementAGCLiftoffTime(char *list, int veh, double dt) [17:02:10] { [17:02:12] CMMLIFTF(veh, dt / 3600.0); [17:02:13] int *octals; [17:02:15] if (veh == RTCC_MPT_CSM) [17:02:16] { [17:02:17] octals = CZLIFTFF.Blocks[0].Octals; [17:02:18] } [17:02:19] else [17:02:20] { [17:02:21] octals = CZTMEINC.Blocks[1].Octals; [17:02:22] } [17:02:23] V7XUpdate(70, list, octals, 3); [17:02:25] } [17:02:32] add that [17:03:29] ok [17:03:42] uhh [17:03:51] CZLIFTFF twice [17:03:55] not CZTMEINC [17:04:08] right [17:07:36] I wonder if that function should be added in the main branch right now? [17:07:54] sure [17:08:04] because if I just put it in my Apollo 17 branch it might sit here for years never to see the light of day :D [17:08:26] ok I will PR just that function after testing it [17:42:03] indy91, I guess P10 and P15 should be redone in the RTCC after the update? [17:43:00] yep, those two [17:43:27] ok I guess I can reuse code from case 10 [18:06:34] I have a key error on GitHub so I cant upload right now [18:07:19] Ill do the uplink PR on Tuesday when I get back from work and can fix my Git key [18:23:02] cya! [18:31:13] n7275, new mission file loading code is less clean than before, but I had no choice but to move away from those Orbiter API functions for reading config files [18:31:32] but it should work fine at least [18:33:19] merged. thanks for checking [18:33:22] I think its good. I opened a bunch of scenerios, clicked on some things, doing my best to break stuff and everything seems fine. The loading code looks okay; maybe eventually we want a wrapper function in some #idfed WIN21 block [18:33:37] W32 [18:33:50] WIN32 [18:33:55] I can't type today [18:34:22] similar to what we have in nasspdefs already [18:34:24] / [18:34:27] / Compatibility warning crap. [18:34:28] / [18:34:29] #if _MSC_VER > 1300 [18:34:30] #define strnicmp _strnicmp [18:34:31] #define stricmp _stricmp [18:34:32] #endif [18:35:34] yeah. why MSVC doesn't impliment standard POSIX functions that GCC and IBM compilers support is beyond me [18:52:24] hey while I'm thinking of it, do you know of any documents that have IMU drift rates and PIPA bias values for later missions. I've found a few documents that have them for 7-9 but nothing later than that. [19:01:33] padloads! But that's of course not directly the data you look for, but the compensations for it [19:06:29] oh yeah haha [19:09:50] before I get too far, I should verify that I have my axes correct. [19:12:13] and resolve any potential merge conflicts with the mission files [19:19:06] we should see better N93 values if we had this right? [19:33:06] hmm, I'm not sure how [19:34:30] we would just have IMU drift, and then AGC compensating for IMU dift, ending up with (ideally) no drift? [19:46:42] ahh, I wasn't sure if the compensation actually pulsed the platform back to where it "should" be or it it just used knowledge of how far it had drifted for to offset the measured values for calculations [19:58:40] yeah I am pretty sure there is an IMU compensation that runs all the time and if the error exceeds a threshold it sends a gyro pulse [20:11:35] okay. there's probably still something interesting we could do with that. at least the code that does the compensation would get to do something. not sure Im ready to start modeling gyro bearing wear yet though [20:20:27] oh yeah for sure [20:21:01] the only time we ever made it do something was by accidentally putting the IMU compensation in the Apollo 12 LM activation checklist into the LGC [21:49:13] night! [14:59:13] hey Niklas [15:04:46] hey [15:11:37] lesson of the day: functions work way better when you actually call them [15:18:49] that's a good less [15:18:57] on [15:39:39] it's always great with more complicated functions [15:40:06] with input and output structs [15:40:33] and you call the function 3x in another function [15:40:50] and fill the input data properly [15:41:09] but then don't call the function the 2nd and 3rd time [15:45:16] and wonder why the output isn't what you expect [15:54:42] yeah that's always fun to diagnose [15:56:46] I have resolver phase error showing up in telemetry now [15:57:44] I may need a bit of help with some other things on the client side at some point. (not strictly related to IMU drift, but other IMU things..."while i'm in here") [16:04:07] sure [17:23:50] indy91, in the Apollo 11 CMC padload the NB Drift compensation rates are in 1460-1462, are those the same addresses that I would put the values I have into if I am using one of the mission scenerios to test? [17:24:08] yeah, EMEM1460 etc. [17:24:42] okay [17:26:03] as always, careful which "EMEM1460" you load. Because of CMC+LGC it exists twice in the scenario [17:26:19] top one should always be the CSM [17:31:52] but the IMU compensation always having been zero for us, it probably doesn't have them in scenarios [17:32:01] but still have to check for which AGC you add it :D [17:37:19] yeah definitely. [17:37:46] I think I know what Scenerio Updater 80003 is going to look like haha [21:14:51] night! [15:21:44] hey [15:26:25] hey Niklas [15:28:54] hey, you wouldn't happen to know what the 'x' 'y' and 'z' gimbals correspond to in our IMU class, as far as O,M,I. and what the padload calls x y and z, would you? [15:29:19] I tried my usual right to left hand stuff and just kept getting confused. [15:36:53] I think our XYZ is the same as padload XYZ [15:37:04] outer, inner, middle [15:42:27] okay. I need to do some logging but it doesn't seem to eliminate drift entirely. wondered if I had the wrong axis. I guess I could test with some known values. [15:43:00] hard to tell from just watching the debug strings though [15:45:51] did you load NBDX/Y/Z compensation only so far? [15:52:51] i had compensation and drift. they're pretty easy to tell apart, the drift is continuous and the compensation is pulsed [15:54:44] and they're definitely going the right direction, ie drift making the angle smaller, and compensation making it bigger again or the other way around [15:57:47] maybe it's a scaling issue? [15:58:42] possibly [15:59:32] what did you use for compensation and drift? [15:59:40] give me an example in an axis [16:01:45] x would be -1.8 meru, and the padload value was 77432 [16:03:03] y is -0.6 or 77663 [16:03:14] that's jus the padload [16:03:18] just* [16:03:22] what does it do in our code? [16:03:25] and z is -0.2 or 77746 [16:03:57] I'm moving the gimbal angle at those rates in radians per second [16:04:37] and that's the part where I wanted to check your math to make sure that isn't the issue with the remaining drift [16:07:36] https://github.com/orbiternassp/NASSP/compare/Orbiter2016...n7275:NASSP:IMU_drift#diff-d92ecc070964c2b94fea2823d0849a7a40efc53ff1f34e50c20419e2c7292b67R487 [16:12:57] ok seems pretty straight forward. Not a lot you can math wrong really [16:13:08] one factor with the MERU which seems correct [16:13:31] morning! [16:14:09] hey Mike [16:14:34] I like how it's on Wikipedia [16:14:35] https://en.wikipedia.org/wiki/List_of_unusual_units_of_measurement#MERU_(Milli_Earth_Rate_Unit) [16:14:48] hahahahaha that is the perfect page for it [16:14:52] "unusual" lol [16:15:15] no pirads though [16:16:13] n7275, there is a bit of a flaw in your drift logic [16:16:26] you modify the accel vector with biases [16:16:44] and use that modified accel in your IMU attitude drift for ADSRA and ADIA [16:16:55] so the measured acceleration and not actual [16:17:26] uh oh [16:17:40] I mean, likely not a big difference [16:17:45] ok that I should definitely fix [16:17:49] but kind of wrong [16:19:33] "621 errors" the pain of doing a change to the inputs to Maneuver PAD calculations [16:26:22] oh that's a bit [16:27:33] all the MCC calculations... [16:30:11] what are you changing? [16:30:38] right now I can't pass CSM and LM mass separately to it [16:30:42] just isn't supported [16:31:03] the Maneuver PAD calculation itself gets the mass of the vessel docked to the "main" vessel [16:31:13] and uses a VESSEL pointer for that [16:31:33] which from it being bad that internal RTCC function use vessel pointers, it makes it MPT incompatible [16:31:40] aside from it* [16:31:58] you could only pass total configuration mass to it then [16:32:01] with the MPT [16:32:15] but then the total mass appears as the CSM mass on the PAD [16:32:18] and LM mass zero [16:32:28] just a lot of old code [16:33:43] ahh [16:34:42] so I now deleted the vessel pointer as Maneuver PAD calculation input [16:34:46] and added LMMass [16:34:57] and gives all those errors in the MCC :D [16:35:00] and that* [16:37:37] I had already done this for the Apollo 7 style Maneuver PAD. [16:37:54] And I thought about doing it for the LM Maneuver PAD now, too, but that gives about 50% more errors :D [16:39:02] it's what I get for starting something like the MCC before the RTCC is more "finalized", I guess [16:40:57] this is also the reason why often in the RTCC there is a newer function for something that only the RTCC MFD uses [16:41:01] and some older stuff for the MCC [16:41:27] the older stuff is better tested and with the MCC it takes a lot more work to change and verify this all [17:06:03] you know what I need [17:06:07] a MCC test suit [17:06:17] oooo [17:06:24] which just calls every MCC function with nominal numbers [17:06:33] that sounds cool [17:07:19] and I guess removing stuff like using VESSEL class pointers is a step in actually making that possible [17:09:57] it's also made difficult by things like data being pulled from the AGCs [17:10:08] but that could be handled by some clever code [17:10:12] wrapper functions or something [17:10:32] or some function define [17:11:57] it could be done in a less clever way where the RTCC calculations just have hardcoded nominal values [17:12:36] and a function like CalculationMTP_C for Apollo 7 has a boolean that uses either nominal or actual flight parameters [17:13:06] then I would just call every calculation in that function and if anything fails I know something is bad [17:13:13] or I then let it draw all PADs or so [20:50:22] tomorrow is a SSV release I think, so I am trying to get a FDO MFD update out soon as well [20:50:34] was trying to build a STS-125 scenario with the mission editor [20:51:03] didn't have a good Hubble TLE, so I requested all of the Hubble TLE from celestrak [20:51:11] 33th launch anniversary btw [20:51:22] total coincidence actually [20:51:33] smart me included today in the requested date range [20:51:50] their automated system will then send me the TLE... at midnight when todays TLE becomes available [20:52:07] if I had requested up to yesterday instead of today I would have gotten it instantly :D [20:54:18] launch anniversary of Hubble, not STS-125 :D [21:29:27] oh that's cool. I didn't realize [21:32:37] yeah I was looking for a date range to enter for the request [21:32:46] and realized I put the same day and month in both lol [21:34:28] night! [14:23:20] hey Alex [14:27:38] hey [14:51:52] hey [14:54:12] hey Niklas [14:55:22] so I was using GetTEPHEMFromAGC(&cm->agc.vagc); in the process to update the liftoff time in the RTCC after the CMC liftoff time update [14:55:41] but the time was wrong [14:55:50] then I looked at how the RTCC MFD does it [14:56:03] its the same except it doesnt use the function GetTEPHEMFromAGC(&cm->agc.vagc); [14:56:10] and [14:56:17] there is this: //Make negative numbers actually negative [14:56:40] by adding that conversion then it works [14:57:00] does GetTEPHEMFromAGC(&cm->agc.vagc); not do that by default I guess? [14:57:28] the if (val > 037777) [14:57:29] val = -(077777 - val); [14:59:53] oh does your TEPHEM have a negative value due to a liftoff time update? [15:00:21] dumb code duplication. The better version should be in the RTCC class where the MFD can call it [15:02:12] would adding a "remote dsky view" to PA MFD accomplish the same goal as the debug string? [15:02:44] n7275, ho that sounds like a good idea [15:02:47] oh* [15:03:29] indy91, yeah I think it was negative. delta time was -2:40 [15:04:14] well, TEPHEM itself is always positive. But it is a triple precision number and you will now have one or two words of it that are negative [15:04:25] it's somewhat random [15:04:34] weird triple precision math [15:06:06] I think on Apollo 14 they decided to manually change the TEPHEM to all positive values [15:06:27] not because they expected issues, just because it seemed "cleaner" [15:11:53] I'll move the "good" code to the RTCC class and remove the duplication [15:15:42] ok [15:22:20] you got it [15:22:23] https://github.com/orbiternassp/NASSP/pull/958 [15:22:59] already tested with the MFD for Apollo 11 and then with the Apollo 7 MCC [15:23:21] still updates liftoff time correctly at least [15:25:40] looks good, approved [15:26:45] then it's getting merged [15:27:59] my Maneuver PAD update is not going to work all in one go [15:28:18] so I'll change only one variable at a time and make a PR with that :D [15:28:39] already causing 52 build errors from one small change thanks to the MCC using the CSM Maneuver PAD so much [15:56:25] this should be a bit more managable :D [15:56:28] https://github.com/orbiternassp/NASSP/pull/959 [16:16:07] I found the source of some of my confusion: the IMU compensation does some pulsing on all gimbals even if you have a value loaded for one, and zero for the other two [16:16:34] although the net effect effect appears to be zero [16:20:07] interesting [16:20:24] before you said that second part I was thinking that it operates in different axes than we were expecting [16:31:57] it appears to match up, but with different signs. [16:46:52] it's going to be cool once I have the acceleration sensitive ones in and flying a TLI or PDI with it. [18:14:52] damn power failure [18:32:35] oh those are never fun. [18:34:50] I live across the street from a hydro plant and substation so for me they're now exceedingly rare. [18:42:18] code cleanup is exhausting [18:43:00] but I just did a lot of it [18:43:20] +453 −847 [18:43:28] was expecting more :D [18:44:50] yay code cleanup! [18:46:06] that's a nice delta [18:47:00] didn't think it would be so much + [18:47:11] but I think it's counting a line that was just changed and not deleted as a + [18:48:32] even if you only deleted something from the line [19:38:26] ahh yep [20:27:45] indy91, MCC does checks on LOI for MCC-4 on Apollo 12 and prior [20:28:03] would those same checks be appropriate in the case of intersection LOIÉ [20:28:08] ?* [20:28:54] like the "while (ApsidRot > 180.0)" etc [20:30:33] that's from the mission rules [20:31:28] it's basically the same in the 17 rules, except it says "relative to HP target" instead of "relative to 60 NM" [20:31:56] ApsidRot constraint can stay the same [20:32:09] mission rule 5-59 if you want to see [20:32:29] so even for the later missions there is no DV threshold, but just that [20:32:32] so would just redefine the "center point" of the limits [20:32:37] so you would* [20:33:13] I would say the DV threshold is indirectly defined with the apsidal rotation [20:33:25] because if that is large then DVZ of LOI is large [20:34:37] but yeah, still no direct DV constraint on MCC-3 or 4 [20:35:14] hmm so even MCC-3 should check LOI? [20:36:46] oh wait, I changed something about that [20:36:49] and left a note :D [20:37:22] yeah the real MCC-3 check was just so involved, testing MCC-4 and LOI without any MCCs that I just put in 3 ft/s [20:37:27] as a MCC-3 threshold [20:37:55] the only thing that needs to be changed from 12 is probably the nominal pericynthion target [20:38:16] instead of e.g. PC being limited from 50 to 70 (60 being nominal) it says nominal HP +/- 10 NM [20:38:22] which if nominal was 60 would be the same [20:38:31] but 17 went almost down to 50 I think [20:38:33] nominally [20:42:30] right [20:48:23] otherwise if nominal was e.g. 51 you would already get a limit violation at 49 NM [20:48:32] but not at 69 NM [20:50:19] the TLC DV budget is also tighter I guess on 17 [20:50:46] we use 120 ft/s as the threshold to wait until MCC-2 or burn MCC-1 [20:50:51] for Apollo 12 [20:50:58] but I set that lower for 17 [21:01:27] that makes sense to me [21:01:39] night! [02:17:06] thewonderidiot, you wouldnt happen to know exactly what angular velocity MIT documents consider a "MERU" to be? [02:17:12] I have 7.29211586E-8; //rad/sec [02:18:43] not offhand but I can do some digging :D [02:19:59] Norton docs might be a good place to check actually [02:20:06] that sounds like something he'd be extremely pedantic about [02:20:58] hmm, or not [02:23:54] the AC electronics books have 7.292115e-8 [02:25:15] Okay, that's what I had before. I added some unnecessary precision and it didn't magicially fix my problems :( [02:25:17] https://imgur.com/pMO2NVy [02:27:18] hmmmm [02:29:05] oh, here's a similar number in Norton: https://i.imgur.com/4I2wNQQ.png [02:29:28] slightly different extra precision than you added [02:38:58] hmm doesn't seen to make a measurabie difference [02:41:06] so without compensation the drift rates should've been -1.8, -0.6, and -0.2 [02:41:55] driftx = -0.212830688238189 [02:41:58] drifty = 0.838210619878087 [02:42:00] driftz = -4.407914264486563e-02 [02:42:15] is what I'm actially getting [02:42:57] maybe it's just a precision thing [02:44:56] as in the stackup between +/- 0.05 MERU and the scaling of the drift compensation rate [03:47:35] I should have been more adventurous in testing this with different gimbal angles. [03:48:10] I think it's just me getting confused about euler angles again. [13:05:19] good morning [13:13:54] hey Matt [15:13:20] hey [15:15:02] hello [15:19:29] hey [15:19:56] looking at Apollo 17 DOI-1 [15:20:33] oh what fun this one is [15:23:58] targeting wise? [15:26:36] yeah [15:26:56] I am making a loop with the GPM HBT mode [15:27:07] to get 31.36 peri long [15:27:16] having some success already [15:27:21] oh right [15:27:28] we didn't really have a clean method for targeting this yet [15:27:47] stealing some of the GPM loops you used in Apollo 7 :D [15:29:15] I am just trying to make it robust, so it can deal with a slightly bad LOI [17:11:15] I think I might be doing things backwards [17:24:37] what are you doing backwards? [17:30:50] oh my stuff with the IMU drift rates. my results keep looking like a series of rotation matrices applied out of order [17:33:53] at 0,0,0 RPY doing it the way im doing it right now works and compensation keeps up with it [17:36:24] but at other orientations it doesn't. and interestingly the total drift rates (nbd+compensation) is always bounded between 0 to 2x the compensation rate [17:37:21] as if the scaling is right but the components of rotation are in the wrong axes [17:37:41] but like, partially, and as a function of attitude [17:38:55] I think what I need to do is apply rotations to the attitude reference matrix from which "newAngles" is calculated [17:48:09] hmm interesting [17:59:53] yeah that's about as far as I've got hahh [18:00:51] I'm trying to find if we have any IMU simulation document that would maybe talk about this or even give the right axis to apply [18:01:07] thewonderidiot, remember when I was trying to reconstruct FP7 [18:01:42] what is my one success with NTRS? I got back some LM Data Book amendments. What do they have? AEA padloads. Did I remember that? No [18:02:08] half the time it's not that we are missing documentation, it's that we already have so much documentation that we forget them :D [18:02:36] and it doesn't really help me. The scaling factors I was sure must have moved between FP6 and FP7 are the same in the Apollo 13 padload [18:02:57] so they must have done the memory address reshuffling with non-padload values [18:06:11] hahahahah oh man [18:13:37] the compensation appears account for the fact that rotation about two axes will produce some movement offset about the third [18:13:49] I don't think my method does that [18:17:55] I believe what you'd actually see if done correctly, is the FDAI ball move through a "great circle" rather then along a constant "latitude" [18:24:17] the set attitude reference function does Y -> Z -> X. would it stand to reason that this would need to happen in reverse for drift in those axes rather then vessel movement about them? [18:30:31] hmm, possibly? Didn't expect there to be cross axis effects [18:30:40] what kind of drift rates are you using :D [18:35:47] small ones, but they still should have coupling [18:36:56] consider being at 90deg pitch. drift that has apparent movement in the yae direction will reduce aparent pitch and increase aparent roll [19:14:53] NAA simulator has constant drift rates along spacecraft axes if that helps... [19:16:26] I think it does. [19:16:42] do you have a link? [19:18:12] https://www.ibiblio.org/apollo/Documents/19730060770_1973060770.pdf [19:23:46] is it possible our gyro pulses aren't even applied in the correct coordinate system? [19:48:25] it's possible I suppose, but I'd kinda suspect that P52s wouldn't work if that were the case [19:51:12] yeah [19:51:30] I don't know the logic in the AGC well enough, not sure if it re-calculates the require gyro torquing [19:51:35] required* [19:51:46] during a large P52 error [19:59:12] but yeah, probably just the drift applied in the wrong system [20:10:05] yeah I think I'm mixing up spacecraft axes and stable member axes [20:50:00] night! [15:17:38] hey [15:30:07] morning! [15:36:23] hey Mike [15:36:28] I'm having dangerous thoughts [15:36:59] I'm getting quite annoyed in my RTCC with the baggage of the past. Bad code, wrong units, wrong coordinate system [15:37:13] I kind of want to start a RTCC 2.0 where I do everything right from the beginning :D [15:37:15] uh oh [15:37:22] those are very dangerous thoughts haha [15:37:47] on a less dangerous note [15:37:50] https://archive.org/details/NARASWSelectedApolloBoxes/page/n577/mode/2up?view=theater [15:37:58] I definitely want to have that on the left for RTCC TLI targeting [15:38:23] you may be thinking "I've heard that before", but it might finally be time that I actually throw some money at NARA :D [15:38:50] oh man! [15:38:57] I can't believe that hasn't happened yet lol [15:39:04] I've sent them emails before haha [15:39:24] never got a reply. It was about IBM RTCC documents... at the height of Covid [15:39:34] so not too surprising I guess [15:40:00] but this time it's not just an enquiry [15:40:07] I 100% know they have this [15:41:32] and given the staple positioning it's also pretty clearly the entire document and not just a sad subset of it lol [15:42:02] probably with a distribution list on the inside cover that somebody *really* wanted to make sure didn't fall off :D [15:48:05] yeah well, there is an earlier iteration of this document [15:48:24] sometimes the new one has the complete set of information necessary to understand it [15:48:32] sometimes it's referring a lot to the earlier document [15:48:35] so who knows :D [15:49:33] oh [15:49:34] hahaha fair! [15:49:36] two earlier iterations :D [15:49:40] uh oh [15:49:48] didn't know there was a June 1969 one [15:49:55] I thought there was only a 1968 one [15:49:58] well, we will see [15:51:32] "$0.80 per scan" [15:51:39] it better be less than 100 pages [15:54:38] if you've never asked for a scan before, sometimes they will send you the first for free [15:54:48] ....or if it's been a while and they forgot about you. it's happened to me several times [15:54:51] so maybe you'll get lucky haha [15:55:10] yay [15:55:14] that would be great [15:55:43] the best way to contact was the Fort Worth email address? And then them everything I know where it is, record ground, all the exact document data etc? [15:55:55] ... something I have already asked multiple times, I know [15:57:41] And then tell them everything I know, where it is* [15:57:50] record group [15:57:59] doing too many things at once haha [16:01:23] hmm [16:01:55] yeah record group (RG 255) and title for sure. you can include the box number, but I *think* the boxes have been renumbered so it may be worth pointing out that it's an old box number [16:03:06] E.157G. MISSION PLANNING AND ANALYSIS INTERNAL NOTES. [16:03:20] was the full category name, if that didn't change [16:10:35] yeah E.157G goes up to late 1971 with these memos [16:11:00] and yeah I always go through ftworth.archives@nara.gov [16:19:29] great, thanks! [16:19:52] Am I misremembering or did you read that one Comanche 72 module a while ago already? [16:19:59] I saw the video [16:22:13] yeah, I was sending the video to Jimmie yesterday to show him what to expect for AS-202, and decided there was no reason to keep it unlisted anymore [16:23:54] aaah ok [16:24:22] he has to expect that if he looks in the wrong direction at the wrong moment he is going to miss the whole process [16:25:42] hehehe [16:25:52] if it is a good day yes [16:25:56] padload is going to be somewhat difficult [16:26:07] I don't expect that much address shifting [16:26:12] if it is not he is going to get to see me be very sad and wire up a sense line to an oscilloscope to start manually writing down bits [16:26:15] but they added a bunch of things for AS-501 [16:26:35] aaaaand scaling [16:26:47] yeah hopefully it's in good shape [16:26:55] I hope hope hope [16:27:03] these things? https://github.com/virtualagc/virtualagc/blob/master/Solarium055/ERASABLE_ASSIGNMENTS.agc#L978 [16:27:16] oh :D [16:27:24] yeah I think those haha [16:27:31] they are mentioned in the change document [16:27:52] neat and tidy all in one place [16:28:11] and at the very end of erasable [16:28:18] yeah so hopefully that part is not so bad [16:28:28] like you said though, scaling is another issue :D [16:28:40] hey guys [16:28:48] I'll look at Sunrise again for that [16:28:50] hey Matt [16:29:09] or maybe I don't have to [16:29:13] we have a AS-202 GSOP [16:29:21] maybe it mentions scaling somewhere [16:29:38] hey hey [16:29:56] the AS-202 GSOP looks shockingly useful from a reconstruction standpoint [16:30:15] it has a section with a bunch of flowcharts that use program labels [16:31:24] hmm, uplink scaling is the same between 202 and 501 [16:32:48] but RN, the liftoff state vector in IMU coordinates, was definitely changed [16:36:28] I wonder if it was just scaled 2^24 instead of 2^25 [16:36:34] that's what Sunburst has [16:36:38] and that's the uplink format [16:37:00] oh maybe we find a place in Solarium where it does a single bitshift [16:37:05] and it says that it was added [16:37:49] Solarium has lots of those haha [16:38:05] compared to Sunrise [16:44:18] well no idea where exactly this happen in Solarium. But my initial padload attempt will have the 2^24 scaling [16:44:22] happens* [16:56:36] let me know which all variables you're most concerned about scaling with and I'll try to target those areas first in the disassembly [16:56:54] ...after doing fixed-fixed [16:56:56] 100% RN [16:57:06] the rest maybe not [16:57:33] the splashdown coordinates are unit vectors, so those wouldn't have changed I think [16:58:30] I can try to figure out where the scaling of RN would be clear [16:58:55] aaaaaaaaah [16:59:03] "The fixed constant WIE has been doubled because of the new RN [16:59:04] scaling." [16:59:26] so I think it's safe to say it has changed by a factor of 2 [17:01:17] oh yeah that seems pretty clear :D [17:02:42] then I have my initial padload worked out. Just have to change some of the input numbers [17:02:51] unusually AS-202 launched to 105° azimuth [17:03:34] over water almost all the way to nominal splashdown [17:03:38] that's probably the reason [17:03:43] oh man that was fast, you're ready to go haha [17:04:09] I just copy and pasted some parts of the padload generator :D [17:04:52] 10 minutes ago I had empty BlockIDefaults and CoronaDefaults functions [17:05:05] and all of the Solarium padload in a SolariumDefaults function [17:05:19] now I just moved the part that I believe they have in common to BlockIDefaults [17:05:24] change RN scaling [17:05:27] the end [17:05:30] lol nice [17:05:40] there's a *chance* that if all goes very well I might have the dump as soon as tomorrow night (which I think is morning for you) [17:06:26] I'm going to spend a good amount of the weekend in my grandma's garden, so not quite sure when I will get to trying it [17:06:43] oh yeah that sounds much more important than trying to fly an obscure mission :D [17:06:45] might be Sunday evening [17:07:43] but I can still do stuff in preparation [17:07:55] like remembering how to start the launch programs and stuff [17:13:05] Nik, can your padload generator calculate IMU drift rates? [17:13:32] it can not [17:13:38] all set to zero so far [17:14:55] shouldn't be hard to calculate some by hand. I have everything I need I think. [17:15:33] I want to try setting some values that differ by a lot from the padload, and then use a few N93 values to see if I can correct it [17:24:33] one feature (for the PAMFD?) I have always thought about is something that calculates the current error of the IMU [17:24:42] just as a debugging tool [17:25:04] when looking at scenarios from other people I always check things like AGC clock [17:25:21] but if the IMU might be badly aligned isn't always simple to tell [17:33:25] hey [17:34:44] hey Alex [17:36:31] hey Alex. [17:36:35] indy91 that's a good idea. [17:42:02] hey [18:56:55] hmm that's actually harder than it sounds [19:03:24] yeah needs REFSMMAT and stuff [19:18:50] yep [19:26:05] not impossible, but I'd want to make sure I wasn't making anything overly hacky [13:31:08] .tell thewonderidiot "one time courtesy copy" you were totally right. I already got the document, for free! [13:41:10] also [13:41:12] hello :D [13:42:10] and it looks like it has all I need [13:45:22] hey Niklas [13:45:45] whats this document? [13:46:03] RTCC Requirements for Apollo 12 (Mission H-1) Translunar Injection Processor [13:46:52] oh nice [13:48:04] has 4 options [13:48:08] that was fast [13:48:12] indeed [13:54:59] but this is probably the only free one I get this year haha [13:55:42] is that to generate numbers for a custom landing site? [13:57:54] hmm not exactly [13:58:10] you still have to input pericynthion latitude and radius and such [13:58:28] but you could play around with those numbers and target a different landing site [13:58:41] that would now be possible just by changing one number [13:58:55] and uplinking to the IU [13:59:03] so it is part of being more flexible [13:59:12] ah right [14:28:50] cya on Sunday! [16:12:34] morning! [16:12:38] :D [16:29:55] Mike, I talked to James a bit last night about his emulator. interesting little bug with the banks. [16:40:26] I was reading Hugh's notes on Block III a day or two ago, that's also giving me dangerous ideas... [16:54:33] hahahaha oh no [18:40:42] it turns out that a lot of my IMU drift error was in fact due to precision. If I convert from pulses/cs to an actual rate the graphs look much better [17:50:47] hey Alex [18:27:50] and MrResiduals [18:28:38] oh and rcflyinghokie [18:29:04] what's up [19:10:38] hey guys [19:20:14] hello [16:14:01] hey Niklas [16:15:26] good evening [16:16:09] it seems GETbase was grinding your gears a bit :D [16:17:17] haha [16:17:31] I started out removing it only from the CSM Maneuver PAD [16:17:46] but then in the span of 2 hours just got rid of as many of them as possible [16:17:59] you should know all about it, you approved the pull request! [16:19:23] indeed I did haha, I just didnt anticipate all the deleting that was need after, but it wasn't that bad [16:19:32] and for the better I think [16:19:41] it's an entirely outdated concept for the RTCC MFD [16:19:51] I started out doing all calculations either in MJD or GET [16:20:04] that's where GETbase was useful [16:20:19] but the real RTCC had at most stored the julian date of midnight before liftoff [16:20:25] and everything else is GMT [16:20:34] MEDs are GET inputs of course [16:20:41] but immediately converted to GMT [16:28:29] seems like thewonderidiot had some fun with Block I modules [16:28:45] AlexB_88 which you missed out on, because you aren't in our private Discord group! [16:29:03] we have to correct that [16:30:25] ah wasn't aware about it [16:30:34] but I need a link I guess? [16:31:28] I'm not sure haha, Mike is the group owner. Maybe I can still add you somehow, have to check [16:37:11] oh I have a question about abort constants [16:37:15] about to head out, but I added you :) [16:37:27] sorry for the oversight! [16:37:37] thewonderidiot, thanks! no worries at all [16:37:51] I think Alex wasn't that active at the time haha [16:38:12] AlexB_88, the answer is probably no [16:38:13] indy91, PoweredDescentAbortProgram(), is that able to do the later mission profiles with the right options? [16:38:19] haha [16:38:20] nope [16:38:30] still only 11 and 12 supported sadly [16:38:44] I saw the 2 segment flag, but I guess its more then just that [16:39:03] yeah the profile changed a lot [16:39:10] Apollo 13 would have been the first mission with a CSM DOI [16:39:15] and then a circ burn [16:39:19] so that changes things a lot [16:39:29] and then later one there are more changes [16:39:56] later on* [16:40:29] it's not super complicated to update, just haven't gotten around to it yet [16:40:47] just have to check it mission by mission [16:40:55] actually I have the abort constants thread working! Don't ask how I did it but it just has one line [16:40:57] sprintf(upMessage, "Use abort constants in the checklist"); [16:41:34] ha [16:41:54] just annoying for a PDI-2 [16:42:05] no real abort support for that [16:42:30] yeah I think I wont support a PDI-2 right now [16:44:40] well [16:44:59] you could still do it just dont try an abort during powered descent [16:45:31] but it could still give a No PDI+12 and T2,T3 PADs [16:45:45] *NoPDI-2+12 [16:48:32] right [17:34:04] hey guys [17:34:19] hello hello [21:40:31] night! [07:47:31] .tell thewonderidiot From the changes between AS-202 to AS-501: "CALCG no longer has to be preloaded with the CADR of CALCGEAR. The Navigation Program now unconditionally transfers control to CALCGEAR for GRAVITY". This is 100% where it goes wrong right now [12:07:44] good morning [12:44:30] good morning [13:20:29] hey guys [13:21:32] hey Niklas [13:21:46] its time to give the DKI a spin [13:21:56] No PDI + 12 [13:22:16] later missions style [13:23:07] I think you ran me through it once before on Apollo 16, looking back through the IRC logs to find it :D [13:23:57] yeah I think so [13:24:08] doing it with the MFD is one thing [13:24:16] but you probably want it in code for the MCC, right [13:26:08] thats the plan but I just want to get refamiliarized with doing it on the MFD 1st [13:30:46] right [14:00:24] indy91, is just a few questions regarding the DKI [14:00:31] sure [14:01:30] I am trying to understand what the terms NC1, NH, NSR and MI are in relation to the terms used in the timeline book (boost HAM CSI CDH TPI) [14:02:03] hmm right [14:02:13] well NSR and CDH are always the same thing [14:02:28] MI isn't a maneuver, it's just a number for the orbit when TPI happens [14:03:57] the other terms can be kind of confusing [14:04:09] HAM can be misleading [14:04:18] I would call that more of a phasing maneuver [14:04:53] right [14:05:51] so in most cases, but probably not all, NH = CSI [14:05:53] NC1 = HAM [14:06:39] in the DKI the NH maneuver will always be the one that sets up the DH at NSR [14:06:50] and boost would be its own maneuver directly on MPTÉ [14:06:58] MPT?* [14:07:42] hmm right, now I remember that we had several cases where the DKI isn't enough to target a full abort sequence of maneuvers [14:07:51] I'm not sure if I ever figured out a MPT-less solution [14:08:38] I mean on 17 boost and HAM is only for PDI-2 anyway [14:08:48] right, was just checking that [14:08:50] and boost comes first [14:08:55] so Ill start with not thinking about them [14:09:03] so you would indeed put the Boost maneuver on the MPT first [14:09:09] and then run the DKI on that [14:09:12] trajectory [14:09:26] that's exactly the same as the FIDO had to do for the T-2 abort on Apollo 11 [14:09:45] put a direct input maneuver on the MPT, then run the SPQ from there [14:10:53] ok [14:11:05] now if there is no HAM, then what do I do with NC1? [14:14:15] uhh [14:14:27] use the SPQ? [14:14:42] I think there is a way to run the DKI without the NC1 maneuver though... [14:15:51] enter a NC1 number that is zero or smaller [14:15:56] I think that would do it [14:16:24] but that's basically the same as using the SPQ then [14:17:53] oh so for NoPDI+12-1 can be done with just the SPQ? [14:18:24] aaah wait a moment [14:18:38] you still have the No PDI+12 itself [14:18:40] ... [14:18:47] and that's also before boost then hmm [14:19:01] so, I think what I did was a bad manual iteration [14:19:29] both the abort maneuver and the boost (if applicable) were direct input MPT maneuvers [14:19:47] because otherwise you couldn't get the DVZ = -50 for the abort [14:19:56] right [14:20:02] our old DKI could do that, kind of [14:20:08] and you iterate it [14:20:17] yeah I just started with +100 [14:20:18] DVX [14:20:43] that's one of the big things I hope to find out if we ever get MOCR audio from a later mission [14:20:48] if they really had to do it this waa [14:20:50] way* [14:21:10] with the MFD this isn't such a bad procedure, not as bad as it sounds [14:21:16] because you can simply use the replace option [14:21:23] still want 2-3 MFD windows open I guess :D [14:21:37] but you just do a small tweak for the maneuver and then run the SPQ again [14:21:53] until you get the DH you like I guess [14:22:01] right [14:22:08] or might also use the fixed DH option of the SPQ [14:22:12] and iterate on TPI time then [14:22:40] I'll be back later [14:23:10] thanks for the help [15:00:30] morning! [15:00:56] alright, that's easy enough. let me find that CADR :D [15:01:19] hey Mike [15:17:37] ind91, I am pretty sure that will be 61652 [16:33:45] indy, motivated by finding that CADR, I spent some time this morning disassembling bank 30. lots of small changes throughout, some of which I'm having trouble finding corresponding entries in the change memo [16:34:36] https://github.com/virtualagc/virtualagc/blob/master/Solarium055/ORBITAL_INTEGRATION_FOR_501.agc#L224 [16:34:56] do you know what this constant is doing? it appears to only be like 2 minutes in 202 [16:36:17] it would be 2DEC 11540 [16:36:59] 1 minute, 55.4 seconds? [16:39:58] bank 30 is in a module that gave me a perfect read so I don't think that's the problem :D [17:10:50] good evening [17:12:33] uhh [17:14:39] AVEGON [17:14:47] this might be related to reentry somehow [17:14:56] ohhh interesting [17:14:58] Average G would be on until after TLI for 501 [17:15:10] so switching it on again would happen for reentry maybew [17:15:12] well [17:15:14] the SPS burns too [17:15:24] not sure if Corona ever switches to orbital integration [17:15:32] does it have orbital integration? :D [17:15:50] yes definitely haha [17:17:11] anyways, no rush on figuring out exactly what it is. it's just a changed number in a bank that is almost certainly fully correct, and it's not impacting alignment [17:17:31] I am quite confident in that CALCGEAR CADR [17:18:07] great [17:18:12] let's see what happens with that [17:18:28] it's directly after the NSHIFT and XSHIFT padloads I still think I need to change [17:19:24] WTRWD, that prelaunch padload that got deleted, is at address 1325. I fixed up the code using it and still have no idea what it does :D [17:19:32] but apparently it's not important since your prelaunch seems to be going fine lol [17:19:40] hmm I hope so [17:20:14] ah I was in my RTCC TLI branch again [17:20:20] switching and building takes a bit :D [17:21:22] https://github.com/thewonderidiot/virtualagc/tree/Corona261/Corona261 [17:21:27] here is my WIP source reconstruction [17:21:47] https://github.com/thewonderidiot/virtualagc/blob/Corona261/Corona261/PRELAUNCH_ALIGNMENT_PROGRAM.agc#L367 [17:21:53] WTRWD is used throughout here if you want to take a look [17:27:26] if WTWRD gets overwritten anyway it hopefully doesn't do anything important for launch [17:30:45] ok, let's see if I get into P11 this time [17:33:00] P11! [17:33:17] simulation froze [17:33:23] why do I get this in this branch haha [17:33:33] I can't remember having it before [17:33:47] maybe I git cherry picked badly [17:34:39] and it's not a crash, something gets stuck in a loop or so [17:36:03] damn it's consistent [17:36:08] T+12 seconds [17:36:59] might have to run it in debug mode, annoying [17:38:22] hmmm weird [17:38:31] but, progress! [17:38:37] yes! [17:38:50] I wonder if it can be the Block I emulator or how I run it [17:39:05] good catch on that CALCG being a padload [17:39:15] I got this same freeze once when I was changing XSHIFT and NSHIFT [17:39:41] the Block I emulator certainly hasn't gotten the same amount of love as the Block II... [17:39:42] yeah I thought that it being stuck in P04 had to mean a fairly narrow piece of code [17:40:01] so I just tracked down what prelaunch stuff it had managed to calculate and what not [17:40:08] very nice :D [17:40:10] velocity was good [17:40:14] gravity vector [17:40:16] not good :D [17:44:57] yeaaaah it's the emulator haha [17:45:06] reeaallly [17:45:09] what's it doing? [17:45:12] I'm getting to this line [17:45:15] if (operand >= 02000) implementationError("CCS accessing fixed memory."); [17:45:22] uh oh [17:45:41] possible rope error there [17:45:49] can you tell what address that CCS is at? [17:46:02] I probably can. let's see [17:47:03] and I think the freeze is from this error code not behaving nicely as part of NASSP, as opposed to being standalone [17:47:10] yeah for sure [17:47:15] I set a debugging point there [17:47:22] and then should be able to tell you anything [17:47:49] oops [17:47:57] debug mode has bad performance [17:48:08] got a short freeze, rocket fell over, auto abort :D [17:48:14] hahahaha [17:48:37] but that should be random and not happen that often [17:50:37] hmm [17:51:13] now it failed somewhere else [17:51:21] O_o [17:51:40] implementationError("RESUME without RUPT.\n"); [17:52:25] what do you need to know? [17:52:52] opcode = 8192 [17:53:00] operand = 21 [17:55:06] Z register and BANK register [17:55:50] agc.memory[02] = 1210 [17:56:08] agc.memory[015] = 1024 [17:57:31] well there's definitely a RESUME there [17:57:35] but presumably it should not be here [17:57:53] I wonder if this is the same thing, where an uninitialized CADR or something is causing it to jump to bad places [17:58:17] by "presumably it should not be here" I mean, "the code probably should not have jumped here at this point" [17:58:57] right, so like the CALCGEAR thing [17:59:15] maybe? [17:59:46] T+12 seconds is kind of suspicious [17:59:58] might be pitch polynomial related [18:02:46] if nothing stands out, we might need to add a log to the emulator so we can see how it is getting to these addresses [18:03:03] so we can see the code that it ran leading up to the problem, instead of just where it finally did something bad [18:09:25] yeah [18:13:15] if I were to focus on disassembling this area of code after work.... where would I look? [18:13:32] 202_MISSION_CONTROL_PROGRAM? [18:18:17] I'd say yes [18:18:49] cool. that looked very different from 501 when I was going through all of the banks [18:19:08] I'm hopeful that the flowcharts in the GSOP will be helpful [18:19:42] bank 32.... [18:20:23] that is in the worst module, B24 [18:20:35] but wasn't one of the banks affected by the double diode failure [18:21:19] do we not have banksums for Corona? [18:21:21] but if any bank has an issue, it will probably be 13, 32, or 33 [18:21:27] oh I know my checksums are good [18:21:31] right [18:21:45] but we don't have known bugger words [18:22:06] and if a bit was flaky, it could *possibly* cancel itself out [18:22:14] especially if working in conjunction with another bad bit [18:22:18] it's unlikely but possible [18:23:17] I could delay the pitch and roll monitors [18:23:28] oh and see if the problem moves with them? [18:23:29] to see if the "bad code" is somewhere called by it [18:23:33] yeah [18:24:50] and I will also try changing XSHIFT and NSHIFT again [18:25:03] although I think they are associated with the padload RN [18:25:07] and they can get changed [18:26:12] but yeah if we find nothing this way it's probably some additional debugging like writing all used fixed memory addreses until the debug code is hit :D [18:26:33] yeah exactly. that would be the most telling by far [18:26:46] and then we just look for where it went wrong [18:27:39] same time again [18:28:29] anything else from the emulator while I am in the debugger? [18:28:50] is it at the same place as either of the previous two? [18:29:06] yes [18:29:17] it's probably always the same place [18:29:26] well, we had the unused CCS first time [18:29:29] that was different [18:29:30] kind of [18:29:35] kind of? [18:29:41] these last two times I had a debug point in implementationError [18:29:54] that time before I pressed the pause button in Visual Studio after it got stuck [18:29:56] oh, you think it might have continued on after implementationError? [18:30:00] yes [18:30:03] for sure [18:30:09] ohhhh gotcha [18:30:17] well in that case [18:30:26] so the first real error is the implementationError("RESUME without RUPT.\n"); [18:30:39] which manipulates some emulator variables, so [18:30:42] one thing that occurred to me is that in Block II, a RESUME without RUPT is completely normal and it happens for almost every single program alarm [18:30:45] who knows what happens [18:30:57] oooh [18:31:04] so it maybe just tries to give a program alarm [18:31:07] and then completely fails [18:31:11] possibly? [18:31:25] should I try to uncomment this implementationError call? [18:31:29] comment* [18:31:34] just this one? [18:31:47] let me look at how RESUME is implemented [18:32:12] ....yeah. try commenting that out [18:32:46] if (!agc.INTERRUPTED) [18:32:49] implementationError("RESUME without RUPT.\n"); [18:33:10] I almost overlooked the if because implementationError isn't more to the right :D [18:33:25] yeah, not the best formatting in this file lol [18:33:49] if it's just a weird program alarm it could still easily be the padload [18:34:02] hmm, I don't think it is [18:34:20] let's see if I get any other implementationError [18:34:29] there's no RESUME in the ALARM code like there is for Block II [18:34:48] and this one really looks like it's in the "leave an interrupt" code [18:35:44] yeah, I'd definitely like to know how it got there [18:38:11] lol [18:38:14] if (operand >= 02000) implementationError("TS accessing fixed memory."); [18:38:38] yeah put that RESUME without RUPT back in. we need to figure out why it's there lol [18:38:47] it went to P14 [18:39:02] but this error only happened 2 seconds or so later [18:39:14] it probably shouldn't go to P14... [18:40:15] I'll stop using debug mode and will play with those padloads [18:40:27] they changed the behavior of the freeze one time before [18:40:42] when we were still stuck in P04 [18:40:51] with one set of values it gave me a freeze [18:40:54] normally it didn't [18:41:03] but that could also be somewhat random behavior of the debug code [18:42:09] I might re-route the printf to a Orbiter log call or so [18:42:27] printf in implementationError [18:46:51] it really shouldn't go to P14 [18:47:00] I think it's on a fixed timer [18:47:08] TTUMON - Nominal time from end of pitch monitor to start of tumble monitor [18:47:17] TENDPITCH is 134 seconds [18:47:27] TTUMON is 43.35 seconds [18:47:45] so it should start P14 at about 3 minutes [18:47:56] it seems to go to P14 just before the freeze [18:48:52] any changes there... [18:50:06] maybe there are some erasable changes there [18:50:16] and the required erasables are zero [19:00:27] I can definitely do a bunch of checking in P11 still, like I did with P04 [19:00:42] what it did correctly and what not etc [19:15:10] hmmmmmmm [19:15:22] yeah that would also be useful info [19:16:11] so this is TARGJOB? [19:17:57] TARGJOB is the start of P11 [19:18:02] that seems to all work right [19:18:12] I would now check step by step if the things it does are right [19:20:43] hmm [19:21:02] now I wonder if I should maybe send a Guidance Reference Release signal to the CMC [19:21:09] it wasn't done on Apollo 4 apparently [19:22:30] oh really? hmmm [19:23:05] just happens at liftoff then [19:23:38] TLIFTOFF has a good value, so much is clear [19:24:56] you know what? I need to make a computer history museum archives appointment [19:25:02] https://www.computerhistory.org/collections/catalog/102785203 [19:25:15] this is very early but if it's going to be relevant for anything, it's going to be for 202 [19:25:56] yeah for sure [19:47:57] research request sent. it will probably be a couple of weeks though [19:48:33] ooo that looks interesting [19:49:25] maybe! as usual, expectations management :D [19:49:33] https://www.computerhistory.org/collections/catalog/102625929 [19:49:40] ^^ this sounded very interesting but ended up being 3 photocopied pages of Don's listing lol [19:51:02] lol also their automated email reply says [19:51:05] > Our typical response time is within two weeks. [19:52:18] ok so TARGJOB seems to do reasonable things for the most part [19:54:29] but there must be a difference to Solarium [19:54:58] pretty sure it should just make copies of TPACIF1 and TATLAN1 at this point [19:55:21] stored in TPACIFC and TATLANT [19:55:30] that doesn't happen the same way [19:55:48] oh I know I think [19:55:53] it adds the liftoff time to it [19:55:57] Solarium doesn't do that [19:56:00] I think [19:58:14] possibly related to change C? [19:58:26] "Lift-Off has been rewritten like 204 to zero the AGC Clock" [19:58:33] yeah must be [19:58:43] if it wasn't zeroing the clock in 202, it would need to account for the starting clock value [19:58:45] I guess Solarium does calculations in GET [19:58:50] and Corona in GMT [19:59:19] so probably all normal there [20:08:46] TMONITOR behaves a bit differently for sure [20:08:59] in MONITJOB [20:09:08] it runs that for about half a second before the freeze [20:11:14] "Since in [20:11:16] 501 boost roll and pitch begin at different times and the platform [20:11:17] alignment is different, the 204 program had to be modified slightly." [20:11:30] surely somehow related [20:12:04] there are separate TPITCH and TROLL in 501 [20:13:41] I should read the GSOP flowcharts more :D [20:14:06] yeah, those flowcharts are great [20:15:34] there are separate TPITCH and TROLL at least [20:47:05] alright my Apollo 17 MCC branch is done up to lunar landing [20:47:41] nice! [20:48:57] its pushed to my online repo if anyone wants to try it [20:49:36] thewonderidiot, I think I see a padload for 202 that doesnt exist for 501 [20:49:44] oh really? [20:49:45] TENDROLL [20:49:54] Solarium handles this differently [20:49:59] in ROLLER [20:50:19] Solarium has new padloads for this, as listed in the 202->501 document [20:50:31] MAXROLL and 1/RLLRTE [20:51:10] so it must be handled differently in 202 [20:51:13] and unlike a few cases, Jay appears to have been exhaustive in deleting TENDROLL. no references to it in Solarium [20:51:20] so, you need me to find where that is :D [20:52:19] yep [20:52:30] MISSION_CONTROL_PROGRAM [20:52:33] has all the fun [20:52:43] okay, I'll focus on that as much as I can tonight [20:52:51] should hopefully have an address for you by the time you wake up [20:53:22] might not be simple as it seems like a bit of a rewrite compared to the 202 flowchart [20:54:39] yeah, I'm going to switch over from Solarium code alignment to straight disassembly of the relevant banks, using the GSOP flowcharts as a guide [20:55:11] I am so happy they put these flowcharts in the GSOP. using proper program labels and everything [20:56:49] 501 GSOP doesn't have this or did I overlook it? [20:56:53] would be nice for comparison [20:58:08] hmmm, doesn't look like it does to the same level of detail at least [20:58:21] yeah [20:59:20] I have the (weak) theory that the memory location of TENDPTCH in Solarium is the location of TENDROLL in Corona [20:59:41] not ending the roll program code and TENDPTCH might be zero, hence the switch to P14 just before the freeze [21:00:11] that sounds perfectly plausible [21:02:16] ok, I'm looking forward to making some progress with this tomorrow. About 10 seconds of mission time at a time if it has to be like that :D [21:02:23] hehehe [21:02:36] it's fun, it's been a while since we've had to work out how to use a program like this :D [21:02:38] surely we will make it to a nominal switch to P14 tomorrow [21:02:51] or more freezes [21:03:05] or both! [21:03:24] sounds likely [21:03:28] good night! [21:03:31] night! [04:34:51] .tell indy91 I've essentially disassembled the whole launch program (I think) and incorporated it into my source tree. You can see it in https://github.com/thewonderidiot/virtualagc/blob/Corona261/Corona261/202_MISSION_CONTROL_PROGRAM.agc -- everything down to ABORTRPT is aligned [04:39:03] .tell indy91 Our GSOP is apparently outdated and TENDROLL doesn't behave as shown. It's actually a counter of MONITSK1 executions (in 0.5 second increments), after which the roll monitor will finish. That counter is at address 1561. TENDPTCH appears to behave essentially the same as 501. [04:43:02] .tell indy91 oh also, ROLLDTH (which existed in Solarium but was apparently unused) is actually used in Corona, in DOROLL. [05:52:09] 623 lines into 202 MISSION CONTROL PROGRAM alignment. this has gotten be below 8000 differences between my source reconstruction and the dump [12:42:47] hey Alex [12:49:13] hey [13:25:44] what's your plan with the Apollo 17 MCC stuff? [13:28:02] for now its just an experimental branch in my git repo [13:30:25] I think it will stay there for a while as NASSP 8 is only up to 11 technically [13:30:38] with 12 sneaking in :D [13:31:50] maybe you could look at it a bit like Nik's block 1 branch, if people want to try it, its there :D [14:35:56] hey [14:39:17] hey Niklas [14:39:31] somehow I cannot get DPS input maneuver on MPT [14:39:57] if I use RCS as a thruster, the maneuver transfers [14:40:43] MFD or MCC? [14:40:59] from which maneuver calculation? [14:41:11] MFD [14:41:24] I am doing the No PDI+12 [14:41:26] direct input? [14:41:30] yep [14:41:41] what do you have for throttle and 10% duration? [14:42:39] -15 and 0.4 [14:43:02] hmm [14:43:12] any complaints on the online monitor? [14:44:08] none at all [14:44:21] it doesnt show anything when I hit transfer [14:45:08] very strange [14:48:00] what I did in the mean time is use the APS thruster to calculate the burn [14:48:02] got a scenario? [14:48:05] sure [14:48:16] might take a bit, I'm in the Block I branch [14:48:37] where I think I just found the main problem with progress for AS-202... [14:48:44] https://www.dropbox.com/s/velvrjynoeyy1ej/Apollo%2017%20NoPDI%2B12test.scn?dl=0 [14:48:52] no rush [14:51:18] btw I am using just the input maneuver on the MPT and the SPQ to get a No PDI+12 solution [14:51:47] and the pre-mission vales of +106.5, 0, -50 actually already give perfect results [14:52:05] fun [14:52:16] using optimum CSI [14:52:26] cheat :D [14:52:54] optimum CSI will then not have the same DT between abort and CSI as the timeline book [15:01:47] right [15:07:24] morning! [15:20:13] hey Mike [15:20:28] I haven't tried it yet, but a pretty important padload got overwritten which I would blame all problems on [15:20:58] POLYENTR [15:21:07] has the address of the subroutine POLY in fixed-fixed [15:21:44] shares a memory location with RETAA. [15:21:54] it might have been my own fault, I forgot that you can simply do V37E 01E and went into V57 at first [15:22:07] I thought I had reloaded the scenario, but maybe not [15:22:22] hey Mike [15:22:44] indy91, ok think I got this No PDI-1 +12 procedure down :D [15:22:57] anyway, it's very likely another TC gone wrong like with the CALCG [15:23:21] +100, 0 ,-50 on MPT, then use SPQ in fixed TPI time and iterate the direct input to get DH of 15 [15:23:32] yeah makes sense [15:23:37] I'm about to debug your DPS problem [15:23:59] oh, yes, POLYENTR is very important haha [15:25:57] AlexB_88, so what inputs should I use [15:26:12] MPT mode is active [15:26:22] the LM MPT still has configuration code CSL [15:26:48] should I just initialize both MPT? [15:26:58] hmm [15:27:04] do I need circ burn and DOI-2, too? [15:27:22] this is after both burns [15:27:26] ah ok [15:27:41] and I thought I initialized both tables already, are they not? [15:27:49] or maybe I did that wrong [15:28:02] I think the format changed recently for initializing [15:28:38] it did yeah, to easier do the propellant and area stuff [15:28:41] ah I forgot [15:28:52] debug mode and auto detection of configurations don't go along well :D [15:29:39] let me check again what is actually on the MPT in this scenario [15:29:41] so I did a direct input on LM table, TIG 113:02:13, DPS, PGNS Ext DV, M40,P2,100,0,-50; [15:30:29] CSM MPT has configuration code L [15:30:32] already not right :D [15:30:45] LM MPT has configuration code CSL [15:30:52] so CSM+S-IVB+LM [15:31:18] and LM MPT also has full S-IVB weight [15:33:02] I wonder if there is some bug with a DPS burn but S-IVB still in the configuration [15:34:06] oh I see [15:34:20] there is an error return but no error message for the online monitor [15:34:44] I don't understand how you got it to calculate an APS burn though [15:35:04] there is a check that forbids DPS, APS and SPS burns if the S-IVB is in the configuration [15:35:20] actually let me just try your inputs with the already initialize MPT [15:38:08] same error for DPS and for APS [15:38:34] it is missing an error message I guess [15:38:54] just for this specific case [15:40:20] LM RCS is allowed [15:40:27] I think you mentioned earlier that you tried that [15:40:42] I had re-initialized the tables and then the APS worked [15:40:48] but DPS still not [15:40:58] I might be doing the initializing procedure wrong [15:41:27] I just select the vessel, then hit auto [15:41:35] you have to do that with both tables [15:41:41] and two different vessels [15:41:42] yes I did that [15:41:51] ah and auto doesn't actually updates the MPT directily [15:41:54] directly* [15:42:03] it basically updates the MED inputs on the left side [15:42:16] left side is MED, right side is what is actually on the MPT right now [15:42:28] so the quickest process is [15:42:42] select CSM or LM and select vessel [15:42:48] then Auto button [15:43:03] and then you still have to go through each MED you want to update and press the update button [15:43:16] and you will see that left side (inputs) and right side (MPT) will show the same things [15:43:30] and then repeat process with other vehicle [15:43:57] hmm I did exactly that [15:44:02] with the update button [15:44:25] did you update the MED for the vehicle configuration? [15:44:34] by default it is CSL [15:44:45] in your scenario you have an updated CSM MPT with configuration L [15:44:52] which is wrong of course [15:44:56] L should be for LM MPT [15:46:09] if you only do a weight update for your LM MPT then it won't touch the S-IVB weights [15:47:35] Id did TGT: America, AUTO then config shows C, UPD and MPT shows C and "Update successful!" [15:47:55] put up a tiny PR for the error message that you should have gotten [15:48:00] then the exact same for Challenger with L and L [15:48:45] is it the wrong scenario then? [15:49:10] if the right side says C for the CSM MPT and L for the LM MPT then it's not the same scenario [15:50:02] or did your MCC mess with it or something :D [15:50:25] maybe you didn't switch to updating the LM MPT or so [15:50:38] and first made the CSM MPT have configuration C and then later L [15:50:42] and LM MPT never changed [15:51:06] one thing I might change is put CSM vs. LM as the top row on the init page [15:51:35] hmm I am on the same scenario, and I had completely deleted the MCC/RTCC out of the scenario to start fresh [15:51:37] because it is the more important change than switching between the MEDs [15:52:01] yeah then it defaults to CSL [15:52:14] from what I am seeing you likely only updated the CSM MPT [15:52:35] oh wait [15:52:39] CSM MPT has no masses at all [15:53:53] you have to cycle through each MED for each vessel to update them [15:54:02] previously there were just three buttons to do the same [15:54:33] the auto button does update all MEDs at the same time though [15:54:41] so the input data is all there then [15:54:52] just each MED has to be done separately [15:55:50] it is more button presses than before, but it has more features (propellant, areas) and you can see exactly what is on the MPT itself on the right side [15:55:56] ahhh [15:56:12] ok I got it now I think :D [15:56:29] did you not do the steps with each MED separately or so? [15:56:36] I wasn't actually cycling the Table before pushing auto [15:58:05] yep now it works [15:58:18] DPS burn transferred to MPT [15:58:36] hmm [15:58:43] I'm not sure I understand that issue [15:58:52] there are no separate MEDs for CSM vs LM MPT [15:59:12] the input data gets filled with numbers from the selected vessel [15:59:19] you can then still cycle CSM vs LM [15:59:37] or did you also not cycle the table before pressing update? [15:59:44] before I was just doing TGT: America, then right away auto and update, TGT: Challenger, auto, update [16:00:06] aaah ok, so both auto and update without changing the table [16:00:36] like I said haha, that's why I want to put the table at the top to be clear [16:00:37] yes [16:00:43] "THIS IS THE CSM MPT YOU ARE CHANGING" [16:00:48] haha [16:01:01] I'll do that some time [16:01:07] back to Block I then for now... [16:01:13] :D [16:01:50] back in a bit [16:01:53] ... while VS is building [16:08:16] apart from this one thing maybe I do quite like the new MPT init method [16:08:24] there are no hidden update [16:08:36] you see everything that actually gets changed in the MPT [16:09:44] AS-202 launch attempt [16:10:22] not frozen [16:10:26] still in P11 [16:10:43] error needles are a bit bad, but I still have a Saturn V pitch polynomial loaded [16:13:13] P14 [16:13:17] everything nominal [16:13:39] not much to do for the CMC now until cutoff [16:14:24] did you mess with the roll monitor padloads at all, or just let it be? [16:15:00] I put in octal 12 for TENDROLL [16:15:04] for 5 seconds [16:15:39] probably not super relevant, that was never the failure point haha [16:15:44] just a tiny roll program [16:15:46] 5° [16:16:12] not sure what to do with ROLLDTH [16:18:30] AlexB_88, I have seen your PRs too [16:19:17] so I just approved the PR to let the RTCC call me a moron for trying to do a DPS burn with the SIVB attached :D [16:20:40] cutoff [16:20:54] P31 [16:20:58] CSM sep [16:21:01] P41 [16:21:03] SPS-1 ignition [16:21:14] shows some DVs with N40 [16:21:34] burn is a bit out of plane but attitude looks good [16:22:07] S-IVB cutoff is still quite suborbital, I think this is a 4 minute SPS burn or so [16:22:19] it targets specific semi-major axis and eccentricity [16:22:37] so I should know pretty easily if it went well [16:23:09] awesome! [16:23:24] I'm actually not sure what it does after cutoff [16:23:28] some coasting I guess [16:23:43] half the DV is done [16:23:59] I think the burn will be longer than planned [16:24:13] could be many things like wrong Block I CSM empty masses or so [16:24:45] 100 ft/s [16:25:01] cutoff [16:25:05] good orbit! [16:25:12] P21 [16:25:18] some attitude maneuver? [16:25:38] error needles moving a bunch [16:25:54] P22 [16:26:31] oh I am dumb [16:26:57] for manned launches they have SCS attitude switch in accel cmd [16:27:15] so it couldn't do a RCS pitch maneuver... [16:27:26] CSM is pointing straight down now [16:27:35] hahaha [16:27:49] that sounds nominal, I was reading something about vertical orientation [16:29:15] apogee altitude and eccentricity of the orbit are as expected [16:29:30] so this might now be coasting for a while [16:29:32] until SPS-2 [16:32:53] oh no [16:32:59] program alarm [16:33:03] COMP ACTY light [16:33:12] DSKY frozen [16:33:24] it was going too well [16:35:13] hehehe [16:35:23] yeah surely that had to happen again :D [16:36:34] I could try again, maybe the orbit wasn't good enough after all with the wrong switch setting. I forgot if that is also inhibiting in pitch with the SPS TVC... [16:36:52] but I'm kind of surprised that this happens now [16:36:57] randomly minutes into P22 [16:40:10] I'll just run it again for fun :D [16:40:18] and no attitude control issues [16:41:39] also need to check if there are any other wrong switch settings [16:42:57] timing wise the lockup might have been FDAONTSK [16:45:03] hmmm okay [16:45:23] if you get stuck, I should definitely be able to disassemble the mission control program that far tonight [16:46:25] oh FDAONTSK is at the beginning of bank 24? what do I know about that bank.... [16:47:00] I think it runs at 5 minutes after SPS-1 cutoff [16:47:06] I'll time it [16:47:24] one bad diode in the last strand of that bank [16:47:27] otherwise healthy [16:47:59] so if FDAONTSK is at the beginning of the bank like it is in Solarium, it is unlikely to have a rope read error [16:48:56] but there has been a decent bit of bank shuffling in the mission control program so far so, it might not be haha [16:50:23] might also be coasting integration that's failing or so [16:50:43] definitely not something at the beginning of P22 [16:50:51] must be something scheduled [16:51:39] need to check this sequence of programs more [16:51:46] maybe I should be getting P24? [16:53:33] SPS burn seems to be just like before [16:59:44] indy91, is the SPQ in the RTCC MFD using ConcentricRendezvousProcessor? [17:01:20] yes [17:01:31] although it calls PMMDKI as a wrapper function [17:01:40] for optimum CSI I think [17:02:07] thewonderidiot, yeah essentially 5 minutes after cutoff is when the lockup happens [17:02:35] I believe that is when FDAONTSK is scheduled to run [17:02:53] and COASTPHS sets up FDAONTSK to start 4.825 minutes [17:03:01] so that makes sense [17:03:54] alright, I'll just keep on disassembling the mission control program and should get through that code tonight [17:04:09] if I can find it :D [17:05:05] not sure I actually implemented this FDAI align thing haha [17:05:39] oh, just looking through the octals of the dump, FDAONTSK is still in bank 32, at the end [17:06:43] the end of banks 12 and 32 are probably my most "there might be problems lurking here still" areas [17:07:23] because there's a bad bit 13, but also bit 7 is kind of marginal and read incorrectly in one memory location (that I found) [17:07:43] so I have a special case to correct that one location, but there might be others [17:08:26] I'm planning on doing a manual oscilloscope reading of bit 7 in the affected strand [17:10:43] hmm I see [17:11:03] from the scenario it looks like the software did set the FDAI align relay in the DSKY [17:11:50] I can check if it's the FDAI align on or off code that is more likely the problem [17:13:41] hmm [17:13:50] I see something already [17:13:52] TCOAST [17:13:59] might be a padload in 202 [17:14:45] could lead to something being scheduled in the past [17:14:56] it's still zero in the pre-lockup scenario [17:14:59] oh interesting [17:15:23] SPS2 ignition sequence in the 202->501 document [17:15:52] oh yeah [17:15:57] FDAI align on was no problem [17:16:02] 10 seconds later is the lockup [17:16:11] I bet it's missing something in TCOAST [17:16:59] it wants to schedule something X seconds after SPS 1 cutoff [17:17:02] that's the TCOAST [17:17:23] has to add subtract 310 seconds in the FDAOFTSK for that [17:17:28] -add [17:27:05] scenarios edited [17:27:10] let's see what happens now [17:30:55] it survived [17:30:58] the mission continues [17:31:01] alright got the MCC calculating No PDI+12 [17:31:10] using a loop with the SPQ [17:31:17] right [17:32:00] now a long wait until it starts maneuvering to SPS2 attitude [17:32:06] woo! [17:32:44] DVX 107.5, datacard says 107.9 [17:33:10] ha [17:33:18] with or without optimum CSI? [17:34:04] without [17:34:11] oooh nice [17:34:34] fixed TPI time and iterates the DVX to get the proper DH [17:34:42] right [17:35:04] all with the DT from maneuver to CSI being the nominal 55 minutes [17:38:50] starting with SPS2 it's going to be quite eventful [17:39:21] there are two short, additional SPS burns without guidance [17:39:35] that was the reason why AS202 couldn't be flown with Solarium [17:39:46] that logic got disabled [17:41:33] yeah [17:41:41] just disabled, not deleted [17:41:54] so I'm hopeful I don't have to do any work on them in the source reconstruction haha [17:53:18] apogee [17:59:58] P24 [18:00:00] attitude maneuver [18:00:05] P32 [18:00:24] and also already ullage? [18:00:35] P42 [18:00:36] ignition [18:00:53] this seems too early [18:01:07] I'm using a mixture of GSOP and mission report numbers, could be that [18:01:44] hmm [18:01:48] I doubt I have enough propellant [18:02:04] huh [18:02:05] cutoff [18:02:19] lol [18:02:23] CM/SM sep [18:02:27] P62 [18:02:28] ok [18:02:44] all very weird and too early [18:02:49] P63 [18:03:01] oh no [18:03:08] hahahahaha [18:03:12] orbit is nearly circular at 700 NM... [18:03:18] not reentering this way :D [18:03:21] oh wow [18:03:28] yeah not a chance [18:03:44] I bet this issue is all in padloads [18:04:07] maybe more got overwritten... [18:13:01] I think the attitude maneuver for SPS2 started at the right time [18:13:09] but it should be 10 minutes from there to ignition [18:13:17] it got into P32 way too early [18:18:21] you know, I might stop here and wait until we can look at the source code for it [18:18:48] the lower half of this 202 mission control program file is still actual Solarium code, right? [18:19:03] it's a bit confusing to look at with variables that got ADDED in Solarium, so clearly not Corona :D [18:19:14] correct haha [18:19:43] I should add a ## ---------------------------------------------------------- EVERYTHING BELOW IS SOLARIUM ----------------------------- comment to track my progress through the file [18:20:56] right now that split is at ABORTRPT, although I went a bit further this morning [18:21:17] I'm up to 3OR4TEST locally now [18:24:19] I got lucky finding this TCOAST thing [18:24:26] it's probably another thing like that [18:24:27] or some flag [18:25:30] the whole purpose of going into att hold 10 minutes before SPS2 TIG is to avoid an attitude maneuver [18:25:55] pointing exactly down and then going into attitude hold should set up the right burn attitude 10 minutes later [18:28:02] I actually missed that it got into P23 [18:28:11] does an orbital integration to SPS2 TIG I believe [18:28:12] then P24 [18:28:16] that's all fine [18:28:30] but then it goes to P32 before it even finished maneuvering [18:28:38] so SPS2 TIG must be bad or something like that [18:31:15] yeah [18:31:24] seems all in all pretty promising though. there is a lot working :D [18:32:47] yep [18:32:52] a lot more than yesterday haha [18:33:06] damn padload being overwrritten [18:33:18] and one that contains a fixed memory address... [18:36:20] indy91, https://www.dropbox.com/s/7vneidh44equsva/Screenshot%202023-05-02%2014.35.34.png?dl=0 [18:36:33] any way to calculate that yet with the current RTCC? [18:36:57] ah, that's an Apollo 17 special, right? [18:37:07] probably due to the bad experience with the Apollo 16 re-rendezvous [18:37:12] hmm right [18:37:24] well [18:37:38] it could be done with the relative motion display [18:37:41] but that's MPT only [18:38:01] don't think we have some simpler tool that calculates closest approach of two orbiting vehicles... [18:40:54] did they actually get this update? [18:41:01] not seeing it in the transcript [18:47:44] ah they didn't eh [18:48:09] its not in the flight plan either [19:13:17] AlexB_88, your Apollo 12 MCC changes, is that based on feedback from Ryan or... [19:14:22] nope just issues I found [19:14:26] ah looks basically just like unused code [19:14:46] yes [19:15:08] like case 32 has no PAD but it was defining one in the thread [19:15:26] yeah [19:16:06] and the LunarSurfaceDataCard had some remnant code from Apollo 11 [19:16:23] that wasn't used [19:16:29] in your Apollo 17 PDI scenario, did you delete anything from the MCC? [19:16:55] I deleted the whole MCC [19:17:32] you might have deleted too much [19:17:35] stuff like LEMNAME [19:17:50] oh [19:17:56] that gets used for AOS/LOS stuff [19:18:04] right [19:18:06] that's also somewhat new haha [19:18:22] the code in the MCC now gets used not just for displaying AOS/LOS messages [19:18:27] Ill re-add it [19:18:32] but it's actually used for e.g. HGA signal strength and stuff [19:18:43] basically a MSFN simulation [19:19:03] that way individual ground stations are being tracked and not just the center of the Earth [19:19:29] right [19:19:35] ill amend the PR [19:19:39] https://www.youtube.com/watch?v=gGDSDvsyzhM [19:24:08] thewonderidiot, I am not seeing a delay from the end of the wait due to TCOAST to ignition [19:24:17] but in the flowcharts there is a different variable, VERTIME [19:24:34] mayb VERTIME is a padload that is 10 minutes shorter than TCOAST [19:24:58] and with those two both the start of attitude hold and later SPS2 TIG is controlled [19:25:24] oh hi [19:25:29] ohai [19:25:58] interesting [19:26:24] "The Vertical Erection Initialization has been replaced by a Cold [19:26:28] Soak Initialization which orientates the spacecraft to [19:26:29] 3 specified [19:26:30] erasable IMU gimbal angles." [19:26:32] hey Matt [19:27:14] ahhh I see [19:27:33] I was about to say something along the lines of "oh no there is no VERTASK or VERTIJOB at all in Solarium" [19:28:02] but that would explain that lol [19:28:09] hmm, the GSOP also says "SPS1 cutoff to end of local vertical phase" is in fixed memory [19:28:38] so I should probably use the time until SPS2 TIG in TCOAST [19:28:46] and see if anything still happens 10 minutes before :D [19:32:08] indy91, like this? https://www.dropbox.com/s/x1fnc3dxklacael/Screenshot%202023-05-02%2015.31.29.png?dl=0 [19:32:32] that should do it [19:32:49] ok Ill push that [19:34:35] PR amended [19:40:36] back to where I was with AS-202 [19:40:42] this time with time acceleration :D [19:41:30] so much for waiting for me to disassemble more :P [19:41:53] well I found something pretty simple haha [19:41:59] if this isn't the solution I have nothing [19:43:58] ooh [19:44:04] long COMP ACTY in P22 [19:44:06] now I am in P24 [19:44:11] I think I had the right idea :D [19:44:18] you better not go to P32 now [19:44:24] pretty large attitude maneuver though [19:44:32] I thought this wouldn't be the case [19:44:36] but we will see [19:44:47] now I would expect it to stay in P24 for 10 minutes [19:46:52] I'm not sure I like this attitude for the burn [19:52:54] ah wait the burn is later than I thought [20:01:45] but still, I think something is off with the SPS2 burn target [20:01:57] well, ignition very soon [20:03:00] P23 [20:03:20] P32 [20:03:49] P42, ignition [20:04:03] yeah this makes no sense [20:04:36] total velocity should be increasing, but burn is kind of upwards [20:05:20] unless the GSOP trajectory is very different from actual [20:06:01] ah damn I missed if it even did SPS3 and 4... [20:06:31] orbit is good for reentry, but it didn't hit the eccentricity target at all [20:06:41] made it more circular [20:08:13] indy91, "ML at input time" would that be the TIG of HAM? [20:08:29] I am doing No PDI2+12 now [20:08:44] insertion and boost already on MPT [20:13:09] HAM is nominally zero there? [20:14:42] I don't think so [20:15:27] actually im not sure [20:16:12] CSI is 47.4 fps according to the PDI summary data chart [20:16:42] ah but I think you use the HAM chart based on the CSI DVX? [20:19:33] uhh, I thought I could at least get a good reentry, but the attitude is very bad [20:19:38] ah I think it is nominally 0 [20:19:56] on the HAM chart if P32 shows DH of 15, then HAV DVX is 0 [20:20:00] I wonder if something broke the state vector or the alignment [20:23:07] yeah very bad reentry [20:23:20] that's it with AS-202 for today, actually this time haha [20:23:59] AlexB_88, if HAM is nominally zero you just have the boost as an extra fixed DV burn then I guess [20:24:07] and CSI is one orbit later [20:24:32] so quite similar to No PDI1+12 then [20:24:41] also SPQ etc [20:25:20] ah [20:25:52] so then what use is the DKI then? :D [20:26:08] ah well I guess PDI-0 for Apollo 13-15 [20:26:31] and Apollo 10 lol [20:26:38] ah right [20:26:41] it has a PDI Abort maneuver [20:26:46] at PDI TIG, not +12 [20:26:49] I should have known I just stole some code from it :D [20:26:55] yeah what use is the DKI... [20:27:12] I need more MOCR audio, that's for sure [20:27:43] DKI is useful for Gemini and Skylab [20:28:04] and certain manual lunar ascent cases I think? [20:53:52] night! [03:54:56] Aparently I unpluged the modem. Whoops. [14:30:47] hey [14:31:03] hello [14:31:16] trying to figure the most complicated part of any padload [14:31:24] the pitch polynomial of course :D [14:31:40] weird scaling and every parameter has its own one [14:33:41] hey guys [14:34:00] oh fun [14:34:23] how related is that to the LVDC polynomials? [14:34:27] hey Alex [14:35:20] it should be basically the same, except the LVDC uses three segments of polynomials [14:35:22] and the AGC only one [14:35:32] so there wouldn't be a simple, direct conversion [14:38:28] I also noticed some things I need to tweak with the LVDC for the AS-202 launch [14:38:34] I'll do that and then give it another spin [14:38:49] not that I expect it to change anything about SPS2, but still, a bit better trajectory [15:08:55] morning! [15:09:58] hey [15:12:59] I finished aligning bank 32 last night, and got a quarter of the way into bank 33 [15:13:08] I don't remember what you wanted to look at haha [15:13:44] awesome [15:13:53] after mission control program it is probably powered flight subroutines I need to look at next, for SPS2 [15:15:15] ah screw this pitch polynomial, it's so convoluted :D [15:16:10] I'll do another launch with some tweaked LVDC things [15:33:14] 30 seconds earlier Earth orbit insertion, much closer to actual now [15:37:12] and back at apogee again with the help of some time acceleration [15:37:35] that's my 3 baseline scenarios [15:37:41] T-60s, after SPS-1, apogee [15:38:41] oh, I've run into vertical erection [15:38:55] was very confused for a bit because a lot of the code matches cold soak exactly haha [15:38:59] time to rename a bunch of things [15:39:55] should be quite different though I would expect [15:40:06] inertial attitude hold on 501 while 202 tracks local vertical [15:40:16] ok, back to the fun part [15:40:27] state vector integration seems longer in P22 this time [15:41:04] hmm, no attitude maneuver in P24 at all [15:41:13] last time it did the maneuver to the bad attitude [15:41:50] not sure if this is better? Although as I had said, the timing of the attitude hold was chosen so that no maneuver to SPS2 attitude would be required [15:42:26] I made no padload changes that I could remember [15:42:32] not sure why it behaves different now [15:42:42] only LVDC changes, affecting the trajectory a bit [15:45:07] a bit of cheaty kill rotation and time accel... [15:46:33] if this is the burn attitude, I think I like it [15:46:47] P23 [15:47:07] P32, ullage [15:47:37] P42, ignition [15:48:13] it might be working??? [15:48:14] randomly [15:48:27] hahaha [15:48:39] previously I used the post SPS1 scenario [15:48:43] and did the TCOAST scenario editing [15:48:56] now I did a new launch [15:49:01] uh oh [15:49:04] gonna run out of prop [15:49:10] cutoff [15:49:11] 2.3% left [15:49:19] ignition [15:49:23] 1.8% left [15:49:24] cutoff [15:49:32] ignition [15:49:35] cutoff [15:49:40] 1.3% left [15:49:44] two short SPS burns [15:49:54] orbit looks right [15:50:00] back to P23 [15:50:50] P61 [15:50:59] last time reentry had a bad attitude, too... [15:51:18] this seems fine though [15:51:50] but no CM/SM sep yet [15:52:22] P62 and sep [15:52:49] normal reentry attitude [15:52:55] P63 [15:54:07] ok attitude is a little bit weird in pitch but might be no issue [15:54:52] 0.05g [15:54:53] P64 [15:55:37] roll to lift vector up [15:55:44] P65 [15:57:58] skipping out a bit [15:59:03] P66 [16:00:28] P67 [16:00:37] now the real steering begins [16:03:37] sadly I overwrote the old scenario at apogee. I only have an old SPS1 scenario without the TCOAST edit still [16:03:57] maybe I'll try that one again to see if it get the attitude issues again [16:04:36] I think it's going to overshoot a bit, but should still be pretty close to the splashdown target! [16:04:44] hell yeah! [16:04:57] we did it! [16:05:00] nice work :D [16:05:12] by just... trying it again [16:05:14] very confusing [16:05:34] maybe something was off in the old on-orbit scenario, but I can't figure out what I would have changed [16:06:10] 50k feet [16:06:58] drogues [16:07:53] so, splashdown target was 17.25°N and 170°E [16:08:07] going to land at 17.27°N 170.21°E [16:08:18] 0.2° in longitude is a fair bit, a few miles I guess [16:08:21] but still [16:08:23] not bad [16:08:32] not bad at all! [16:08:36] no alignment or state vector updates on-orbit [16:09:04] nice! [16:13:14] splashdown [16:13:50] programer still doing all its jobs [16:18:28] although I feel like it should be cutting the chutes [16:18:41] anyway, mission success [16:18:43] but why :D [16:20:58] hehehe [16:21:07] I had copied the state vector from the bad scenario, I can still check if that one looked reasonable [16:21:22] the one from orbital integration for SPS2 ignition [16:33:01] alright well in light of the success, I'm going to take a break from disassembly tonight and work on validating the module B24 dump better [16:34:08] haha sounds good [16:38:01] the only difference in padload between the old bad SPS1 scenario and the new good T-60s scenario was that I added a TENDROLL [16:55:13] weird that that would make a difference O_o [16:57:22] I doubt it [16:57:37] it must have been some random factor. The trajectory, the attitude etc. [16:58:02] maybe my CDU implementation is faulty [16:59:14] I'll still fly the mission a bunch of time, I will investigate it if it ever happens again [16:59:24] integrated state vector looks good in the bad scenario [16:59:33] so I don't think it was a state vector issue [17:06:07] ah and the only old scenario I have was actually before SPS2 with the bad TCOAST, not missing TCOAST [17:06:23] so unless I manage to edit the waitlist in the scenario it's going to be difficult to reconstruct :D [17:09:26] hah oh yeah that would be tricky [17:20:33] slightly suspicious that the attitude was pretty much exactly in the wrong direction [17:20:51] maybe it was a confused CDU [17:21:09] but difficult to tell. I better just forget it ever happened :D [17:21:22] so what do I still want to tweak about this scenario... [17:21:27] pitch polynomial I guess [17:21:49] and trajectory wise it is following the GSOP and not the mission report, they seem to have made some tweaks still [17:22:47] hopefully we can get that newer GSOP [17:23:45] also I'm going to be checking out those reentry things from Dan Lickly at the computer history museum next friday [17:24:26] sounds good, updated GSOP would still be useful [17:26:43] the end of the SPS-2 burn through SPS-3 and 4 was very fun to watch [17:26:54] nerve wracking because I was sure it would run out of propellant :D [17:27:12] I'm sure I am cutting it too close [17:27:15] hahaha [17:27:19] I can't wait to see the video :D [17:27:21] maybe I have too much SM RCS mass [17:27:40] definitely need to check all masses again [17:32:54] 200 pounds propellant total for each SM RCS quad [17:33:16] we use the standard Block II value of 336 pounds [17:33:48] so that's about 500 pounds too heavy [17:37:32] ah the Block I propellant is basically identical to the primary RCS propellant tanks of Block II [17:45:35] indy91, btw the Apollo 17 PDI scenario PR was updated [17:46:53] ah yeah [17:47:20] merged [18:28:41] oooo new video? I'm excited :) [18:43:44] well I can finally fly AS-202 successfully haha [18:43:52] still want to tweak various things [18:43:56] but then I'll make a video about it [19:08:43] so in this thread https://www.orbiter-forum.com/threads/implementing-as-202.40913/ [19:08:49] you said "Should it become available I would return to my Block I branch and probably try to get a release version done." [19:08:52] :P [19:22:01] oh nooo [19:22:24] totally forgot about this thread [19:22:38] that was ages ago [19:22:44] 5 months [19:22:51] :D [19:24:01] I don't think I can develop a proper Block I addon with meshes and all [19:24:23] but I could put up a NASSP release of the branch [19:24:27] as it is [19:27:40] hehehe [19:27:45] yeah makes sense [19:28:13] it would be fun to make a proper Block I some day [19:28:22] but that is a lot of work lol [19:29:30] I want a full realistic early Apollo addon [19:29:51] from SA-1 in 1961 through Apollo 6, minus Apollo 5 [19:35:21] trying the abort from S-IVB flight now [19:35:27] should be much the same as Solarium [19:35:32] P73 [19:35:43] I think I did it too early [19:35:51] don't think I have this amount of DV :D [19:36:46] but it's going to try until it comes too close to reentry [19:39:32] maybe in the mean time we could at least get a block 1 DSKY into that branch [19:40:20] haha yeah [19:40:26] oh nice it was enough prop [19:40:30] burned from 50% to 4.6% [19:40:33] should be just a bit of graphic work [19:40:48] so already overwhelming for me [19:40:51] not that I am volunteering myself or anything :D [19:41:26] nah, keep doing the important works that brings us closer to a NASSP 8 release [19:41:32] the Apollo 17 MCC [19:41:37] haha [19:42:00] was in P23, now P61 [19:42:29] Atlantic abort point is at 4°N 31°W [19:44:02] https://i.imgur.com/7QtgTlG.png [19:44:05] done [19:44:13] I did this years ago, mostly as a joke :D [19:46:24] hahahaha [19:47:07] ouch, the burn was a bit too long [19:47:12] had to go steep in [19:47:17] just below 12G [19:47:28] but it might make the target [19:48:03] nah [19:48:05] was too steep [19:48:14] undershoots the target [19:48:18] but not that much [19:48:41] 5.12°N 31.57°W [20:46:19] night! [13:37:06] good morning [14:54:21] hey [15:01:43] hey Niklas [15:02:05] closing in on ascent day [15:03:24] ah nice [15:49:44] it took until today that I remembered why the Block I launches have 327° pitch at liftoff [15:49:51] 0° in body axes [15:49:56] instead of 90° [15:50:21] and the Block I IMU is at a 33° angle, the same orientation as the sextant... [15:50:37] I'm actually not sure what the Block I FDAI should show [15:50:52] body or IMU attitude, there seems to be some transformation in the display electronics [15:53:15] in any case, the Block I FDAI actually had two indizes for the current attitude [15:53:25] one for body and one for IMU [15:53:48] very complicated that all, good that they changed it for Block II [15:55:48] https://i.imgur.com/oyGeUZs.png [15:55:54] looks like both aren't at the center??? [15:59:59] oh right, we have video from AS-202 [16:00:24] https://youtu.be/XfBRe1AhpRE?t=192 [16:00:33] falsely labelled as Apollo 6 [16:00:36] at least that part [16:01:04] the body axes indicator is at 0° pitch, that makes sense [16:03:47] morning! [16:04:55] oh some of that is AS-202? [16:05:10] hey Mike [16:05:13] yes! [16:05:16] starting at 2:30 [16:05:33] launch is at 3:14 [16:06:01] 5° roll angle, because it has to go from 100° to 105° after launch [16:06:10] oh wow [16:06:15] so can't be Apollo 4 or 9, they had a 72° launch azimuth :D [16:06:16] 4 or 6* [16:06:19] fascinating :D [16:06:32] that stage separation shot they start the video off with is also AS-202 [16:06:47] yeah must be Saturn IB [16:07:16] apparently the 3 ullage motors on the S-IVB uniquely identify 202 [16:10:53] hmm [16:11:29] uniquely identifies a Saturn IB S-IVB I would say [16:11:33] I think they all had 3 [16:11:48] so it can't be Apollo 4 or 6 at least [16:13:37] I was kind of playing with the idea of implementing the transformation so that the FDAI works more like Block I, but considering it was also a design change with the two indizes [16:13:39] probably not [16:13:57] IMU to body transformation* [16:33:26] thewonderidiot, just sent Ron an email about a few things, but about one I wanted to talk to you, too [16:33:43] about LVDC emulators [16:34:05] I always assumed that to make it do anything useful you would need a Saturn vehicle simulation of sorts [16:34:13] but that's not correct [16:34:20] it has a flight simulation mode [16:34:25] two types actually [16:34:37] one uses the interfaces to other hardware like the LV IMU [16:35:02] but if it's anything like the Saturn IB EDD describes it, there should be a repeatable flight simulation mode that is entirely contained to the software [16:35:44] oh that's fun :D [16:35:54] so you just need to have the emulator and the software [16:36:01] ok, still not quite there yet I guess :D [16:36:19] write the right number to the flight simulation indicator word [16:36:38] and it should then not be too hard to make it do fun things [16:36:43] that you can monitor on e.g. telemetry [16:36:47] looking at segment names now [16:37:00] there is a simulated accelerometer section [16:37:06] SIMULATED ACCELEROMETERS and SIMULATED PLATFORM GIMBAL ANGLES are two [16:37:07] that's what it would use [16:37:10] yeah [16:37:30] well, it'll be a bit yet before the transcription is done [16:37:42] the EDD says this is for LVDC hardware and software integrity testing [16:37:45] but we will definitely have to try that haha [16:37:54] also I'm going to need to fix MPY and DIV in yaLVDC [16:37:57] you should get the exact bit by bit memory state of the LVDC after each repeatable sim run [16:38:17] neat [16:38:27] do you know what that simulation indicator word is called? [16:39:14] EDD just calls it "flight simulation indicator word" [16:39:32] I also saw it in the documents that converted the LVDC code to other languages [16:39:56] hmmmm [16:41:15] but I don't think the naming of variables there applies to the LVDC code [16:41:21] the actual code [16:41:42] DFLT [16:41:45] maybe FLT? [16:41:55] too simple maybe [16:42:48] O_o [16:43:06] "SET LATITUDE AND GRAVITY FOR HUNTSVILLE FOR SIM. ACC." [16:43:14] they launched it out of Huntsville? lol [16:43:40] uhh [16:44:19] ah yes [16:44:24] I see that in the EDD as well [16:44:45] it might be FMDI? [16:44:59] FLIGHT MODE INDICATOR LOADED BY RCA 110A [16:45:00] it probably has 3 possible values [16:45:14] for normal flight, repeatable and non-repeatable flight simulation [16:45:22] you would find it in various places [16:45:27] including switch selector [16:45:28] oh [16:45:31] no you were exactly correct [16:45:33] D.LFT [16:45:35] haha [16:45:46] - = FLIGHT, + = REPEATABLE FLT TEST, 0 = NON-REPEATABLE FLT TEST [16:45:52] perfect [16:45:58] have fun... in a few months [16:46:01] hahahaha yes [16:46:08] after I'm done having fun with 202 [16:46:13] same [16:46:18] I figured out the pitch polynomial [16:46:24] nice! [16:46:33] quite a few differences to Solarium there [16:46:55] scaling and this whole IMU vs. body attitude thing, too [16:47:02] Solarium pitch polynomial starts at 0° [16:47:25] but with Corona you need to start at -33° pitch, which the IMU has at liftoff [16:48:21] don't think I will change much more at this point about the padload. You can continue to tweak things forever, but it's in a good state now [16:49:22] don't know a good value for ROLLDTH [16:49:48] but the roll error needles behaves fine with using 1 haha [16:49:52] needle* [16:53:10] sounds good enough :D [16:56:47] it didn't perfectly agree with the Saturn pitch polynomial [16:57:03] but I didn't see one in the AS-202 LVOT... where did I even get it [13:32:03] hey [13:32:46] hey [13:33:19] how is the search for the NaN source going? [13:34:01] haven't found anything yet [13:34:31] I did find your fix from about 3 years ago [13:34:40] haha [13:36:29] I might need to add some asserts in there or just log everything [13:38:45] hey guys [13:41:41] hey Alex [13:44:55] starting on an AS-202 video today [13:52:59] nice! [13:53:33] I wonder what the best way of presentation is [13:53:39] wondering that before every video :D [13:53:50] I'm kind of thinking about an outside view with the DSKY in the corner [13:53:56] for most of it [13:54:48] maybe DSKY and FDAI [13:55:29] oh wait [13:55:37] this is an old branch [13:55:54] no FDAI.... nope my eyes can't take it [13:56:38] I got you [13:56:44] I cherry picked the FDAI updates [13:56:46] and DSKY [13:57:23] full merge from the Orbiter2016 would have taken ages to untangle [13:57:29] but I at least took a few commits :D [13:57:37] nice!! [13:58:20] so it looks pretty normal [13:58:32] there seems to be a slight visual difference in the VC [13:58:45] maybe I am imagining it, but I could be missing a commit or two. Nothing bad though [13:59:12] is the Block I SM significantly than block II, for some reason I don't know this? [13:59:32] not super different really [13:59:43] lots of systems in the CM are different [13:59:46] but SM not so much [14:00:40] notes on future project list [14:07:48] ^distant future [14:09:40] haha [14:10:05] I really just squeezed some Block I systems into our Block II CSM [14:10:14] it's far from a good standalone addon [14:10:32] doing that properly would mean starting from scratch [14:13:34] hmm wasn't there an MFD that could show the DSKY with the help of lua scripts or something [14:15:23] ah not quite [14:15:34] we have some lua support to set AGC memory state and read channels [14:15:50] there is a lua example script that comes with NASSP that does a V35 [14:16:06] I've always wanted to use this to set up some tutorials using lua... [14:17:32] there is some fun stuff you can do this way [14:17:50] like the Challenges scenarios that come with Orbiter [14:44:09] that would be cool [15:24:09] can Lua flip generic switches like the checklist MFD interface can? [15:49:39] indy91, I keep forgetting, do we have the P99 EMP for LM deorbit? [15:50:37] I know we have one, but can't remember which mission its for [15:58:16] morning! [15:58:35] AlexB_88, it was first created for Apollo 14, and we have it for 14-17 [16:00:30] hey Mike, thanks [16:00:44] it will come in handy shortly :D [16:08:17] I'm pretty sure it's baked into the MFD somehwere where you can click a button and uplink it [16:09:26] in the RTCC MFD [16:09:53] right [16:53:11] n7275, it sure can [16:53:29] AlexB_88, we have the EMP, but so far I only had put it in RTCC MFD code [16:53:43] I had grand ideas for generic EMP support, with EMPs saved in text files [16:53:52] but we don't have that yet [16:54:09] maybe it's the best idea for now to just hardcode the uplink string with the EMP data [16:54:12] right [16:54:19] yeah thats what I was thinking [16:56:08] as they often said on the MOCR audio they could save MED inputs as "tape" [16:56:32] so if it was actually tape or punch cards or whatever, they probably just had it flying around in the RTCC in such a format [16:56:47] oh and tweak burn, was that read up directly from the TI processor results? IE. impulsive DV? [16:57:14] no, they had an extra display for this [16:57:22] already for the coelliptic profile actually [16:57:57] right [16:58:47] I have it right now just putting the LambertTargeting res.dV_LVLH into a upmessage, should that be ideally made into a non-impulsive DV? [17:01:11] I also put in a special extra evaluator that lets you fly the coelliptic ascent if you want [17:01:32] just wait past the direct ascent TIG + 10 seconds and it switches [17:01:36] impulsive will be totally fine [17:01:45] yeah thats what I thought [17:01:46] oh that's neat [17:02:03] I know which RTCC Requirements document I need for the display, but we don't have it yet [17:03:10] I really know nothing about what is on it, but I could probably come up with something that automatically calculates tweak burns [17:03:12] but [17:03:21] for the MCC that would still be problematic [17:03:27] it's probably just a dislay for the FIDO [17:03:43] and it updates automatically every few seconds or so [17:03:49] right [17:03:58] so for the MCC using the Lambert targeting is probably simpler [17:04:12] even if we would have that display [17:05:17] I was going to get rid of the LambertTargeting because it is redundant now, the Two Impulse Processor is separate [17:05:33] but I really don't like the structure of the TI and the input/output for the MCC [17:06:12] I was trying to make it like the real thing, but as so often sadly the "real thing" is not very good with something like the MCC [17:07:12] maybe I just need to make it even more realistic, go all in with the MPT, and the MCC is controlling things only via MEDs :D [17:08:30] like, the TI on a normal request only updates displays, none of which is a DV in a format useful for a Maneuver PAD [17:08:52] when you move a TI solution to the MPT, only then it generates the DV properly [17:09:03] so using the real structure just makes it bad for our MCC right now [17:13:34] and using the MPT for the MCC a lot also has some problems [17:13:48] mostly debugging really [17:14:18] if you let the MCC add a maneuver to the MPT you would need a check that the maneuver isn't already there from e.g. refreshing the MCC state [17:19:42] right [17:20:10] sounds like a pain :D I would vote to at least keep some legacy things in for the MCC [17:22:31] yeah, some of this now duplicate code is really the better choice for the MCC [17:29:23] oh Alex FYI if you didn't hear, I should be getting an updated CSM AOH Vol 2 next week. it's for CSM 113 and 114, and is newer than our current one by more than a year (current is July 1970, new one will be October 1971) [17:30:02] so there may be some Apollo 17-relevant updates in it [17:33:39] oh nice! [17:35:19] maybe they finally deleted the orb rate and PTC procedures using DAP manipulation [17:35:26] which already was outdated when V79 got added :D [17:35:31] hehehe [17:39:46] oh btw indy91, I noticed the rover has super stable TD points [17:40:01] I wonder what kind of black magic max q used for that [17:40:16] but I kind of want to see if they work good for the LM [17:40:32] haha go ahead [17:41:05] I am still annoyed with them, just a slight RCS fire and it jiggles around [17:43:27] yeah [17:46:16] if you don't pause on load in a few of the Apollo 11 scenerios, Eagle gets to be Mare Tranquillitatis' first submarine. [18:11:39] yeah lol [18:12:13] not something I'm proud of as the LM's TD designer [18:20:53] I mean they did call it a sea [18:20:56] what were they expecting to happen [18:42:40] lol [18:43:15] it must've been quite a dramatic place the last time it was actually liquid [19:35:44] tweak burn less then 5 ft/s [20:58:51] night! [12:32:16] hey [12:40:17] hey Alex [12:48:04] just a time for a bit of NASSP today then tonight I go to your side of the pond :D [12:55:58] oh nice, what are you doing in good old Europe? [12:57:31] going to rainy Ireland [12:58:13] Need a refill on some fresh Guiness :D [12:58:36] ah makes, sense :D [12:58:43] Guinness* [12:59:18] ever been? [12:59:21] nope [12:59:30] closest I got to it was Ireland haha [12:59:31] uhh [12:59:33] London [12:59:45] haha [13:00:06] although technically the closest I have been to Ireland was probably an aircraft [13:00:09] well at least there the street names are not in Gaelic :D [13:00:47] they sure aren't [13:01:15] unbelieably I managed to record a 2D panel DSKY, crop it out and can put it in the corner of my main video fo AS-202, an external view [13:01:51] win some, loose some. I had the PAMFD up to show orbit data during the SPS1 burn. But it doesn't automatically record the External MFD because it's a separate window... [13:02:01] so now I have to record the MFD separately, too :D [13:02:16] or re-record with recording the full screen [13:03:54] ah cool [13:05:02] yeah the external MFD can be cumbersome sometimes [13:05:22] I successfully docked with America [13:05:40] I got the direct ascent and tweak burn all working with the MCC [13:05:57] great [13:06:09] you know your Apollo 17 MCC is going to break at some point, right? :D [13:08:15] who knows it may already be :D [13:09:17] ha, I would hope not [13:09:29] maybe if you started it before my GETbase change... [13:11:15] my plan is to update it periodically with RTCC/MCC updates you make [13:12:20] sounds good [13:12:39] maybe have it a bit like your block 1 branch where you revisit it every so often [13:14:13] but I guess what you mean by it could break is your plan to make the MCC more MPT based? [13:16:42] nah, just general changes. I don't really plan to make it MPT based anytime soon [13:16:50] one thing I will do is a change to Maneuver PADs [13:16:55] which the GETbase stuff was a part of [13:16:59] right [13:17:16] but there are a lot of CSM Maneuver PADs in the MCC, so, that always means a lot of changes [13:17:59] hey [13:19:17] hey Matt [13:19:47] yeah I expect there will be a lot of changes like that, I will just update my branch as they come [13:19:50] hey Matt [14:00:01] n7275, so as far as I can see, the changes you did were [14:00:23] remove check if voltage has converged and instead always do 10 iterations [14:00:48] upper limit for voltage because the coefficients for the polynomial can result in an unrealistically high voltage with high temperature [14:01:01] and gitignore any MATLAB files :D [14:04:17] yes [14:07:22] and why did the temperature get so high again? [14:08:48] current draw creates temperature, which increases voltage, which increases current draw. [14:09:00] this results in runaway power output [14:09:15] in reality this would be limited by reactant input [14:09:19] right [14:09:37] isn't reactant input limited? [14:09:44] I thought you added tanks and such for it [14:10:04] several times in test branches :) [14:10:28] it's in the works with my yet-to-be merged stuff [14:10:44] oh [14:10:53] I was sure this was one of the things that did get merged at some point :D [14:11:48] merged [14:31:05] yeah, my earlier attempts required all of the systems updates I've been working on [14:50:47] hopefully I can work on this ASA heat thing a bit tonight and tomorrow and we can get that merged too [15:35:01] morning! [15:36:48] hey Mike [15:36:59] your knowledge was summoned :D [15:37:06] uh oh [15:37:09] what was the change from Luminary 177 to 178? [15:38:18] hmmm, not entirely sure [15:40:20] it could have been one of a few things [15:40:48] right, I saw that memo [15:40:56] so we don't 100% know then [15:42:03] unfortunately no [15:42:52] I can audit the Luminary 177 P99 and make sure no addresses changed [15:47:30] Ryan is testing it right now [15:47:31] seems to work [15:53:04] yeah I don't see any address changes [15:54:05] https://www.ibiblio.org/apollo/Documents/LUM199-DM_text.pdf [15:54:55] this memo states that it was written for 178 -- which is wrong, but I think implies they didn't change P99 at all until Luminary 209 [15:55:40] hmm right [15:56:03] and there are clear problems with the EMP for 1E when using it in 1D? [15:56:14] ah yes [15:56:21] that memo says so :D [15:56:59] I'll add support for more EMPs on the pile of projects... [15:57:04] hehehe [15:10:37] hey [16:47:36] hey Niklas [16:49:56] hello hello [17:03:40] morning! [17:03:59] hey Mike [17:46:02] I was back in my TLI branch for a bit [17:46:48] you know what helps getting into the right orbit? Actually copying the longitude of the ascending node from the uplink to targeting [17:55:19] yes that sounds quite helpful :D [17:55:44] it still had the one from orbital insertion [17:56:05] which sounds fine, but there is a lot of non-spherical gravity pushing you out of plane :D [18:15:40] feels disturbance in the force, measuring a few hundred mGal [18:23:45] so that it is pushing me 1 centimeter out of plane further? [18:23:48] :D [18:40:02] something like that :) [18:41:28] I have a dumb RR antenna pattern question [18:41:39] what should be the angle from peak to peak? [18:57:05] looks like about 6 degrees? [18:57:46] maybe 5 [18:59:54] ok, close enough :D [19:00:40] we might have it exact, but what I was seeing in figures wasn't really agreeing with numbers I was reading [19:00:52] but I don't think we have that really wrong [20:10:19] n7275, I put all of the RR/Transponder code in a MATLAB script to check how it works [20:10:31] gets quite complicated with the CSM and LM interaction :D [20:11:51] oh yeah [20:12:09] pretty easy to run out of dimensions in which to visualize things [20:12:28] yeah [20:12:35] I just stuck with ideal CSM pointing [20:13:01] there is one thing I am slightly confused by [20:13:07] "//calibration for gauge" [20:13:11] const double HighSignal = 1.0; //3.28V [20:13:37] but for the gauge, should this become 1.0, it gets multiplied by 4.0 [20:14:04] so the gauge will show 4V, in the perfect case [20:14:35] I have no idea. it's been a while. I can look at the code [20:15:19] 3.28V seems like a reasonable maximum value [20:15:29] it's even slightly less than that in the graphs I am finding [20:20:41] I don't particular like the peak voltage vs. range [20:21:27] too high at small range, too low at high range [20:21:40] especially off in the 100 NM region I would say [20:21:44] about 0.5V [20:22:04] off enough that with our side lobe behavior you couldn't trust the cue card [20:23:08] the range calculations look quite sophisticated, so I can't easily if and what is wrong [20:23:16] easily say* [20:23:59] yeah, I can go through that again. [20:24:07] or at least help with it [20:28:31] would be nice to have the LM simulator equations for RR signal strength [20:44:07] night! [14:55:28] hey Niklas [14:59:57] hey [15:05:19] I think I've fixed the LM heat issue that Ryan had. needs more testing though [15:05:24] oh nice [15:07:21] either that or I've found some great confirmation bias [15:30:25] fairly easy to find haha [16:12:33] morning! [16:13:54] hey [16:14:10] got all the parts of the AS-202 video recorded [16:14:57] it's going to be longer than I thought [16:15:12] I basically want to capture everything interesting that happens on the DSKY [16:15:13] nice! [16:15:21] so I am cutting out e.g. a large part of the ascent [16:15:34] but from SPS2 through opening of the chutes there isn't much downtime [16:15:43] awesome :D [16:15:48] so that part of it is 20 minutes already I don't want to shorten :D [16:18:19] I hadn't realized that 202 was such an action-packed mission [16:20:09] Corona had some surprises for me last night [16:20:19] I disassembled all of orbital integration [16:20:59] it's just, SPS-2, then the short SPS-3 and 4 directly after it [16:21:06] and that all happens not long before reentry [16:21:17] so SPS-4 cutoff to the attitude maneuver for CM/SM sep is like 1-2 minutes [16:21:32] gotcha gotcha [16:21:53] so, this drag code is not present in Corona: https://github.com/virtualagc/virtualagc/blob/master/Solarium055/ORBITAL_INTEGRATION_PROGRAM.agc#L703 [16:22:13] ....but this code and vectors that we couldn't figure out in Sunrise still is: https://github.com/virtualagc/virtualagc/blob/master/Sunrise45/ORBITAL_INTEGRATION_PROGRAM.agc#L1230 [16:25:54] I don't know why they bother having drag code in Solarium [16:26:01] hahaha [16:26:10] S-IVB venting was 10x stronger [16:26:29] but maybe it was more the code they had developed for Earth orbit missions [16:28:00] unless Solarium has some venting code I haven't seen :D [16:28:13] but Apollo 4 and 6 certainly needed state vector uplinks to work right [16:28:21] AS-202 can get by without it [16:29:50] it would have made my life easier if they hadn't touched it lol [16:30:06] haha [16:30:16] despite that list of changes memo by Jay Sampson, I continue to be surprised by how many differences like this there are that just are not mentioned [16:31:18] Corona's more different from Solarium than I thought, which is both good and bad haha [16:31:33] good because yay more interesting AGC code, bad because oh man does it make reconstructing the source harder [16:34:51] yeah, kind of the same from a padload standpoint [16:35:11] even more addresses in fixed memory that you have to preload in erasable memory! [16:41:00] oh there was something I wanted to ask about [16:41:29] ABSOLUTE_ADDRESSES_FOR_UPDATE_PROGRAM [16:41:40] is that something that only exists in the listing? [16:41:44] or somehow also in code [16:41:47] that sounds like something much later than Corona :D [16:41:49] in the software itself I mean [16:41:50] only in the listing [16:43:53] RTCC has system parameters for uplink addresses because they are quite mission specific [16:44:18] I thought that maybe, just maybe, there was some way to access a fixed address in the AGC to get them, but I didn't have much hope haha [16:44:43] nope [16:45:05] they had to add a new assembler operator (=ECADR) to spit out an erasable memory address without actually generating code [16:45:23] https://www.ibiblio.org/apollo/Documents/COL-258.pdf [16:45:26] item 5 [16:45:35] apparently the original implementation did used fixed memory [16:47:09] why do I have the feeling that ACB 100 was a MSC request [16:50:58] haha at least for the Luminary equivalent (ACB L-21) the originator was Margaret [16:51:26] but there could definitely have been some external pressure on her for it :P [20:59:14] night! [14:57:53] hey [15:00:48] hey Niklas [15:03:10] finishing the AS-202 video [15:03:21] might even get released today! [15:04:06] that's one project finished... well, Mike still might ask me to name some unknown variables in Corona [15:18:48] morning! [15:18:53] might? definitely! :D [15:20:46] haha [15:21:11] nice AOH! [15:21:27] so many pages and megabytes [15:21:42] hahaha I tried to compress it a bit [15:22:06] the only settings I could find that meaningfully reduced file size also caused horrible artifacts [15:22:09] right [15:22:16] it's not bad for 1000 pages [15:22:20] and the only compression level that didn't do that only saved 2 megabytes, which felt not worth it :P [15:23:23] uhh yeah, that's not a relevant difference [15:24:08] it's now the second largest file in my AOH folder [15:24:27] the largest one is the CSM Data Book Revision 2 [15:25:00] 800 pages. Somehow revision 3 has 1500 pages, doesn't look any worse and is only 59 MB [15:25:14] both come from UHCL, they must have played around with their settings in between [15:26:15] oh wow [15:26:21] I need to learn their secrets haha [15:28:18] so last night I was browsing through the AS-202 GSOP [15:28:41] https://www.ibiblio.org/apollo/Documents/R477-AS202-GSOP-Rev2.pdf#page=126 [15:28:44] pdf page 126 [15:28:49] have you seen that? [15:31:53] uhh, which part of it? [15:32:15] but yes, I adjusted some padloads based on this page [15:34:19] the pitch polynomial stuff [15:34:24] okay just making sure. I didn't realize it had padload type numbers in it [15:34:47] oh a lot of them actually [15:34:55] Atlantic and Pacific splashdown targets etc. [15:35:34] has E for erasable and F for fixed memory :D [15:35:58] based on that I noticed that SPS1 to attitude hold time was not TCOAST but was actually fixed memory [15:36:16] and then adjusted TCOAST to be until SPS2 ignition [15:36:36] PDF page 128 [15:36:39] find the one E :D [15:36:58] oh hahaha [15:37:00] amazing [15:39:12] AS-202 video is now rendering [15:39:17] 35 minutes [15:39:27] that's all the boring parts cut out [15:39:50] didn't know what to cut out from reentry, that's the longest part [15:40:08] it switches through all the programs so quickly [15:40:14] ooo that's a nice meaty video :D [15:40:22] so SPS2 through chutes is all one block without cut [15:41:14] Apollo 4 had an extra TLI and that has a two parter [15:41:24] other than that AS-202 does most of the same things [16:44:05] tonight's project (if I have time outside of document scanning) is going to be starting to disassemble the reentry code [16:44:43] despite Solarium having a "new" reentry package I'm hopeful that a lot will still be the same, based on initial pokings through the code [16:45:16] the TFF package I'm more afraid of, I think that might be completely changed [16:46:24] yeah sounds like they needed to do some changes for high eccentricity [16:48:16] also I'm mad about the orbital integration section of the 202 GSOP [16:48:37] so many great flowcharts for reentry and the mission control program [16:48:49] and orbital integration just says "See The Compleat Sunrise for a description" [16:48:51] damnit lol [16:48:57] uhh [16:49:10] which doesn't have much of flowcharts [16:49:19] only the same descriptions as a GSOP [16:49:21] yuuup [16:49:26] how many rope modules was Corona on again? [16:49:30] 6 [16:49:37] full set? [16:49:47] yep, all banks are filled [16:49:59] and that were the flown modules or spare? [16:50:08] actually flown modules as far as I can tell [16:50:28] right, you had a few modules there and I couldn't remember if these were flown ones [16:50:33] just some notes for the video [16:50:38] video description [16:51:19] https://archive.org/details/aperturecardbox432naraswimages/page/n1001/mode/1up?view=theater [16:51:23] item 3.3.5 [16:51:54] the yellow "Flight 202" markings on the modules line up very well with that description [16:52:03] I really like their wording "having been subjected to flight" [16:52:25] haha [16:52:49] that's on the other end of the spectrum as "flight proven" [16:54:56] hehehe yeah [16:55:16] that's like, the ultimate passive-voice translation of "flown" [16:55:46] the G forces on AS-202 can't have been too bad [16:55:57] not during the reentry anyway [16:56:18] after the mini skip it would have flown lift vector up all the time, still falling a few hundred miles short of the target :D [16:57:32] 2.4G maxed [16:57:34] max* [16:57:42] compared to 3.9G predicted [16:58:48] well that would be the worst part of being "subjected to flight" were always going to be the launch then [16:58:55] would mean* [17:00:03] video uploading. It chose the CSM pointing straight down as the thumbnail [17:00:12] hahaha perfect [17:00:14] makes sense, that's what the CSM does for most of the flight [17:00:24] ... even if the video barely shows that :D [17:00:30] somehow it knew [17:01:40] it's not a cold soak [17:01:47] not sure how you named that changed code [17:01:55] but it was probably for communications [17:02:19] half the flight was in darkness anyway and it was short [17:02:38] the thermal issues the cold soak attitude tried to avoid would only have happened on the hours of sunlight on 4 and 6 [17:04:02] the GSOP has the names [17:04:46] "vertical erection" was the phase name [17:05:09] ah ok [17:05:22] I thought that was the name for the alignment on the launchpad, but, ok :D [17:05:43] it is also that [17:05:45] very confusing :D [17:06:02] the names in code are VERTASK, VERTIJOB, etc. [17:06:15] ... [17:06:36] having flown the mission again, there are two things I didn't like [17:06:48] landing a few miles long [17:06:53] probably state vector off [17:07:03] could also be a guidance thing [17:07:22] and for reentry I noticed, the attitude it is holding to await the atmosphere is a bit off [17:07:29] trim attitude [17:07:43] not sure if our aerodynamics are off or what [17:07:52] I think I slightly changed it for Block I [17:08:00] but maybe AS-202 was different, not sure [17:08:04] hmm. if it were a problem with the dump, do you know where in the code I would look? [17:08:15] oh I doubt it's a problem with the dump [17:08:23] have to search in Solarium [17:08:36] it has to fire the RCS a lot in pitch before 0.05g, when pitch and yaw are switched off [17:08:56] meaning the aerodynamics want a different trim attitude than the AGC was predicting [17:10:52] with the longitude error it could also be some timing thing [17:11:03] need to check what it has for liftoff time [17:11:13] but that would have to be off by like a minute, sounds unlikely [17:14:02] hnmmm okay [17:14:43] I wonder if I have something wrong with entry mode in general [17:14:54] I thought there was something different about IMU and CDU and stuff [17:16:42] I think the relevant part hasn't changed to Solarium [17:16:44] COS(13) [17:17:01] IMU is at a 33° angle, so this assumes 20° trim AOA... I think [17:19:00] but maybe it's not as big a difference as I was thinking [17:19:04] have to check in the video again :D [17:19:17] just plenty of pitch RCS firing just before 0.05g [17:21:06] hmm, aerodynamics aren't any different than what we had for Block II at the time [17:21:12] thought I made a change [17:21:39] ooh I see, I made a change in a different place [17:21:57] I think I gave it more lift [17:22:01] maybe too much now [17:29:04] ok in the video it looks like it wasn't much off at all in pitch [17:29:11] why so much RCS then :D [17:40:57] if you've got it, might as well us it up haha [17:41:02] *use [17:44:31] yeah might just be a mixture of not having quite the right trim AOA and a small deadband [17:45:06] didn't notice it with 4 and 6 because it happens within a few seconds [17:45:15] first traces of atmosphere to 0.05g [19:13:01] https://www.youtube.com/watch?v=N0NdPFl1yE4 [19:15:45] woooo! [19:15:50] excited to watch it :D [19:16:10] glad to hear it haha [19:35:11] thewonderidiot, I wanted to post my AS-202 video on the Virtual AGC mailing list. But the recovery of Corona 261 has not even been announced there :D [19:35:37] ... I think I already spilled the beans on the Discord about it [19:35:49] before you properly announced it [19:36:29] hahaha go ahead! I'm fine with you announcing it :D [19:37:07] ok, I'll include that then [19:47:33] oh man SPS-3 and SPS-4 are exciting [19:48:47] SPS2 off, on, off, on, off [20:54:22] night! [16:24:57] hey [16:58:46] morning! [17:05:47] hey guys [17:38:30] indy91, you should update this thread https://www.orbiter-forum.com/threads/implementing-as-202.40913/ [17:39:02] I will! [17:41:21] I think I remember why I didn't try to at least make a Block I DSKY for my branch [17:41:30] the dimensions aren't even the same as Block II [17:41:52] no, Block I DSKYs are huge [17:41:59] I was very surprised the first time I saw one in person [17:42:35] got to have some space for all those relays [17:42:38] so many! [17:42:45] hahaha yeah [17:42:53] and it's not even hermetically sealed! [17:45:06] they really gave up early on making Block I a good spacecraft :P [17:45:13] lol [16:20:30] hey [16:22:23] hey Niklas [16:23:33] I log on and the number of PRs goes up and down and up and down :D [16:24:35] I think you, me, and Ryan were all editing something all at the same time [16:25:09] well I only merged one so far haha [16:26:34] I figured the number hit some threshold, and some alarms started going off, "what are they up to?!" :) [16:33:23] they are up to small and easy to review PRs [16:33:27] I like it :D [19:02:39] I may be able to help Ryan with some cherry-picking tonight [20:50:46] great! I think he has gotten himself into a bit of a mess [20:51:07] should have merged the MCC stuff only a few weeks ago, like I suggested... [20:57:24] :) [21:04:19] :| [21:34:14] more accurate [21:38:38] night! [16:39:21] morning! [16:39:39] hey Mike [16:39:52] what's up? [16:41:02] a new scan from you. But haven't had the chance to check it yet [16:41:18] weather is way too nice to spend inside, just got home [16:41:26] hahaha totally fair [16:41:41] I should go outside today. Corona has been keeping me inside [16:41:52] ....which could be set about the past few years. only this time it's a different Corona :D [16:41:59] a good Corona [16:42:26] well, it has fixed memory addresses you need to load in erasable memory so that some other fixed memory can TC to it [16:42:30] but otherwise good :D [16:42:36] hahaha [16:45:20] looks a lot like the Apollo training courses for astronauts [16:49:54] ... at the start [16:50:00] then it goes into a bit more detail :D [16:50:10] hahaha yeah. quite a bit more detail than the astronauts would care about :P [16:50:48] the SCS training module goes also quite far [16:50:55] manual* [16:51:11] more than I would have expected [16:51:30] but not quite "individual logic gates" [16:58:27] We're having our first week of warm weather here in Maine. I'm really trying to finish up my priojects before I wander outside and don't come back in until September [17:05:51] that's a long bit of wandering [12:32:34] hey [12:33:03] hey Alex [13:04:35] already checked out the new RTCC TLI targeting? [13:04:40] Only can target apogee for now [13:10:56] right, would that be for a 7-parameters update? [13:11:09] yep [13:12:24] "Only can target apogee" does that mean in cant do TLI yet? [13:13:49] not the L in TLI, no :D [13:13:58] only the option for the E-type mission [13:14:03] input an apogee [13:14:09] and it will do a "TLI" to achieve that apogee [13:14:20] ah ok [13:16:00] next I would add a similarly simple option [13:16:02] input DV [13:16:26] then the TLI processor could also show parameters a nominal TLI [13:16:37] without having to put the TLI maneuver on the MPT yet [13:16:47] kind of like a TLI PAD I guess [13:17:04] and lastly there is the option that actually targets the Moon [13:19:30] in this RTCC TLI processor they only have a free-return option though [13:19:37] as of Apollo 12 [13:19:44] didn't see an updated document [13:26:38] right [13:27:07] so you would have to fly a hybrid profile to reach a custom landing site [13:31:16] I might add more modes than are in this document [13:31:18] but still [13:31:33] there is going to be some amount of external data generation necessary for custom landing sites [13:31:51] to calculate some constraints for pericynthion [13:41:11] makes sense [13:42:40] hey guys [13:42:56] hey Matt [13:43:46] hey [13:49:25] indy91, whats the "perigee adjust" section for? [13:51:15] it's a tool to calculate a maneuver that gets you a safe perigee [13:51:23] it's mainly for a Mode IV abort [13:51:34] usually you get into some sort of orbit with Mode IV [13:51:50] but there are some techniques that only get you a safe apogee [13:52:02] right [13:52:32] so nothing very special or commonly used [13:52:38] but it was very well documented [13:52:43] so easy to implement [13:59:52] to fill out this? https://www.dropbox.com/s/k8fa67opt87ejqb/Screenshot%202023-05-14%2009.58.59.png?dl=0 [14:20:22] yeah, it can be used for that I guess [14:20:26] hmm [14:20:30] no actually :D [14:20:33] that's a different thing [14:20:40] an automatic display active during launch [14:20:54] which we have the specifications for actually [14:21:00] just not implemented yet [14:21:46] FDO Launch Digitals [14:24:27] ah [14:32:26] it's something I have been struggling with how to implement [14:32:36] these displays are only run in certain mission phases [14:32:40] and have automatic processing [14:32:58] so I would kind of have to implement these RTCC mission phases [14:33:22] adds more things you have to do in the RTCC MFD [14:35:00] this abort DV from the PAD you posted would be calculated if/when the FIDO puts a switch on his console to the Abort position [15:23:29] ah interesting [15:23:43] coming up on LM deorbit burn [15:33:50] hmm RTCC MFD has 4 sets of P99 erasables [15:34:03] but the checklist only says 3 [15:34:41] yeah there are a few versions of it [15:34:53] not sure if only the uplink was different or the content as well [15:35:02] would have to check [15:35:22] I think I put the GSOP section 7 version in the RTCC MFD [15:35:27] I did all 4 and it doesnt work [15:35:56] this is Apollo 17, right? [15:36:01] yes [15:36:13] it should really work, it hasn't been changed in forever [15:36:18] it doesn't work on Apollo 14 [15:36:23] Luminary 178 [15:36:28] but it works in 210 [15:36:40] right [15:37:01] what exactly didn't work about it? [15:37:07] restart when calling P99? [15:37:48] well I hard-coded an uplink with the MCC, using the same 4 blocks of erasables in RTCC MFD [15:37:52] nothing happens [15:38:30] it just stays in P00 when going through TIG [15:38:52] let me try uplinking it with the RTCC MFD [15:39:33] but something has to call P99 [15:39:47] oh [15:39:57] ok then that was done by MCC? [15:41:01] for some reason I thought it would auto-execute itself but of course it can't :D [15:41:23] yes [15:41:56] https://www.ibiblio.org/apollo/Documents/R-567-GSOP-Luminary1E-Section7-ErasableMemoryPrograms.pdf [15:42:13] starting on PDF page 12 [15:42:17] has procedures [15:42:24] and says what the crew does and what the ground does [15:43:26] ah great thanks [15:45:06] the EMP is less for doing things automatically but more for allowing a guided RCS burn [16:03:15] morning! [16:30:15] hey Mike [16:32:27] the word counts in the MIT progress reports are very useful [16:32:51] bank 13 in Corona has 159 words that I couldn't identify that are not in Solarium [16:33:07] and the progress reports say the MIDCOURSE INITIALIZATION section is 159 words long [16:33:13] ...I think I know what is in bank 13 now :D [16:33:17] haha [16:33:47] probably a proto P23 [16:33:50] it appears to have a hardcoded W-matrix just like Sunrise [16:33:55] but also a hardcoded REFSMMAT [16:34:11] yeah! a very early P23 [16:34:23] I don't think it will let us start it with V37 [16:34:32] but I want to try it once I figure out how to run it :) [16:35:00] yeah that would be fun [16:36:20] as much fun as P23 ever can be [16:38:16] hey it's called "midcourse navigationg game" in Corona [16:38:20] it must be fun! [16:38:27] *navigation [16:44:44] it probably doesn't actually require you to do anything with the sexant [16:44:47] so yes [16:44:48] fun! [16:46:56] the trick works again! bank 23 has 168 unknown words at the end [16:47:07] and MEASUREMENT INCORPORATION is 168 words long [16:49:06] what could it be??? [16:50:03] banks 24 and 31 will be a bit harder to divide haha [16:50:11] but I'm pretty sure midcourse navigation game is in 24 [20:46:29] night! [13:57:11] hey [14:01:02] hey Matt [14:33:14] hey [14:37:16] hey Niklas [15:53:23] fly an E-type mission today with the new RTCC TLI targeting :D [15:53:52] flying* [16:37:28] nice [16:39:56] just did the TLI [16:40:00] two things I haven't considered [16:40:17] it probably won't go to a TD&E attitude [16:40:29] this is with an on orbit Apollo 9 scenario [16:40:34] also [16:40:38] sun is setting [16:40:52] not sure the altitude is rising fast enough to stay in sunlight the whole time :D [16:41:14] the spot light works, but still, TD&E in darkness is not ideal [16:49:21] morning! [16:50:30] hey Mike [16:50:53] I think the sun is winning the race [16:52:09] uhh [16:52:14] I think my morning brain might not be working yet :D [16:52:28] haha [16:52:40] I'm flying an E-type mission [16:52:42] just did the "TLI" [16:52:44] 100 x 4000 orbit [16:52:53] using an Apollo 9 scenario [16:52:56] the problem is [16:53:04] TD&E is just around the corner and the sun is setting [16:53:11] didn't consider that [16:53:14] but altitude is rising fast [16:53:22] might not even get a sunset at this point [16:53:30] oh interesing! [16:54:12] yeah that sounds like something you'd want light for haha [16:57:01] yeah, no sunset [16:57:29] the example launch date has a launch 3 hours later than Apollo 9 [16:57:40] that would probably result in better lighting [16:57:48] launch time* [17:11:05] https://i.imgur.com/jZA4nZJ.png [18:11:54] nice :D [18:13:18] I'm changing my Corona plan of attack for a bit. the P23 stuff seems completely walled off (outside of a few references from the restarts section) so I think I'm going to focus on finishing up the rest of the rope as much as I can [18:14:04] so, moving into the phase where I discover constants that I thought were unused are actually referenced by some other log section, or fix code flow that I got wrong [18:14:12] and most importantly, name things :D [18:14:19] so I will probably have questions for you soon haha [18:15:57] sure [18:20:32] oh I almost forgot I still need to disassemble time of free-fall [18:20:48] I was terrified of it because it looked enormous and completely different from Solarium [18:21:17] ....and it is completely different, but I feel much better knowing that the vast majority of it is P23 haha. the GSOP makes it sound small and simple [18:23:34] yeah TFF is pretty complicated, but shouldn't be that much code [18:28:06] oh weird, going off the status reports it looks like it doesn't even have its own log section [18:29:06] I'm actually not sure where it goes then [18:33:44] wait, did I already accidentally disassemble it? lol [18:34:11] lol how does that work [18:34:36] wow, I did [18:34:55] first maneuver calculation on Mission E, immediately ran into a bug I introduced recently [18:35:26] lol nice [18:35:35] so you already disassembled TFF and what you thought was TFF is all P23? [18:36:32] yep [18:36:49] the TFF calculations are just a small chunk of code in RTB OP CODES [18:37:05] there really is no log section for it [18:37:32] I disassembled that little chunk while working on the mission control program, couldn't identify it, and assumed it was just some weird logic [18:39:10] er, not RTB OP CODES [18:39:18] it's in POWERED FLIGHT SUBROUTINES [18:39:37] makes more sense haha [18:39:41] here it is: https://github.com/thewonderidiot/virtualagc/blob/Corona261/Corona261/POWERED_FLIGHT_SUBROUTINES.agc#L422 [18:39:50] yeah I can see the difference between 202 and 501 in the GSOPs [18:39:53] UNK6146 must be CALCTFF :) [18:44:29] in retrospect all of the "STORE TFF"s should probably have clued me in to that [18:51:04] UNK6503 must be two different Earth radii as TFF reference [18:51:37] oh, I was wondering what those were :D [18:52:23] just trying to understand all this code [18:52:32] same scale as RMAG [18:53:37] haven't quite understood yet on what basis it uses which value [18:53:50] must be the block of code before it gets used? [18:53:52] the TS X1 [18:53:53] I think that's the logic looking at FLAGWRD2 [18:53:54] yeah [18:54:28] oh it just looks at the flagword, ok [18:54:47] UNK6507 being the mask for it? [18:54:49] yep [18:54:57] if any of those four bits are set, it uses one, otherwise it uses the other [18:55:58] not quite sure which those flags are yet [18:56:22] looking at Solarium, it's basically the same [18:56:34] I think UNK6503 is R280K [18:56:42] well [18:56:45] and R400K [18:57:08] ooo, yeah you're right [18:57:39] UNK6507 is NOMBURN [18:58:05] yep, exact same values, too [18:58:13] or maybe rescaled by 2 [18:58:14] awesome :D [18:58:19] but I see the same values [18:59:21] yeah I think it's rescaled and not exactly the same values [18:59:28] well this is dramatically easier than I feared lol [18:59:30] just different by the factor of 2 [18:59:45] like a lot of things between Corona and Solarium I guess [19:00:06] yeah [19:00:25] it's a weird mix of much harder than expected, and much easier than expected [19:01:44] UNK6467 will be the logic for r < r_e [19:01:47] as mentioned in the GSOP [19:02:08] or no [19:02:11] the other way around [19:02:13] UNK6475 is that [19:02:21] right [19:03:04] uhh [19:03:13] well it's two off nominal cases it mentions there [19:03:26] in one case TFF becomes 0 in the other case MAX [19:03:39] I guess NEARONE is the maximum value [19:03:47] it is indeed [19:04:35] so yeah, the first STORE TFF will be normal case then [19:04:44] and then there are two jumps to the off nominal cases [21:00:12] night! [12:31:24] hey Alex [12:50:56] hey [12:51:09] whats up? [13:15:55] on my end I am just about to re-enter with Apollo 17 [13:16:08] my Apollo 17 MCC branch is finished :D [14:09:16] not too much [14:09:30] wishing I had more time in the week to work on stuff [14:59:08] I think I have time to take another swing at LM temps tonight though. [15:41:35] hey [15:43:41] someone on GitHub may have found a small off-by-one error in my harmonic gravity project [15:44:38] oh no! [15:44:47] off by one could mean many things though haha [15:45:26] I'm hoping that's where my drift with respect to GMAT is coming from [15:47:07] that would be nice [15:49:04] I think I just overcorrected for Matlab arrays starting at 1 [15:49:35] yeah that's never fun. I often prototype things in MATLAB [15:49:45] and then I need to convert it to start at 0... [15:50:00] same with any actual RTCC flowcharts. Start at 1 [15:50:24] and they are quite often using some non-standard loops [15:50:35] always a bit of brain power required to not screw it up [15:54:32] hey Niklas [15:56:17] hey hey [16:02:11] so I guess Apollo 17 uses the horizon check attitude for the sextant star check [16:05:42] up to at least Apollo 13 it says to be in entry attitude for the star check, and it looks like by 15 they changed the procedure. I don't know what 14 did as I don't have the entry checklist for it [16:06:36] in any even for now our entry PAD calculation only seems to support the former [16:08:07] right, I remember this topic. Came up before haha [16:09:11] I probably mention it every time I fly a J mission, then completely forgot about it lol [16:12:32] for that I first have to properly calculate the horizon check attitude [16:12:42] and not just badly calculate the pitch angle [16:34:57] AlexB_88, based on the flight plan I would say 14 uses the old technique [16:35:07] right [16:35:36] oh you know what [16:35:55] the sextant star check calculation takes RPY as inputs anyway [16:36:09] so I will just give zero roll and yaw to it [16:36:22] and the pitch attitude calculated for the PAD anyway [16:36:35] is anything else different? [16:36:42] The timing of the horizon check is still the same? [16:36:51] 2 minutes before CM/SM sep? [16:37:13] yeah [16:37:28] then I think this isn't so complicated after all [16:37:33] I'll add it [16:37:57] ok great [16:38:32] I guess it just feeding the desired pitch into the checkstar function? [16:38:42] yep [16:38:50] I'll add a flag to LunarEntryPADOpt [16:38:59] makes sense [16:39:02] defaults to the old technique [16:39:16] and in the MFD there will be a button to choose the option [16:44:55] morning! [16:46:20] hey Mike [16:47:01] https://github.com/virtualagc/virtualagc/commit/5c0f3f2aed5791c102124dea077bbd292064d472 [16:47:16] I was expecting a bit more when I read that a new instruction got supported :D [16:53:45] hahaha [16:53:54] yeah, easy change that scared me for a second [16:54:24] that is matrix-vector multiplication but with conditional address? [16:54:46] I guess yaYUL already supported it, it just couldn't convert it to the opcode [16:57:23] or maybe converting it to an opcode is that yaYUL has to do here :D [16:57:27] is all* [17:09:54] yeah, that's all yaYUL had to do [17:09:59] VXM* = 45 [17:10:35] otherwise it just rose an error for an unrecognized opcode [17:10:46] I was thinking too complicated [17:10:54] the interpreter is the thing implementing the actual matrix-vector multiplication haha [17:11:05] yeah haha [17:11:23] and only Corona is ever using it? [17:11:27] For Block I at least [17:11:41] yep! neither Sunrise nor Solarium use it [17:12:11] perhaps unsurprisingly, the code is not too different from the Block II MEASUREMENT INCORPORATION log section https://github.com/virtualagc/virtualagc/blob/master/Colossus237/MEASUREMENT_INCORPORATION.agc#L149 [17:12:20] good chance that Sunspot is using it! [17:12:37] I'd say it's guaranteed that Sunspot uses it haha [17:13:00] ah W-Matrix fun [17:15:37] AlexB_88, you have two RTCC related PRs to check :D [17:15:59] im on it [17:17:03] one thing I realized when reading about midcourse navigation last night [17:17:51] ....Corona's going to have to have a star table right? surely it is quite early compared to other star tables we have [17:18:36] indy91, both approved [17:18:47] I had already looked at the 1st one a few minutes ago [17:19:07] great [17:19:23] thewonderidiot, unless it just has one or two stars hardcoded for this testing code [17:20:56] but yes, some sort of star data is required [17:21:09] there isn't a technique without stars :D [17:22:00] thewonderidiot, just saw the link for that CSM 113/114 AOH...many thanks from me! From my hard drive, not so much :D [17:22:18] my words exactly :D [17:22:35] hehe [17:22:41] hahaha sorry. I've taken up a policy of 300 DPI full color for scans, with only as much compression as doesn't cause visible artifacts [17:22:54] I figure a PDF can always be made black-and-white or further compressed, but you can never do the reverse [17:22:57] that one 500 MB CSM Data Book is still looking down at it though [17:23:49] I'm going to try to scan the early (first revision) of the CSM AOH Vol I tonight -- from 1967ish [17:23:53] I did a really dumb scan a few weeks ago [17:24:00] yeah its definetly worth it for the better quality [17:24:04] photo of my great-great-grandma [17:24:13] my grandma wanted to have a copy of it, on photo paper [17:24:29] I did a high quality scan of it, 70MB, saved it as PDF (for some reason) [17:24:35] hahaha [17:24:38] habit :D [17:24:47] printer application for photos can't handle PDF [17:24:53] had to convert it back to jpg [17:25:08] didn't really find a good method and in every case I got a 200 KB JPG [17:25:13] that is what I ended up printing... [17:25:18] still looked fine though! [17:25:24] original was already a copy anyway [17:25:30] didn't make the quality much worse... [17:25:31] hehehe [17:25:40] and the photo was taken around 1900 so... [17:25:58] but I shouldn't have saved it as PDF initially [17:26:06] maybe counterintuitively, GIMP actually does a really good job with PDFs [17:26:19] it opens every page as a different layer, so you only want a few pages max [17:26:32] but it asks you to specify the DPI you want when you open it [17:26:57] it used to be part of my foldout scan processing pipeline, back before I got the fancy scanner that can scan foldouts directly [17:33:09] indy91, for TEI I forced a 66.5 D return [17:33:22] to get better splashdown latitude? [17:34:29] the SCOT says 66.5 D was targeted for TEI [17:34:48] if I read that correctly [17:36:57] but at first I did try leaving it optimized and I think it was a ~54, which gave a lower total DV (more optimized) [17:37:07] hmm right [17:37:15] but doesn't hit the end of mission target [17:37:56] but it seems to me they wanted 66.5D since the FP/SCOT gave about ~50 FT/s more total DV then the optimized TEI solution I had [17:38:57] I used the EOM [17:39:59] right [17:40:12] but they would have used the preferred targeting point mode [17:40:18] targeting both latitude and longitude [17:40:32] which our RTCC can't yet [17:40:35] right [17:40:41] maybe the EOM coordinates were more desirable [17:40:46] didn't matter if it was more DV [17:40:57] I did a lot of work on the moon-centered RTE [17:41:00] have it in a branch [17:41:04] nearly ready [17:41:07] but didn't like some things [17:41:17] so might not get merged... [17:41:35] as it turns out the "real thing" is quite bad code by modern standard :D [17:41:42] haha [17:46:29] I will not delete that branch though [17:46:43] there are still some small fixes and improvements that can be worked into our current RTE [17:47:15] and maybe even a makeshift PTP mode that I develop myself [17:47:19] the real thing is such a pain... [17:47:49] it was an afterthought so many low level functions had to have code added to them to make the mode work [17:47:54] I imagine the range of targetable latitudes must be quite narrow? [17:48:03] yeah it is [17:48:16] it depends quite strongly on the entry range [17:49:05] a long skip reentry gives a much bigger range [17:49:11] range of latitudes [17:51:30] right [17:56:54] btw I was thinking we could make a pinned thread in the Orbiter Forums called "Experimental NASSP Branches" or something [17:57:25] and we could add to it a link to Apollo 17 MCC, Block 1, etc [17:57:59] with a disclaimer "use at own risk" [17:58:32] but it could be a way so people can easily find them [18:04:58] hmm yeah maybe [18:05:20] only for people who already use git, because we have no auto builds for other branches [18:07:54] right [18:13:45] just tested the star check update, works great [18:14:01] thanks again [18:18:43] no problem [18:18:52] I thought it would be more complicated [18:18:58] that's what I hadn't tackled this yet :D [18:23:16] whyÜ [18:23:19] why* [18:30:27] I think ill refresh the Apollo 17 re-entry scenario [18:34:46] PR sent [18:54:53] merged [20:45:43] night! [12:32:12] hey [13:01:18] good morning [15:14:25] hey [15:27:55] hey Nik [15:28:43] I learned a valuable lesson about leaving pull requests open that you're not ready to merge. [15:29:04] Xyon merged my gravity update. :) [15:30:31] uh oh [15:30:38] the one with the bug [15:32:27] yup [15:33:48] not too disastrous, I mean, lunar gravity is still way less wrong than it used to be, but for me fixing that is no longer optional or at my convenience [15:39:21] a feeling very familiar to me [15:39:27] every time someone discovers a MCC bug... [16:07:32] morning! [16:11:27] hey [16:13:11] hey Mike [16:19:28] I'm having dangerous thoughts [16:19:35] messing with RTCC coordinate systems [16:19:45] a good way to break everything :D [16:31:03] I have to do it at some point though [16:31:09] it's just staring me in the face too often [16:34:20] would it break old scenerios? [16:34:44] almost no [16:35:00] the MCC has the ability to store a state vector [16:35:04] for various purposes [16:35:10] it uses it a few times, but not many [16:35:21] RTCC MFD stores vector panel summary vectors [16:35:29] MPT stores anchor vectors [16:35:33] that's about it [16:37:52] it's just, there is a lot of RTCC code where the coordinate system is relevant [16:37:56] and that need changes [16:37:59] mostly for the better [16:38:08] where I have to use additional versions where the real RTCC didn't [16:38:13] conversions* [17:00:54] oh man, very bad ideas :D [17:15:38] no no, it's a great idea, just not in the short term [17:15:42] and maybe mid term [17:15:48] but long term it will be great! [17:18:25] hehehe [16:01:48] hey [16:11:42] hey [16:24:24] what's up? [16:28:40] not much, on the road right now with my laptop and my Bluetooth mouse decided to take a vacation [16:28:56] not easy to play NASSP with the touchpad :D [16:30:00] but I am also looking at revisiting the LM touchdown points again [16:30:50] on my 17 mission it really bugged me how the LM jitters around for a few seconds when firing an RCS [16:32:05] but I noticed Max Q added some new code for the LRV which nicely follows the lunar surface and is rock solid so I am looking to see if some of that code is usable for the LM [16:52:06] there are a few addon devs that seem to have he magic touch with touchdown point parameters. I think they should put something together and add it to the Orbiter API guide. [17:00:32] its one of the few things I dont like about Orbiter 2016. As good as they are compared to 2010, its very badly documented and complicated to implement [17:02:36] off to work, cya! [14:14:43] good morning [15:37:20] hey Alex [16:02:41] morning! [16:11:12] hey guys [17:52:55] good evening [17:53:00] good morning! [17:53:45] so, I've pretty much entirely changed my mind [17:54:03] I'm quite convinced now that whatever midcourse navigation game is, it is *not* P23 [17:54:06] or even meant for flight [17:55:15] huh [17:55:40] then I want to look at the code even more :D [18:00:20] I'm working on it :D [18:00:40] MIDCOURSE INITIALIZATION starts off by asking you to load N72 and N73 [18:00:41] haha good. If it's a lot of interpreter then I might be able to see some patterns and what it could be all about [18:00:50] which are DELTA POSITION and DELTA VELOCITY [18:00:59] and marked as for ground use only in some of our documentation [18:01:36] sounds like N49 or N99 in Colossus [18:04:47] hmm, potentially yeah [18:05:04] but anyways, yeah, this thing is almost entirely interpretive [18:05:24] and Jay was not so good at deleting erasables for this so we know a lot of erasable names [18:06:03] it interacts with ORBITAL INTEGRATION a lot [18:06:23] and even references our mystery friend from Sunrise TESTVEC1 [18:06:48] so we're potentially going to get more information about what the hell that is [18:14:11] all that sounds fun [18:18:15] I also haven't figured out how to run it yet haha [18:18:37] my attempts so far have either caused nothing interesting to happen, or caused it to do stuff for a bit and then crash [18:48:44] oh wait [19:27:35] still waiting [19:27:56] lol sorry I briefly forgot the N31 conversation was happening in discord [19:28:49] haha, that's what I figured [14:23:41] hey [14:28:06] hey Niklas [14:30:18] what's up? [14:37:11] just doing some fixes in my 17 branch [14:37:28] had a question for you btw [14:39:48] in AP10MAPUPDATE, it uses "LOI-1" as the name for the maneuver in the case of AOS with or without burn [14:39:58] can we make that more generic? [14:40:18] like just use "with burn" or "without burn" [14:41:10] hmm [14:41:13] you could add another type [14:41:25] true [14:41:39] I'm breaking the entire RTCC right now btw [14:41:41] I thought it would be a bit silly just for the name though :D [14:41:46] changing its coordinate system :D [14:42:21] yeah I got a hint of that reading the logs :D [14:44:54] will take a bit of working on it [14:45:01] then you can start helping test, too [14:45:08] sure [14:45:13] just trying anything and everything [14:57:17] now trying if the basic coordinate conversions are still working [15:00:39] hmm didn't get it right yet haha [15:17:51] hi guys [15:19:56] hey Matt [15:24:41] hey [15:25:16] I think I might try to get my density update mergable next. [15:28:41] if I recall, it was the tunnel and the repress package valves that were not playing nice [15:41:44] looking forward to it! [15:44:08] RTCC not entirely broken anymore [15:44:13] Nav Check PAD is working :D [15:48:08] which is basically a coordinate conversion and nothing else [15:54:15] nice [16:23:49] indy91, in the RTCC, what is the difference between LDPPDescentFlightArc and SITEROT again? I s it the same? [16:25:36] not exactly the same thing [16:25:40] especially not for Apollo 17 [16:25:59] LDPPDescentFlightArc is how the power descent is simulated in the LDPP [16:26:05] an angle (arc) and a time [16:26:19] so that is the actual travel angle, should always be 15-16° [16:26:33] SITEROT is used by the TLMCC, right? [16:26:44] that is the true anomaly at the landing site [16:26:48] yeah I think and as DW in the LOI it seems [16:27:02] for other missions it should also be 15° I think? [16:27:19] because you reach perilune and 15° later you are at the landing site [16:27:30] but on Apollo 17 they didn't have PDI at perilune [16:27:34] quite far from it actually [16:28:19] now I am a little bit confused about signs though [16:28:46] SITEROT is used by both the TLMCC and LOI processors [16:29:07] yeah 10 degrees after the landings site for Apollo 17 perilune I think [16:29:39] normally it is -15 or -16 [16:29:52] just a sign convention [16:30:11] "angle of perilune from the site (negative if the site is post-perilune)" [16:31:51] hmm [16:32:00] I do not understand our RTCC parameters actually [16:32:06] LDPPDescentFlightArc -10.0 [16:32:09] SITEROT 20.0 [16:32:12] for 17 [16:32:16] that doesn't seem right [16:32:51] which is actually why I brought up this question :D [16:33:33] is this the smoking gun why Apollo 17 DOI-1 never worked with the LDPP lol? [16:34:09] maybe? :D [16:34:33] these parameters were already like this before they got moved from ARCore to the RTCC file [16:35:33] right [16:35:51] https://github.com/orbiternassp/NASSP/commit/5b085880f494bd874bab4f1d0f9fd559bcf1c276 [16:35:59] but the thing is [16:36:04] is this for DOI-1 or 2 [16:38:44] I would say it is meant more for targeting DOI-1 [16:38:50] hmm [16:38:57] and you then would want to change them from DOI-2 [16:39:00] but not quite sure [16:39:08] but the perilune was set at 40000 feet [16:39:16] right [16:39:20] sounds more like DOI-2 [16:39:29] assuming DOI-1 isn't even targeted with the LDPP [16:39:49] I need to implement the integrated DOI mode some day [16:40:00] I don't have any documentation for it, but they added it on Apollo 13 already [16:40:18] it should work similar to how the LOI processor is calculating DOI [16:40:52] builds a state vector at the landing site and propagates backwards [16:41:01] should SITEROT be set to 10 for DOI-2? [16:41:18] ah interesting [16:41:24] hmm [16:41:35] did they have a DVZ component for DOI-2? [16:41:39] no [16:41:46] not planned anyway [16:44:59] actual doesn't either [16:47:31] might just be a perilune lowering and not even a LDPP DOI calculation [16:50:18] right [17:22:48] still trying to understand why I put SITEROT 20 in that commit :D [17:25:50] https://nassp.space/irclogs/2020/2020-03-30-22%3A44_Log.log [17:25:54] https://nassp.space/irclogs/2020/2020-04-01-21%3A17_Log.log [17:25:59] https://nassp.space/irclogs/2020/2020-04-06-21%3A56_Log.log [17:26:02] search for SITEROT [17:26:06] we are talking about it [17:28:40] ah thanks [18:24:17] indy91, we were talking about abort constants back in those convo's as well...apparently you said "looks like 12 and 17 are quite similar" and "if the timing of Boost etc. is also the same then it should work fine" :D [18:25:01] that being said they might indeed be very different, Ill have to check [18:25:05] right [18:25:11] ... I'll get to it, I promise [18:25:29] no rush haha [18:59:13] hmm I think using SITEROT 20 for the TLMCC/LOI solutions was required so that the DOI-1 with the GPM could target the proper biased perilune longitude (~31 E) so that it becomes 20 E at PDI [18:59:36] 20 E being 10 degrees past the landing site [19:07:14] hmm that makes sense [19:18:12] still confused as to why the SITEROT needs to be biased as well, since the TLMCC/LOI processors know about the 10 REVS from DOI-1 to landing [19:18:21] REVS2 [19:21:24] not sure, but TLMCC and LOI don't simulate DOI-1 and 2 separately [19:21:33] but DOI-2 really isn't that significant of a burn really... [19:26:42] oh thats what I did [19:26:46] " the way I am doing it now is to bias the SITEROT to get the proper pericynthion height (50 NM)" [19:27:32] haha [19:30:19] and a few lines later [19:30:23] " I can get creative and implement how I think it should work" [19:30:32] "and disregard the source material" [19:30:34] :D :D [19:30:50] I feel like you have similar sentiments for many things [19:31:16] that needs context [19:31:19] checking [19:31:41] oh with the LOI and DOI DVZ not being taken into account for DV optimization [19:31:46] yeah haha [19:31:49] I think that is still mostly the case [19:31:54] and it's not that great [19:32:16] right [19:32:43] at least with the constraints for the LOI and DOI ellipses in the TLMCC processor the trajectory gets mostly forced into the required shape [19:32:57] I do notice that LOI DVZ's are always a little higher then the real mission for Apollo 14-17 [19:43:01] true [19:43:11] need to revisit that some day [19:43:14] add it to the pile [20:32:10] night! [11:59:55] good morning [12:00:41] hey Matt [12:04:16] how's the coordinate system stuff going? [12:04:56] more and more things working [12:05:13] nice [12:05:24] so, what does that actually change? [12:05:53] RTCC now would use the same coordinate system as the AGC [12:05:58] changing yearly [12:06:25] enables me to reduce a whole bunch of extra conversion I had to include where I was using real RTCC equations [12:06:36] but then had to account for using an ecliptic coordinate system [12:07:17] was quite annoying in something like the RTE [12:07:22] which has inclination limits [12:07:43] so every time I have to account for the inclination I first have to convert ecliptic to equatorial [12:08:29] if you want to help me you can do a MCC-7 calculation real quick as comparison so that I don't have to switch branches :D [12:09:18] I would love to.... unfortunately I'm talking over moble IRC and am not home right now [12:09:29] no problem [12:10:01] one annoying thing is that our Apollo 11 scenarios are quite old [12:10:15] was going to check a RTE calculation but there is a bigger difference in latitude than before [12:10:26] to what's already loaded in the CMC [12:10:50] still a looot to do [12:11:06] I often use 11s scenerios for system test stuff, I can agree. [12:11:13] MASTER ALARM [12:11:21] I'm changing two coordinate systems at the same time really [12:11:27] well [12:11:30] technically even 3 [12:11:47] ECI, MCI have the same orientation, just Earth vs. Moon centered inertial [12:11:56] MCT (true) is rotating with the Moon, that stays like before [12:12:07] but the ECT system is quasi inertial, doesn't rotate with the Earth [12:12:23] so to calculate actual longitude you always have to add Earth rotation rate times GMT [12:13:31] but I think it's the right decision to not also change the units now [12:13:43] from meters and seconds to Earth radii and hours [12:13:52] that would really break everything at once [12:18:04] but that will also come eventually :D [14:28:38] hey [15:01:48] hey Niklas [16:56:11] morning! [17:15:40] hey Mike [17:17:53] what's up? [17:18:28] watching Turry [17:18:35] I doubt I get something else done today lol [17:19:01] hahaha [17:19:29] how is the midcourse navigation game coming along [17:19:50] spent most of the weekend with my dad who was visiting, so slowly [17:20:11] ah nice! [17:20:20] should get back to it tonight though [17:20:36] can't wait to try and figure out what it even does [17:21:02] I'm realizing I'm going to have to learn how the orbital integration code actually works [17:21:14] so I have started to read about encke's method [17:23:11] it has been many years since I've done this sort of math :P [17:24:25] also unrelated -- yesterday there was yet another instance of "documents that Mike finds on ebay that are interesting but probably not useful" [17:24:26] https://i.imgur.com/CLXDZRG.png [17:24:41] so that should be here soon. I didn't know they republished that for ASTP [17:25:32] and by find you mean, already bought :D [17:25:40] lol yes [17:26:11] more CSM Data Book can only be good [17:26:18] padload we already had [17:27:01] and regarding orbital integration, even know the GSOP quite well it doesn't easily translate to reading the actual code as I had to find out [17:27:10] knowing* [17:27:41] the code seemed quite different in places [17:27:51] Solarium, Colossus, any version really [17:28:11] yeah, and the compleat sunrise really doesn't help as much as the AS-202/AS-501 GSOPs suggest that it should either [17:28:53] this data book might have stuff about the DM [17:29:03] could be quite nice if we ever properly simulate it [17:30:15] yeah it definitely does [18:39:52] hey [18:55:24] hey Alex [19:14:15] thewonderidiot, let's assume one does V21 N01E, 20000E [19:14:26] what happens on the Virtual AGC and what should really happen [19:16:20] hmmmm [19:18:15] I'm not entirely sure [19:20:10] haha ok [19:20:36] I can research it tonight [19:20:55] that question is really "how does the PINBALL code behave", and the PINBALL code is a lovecraftian nightmare of spaghetti [19:21:11] I have no idea what address it actually will try to hit, if any [19:27:00] doesn't look like it crashed Turry's AGC, so, all good haha [19:35:33] yeah I think it should be fine [21:28:37] night! [02:26:23] .tell indy91 PINBALL effectively ignores those upper bits. what Turry did is no different from V21N01E, 0E, which will change (briefly) the contents of the accumulator. whatever is loaded into the accumulator there is never used, and the accumulator is set to 0 two instructions after it would be changed [12:58:54] .tell indy91 I think we might have a little bug in our PCM, not sure though. It looks like were only able to send one word per call of PCM.timestep when the CMC is on. have not looked at the LM yet. [16:29:28] good evening [16:30:21] n7275, could be, never looked much at the PCM code [16:30:29] aside from adding more telemetry haha [16:30:49] hi [16:31:07] yeah it definitely does. I looked into it a bit more [16:32:04] it also means that we're sending telemetry way slower than we should [16:33:24] but those "one byte per (rendered) frame" TCP messages are almost certainly what's killing performance under time acceleration. [16:34:18] interesting [16:34:53] you can actually see it if you look at the client in HRB and then pull the CMC breakers [16:35:14] update rate increases massively [16:36:35] could be a mutex thing with the AGC or interrupts taking too long [16:37:21] I should really make sure I didn't accidentally disable multi threading or something dumb line that though [16:37:33] like [16:38:54] hmm right [16:41:18] hey [16:41:46] hey Alex [16:42:53] I wish I knew more about TCP [16:43:05] not feeling like learning another aspect of NASSP though haha [16:45:27] I will work on it when I finish my other projects [16:46:42] sounds good. Don't think it's super urgent [16:48:22] I have important projects like breaking the RTCC apart with coordinate systems... [16:48:35] I think it's probably been like for a long time [16:48:44] could very well be [16:48:57] I wonder if this discussion about a 1202 on discord could be related [16:49:03] telemetry too slow sounds a bit weird, but, possible I guess [16:49:41] morning! [16:49:52] hey Mike [16:51:20] I'm not getting rid of transducers or any of the PCM stuff (except maybe the sockets eventually), if you followed the discussion on discord. just floating ideas around. [16:52:18] I've added too many of those. I'm invested in their existance [16:53:29] haven't really followed it [16:53:37] too much text :D [16:54:54] you and Daniel just do what you think is best [16:55:12] I have no stake or knowledge there really [18:45:33] indy91, the document which our Powered Descent Abort Program is based off, do you have it by any chance? [18:45:41] sure [18:45:55] can't seem to find it in my repo [18:48:15] https://web.archive.org/web/20100519144550/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740072723_1974072723.pdf [18:49:26] thanks! [18:51:09] no problem [18:51:51] oh and I had a few questions about some of the variables [18:52:49] dt_step, what is that exactly? "DT between successive abort points" Is that between the 1st and second set of insertion parameters? [18:54:29] it seems RTCC MFD sets this to 20.0 for Two Segment and 120.0 for one segment [19:11:10] it will simulate aborts at PDI+20, 40, 60 etc seconds [19:11:22] and then make a curve fit out of the data [19:11:26] to generate the abort constants [19:11:56] I set one segment higher so that there are enough data points for the Luminary 99 style polynomial [19:12:06] but not more than needed [19:12:23] right [19:51:07] good night! [21:11:59] night! [15:32:44] good morning [15:45:03] hey Alex [16:37:35] hey [16:38:28] hey Niklas [16:40:02] how's the RTCC breaking going? [16:41:10] smashing [16:41:25] :D [16:41:30] there are so many functions that are coordinate system dependent... [16:41:50] I should have done this change the moment I realized that I was using the wrong coordinate system [16:42:05] was always going to be painful though [16:42:20] don't approve my PR on Github btw [16:42:26] needs another change [16:43:21] right [16:43:26] ah yes just saw it [16:46:10] when only Apollo 7 and 8 were supported the RTCC MFD was using the correct coordinate system [16:46:18] same as AGC coordinate system [16:46:40] but then I changed it to ecliptic because they changed the coordinate system every year [16:46:51] and I wanted a consistent system that didn't change [16:47:27] but it's been so painful doing all these extra conversions that the real RTCC didn't have to do... [16:48:04] ah I think I remember that change [16:49:01] yeah it was not long after the RTCC MFD got included in NASSP [16:49:30] started to look at that old version with the correct coordinate system [16:49:35] how I did it back then :D [16:49:39] only slightly helpful [16:49:55] in a lot of places it has the coordinate system for Apollo 7-10 hardcoded [16:52:22] I'd say if I keep it up then in 1-2 weeks the branch should be ready to start some testing [16:58:09] morning! [16:58:43] AlexB_88, PR should be good now [16:58:45] hey Mike [17:25:54] hey [17:25:58] indy91, done [17:26:47] great thanks [17:28:02] now the RTCC MFD can be opened in the S-IVB, too [17:28:38] helpful for MaxQ's attempt to target a launch of a LM on a Saturn IB, AS-258 mission [17:29:34] that mission would have had some really narrow insertion requirements [17:29:48] we'll see if it works out haha [17:44:50] nice [17:45:40] btw I think free flying viewpoint PR should be good to merge, I did some testing and it works quite well [17:47:04] right, I think he did some last minute fix today haha [17:47:58] ah lol I didn't notice [17:51:57] I want to read that code a bit before merging it [17:52:07] ok [18:50:34] I haven't tried it out yet, but that sounds like it would be very useful. [19:44:31] indy91, I think my first pass at MEASUREMENT INCORPORATION will have no UNKs in it (except for references to bank 24), thanks to leftover erasable names and similarity to Colossus 237 :D [19:45:13] one interesting thing, it has its own version of RECTIFY that uses DELR and DELVEL instead of TDELTAV and TNUV [19:45:51] and since it is rectification happening in the incorporation section, where all of the labels are called things like INCOR.... I naturally named it INCORECT :P [19:56:55] lol [19:58:56] and what were DELR and DELVEL again? [20:01:25] I have no idea! [20:02:00] they are N72 and N73 [20:02:19] "delta position" and "delta velocity" [20:02:22] hmm [20:02:33] I am not super familiar with measurement incorporation [20:02:46] maybe it does work kind of like Encke rectification [20:03:10] so you might be manually putting "sextant mark" data into those nouns [20:15:04] oh interesting, that could be [20:15:37] the basic concept appears to be a bit similar to the encke stuff [20:16:07] it does a lot of math with the W matrix and the B vector, and if it causes an overflow then it does this rectification [20:16:24] and then finishes its calculations after rectifying [20:17:04] and very rough comparison of the Block I vs. Block II interpretive code suggests that the math is basically the same [20:17:16] (for the two versions of measurement incorporation I mean) [20:17:34] so whatever the GSOP has to say is probably mostly applicable to Corona already [20:22:44] ok but Block II doesn't have those nouns [20:23:01] unless it isn't actually mark data but instead W-Matrix reinitialization values [20:23:11] technically Retread has those nouns :P [20:23:22] ha [20:23:27] like in V67 [20:23:31] N99 [20:26:16] uhhhh [20:26:21] what are V67 and N99... [20:29:38] in Colossus [20:29:47] V67 to load W-Matrix reinitialization values [20:29:51] N99 is displayed in V67 [20:30:57] you said it's similar to Block II, so there should be variables similar to DELR and DELVEL it uses [20:32:53] actually, what happens in Colossus if the W-matrix overflows... [20:32:57] there is a program alarm [20:33:19] actually you know what, hang on [20:36:03] https://github.com/thewonderidiot/virtualagc/blob/Corona261/Corona261/MEASUREMENT_INCORPORATION.agc [20:36:05] there you go [20:40:08] ah great! [20:41:58] do NEWNUV and NEWDLTAV get used anywhere? [20:42:34] on a first looks it seems like mark data that you manually enter in the nouns [20:42:39] look* [20:43:13] they really should shouldn't they? [20:43:26] I don't remember seeing them anywhere else but I might not have been looking correctly [20:43:36] I'll have to do another pass looking for those addresses [21:08:50] night! [12:42:08] hey Alex [13:01:35] hey [15:12:14] hey [15:13:32] Hey Niklas [15:24:26] how's Apollo 10 RealTime been going. I've been busy for all the important parts so far. [15:27:40] reentry tomorrow [15:27:57] going pretty well, struggles with P23 as we all have :D [15:28:12] he did a bit of a silly mistake yesterday. Had the event timer set wrong for MCC-5 [15:28:22] wasn't paying attention that the DSKY wasn't blanking [15:28:27] so he did the burn one minute too early :D [15:28:34] without Average G running [15:28:38] but no problem overall [15:29:08] rendezvous was a challenge, but there was a larger support crew in chat, so he got through it haha [15:30:03] somehow his LGC CSM state vector was a bit off right from the start [15:30:19] that caused basically all the problems until there was another uplink. He did good. [15:35:50] nice [15:36:05] man must be something to fly an entire mission in real time [15:38:19] It looks like a lot of fun. I'm not sure when I would find the time to do that though. Maybe when I retire in 50 years or so [15:45:03] he has challenged me to do an Apollo 5 real time stream [15:45:09] I think that would be doable :D [15:48:30] I would probably have to take 2 weeks vacation [15:48:50] but even then would get much protest from my significant other :D [15:51:24] indy91, btw I am happy to say that I got the PDAP spitting out good constants for Apollo 17 PDI-1 & 2... [15:51:34] oh nice [15:51:38] except it required a few little modifications :D [15:51:44] I bet [15:52:45] it needed to be able to use the canned maneuver and long profile for the 1st segment for PDI-2 [15:54:26] and I defined a second R_amin because unlike 12, the 2 segments seem to be terminated at different apolunes for 17 [15:54:36] not both 30 NM [15:55:05] hmm [15:55:10] but for PDI-1 the switchover is at ~59 NM and then PDI-2 136 NM or so [15:55:33] but then 30 NM for both second segments [15:56:02] oh I bet there is something in the mission techniques about this [15:56:19] depends on the mission where they started this [15:57:34] Apollo 16 seems like they got lower than 59, but still not to 30, weird [15:59:40] right [16:00:22] hmm is there a specific document you're referring to? (mission techniques) [16:00:28] pardon my ignorance :D [16:01:14] several, none of them have anything so far [16:01:25] there is one document for updated techniques for 16/17 [16:01:35] ah right I think I have that [16:01:39] and then one for 17 only and only lunar orbit and ascent [16:01:53] the 16/17 one should have maybe had something, but it doesn't seem like it [16:03:03] oh yes it has [16:03:17] it changes the threshold from being based on altitude to based on time [16:03:27] first segment always up to PDI + 10 min [16:03:30] no matter the altitude [16:04:01] maybe to make aborts in switchover region more clear [16:04:16] so that the astronauts aren't unsure which abort region the computer has selected [16:04:42] the altitudes are actually quite similar before and after the switchover [16:05:17] ah [16:05:44] because they moved the CIRC burn [16:05:45] one way I found if there is confusion about which abort was selected is checking apolune after insertion [16:06:05] Apollo 15 did the CIRC burn 1.5 orbits before PDI [16:06:08] and then comparing it to the PDI summary data chart [16:06:27] yes but that is kind of the problem [16:06:47] the apolune altitudes aren't very different before and after switchover [16:07:04] well [16:07:13] I guess 20 NM higher or so [16:07:24] they are a bit different but I see what you mean [16:07:58] definetly better to make it a fixed time I guess [16:08:36] was already pretty close before 16 [16:09:14] Apollo 15. PDI+5 apolune 135.8, PDI+6 is 130.9, then switches and PDI+7 has 142.8 [16:11:30] the plots in the 16 and 17 timeline books are basically the same [16:11:42] even if the apolune altitudes are 10 NM different for the same time... [16:13:14] its also mentions that the PDI-3 would be similar to PDI-2 for Apollo 13-15 [16:15:11] it also doesn't seem to be an issue with CDH to TPI time [16:15:15] that can be variable [16:15:24] and you don't want it to be too short [16:15:36] but is actually slightly increase with lower altitudes in the first segment for 17 [16:15:41] increasing* [16:17:13] maybe we are being slightly fooled by there being only data for every minute [16:17:22] if the switchover time is 10 minutes [16:17:32] and at 9 minutes apolune is 59.3 [16:17:47] looking at the rate it is going down [16:17:52] right [16:17:57] just before switchover it would be in the 40s maybe [16:19:33] I will check the LGC padload actually [16:19:37] btw it seems in the current version its impossible to set the long profile for the 1st segment right? [16:20:05] it seems weird they would have the processor like that for 12 when the very next mission had the long profile on the 1st segment [16:20:40] doesn't seem that weird to me haha [16:20:52] they liked changing their minds [16:21:12] anyway what I did was add a LongProfileFirst flag which then sets the canned maneuver in the SV with K3 to false and not when its true [16:21:16] it might be impossible, hard to tell for me [16:21:25] but thats probably a bad hack :D [16:21:36] what I would like to see is fully customizable rendezvous profiles [16:21:50] so that all missions can be easily supported [16:23:29] yeah that would be ideal [16:28:39] but the PDAP constants are looking pretty good (after the slight hack) [16:29:13] P32 shows DH 14.5, 15.0, etc on the tests Ive made [16:29:29] very nice [16:29:45] let me try to calculate the switchover apolune from the padload [16:29:53] ok [16:29:57] maybe that is more exact than these data every minutes [16:30:04] right [16:31:51] ah RAMIN itself is a padload [16:31:59] but that might be the 30 NM [16:32:37] yeah [16:33:13] btw 662 and 673 are K1 and K2? [16:34:11] I think so yeah [16:34:51] I see 227 uses K1 [16:36:04] morning! [16:36:09] hey Mike [16:41:17] hey [16:41:28] ah damn, I can't actually calculate it by hand [16:41:41] the padload has the phase angle it uses for the decision between the two segments [16:41:44] at the time of abort [16:42:06] but the insertion conditions are continually re-calculated until insertion [16:42:19] so the insertion velocity is a function of the phase angle at insertion, not at abort [16:44:05] right [16:56:46] indy91, I have finally located a single document outside of the status reports that acknowledge the existence of midcourse navigation game [16:56:58] in these minutes of a meeting between MIT and NAA: https://www.ibiblio.org/apollo/Documents/naa_meeting_130b_minutes.pdf [16:57:20] PDF pages 34 and 35 [16:57:36] and gives a very short description. "Routine Procedure to Accomplish Sightings" [16:57:56] ...probably not more helpful than what we already knew, but it is very nice to find *something* haha [16:58:21] the Orbital Integration Program description on page 34 is possibly more helpful, it gives some details that might help us identify TESTVEC1/TESTVEC2 [17:13:39] hmm right [17:13:50] I'll try to dive a bit deeper into the code later [17:13:57] later today* [17:14:58] I'm about 50% of the way through translating my midcourse navigation game disassembly into source code.... I think I should have Corona source assembling completely correctly in a couple of days (with many many UNKs) [17:16:58] until then I can try to understand INCORECT :D [17:17:03] hehehehe [17:17:15] oh you asked about NEWDLTAV and NEWNUV yesterday [17:17:45] and the answer is, those just share addresses with TDELTAV and TNUV directly [17:18:00] I think I just used those labels because they were there and looked like they made sense for that function heh [17:19:39] haha [17:19:49] EQUIVALENCE [17:19:55] hahaha yeah [20:27:35] our old friend [20:32:10] more like fiend [21:01:21] night! [21:23:29] haha yep [13:09:46] hey [13:22:22] hey Niklas [13:24:46] I put my RTCC coordinate system branch on Github yesterday. A bit too early to start testing things, but it should be ready for that this weekend. [13:25:37] oh and I had to do some changes to the Apollo 12 MCC Ascent PAD calculation [13:26:08] you basically copied everything out of the AscentPAD function and calculated and wrote the PAD in the MCC file [13:26:15] because it's a different PAD format [13:26:34] I've changed that so that it is calling the Apollo 11 Ascent PAD function [13:26:48] and then copies the data from the 11 to 12 PAD format [13:27:00] still a bit ugly, but at least there is no code duplication [13:27:49] hey guys [13:28:57] hey Matt [13:29:01] indy91, sounds good [13:29:40] hey Matt [13:29:51] I don't really want to do too many upgrades like that in this branch, just keeping it to coordinate system fixes [13:31:30] but I would have had to do the Ascent PAD coordinate system fix in two places so... [13:35:11] btw just wanted to show you the modifications I did in my branch for the PDAP: https://github.com/orbiternassp/NASSP/compare/Orbiter2016...jalexb88:NASSP:PDAPwork [13:35:43] what do you think? Not planning on PRing it or anything unless you think these are good [13:40:17] I think more reading is required on the switchover point [13:40:35] the problem is, it might be procedurally nice to have it at exactly PDI+10min [13:40:56] but depending on the rendezvous profile you could get altitudes lower than 30 NM apolune like this, right? [13:41:16] or is h_amin still preventing that [13:42:09] ah you could I think [13:42:31] the apparently early switcover seems like an Apollo 17 only special [13:42:37] switchover* [13:42:38] maybe the h_min should still be used on the 2nd segment [13:43:20] it would use data in the curve fit for the abort constants that is not used in reality, apolune below 30 NM [13:45:19] I think Apollo 13-15 also have an early switchover [13:46:50] oh in that case there are more documents to check for the reason [13:48:06] it seems to be associated with the long profile (with BOOST/HAM) [13:55:28] "The 2-REV sequence is used in abort situations which would place the spacecraft beyond the maximum VHF ranging [13:55:32] distance during the tracking period prior to the nominal 1-REV CSI maneu [13:55:35] ver" [13:56:28] so for Apollo 13-15, if you would use the short profile, you get a quite high apolune [13:57:13] and a lot of total distance to the CSM in the time before CSI [14:02:45] right [14:06:28] but I'm not really sure that logic applies to Apollo 17 [14:07:24] Apollo 17 abort at about 7:20 has a chance to hit the CSM before CSI :D [14:13:31] the version of 69-FM-225 at NARA (in old box E157G-39) has an eight page change document from October 1969 [14:14:21] https://archive.org/details/NARASWSelectedApolloBoxes/page/n551/mode/2up?view=theater [14:14:46] although I wouldn't necessarily expect it to already have changes for Apollo 13 [14:15:21] might be worth asking them to scan only change documents [14:15:30] I hope one document for free for them [14:15:37] I got* [14:15:47] and if it's just a few pages and like 80 cents per page [14:15:52] would be worth it [14:16:13] just have to tell them explicitly to not scan the original document :D [14:17:52] for Apollo 17, maybe the problem is after all the range at CSI [14:17:56] or before CSI [14:18:03] looking at the plots the distance is quite large [14:18:09] for aborts after PDI+9 [14:19:31] maximum VHF range is 320 NM [14:19:35] found that in a plot [14:19:40] not actual maximum of course [14:19:44] just for mission planning [14:20:31] would be kind of difficult to enforce this in the PDAP code though [14:21:45] yeah [14:22:46] so I think the switch on time is not the right way anymore [14:23:02] right [14:23:04] maybe different apolune minimums for the two segments [14:23:47] thats what the original version of my mod did :D [14:24:10] haha sorry [14:24:57] I think that's the way to go [14:25:08] in reality the PDAP might have output extra data like ranges at CSI [14:25:41] I wished I had the Apollo 12 RTACF Operational Support Plan [14:25:50] don't think they ever ran it in the RTCC [14:26:08] I know on Apollo 11 they had to give a bunch of data from the RTCC to the RTACF people to run the PDAP [14:27:09] in the 11 support plan we have the printout from the PDAP at least [14:28:37] doesn't help much [14:29:19] oh and on 12 PDI-2 it seems it used only one segment [14:30:56] only one was really needed [14:32:19] there were so many changes with these descent abort constants haha [14:32:29] Apollo 12 and later at least used the same format [14:32:40] 11, a polynomial [14:32:46] 10, two fixed velocities [14:32:52] 9, one fixed velocity [14:32:57] in the LGC software I mean [14:37:38] ah interesting [14:38:26] has anyone tried a PDI abort with 9/10? [14:38:45] not that they had nominally flown PDIs obviously [14:39:15] but I know you flew the Apollo 9 software to a landing I think [14:39:26] and I did with 10 but never thought of trying an abort [14:39:43] I have at least checked the code, to see how it works [14:40:17] and yeah, different abort concept on every mission from 9-12, then they finally stuck with one [14:40:24] ... borrowed from the AGS software [14:44:18] ah right, the two velocities for Apollo 10 are padloaded [14:44:25] Apollo 9 has a hardcoded insertion velocity [14:45:53] but that doesn't help us much with the 12+ abort constants haha [14:46:15] maybe that change document would [14:46:37] might be changing it to two different apolune altitudes, who knows [14:54:53] I have an annoying change I want to make to the pipe class [14:55:17] annoying to whom? [14:56:02] well, me mostly haha, but a little bit to everyone if it causes complications (scenerio fixes) [14:59:19] flow is dependent on in-valve size, but not out-valve size [14:59:33] I want to make it the geometric mean of in and out [15:01:07] I'm trying to fix the repress package fill problem (dropping the pressure too much in the cryo tanks) [15:01:56] sounds like a good change. Why would it require a scenario change though? [15:02:27] if it necessitates some valve sizes changes [15:02:38] valve sizes get saved to scenerios [15:03:30] not sure it will yet though [15:03:52] ah ok, changes necessary because this has an effect on behavior [15:04:16] I can't imagine it being bad enough to totally break scenarios [15:04:27] and a bunch of our current mission scenarios still have master alarms anyway... [15:05:05] yeah, and most of our in and out valves are close in size [15:05:18] I'll try it and see where I end up [15:16:06] indy91 here is what I did (now uses 2 minimum apolunes) https://github.com/orbiternassp/NASSP/compare/Orbiter2016...jalexb88:NASSP:PDAPwork [15:18:36] that's good [15:18:41] could be merged if you want [15:18:55] how many missions that does now cover? All of them in theory? [15:18:59] with the right inputs [15:19:05] I think so [15:19:58] yeah I tested a lot of aborts and it seems to work well [15:20:07] ill PR in a few mins [15:22:24] of course to use the different profiles in the RTCC MFD there will need to be more input fields [15:22:36] yeah [15:22:42] I can handle that (at some point) [15:22:52] but maybe not a huge rush since were still focusing on the early missions [15:23:01] btw, did you encounter this line in the code "Overwrite actual insertion velocity with desired one; gives more consistent results" [15:23:21] Apollo 14 FIDO report [15:23:28] oh yeah haha [15:23:35] I wondered about that [15:23:42] the Apollo 14 FIDO report mentions exactly this issue [15:23:57] and that they had to fix the PDAP for this :D [15:24:17] because the ascent predictor (ascent simulation) is not giving 100% consistent results [15:24:23] kind of like ascent before trimming residuals [15:24:38] and I had the same issue in our RTCC [15:24:41] thought that was funny [15:31:00] haha proves that the equations are authentic :D [15:31:07] PR sent [16:19:15] morning! [16:21:26] hey Mike [17:23:21] hey [21:49:26] night! [12:07:21] good morning [13:18:48] good morning [17:28:37] hello [17:29:59] hey Matt [18:31:51] I think the valves for the hatch pressure relief need to be changed, other than that things should be okay [18:50:02] hmm, it is not obvious to me how the side hatch even works [18:56:24] haha [18:56:51] I read your PR and been thinking about cases where that change is really necessary [18:57:06] I guess it's cases like the side hatch where you don't have a classical pipe [18:57:35] what part of the side hatch do you have problems with? [18:59:13] well I'm trying figure out how, when I open the vent valve, the cabin actually vents. I see systems stuff for the forward hatch but this one is a bit different [18:59:32] is there a valve here that I'm just missing? [19:02:32] the side hatch is kind of bad, weird code [19:02:48] let me check [19:02:55] I'm coming to that conclusion too... [19:03:18] doesn't the CabinPressureReliefValve class handle this? [19:06:50] I don't think so, but maybe [19:08:50] hmm, definitely involved in the cabin purge though [19:09:19] CabinPressureReliefValve::SystemTimestep uses sideHatch->GetVentValveRotary() [19:10:21] oh [19:16:09] this could be replaced by muuuch simpler code at some point [19:18:53] afternoon! [19:19:58] right now it's just a few numbers I can change in code [19:20:06] hi Mike [19:21:08] yeah this might be one of the worse parts of the CSM ECS [19:21:10] hey [19:21:21] no wonder Ryan has wanted to replace it for a long time :D [19:22:30] my goal for all the vents and external pressures eventually, is to have SPSDK have a default internal tank that is created automatically, and which the SDK updates automatically to have the right partial pressures. then we can just plumb things to it. [19:24:52] yep makes a lot of sense. Something I have occasionally thought about as well over the years [20:10:59] well that seems to have fixed it [20:14:01] I think I am done with breaking the RTCC. Now it's all about fixing it. I've made the necessary changes to wherever I saw a coordinate system conversion that is now different. [20:14:17] whatever I have tested so far works or needed only some small fix [20:14:28] ... but there is so much to check, it's a bit overwhelming [20:31:35] I can imagine [20:46:12] thewonderidiot, starting to look at it, I think my entry point is where it does a VMOVE on that long table [20:47:05] but before that it must build some matrix because it does a MXV with a loaded vector [20:47:12] go for it! you'll notice that there's one point where I have a -6,1 to force it to point at that table [20:47:27] otherwise it points at some of the VN codes which I can't imagine is possibly correct [20:47:38] but that -6 is definitely a hack and possibly wrong :P [20:47:49] how did you get the name SITENUMB? [20:48:03] it's an unused variable at that same address in Solarium [20:48:31] a variable called MEASMODE is also at that address [20:48:42] but MEASMODE is actually used and doesn't look like it's used in the same way, so I went with SITENUMB [20:49:32] I think U31,7314 builds the matrix [20:49:38] and it accounts for body rotation [20:49:41] not sure if Earth or Moon [20:49:52] U31,7402 could be Earth rotational rate [20:50:03] for the most part I just took erasable names straight from Solarium. where there were multiple choices I made a guess -- usually educated but sometimes random. so it will probably be useful to have Solarium up to look for other erasables that share the same address [20:50:22] oh man you're figuring this out fast :D [20:51:33] haha not really, just seeing some "patterns" that look some math I might have encountered [20:51:42] not doing it systematically line by line yet [20:51:48] look like* [20:52:05] I'm in the same boat with midcourse navigation game itself [20:52:18] there is a lot of structure there that looks a lot like the tests in Sunrise [20:52:42] same patterns being followed code-wise [20:52:51] which should help with understanding how it flows [20:53:36] yeah surely U31,7314 builds a (literal) rotation matrix [20:53:42] when else do you multiply with TET :D [20:55:02] name of SITENUMB is curious, could be a table of landmark unit vectors or so [20:55:11] but there also have to be stars somewhere... [20:57:41] a lot of midcourse navigation game is probably more the UI [20:57:48] and some data like that table [20:57:51] if not SITENUMB or MEASMODE, there's always the third possibility that another erasable name got deleted [20:57:54] rather than the actual math [20:58:03] yeah [21:03:39] enough guessing, have to start this a bit more systematically [21:20:42] night! [15:07:45] hey [15:08:19] hey Matt [15:08:49] something was still bugging me about the VC free camera PR [15:09:10] looking up now if/what Orbiter default keys that is using [15:09:35] oh, yeah that would be good to check [15:09:46] insertion and delete are used for aerodynamic trim controls [15:10:01] I guess we can do without that [15:10:32] I can agree [15:25:12] I think what is annoying me a bit that this is a feature that NASSP needs to implement [15:25:21] and even adding special code to each vessel [15:26:28] well, we could always impliment it as a feature in OpenOrbiter :) [15:27:21] the thing it has going for it though is the CSM main panel being at an angle [15:27:51] so if there were some kind of generic camera system it wouldn't move right in up and down [15:29:21] that could be as simple as defining the basis of a camera coordinate system though [15:32:15] yeah [15:32:35] if you look at the code of e.g. the Saturn class there are generations of NASSP developers wanting to just implement a small little extra feature [15:32:54] and that's how you get the state of it, where even I still discover unused code in it [15:33:30] so for the Saturn class specifically there needs to be a very good reason to add new code to it that doesn't also get rid of other code [15:35:43] I'll think about it some more [15:38:26] speaking about PRs [15:38:37] your PR is adding the effective size as an optional parameter [15:39:06] is there actually any place where GetFlow of the valve class gets called now without that? [15:39:35] hmm, let me check [15:39:40] ah [15:39:43] h_MixingPipe [15:39:58] h_CO2Scrubber [15:40:03] h_WaterSeparator [15:40:31] yep [15:40:49] Do I want to mess with those....hmmmm [15:41:27] I'm thinking not [15:45:01] hmm [15:47:12] I think h_MixingPipe should probably have this too. I need to think if I want that now though [15:48:54] other than that, geometric mean makes a lot of sense [15:49:25] that 10 -> 200 change makes CABINVENT more effective I guess? [15:49:44] For a long time I thought that was how pipes worked in our code [15:50:10] yes, it makes it flow at the same rate as it it did before [15:50:22] I have another commit to push for water dump [15:51:54] ah so your PR still needs a few tweaks like that then? [15:52:17] yep [15:57:58] I am going to change MixingPipe. we have exactly one of them. And If i don't thange it now I'll need to later. Might as well have it all in one PR [16:17:54] with my RTCC coordinate system change a few more things are now coordinate system dependent [16:17:57] like the star table [16:18:26] the text file for that is still in ecliptic, but the table in the RTCC class gets rotated to the desired epoch [16:18:44] I think that works fine, but I probably want to overhaul RTCC initialization a bit soon [16:18:56] also consider some trouble that MaxQ had with his custom missions [16:19:10] considering* [16:19:35] I'll probably give less options in the RTCC MFD and add more to the RTCC mission file it loads [16:20:01] kind of equivalent to the initial program load they would have done in the RTCC, before loading anything specific to a launch day or calling a MED [16:20:57] makes sense [16:22:08] If you have anything in punch-card format could we preserve the fixed width columns? [16:24:13] Also, I think my branch is good now. [16:27:12] fixed width columns? [16:32:58] as in, replicating the punch card format, parameter ____ in column 16, etc. maybe that's a dumb idea, not sure [16:35:49] I like it [16:37:13] it is not currently in that format [16:37:17] I'm only using one punch card equivalent right now really [16:37:18] the RTCC TLI simulation parameters [16:37:19] I know the format, including columns [16:37:20] basically what I set up is a little tool that searches scenarios and then writes this "punch card" data in a text file [16:37:21] one line per card [16:37:22] and that text file is read by the RTCC [16:37:23] searches scenarios for the actual LVDC presettings I mean [16:38:13] lol is Github down [16:39:49] I had put that tool on Github. I can probably update it so that it writes the data properly formatted [16:39:53] the website is working for me [16:39:55] ah now it works again [16:39:56] https://github.com/indy91/RTCC-TLI-Presettings-Card-Format [16:41:07] ooooo I remember this one. [16:45:21] might even load right without any RTCC code changes if I change it to fixed width [16:47:02] scanf is pretty good about things like that [13:12:50] hey guys [13:13:33] hey [13:14:53] hello hello [13:26:43] I think my pipe branch is ready for another look. I should have waited before making it mergable, but I think it's good now. [13:39:02] yeah I'll look at it [13:39:05] I'm sure it's good now [14:04:07] still discovering some major issues with coordinate systems, but the number of them is going down [14:04:21] I bet the majority of bugs right now is wrong longitudes [14:08:55] and I am thinking I should request some more UHCL documents [14:09:02] PHO-TR560, Apollo Soyuz Test Program, Mission Program Requirements for the Real - Time COMPUTER COMPLEX [14:10:07] hopefully that has an appropriate number of pages [14:10:43] they never have [14:10:46] even the 1000 pagers haha [14:11:17] also, sometimes dates are deceiving [14:11:20] 10/07/1965 RTCC ( REAL TIME COMPUTER COMPLEX ) COMPUTER REQUIREMENTS FOR PROJECT APOLLO [14:11:42] I definitely had some documents that said 1967 but many pages were replaced by updated versions up to 1969 [14:58:28] n7275, your PR won't need any scenario fixes? [15:00:12] Wastewater dump may be a bit slow, but that was already broken in old scenerios since 2020. [15:01:55] other than that, no, I don't think so. [15:04:28] great [15:31:27] indy91, I am looking at the Apollo 12 MCC calculation for the PDI-2 abort constants [15:31:54] Apollo 12 PDI-2 has only one segment for the whole powered descent phase [15:32:29] I think that J2 and K2 should be set to a constant 30 NM apolune height, does that sound rightÉ [15:32:35] ?* [15:42:21] morning! [15:43:46] hmm [15:43:51] not sure it really matters [15:44:13] it just shouldn't switch to the second segment [15:44:22] you wouldn't do a P70/P71 abort that late anyway [15:44:27] hey Mike [15:45:45] it might be better to wait a bit before requesting stuff from UHCL [15:46:41] I tried to get a ~300 page document a couple of weeks ago and they came back with "sorry, we don't have the staff resources to digitize that" [15:47:04] hmm ok [15:49:24] AlexB_88, how does the PDAP even react to the Apollo 12 PDI-2? [15:49:30] does it calculate a second segment like normal [15:51:09] I mean you could set K2 to zero and J2 to the equivalent of 30 NM altitude I guess [15:53:55] yeah thats what I am trying to do [15:54:35] J2 is a semi major axis height? [15:55:24] radius [15:55:40] but yeah I think the PDAP calculates a second segment (with the phasing maneuver) so that should be nulled [15:55:43] right [15:56:02] boost* [15:57:40] I guess the only case where the second segment could ever be used is if you use P70/P71 past the T1 time [15:58:08] might make sense to have a safeguard against that [15:58:38] right [15:59:43] I am just having trouble figuring out what the proper J2 value is for 30 NM apolune :D [16:00:38] landing site radius plus 30 NM :D [16:00:47] I can calculate it for you [16:00:55] hmm [16:01:41] I thought that was it but it seemed to put me in a 50 NM apolune when I tested it [16:02:21] 30.0 + 937.1632784 [16:02:35] then convert to feet right? [16:02:48] AGC units are meters [16:03:46] where is that radius value from? I've got a slightly different value using the RLS from the padload [16:04:04] 1969-11-14.init [16:04:33] ah fun, always small differences in the RLS :D [16:04:39] I got 1791278.7 meters [16:04:55] good enough :D [16:05:10] I got a RLS radius of 937.21 NM [16:05:13] so not too different [16:09:43] I really need to add the custom erasable memory uplink stuff to the RTCC [16:10:02] for EMPs and any non-standard uplink type [16:10:05] like abort constants [16:10:16] and the manual editing capabilities of it [16:10:42] they could even input engineering units and it converted it to octal [16:11:22] actually, I feel like I am remembering hearing on the MOCR audio that they were using this feature to conversion to octal, even if they didn't want to uplink anything [16:11:30] to convert* [16:11:52] just the most convenient tool, let the big computer do it :D [16:15:57] ah nice [16:17:34] hmm [16:19:00] still putting me in a near 50 NM apolune using 1791278.7 meters in J1 and K1 to zero (just testing with the 1st segment for fun) [16:19:23] I am just trying to wrap my head around what the J value actually is [16:20:42] oh wait [16:20:46] I am dumb [16:20:48] semi major axis [16:20:51] orbit is not circular [16:20:53] sorry :D [16:21:20] insertion altitude is about 10 NM [16:21:28] so a semi major axis of 30 NM gets you a 50 NM apolune [16:24:23] 1772642.7 [16:24:49] is what you want [16:25:11] average radius of 60k feet (perilune) and 30 NM (apolune) altitudes [16:28:46] ah ok [16:36:55] feel free to start messing around in my RTCCCoordinateSystem branch btw [16:37:05] anything and everything needs to be tested [16:41:43] sure Ill give it a go once I get back home [16:42:58] btw the pad-loaded (and uplinked) J1 and J2 values, do they represent the start of the segment? [16:44:07] and K2 adds the difference depending on the traveled angle? [16:44:26] K1/K2* [16:48:07] SMA = J + K*PhaseAngle [16:48:24] so the J values would be semi major axis you get at zero phase angle [16:48:28] and K is a slope [16:48:31] of this linear function [16:49:11] ah zero phase angle [16:51:26] zero phase angle is probably not a realistic case though [16:51:41] so it's really just a linear function, with a slope and a constant term [16:52:46] right makes sense [16:53:32] oh actually [16:53:38] you do get zero phase angle [16:54:12] at like PDI1+6 [16:54:29] yeah [16:54:49] on PDI-2 for Apollo 17 you definetly wouldn't I think [16:55:23] the switchover angle is ~-17/-18 degrees [16:56:26] as is PDI-1 for 13-15 [17:07:31] anyways thanks for the help, im off to work. cya! [17:17:42] Ron is adding a bunch of RTCC documents to the library it seems [17:17:55] all of them from the archived NTRS I think [17:47:12] oh nice [18:05:31] Voteins in discord is the one sending them in. he sent Ron a couple hundred docs so they're going to be trickling in for a while haha [18:07:16] at least I can point people to there now instead of having to search for the archive.org link or make them search through the restricted NTRS list [18:07:45] heheh [18:09:13] and I'll be looking through the new documents list, always possible one slipped through during my searches [18:13:39] so in Corona news, I finished naming things in MIDCOURSE INITIALIZATIN yesterday and am making good progress in the game [18:14:33] like Sunrise it has a hardcoded initial orbit (at a much more reasonable altitude) and the initial N72 and N73 inputs let you modify the initial orbit if you want to [18:15:09] whatever you put in just get added to RRECT/RCV and VRECT/VCV [18:15:28] ooooh interesting [18:16:04] so that's what that does, not incorporating a measurement [18:16:22] yep [18:16:25] more like, you can send yourself on a post TLI trajectory [18:16:28] at least when starting up haha [18:16:39] and it's a circular orbit again? [18:16:58] it looked very circular to me at ~190km [18:17:35] ah nice, standard parking orbit [18:17:38] 100 NM [18:17:53] https://github.com/thewonderidiot/virtualagc/blob/Corona261/Corona261/MIDCOURSE_NAVIGATION_GAME.agc#L1017 [18:18:04] same scale factors as Sunrise [18:28:31] I guess U24,7361 continues to be interesting [18:28:44] don't seem like unit vectors [18:29:16] scaling wise, if I use the same as the state vector position, I would get 6372.69 km [18:29:23] I thought for sure they were going to be unit vectors [18:29:40] hmmmm [18:30:57] don't think it's a normal Earth fixed position vector though [18:35:14] hmm [18:35:22] the vectors do have the exact same length [18:35:49] so maybe they are unit vectors with some factor already applied or something [19:01:26] okay, now to fix the other branch(es) [19:06:57] I'll merge your branch too, I guess [19:07:01] should be good [20:45:51] night! [15:08:12] hey [15:18:41] hey Niklas [15:30:42] definitely still finding things to repair with the coordinate system. But for the most part now e.g. MPT only displays [15:34:43] when I think everything works I will fly some mission with the MCC and if that all works then I am happy [15:34:51] nice [15:34:56] there will still be bugs for sure [15:35:08] but hopefully not too often, not too major [15:35:41] i think I'm going to take the time to go through al the LM pipes and make sure they're right. [15:37:00] nothing looks broken, but the whole point of this feature was to aid in improving stability...I probably shouldn't break existing stability in the process [15:37:26] sounds reasonable. But damn, you never seem to get lucky and just have a small, mergable pull request that doesn't take long [15:39:04] I'd merge it as it is. But it makes sense to check some things beforehand. [15:56:32] my motto is "move slow and try not to break too much" [15:57:48] also, in case you were wondering, our LM has 74 pipes :) [15:59:05] just have to compare in and out valve sizes 74 times :D [16:01:13] my motto right now is "change extremely fundamental things, move slow, and you will break things anyway" [16:02:20] thankfully, in most cases the in and out are the same size. [16:02:22] haha [16:12:03] morning! [16:57:24] hey Mike [17:06:53] what's up? [17:10:04] opening every page of the RTCC MFD to see what else could still be broken [17:15:08] hehehe [17:42:55] hey [18:23:31] hi Alex, hi Mike [18:58:53] I *think* have a build of Corona where midcourse navigation game is functional, and can be interact with via its intended V37 interface [18:59:04] it may or may not break everything else :D [18:59:13] depends on how sensitive things are to PHASCHNG modifying MPAC [18:59:26] haha nice [18:59:50] also need to make sure that master control didn't do anything weird when changing the phase of a running program [19:00:03] oh you added quite a lot of comments [19:00:06] that is helpful [19:00:12] and changed a lot of names! [19:00:26] including in latitude-longitude subroutines and b-vector routine [19:01:06] making steady progress on figuring the functional side of it [19:01:13] but still will need lots of help on the math side :D [19:04:48] would have been nice if U24,7361 was simple Earth fixed landmarks [19:04:53] the scaling works out [19:04:57] but the locations now [19:04:59] not* [19:05:16] hmm [19:05:22] where are the locations? [19:06:25] I had checked the first one, middle of nowhere in China [19:06:31] maybe it's not a true longitude [19:06:39] the latitude was kind of nice, could be US [19:07:43] hmm, speaking of longitude [19:08:02] this code is very interesting to me at the moment: https://github.com/thewonderidiot/virtualagc/blob/Corona261/Corona261/MIDCOURSE_NAVIGATION_GAME.agc#L106 [19:08:41] asks you to load TDEC, then multiplies it by U24,6115 and stores it in a location potentially named "LONGDES", then calls U31,6000 (possibly "LAT-LONG", in latitude-longitude subroutines) [19:09:31] U24,6115 is probably Earth rotational rate then [19:10:24] hmmm right, and because TDEC is in weeks, it probably has weird units [19:10:53] ouch weeks :D [19:12:22] would work out to kind of nice units [19:12:27] 1 rev per day [19:18:55] hmm [19:19:00] it's 0.4666666... without scaling [19:24:53] which is 7/15 [19:25:13] which... I don't entirely understand yet [20:50:01] night! [15:53:45] hey [15:54:53] hey Alex [16:10:13] hey guys [16:17:53] hello hello [16:18:08] starting to fly Apollo 11 to test the MCC with the coordinate system change [16:21:52] already seeing things I want to change with the MCC [16:21:59] but I am not giving in to feature creep [16:26:50] and I am saving new scenarios [16:37:15] ah nice [16:46:47] morning! [17:09:11] hey Mike [17:15:51] I'm thinking about trying to automatically generate flowcharts for midcourse navigation game [17:16:06] I'm getting lost in the tangly maze and manually creating them would be a lot of work [17:17:42] ah yeah, I had a thought like that as well when we were looking at Sunrise [17:18:04] Interpreter only? [17:18:24] nah, I'm going to try to make it cover both [17:19:01] it's the basic code in MIDCOURSE_NAVIGATION_GAME itself that I'm getting lost in [17:19:06] at least with the interpreter you would need to start the automatic generation before it TCs to INTPRET [17:19:10] ah ok [17:19:14] so not really the math part [17:19:29] knowing what the math part does would help haha [17:19:50] but yeah. it's the 8 different phases, and ~13 different flags in FFFLAGS that control the flow [17:19:52] I wish I had a better handle to scaling [17:19:56] and not knowing what those flags are [17:19:58] in Corona and in general [17:20:04] handle on* [17:20:39] the other thing I want to do is add interpreter debug support to yaAGCb1. so I can breakpoint on interpretive instructions and display the contents of the pushdown list and index registers [17:20:56] oh that would be a game changer [17:26:39] https://github.com/thewonderidiot/virtualagc/blob/Corona261/Corona261/LATITUDE-LONGITUDE_SUBROUTINES.agc#LL291C1-L301C7 [17:27:01] these are just little mini-temporary-rectification subroutines right? essentially "get current position" and "get current velocity" [17:36:51] yeah probably [17:36:58] something you have to do with Encke's method [17:37:17] you are numerically integrating only the deviations from conic [17:37:32] but you still need the total position/velocity to calculate gravity and such [17:37:48] so you always have to be careful what you are adding together there :D [17:40:20] hahaha right [17:40:48] these two little functions are used in the function right above them, U31,6272 [17:42:10] which does position into ALPHAV, velocity into BETAV, and then some math..... that I think is calculating an azimuth? it's definitely calculating an angle and Solarium has an unused variable named AZ at that location [17:45:20] yeah that math looks interesting [17:48:06] definitely azimuth it calculates there [17:49:13] because I'm quite uniformed with this stuff -- what does "azimuth" mean exactly here? [17:49:27] is it sort of like inclination? [17:49:43] exact same thing as heading [17:49:48] 90° being east [17:50:06] ah, interesting, okay [17:50:52] it calculates two vectors there from the state vector RCV and VCV [17:51:08] and then takes the angle between them with acos(dot(V1, V2)) [17:51:21] and that's the azimuth [17:51:36] referenced from north because it uses UNITZ [17:51:52] gotcha gotcha [17:52:00] the extra cross products with ALPHAV were confusing me [17:52:51] yeah just has to build those two vectors, local north pointing vector and local flight direction vector [17:53:18] makes sense :D [17:53:49] so phase 15 of MNG uses these subroutines to calculate latitude, longitude, and azimuth, and puts them up as an N22 display https://github.com/thewonderidiot/virtualagc/blob/Corona261/Corona261/MIDCOURSE_NAVIGATION_GAME.agc#L720 [17:55:21] hmmm [17:55:55] so purely a display value? [17:56:11] potentially [17:56:16] not used in any calculation. Was alreading starting to check P23 equations if azimuth is needed there anywhere [17:56:19] don't think it does [17:56:42] it needs to do some similar calculations to determine where above the Earth ellipsoid the CSM is [17:57:02] to calculate the actual radius of the Earth at the place where any star/horizon measurements were done [17:57:15] but definitely doesn't need the azimuth like this [17:58:03] yeah as far as I can tell it is display-only [17:58:52] B VECTOR ROUTINE is still scary to me. I feel like I at least have a handle on all of the other sections haha [17:59:05] I think that's where most of the P23-like math is happening [17:59:44] yeah [18:01:23] you know I haven't seen anything yet that really points to it being P23 [18:01:34] maybe it's P22 instead [18:01:51] where are the star vectors? [18:02:25] U24,7361 are probably landmarks, which could be either [18:03:10] I don't think there is anything other than U24,7361 [18:03:32] the only other big blocks of data are the hardcoded initial W-matrix and REFSMMAT [18:04:01] so, what are the valid inputs for SITENUMB? [18:04:41] oh man I have absolutely no idea [18:04:49] SITENUMB is a complete mystery to me right now [18:05:10] it kind of looks like a bitfield, where you set different bits to mean different things [18:05:34] SITENUMB is another motivator for the flowchart generator haha [18:28:33] I just sent an email out to the apollonauts mailing list asking if anybody remembers midcourse navigation game haha [18:29:05] hopefully somebody does -- just about any information would be helpful [18:31:54] yeah we really have nothing [18:32:51] indy91, I have a question for you about AGS 662 in FP8 (4K10) [18:34:15] that's equivalent to J1PARM [18:34:19] and 673 (retarget for 4K10) [18:34:55] hmm I thought it was K1 & 2 [18:35:49] ah maybe [18:35:55] manual calls it constant [18:36:05] so I thought it was the constant term as opposed to the slope [18:37:19] I used the Apollo 17 values of -605981.87 ft/rad and -318029.5 ft/rad in the equation to get the octals for 662/673 [18:37:22] yeah I think you are right [18:37:58] 2^-20 then converted to AGS [18:39:25] why do we need octals? [18:39:29] for the padload? [18:39:30] the 2 values it gives are: 554035 and 662266 [18:39:40] thats what 662 and 673 takes [18:39:46] octals [18:40:51] Im just curious why only one of the resulting octals are close to the Apollo 17 LM datacard book vales [18:41:30] A17 data card book: 662: -33007 673: -54456 [18:41:55] and I got -554035 and -662266 [18:42:01] 1st one is close [18:42:22] I almost think the 2nd one is also correct IF you devide it by 2 [18:49:03] I don't really understand the issue. The RTCC MFD does the conversion for you? [18:49:16] I guess it doesn't currently show the second segment for AGS [18:49:36] the conversion should be added to the PDAP itself [18:49:46] no Im just trying to calculate them with the FP8 padload worksheet [18:49:52] pretty sure the RTACF display for the PDAP showed both octal and engineering values [18:50:36] what I did for Apollo 17 MCC was read res.K2 [18:50:59] like DEDA227 reads res.K1 I think [18:51:33] yeah [18:51:48] my issue is that only one of the resulting octals makes sense [18:52:56] the Apollo 17 K2 value of -318029.5 ft/rad gives -662266 when converted to octals [18:53:22] but looking at the Apollo 17 datacard book this seems to be -33007 [18:53:39] its funny its like if its just divided by 2 [19:05:44] indy91, passing along a response from Hugh Blair-Smith to my email: [19:05:50] > I personally had nothing to do with the MNG, or with P22/3 for that matter, so I can't help you with your questions. I just wanted to congratulate you and Niklas on your stellar reverse engineering, and on raising the status of the Block I HW/SW in your historical structure. [19:05:51] :) [19:07:04] :) [19:07:22] AlexB_88, I have no real answer, but one idea could be rad vs rev [19:07:26] 1 rev = 2 rad [19:07:38] maybe the AGS needs ft/rev and not ft/rad [19:07:45] ah [19:10:09] manual explicitely says rad though [19:10:29] ohh [19:11:43] as a quick test I tried the ft/rad values times 2 to get an aprx ft/rev [19:12:15] and now its giving me octals that almost match the datacard book ones perfectly! [19:15:10] hmm, but, for the first segment this didn't apply? [19:15:18] that can't be right [19:15:56] hmm [19:16:43] well using the 4K10 calculation in the padload worksheet: [19:17:22] Apollo 17 K1: -605981.87 gives 554034 [19:19:27] and with the same value doubled it gives 330071 [19:20:11] Apollo 17 K2: -318029.5 gives 662266 [19:20:40] same value doubled 544555 [19:21:21] Apollo 17 data card book: [19:21:56] K1 (662): -33007 [19:22:11] K2 (673): -54456 [19:22:34] so I guess the first segment was wrong as well before [19:23:48] the doubled values are suspiciously close to the datacard book [19:29:59] so it's double in both cases [19:30:02] not just K1 or K2 [19:30:12] yes I think [19:31:07] and the one that looked close before was actually the wrong K1 when it should have been K2 [19:31:36] *was actually K1 [19:32:34] Ill check the other missions padloaded ft/rad versus 662/673 loads [19:37:34] just tried Apollo 15 [19:38:13] using the padloaded ft/rad values doubled I recreated the pre-mission 662/673 values in the datacard book perfectly [19:38:20] oh you know what [19:38:25] we have some more AGS padloads [19:38:38] I recently realized that we have it in the LM Data Book amendmends haha [19:41:26] ah nice [19:41:29] Apollo 15 AGS padload [19:41:34] 4K10 = 663766 [19:42:29] hmm [19:42:34] thinking about it, that's not much of a revelation as you can just take the last few bits from this value to get the data card DEDA value :D [19:43:54] whats the 11J padload? (4K10 retargeted value) [19:47:01] I don;t get why they padloaded 4K10 = 663766 but the data card book has it at -54776 [19:51:36] isn't that just how negative numbers work in the AGS? [19:52:40] oh [19:53:01] I keep forgetting were talking padload and not what you see in the DEDA [19:54:06] yeah [19:54:13] you can tell by the additional digit :D [19:55:01] " you can just take the last few bits from this value to get the data card DEDA value" [19:55:07] what did you mean by that? [19:58:22] ah sorry [19:58:26] take the bit AWAY [19:58:29] bits* [19:58:52] I think that what the AGS does for the DEDA [19:59:03] just drops the last few bits [20:00:44] so for the purpose of converting the value to the DEDA format, whats the formula? (ie. how that 663766 gets to -54776) [20:02:00] -54776 being the pre-mission value on the Apollo 15 data card book (662) or 4K10 [20:07:11] the 663766 in octal is equal to -0.311376e6 ft/rad [20:07:26] the conversion involves inverting all the bits I think [20:09:59] wouldnt DoubleToDEDA take care of that? [20:10:13] it seems to not correclty convert them for some reason [20:11:15] possible I guess [20:14:08] well I guess its basically the same as DEC2AGS in the excel worksheets [20:14:18] and they both give the same values [20:14:25] so probably not wrong [20:14:51] padload-wise [20:16:00] but I think this issue is the way the RTCC MFD/MCC converts the res.K1/K2 values to the DEDA227 or 662/673 [20:16:04] OrbMech::DoubleToDEDA(res.DEDA227 / 0.3048*pow(2, -20), 14); [20:16:31] what basically happens is the value it gives is in the same format as the actual padload [20:16:46] with one digit less [20:17:03] but I think it doesnt fully convert it correctly in that function for DEDA entry [20:44:23] might be [20:45:17] I thought I would have checked it against actual checklist values, but maybe not [20:57:46] night!