[14:21:44] NASSP Logging has been started by n7275 [14:21:46] good morning! [16:04:22] hey [16:05:30] hey Niklas [16:09:53] DEDA keys in the VC [16:10:00] can you hear the click sound when you use them? [16:11:17] es [16:11:19] yes [16:12:14] clear seems to work for me [16:12:16] enter not so much [16:12:20] most of them work, its the enter and the readout [16:12:22] yeah [16:12:26] oh readout [16:13:17] I believe enter and readout need to be pressed for a certain amount of time to work, maybe the VC has an issue with that [16:14:33] hmm no [16:14:39] the operator error light comes on [16:14:46] that's a DEDA issue [16:15:01] something not going into the AEA when you press enter long enough is different [16:15:37] the AEA actually has nothing to do with the operator light [16:15:42] that's all the DEDA internal logic [16:19:11] right [16:22:41] just trying to figure out how any of the DEDA keys are currently working in the VC haha [16:24:05] I guess the registered callbacks work in the VC as well [16:25:07] or not [16:27:40] yeah that what I thought the issue may be [16:27:49] seems to work for the other keys [16:28:17] LEM_DEDA::zeroCallback is definitely called [16:33:30] I got it [16:34:00] thanks to a useful debug string I added [16:34:05] in PanelSwitchesVC::VCMouseEvent [16:34:22] inside of the if (id == SwitchArea[i]) [16:34:23] I added [16:34:27] sprintf(oapiDebugString(), "%s", SwitchList[i]->GetName()); [16:34:48] so it showed me the name of each button I press [16:35:05] when I press Readout it shows DedaSwitchHold [16:35:18] when I press Enter it shows DedaSwitchReadout [16:35:28] when I press Hold it shows DedaSwitchEnter [16:35:51] so I guess you must have mixed up the click area of those [16:36:42] oh [16:39:00] yep, just need to fix the clcik area [16:39:03] thanks! [16:39:55] no problem [16:40:28] I knew something was happening when I pressed those buttons, just not the right thing, so I just checked what those click areas actually did haha [16:40:48] and the callback functions work exactly the same for the VC, so no issue there [16:41:13] all those register calls in LEM::InitSwitches are universal [16:41:19] yeah, I was going crazy last night trying to figure out and I just couldnt...and I kept telling myself it must something so simple taht I am not seeing haha [16:42:29] the Apollo solution to this problem is sticking pieces of paper above each button which say what they actually do :D [16:42:48] morning! [16:43:13] hey Mike [16:43:30] AlexB_88, now it's your turn to find my issues lol [16:44:09] but I wouldn't ask you to restart your PC 100 times to find that SM panel disappearance bug lol [16:44:44] right that is a weird one [16:46:28] btw I have a PR waiting to be merged, but maybe you can hold off ill get the DEDA button fix in it as well [16:46:36] sure [16:58:23] and fixed [16:58:53] I had just messed up the order of the last 3 entries for the DEDA MainPanelVC.AddSwitch entries [17:02:08] indy91, PR amended [17:02:17] yeah, probably easy to make with all those numbers for so many buttons [17:03:09] yeah [17:03:24] and merged [17:03:46] I have added comments for some of them so I can easily see what button it corresponds to, but I have been lazy and have not done them all yet [17:03:56] thanks [17:04:00] I guess we still need to figure out that suit fan audio issue? [17:04:31] I tried setting my Orbiter Sound options to default but that didnt do anything [17:05:17] so when I uninstalled OS 4.0 I deleted all the original files from that installation [17:12:29] So I encountered a weird OS4 issue last night. [17:14:14] I pulled the new updates from orbiternassp/NASSP to my fork the night after they happened [17:15:16] the orbiter2016 branch built fine with OS5, no errors, and I was able to use it [17:18:12] when I tried to update my VHF-RNG-Connectors branch, although it merged the commits for the vsproject files to update to OS5, the files didn't appear to change and I got missing orbitersound4.lib errors [17:19:00] ah [17:19:12] the lib file is used in the Visual Studio project files [17:19:32] usually when those files change with something Git does it gives you a prompt [17:19:39] to reload the project files [17:19:51] in doubt restart Visual Studio [17:22:34] that makes sense. I probably just missed it. ended up making a new branch the updated orbiter2016 branch, and manually updating from the last commit in the vhf branch [17:22:47] whatever works haha [17:23:01] I don't know if it's that, but if the project files change there can be some strange behavior sometimes [17:23:24] AlexB_88, any chance the same thing happened to you? [17:24:50] the auto build isn't doing better (yet): http://cirno.lunar-tokyo.net/NASSP/show-build.php?br=Orbiter2016 [17:25:10] I had some orbitersound4.lib errors until Niklas made a fix for that a few days ago. [17:25:47] oh right, I almost forgot that. How could I, I spent more than half an hour editing project files :D [17:26:07] I would still get an occasional error with one of the project files (SIB I believe) that would fail 1 every 2 or 3 times I rebuilt [17:26:22] but for some reason that seems to be fixed now [17:26:36] yeah, something is weird with the s1b project I think [17:26:50] so I always get no errors now [17:27:03] but still that weirdness with the suit fan of course [17:27:15] its odd that I seem to be the only one that experiences that [17:28:32] if only I had my laptop with me I could try on it [17:28:55] maybe I will make a second Orbiter installation on my main PC and see if it occurs there [17:29:33] I wonder if a nice debug string can help with that as well [17:29:43] something that shows what is being played [17:29:47] with which volume etc [17:29:58] yeah [17:32:38] there is an "IsPlaying" function [17:32:55] something good to check [17:35:02] like [17:35:02] sprintf(oapiDebugString(), "%d", SuitFanSound.isPlaying()); [17:35:23] for me that is a 1 during fade in, stead state, fade out [17:35:34] so immediately when I switch the suit fan to 1 or 2 [17:35:44] and a few seconds after I switch it off it goes to 0 [17:36:38] ok [17:37:13] where did you put that debug string? [17:37:55] I guess I can put it in the systems timestep [17:38:17] anywhere in timestep would work, I put it where the SuitFanSound is played and stopped [17:38:26] ok [17:41:10] also, maybe try what happens with no volume input [17:41:11] so not [17:41:12] SuitFanSound.play(220); [17:41:13] but [17:41:15] SuitFanSound.play(); [17:41:36] it stays 1, even if I turn the suit fan off [17:41:49] I tried that already [17:42:12] uhh [17:42:15] always on??? [17:42:30] but it doesn't actually play? Or what was the issue again... [17:42:44] the sound stays constant [17:43:03] ah right [17:43:11] so that's consistent with the 1 [17:43:36] for example: if I have the suit fan sound playing already, then turn the suit fan off, there is no change in the sound, it just stays the same [17:43:54] doesnt fade out and doesnt stop [17:44:07] but for the glycol pumps it works fine [17:44:32] BUT [17:44:43] and that's only in the VC [17:45:23] if I repeatedly play with the view positions (Ctrl-Left, then Ctrl-Right over and over) it then slowly fades out [17:45:42] its very weird [17:46:19] like very hit of changing the views updates something and forwards the fade process but only a little bit, not all the way [17:46:57] so I have to hit Ctrl-Arrows over and over for the sound to completely fade out (and the 1 change to 0) [17:47:04] I have some more debugging code for you in a moment [17:47:41] in soundlib.h [17:47:49] in the class FadeInOutSound [17:47:52] add a public function [17:47:57] int GetVolume() { return currentVolume; } [17:48:13] and then where you have the debug string, change that to [17:48:15] sprintf(oapiDebugString(), "%d %d", SuitFanSound.isPlaying(), SuitFanSound.GetVolume()); [17:48:33] for me that starts at 220 volume and goes down [17:48:58] there could be an initialization problem [17:49:09] maybe currentVolume is -1 or 0 or something [17:49:16] doesn't mean that that's the actual volume [17:49:35] but that could break the fade in and out [17:50:35] ok [17:52:31] starts at 220 [17:52:42] oh and the issue is only in the VC [17:53:31] does to go down to 0 when you switch it off? [17:53:43] from the 2D panel [17:53:47] in the VC [17:54:41] it counts down but very slowly [17:55:06] interesting [17:55:10] it will take like 15 minutes to reach 0 [17:55:23] for me it was more like 15 seconds [17:55:27] ok... [17:55:32] but if I quickly move the VC views back and forth it jumps down quicker [17:55:34] it gets its timestep with [17:55:35] oapiGetSimStep [17:55:40] that shouldn't be broken [17:55:42] also, time acceleration makes it go down [17:57:42] and from 0 volume if you turn it up again? [17:57:47] what happens in that case [17:58:35] same thing, goes uo very slowly [17:58:38] up* [18:00:11] int GetFadeSlope() { return fadeSlope; } [18:00:20] and [18:00:21] sprintf(oapiDebugString(), "%d %d %d", SuitFanSound.isPlaying(), SuitFanSound.GetVolume(), SuitFanSound.GetFadeSlope()); [18:03:03] constant 51 for me [18:04:44] same [18:04:45] 51 [18:06:10] ooooh [18:06:15] what frame rate are you running? [18:06:38] unlimited? [18:07:15] try VSync [18:07:50] hmm, but is the VC frame rate really much better than the 2D one... [18:08:03] bingo [18:08:13] ok, the issue is this then: [18:08:18] dt = oapiGetSimStep(); [18:08:18] currentVolume -= int(round(double(fadeSlope) * dt)); [18:08:22] I had Vsync off, turning it on makes it work [18:08:28] high frame rate makes dt quite small [18:08:36] and that round then screws it up [18:08:43] right [18:08:45] so that currentVolume is hardly decremented [18:09:13] its weird though that the glycol pump sound didnt have the issue [18:09:22] uses the same function [18:09:40] quicker fade time [18:09:43] SuitFanSound.setFadeTime(5); [18:09:48] GlycolPumpSound.setFadeTime(3); [18:09:54] right [18:10:01] I guess that makes the difference for the rounding errors [18:11:05] the reason I had Vsync off is that it forces my fps to 50 [18:11:09] all the time [18:11:24] oh 50 [18:11:30] for me it's 60 [18:11:40] or 144 if I have the monitor running at that rate [18:11:45] what I did was Vsync off and then use an external limiter to limit to my monitor refresh rate (144 fps) [18:12:02] I have it running at 144 [18:12:11] I usually run 60 though, which is probably what most people have, I want to run NASSP close to the general user [18:12:40] lol [18:12:41] so your actual frame rate was 144 [18:12:52] and not unlimited? [18:13:03] I *dont* have my monitor at 144 actually [18:13:17] just checked and somehow it was set to 50 [18:13:37] well, if you don't have VSync on then Orbiter runs at full speed anyway [18:13:42] doesn't matter what is displayed [18:13:50] VSync in the Orbiter settings that is [18:14:21] yeah with vsync off and no fps limit I was pulling like 700 fps :D [18:14:39] my video card was actually humming lol [18:15:03] I know that sound from my 970 [18:15:49] hmm, I guess there are lots of functions which eventually run into numerical trouble with high frame rate [18:15:55] but this particular case is rather dumb [18:17:27] sound volume is an integer though, so it's not super easy to fix [18:18:20] I could make it round up [18:18:24] and not round [18:18:37] right [18:19:00] try it with ceil instead of round [18:19:35] ah I can try too of course, don't need to switch cables for the 144 Hz [18:19:43] I am setting my monitor back to 144 Hz and will leave Vsync on with no fps limiter set [18:19:44] I was switching around cable, HDMI can't do 144 Hz [18:19:50] cables* [18:19:53] but DVI can [18:19:55] weird [18:21:17] trying ceil [18:22:17] much better [18:22:30] guess what, at 500 fps I also get your issue :D [18:22:47] so what bad thing could ceil do... [18:22:59] your video card humming can replace the suit fan sound anyways :D [18:23:03] true [18:23:20] I guess ceil makes it so volume is decremented by at least 1 on every timestep [18:23:34] which is too quick probably [18:23:42] at least at 500 to 700 fps [18:23:53] it should take 5 seconds for it to reach 0 [18:24:48] yeah with ceil it's way too quick [18:25:56] better than it not working, but it's also messing with the normal case [18:26:04] right [18:27:32] I think I may just set an external fps limit of 60 [18:29:43] sure, but I think it still needs to be fixed [18:30:21] we can create an issue on Github and forget about it :D [18:31:59] sounds fair :D [18:34:01] lol, we have a label for issues on Github called "Orbiter's fault" [18:34:09] did you add that Thymo? [18:35:21] hahaha [18:39:12] indy91, ill try replicating the SM panel issue [18:39:14] https://github.com/orbiternassp/NASSP/issues/545 [18:39:28] AlexB_88, good luck getting it even once [18:39:47] so I guess a PC restart is the 1st step [18:40:03] probably yeah [18:40:11] And then maybe use the Apollo 11 T-30s scenario [18:40:21] I'm never quite sure if the pane is missing immediately [18:40:28] or only after one of the stagings [18:40:38] because that reshuffles all the meshes [18:40:43] right [18:40:54] usually when I am getting it I didn't think about that bug [18:40:58] so I didn't look [18:42:26] rebuilds might also have a role, but not sure in what way. I can't replicate by just rebuilding [18:44:46] so I don't know much [18:46:57] rebooting, brb [18:47:18] I really should make a screenshot of it [18:47:25] like an UFO sighting [18:47:28] about as rare, too [18:47:29] well [18:47:36] not quite as rare or it wouldn't annoy me [18:59:04] so just from memory and some testing [18:59:08] if (!ApolloExploded) [18:59:08] AddMesh (hSMPanel4, &mesh_dir); [18:59:09] else [18:59:09] AddMesh (hSMCRYO, &mesh_dir); [18:59:27] normally SMPanel4 is loaded [18:59:38] and with the bug it looks like neither mesh is loaded [18:59:39] 3 restarts, no missing panels [18:59:41] so just empty [18:59:53] so the panel that exploded on Apollo 13 [19:00:00] not the SIM bay panel as I might have said [19:00:27] but I'm not 100% sure it looks exactly like just that mesh missing [19:00:37] I'll make a nice screenshot of it when I get it the next time [19:00:51] and until then we can just forget about it :D [19:00:55] thanks for trying though [19:01:09] no worries, Ill keep an eye open for it [19:01:22] if it's more than just that one mesh missing that could give us clues [19:02:16] we have a fair amount of SetMeshVisibilityMode calls [19:02:22] it could be a buggy one [19:02:34] that actually means to make another mesh invisible [19:03:48] back to the LVDC then [19:05:23] I think I will fly Apollo 15 now [19:05:39] give all the VC work a test [19:09:38] yeah the VC is quite functional now [19:31:15] whats G00 button on the REFSMMAT page [19:31:29] CSM/LEM REFSMMAT Locker Movement [19:32:26] locker must be a 60s terms for array haha [19:32:42] the RTCC can store multiple REFSMMATs at once, for both CSM and LM [19:33:07] the current REFSMMAT is generally used in calculations [19:33:56] there is for example G03, which saves a LVLH REFSMMAT [19:34:07] short "LCV" [19:34:14] CUR is current [19:34:32] so if you want to make the LVLH REFSMMAT you just calculated the current REFSMMAT you need to copy it over [19:34:36] so LCV to CUR [19:34:41] and that is done with G00 [19:34:56] moving a REFSMMAT from one save "slot" to another [19:35:05] works across vehicles, too [19:35:16] G00,CSM,LCV,LEM,CUR; [19:35:20] ah ok [19:35:32] makes the LCV REFSMMAT saved for the CSM the LM current REFSMMAT [19:35:41] is there a description of each code? [19:36:17] yeah in multiple places [19:36:21] do you have 19730062602? [19:36:36] ah sorry [19:36:38] 19730062603 [19:36:59] yes [19:37:20] oh and you get feedback for it on the On Line Monitor [19:37:25] you'll see [19:37:58] page 899 [19:38:06] to 901 [19:38:25] thanks [19:38:54] a list of codes without explanation is also in the MED description [19:39:13] HSI-209462 [19:39:16] page 406 [19:39:22] that is for Apollo 11 [19:39:39] the previous document is a bit older [19:39:43] if I want to download the REFSMMAT from the CMC/LGC, what code would that be? [19:40:03] I think there still is a button for it on the REFSMMAT page I think [19:40:17] would be stored in TLM, telemetry [19:40:22] ah ok [19:40:24] but I'm not sure if that's how I implemented it [19:40:52] so I hit the button to download then G00,CSM,TLM,CSM,CUR; I guess [19:41:15] yes, but in the code for the downlink button I currently have [19:41:19] GeneralMEDRequest("G00,CSM,TLM,CSM,CUR;"); [19:41:34] so right now that button stores it in both CUR and TLM [19:42:02] probably wanted to keep it that way until I wrote a better manual [19:42:11] that says you have to move it to CUR by yourself [19:43:04] ok [19:43:36] so pressing that buttons adds lots of lines to the online monitor [19:43:38] and on the DMT page I always have to select the REFSMMAT now I guess (CUR) [19:43:52] you can add it, but it has a default [19:43:56] if you leave it open [19:45:24] yeah it defaults to CUR [19:45:46] so U20,CSM,1; is the shortest valid U20 code [19:46:01] uses defaults MSK 54, CUR as REFSMMAT [19:46:49] but having a bunch of REFSMMAT available lets you try out different things [19:47:10] you want to keep the actual current REFSMMAT as CUR in the RTCC [19:47:32] you can store REFSMMATs for maneuvers in the future [19:50:42] for Apollo 11 for example, they calculated the PTC REFSMMAT (in some way, not 100% sure how) before the mission [19:50:53] temporarily stored it in the MED REFSMMAT slot [19:51:08] (where you can also manually enter REFSMMATs) [19:51:14] hmm I tried downlinking the REFSMMAT from my CMC, then use it with a simple maneuver displayed on the DMT but the MY showed nan [19:51:23] and so had it available before launch and could then quickly move it to CUR at the right time [19:51:39] check the online monitor [19:51:43] does it have good numbers? [19:53:19] oh, and the GOST has a REFSMMAT display tool [19:53:54] although I have to relearn myself how to use that [19:55:27] in doubt I implemented it to spec [19:56:40] I think I unscrewed the build resource package. [19:56:48] yay [19:57:03] I thought I messed up something related to permissions but it was stupid. [19:57:19] OS5 added two sln files as examples and it confused appveyor [19:57:28] so I was barking up the completely wrong tree (as is usual) [19:57:44] It's doing its thing now. [19:58:16] indy91, So my test was from a MCC-1 scenario on Apollo 16, I used a fresh MFD and activated/initialized the MPT and downlinked my CMC RESFMMAT. I then calculated MCC-1 and put on the MPT then opened it on the DMT. MY shows -nan(ind) [19:58:17] MED P80,1,CSM,4,16,1972; [19:58:18] MED P80 OK [19:58:19] MED P10,CSM,17:54:00; [19:58:19] MED P10 OK [19:58:20] MED P12,CSM,17:54:00,72.0; [19:58:22] NEW IMU MATRIX CUR001 CSM [19:58:24] GET = 000:00:00 [19:58:26] -0.6455088 +0.7628591 -0.0369370 [19:58:28] +0.2139425 +0.1341820 -0.9675866 [19:58:30] -0.7331759 -0.6324881 -0.2498236 [19:58:32] MED P12 OK [19:58:34] MED P10,CSM,17:54:0.370000; [19:58:36] MED P10 OK [19:58:38] CSM EPHEMERIS UPDATE COMPLETED [19:58:40] RMMASCND CONVERGENCE LIMIT [19:58:42] NEW IMU MATRIX TLM001 CSM [19:58:44] GET = 011:59:11 [19:58:48] +0.1339673 +0.8710259 +0.5040886 [19:58:51] +0.7293605 -0.7836498 +0.8368011 [19:58:52] -1.6126493 +0.0823997 -0.0642283 [19:58:54] MED G00,CSM,TLM,CSM,CUR; [19:58:56] NEW IMU MATRIX PCR001 CSM [19:58:58] GET = 011:59:11 [19:59:00] -0.6455088 +0.7628591 -0.0369370 [19:59:02] +0.2139425 +0.1341820 -0.9675866 [19:59:04] -0.7331759 -0.6324881 -0.2498236 [19:59:06] NEW IMU MATRIX CUR002 CSM [19:59:08] GET = 011:59:11 [19:59:10] +0.1339673 +0.8710259 +0.5040886 [19:59:12] +0.7293605 -0.7836498 +0.8368011 [19:59:14] -1.6126493 +0.0823997 -0.0642283 [19:59:18] MED G00 OK [19:59:21] CSM EPHEMERIS UPDATE COMPLETED [19:59:23] MED U20,CSM,1,54,,; [19:59:25] MED U20 OK [19:59:33] ouch [19:59:35] :D [19:59:52] that looks good though [19:59:54] it has numbers [19:59:58] that is what should count [20:00:46] what kind of maneuver did you add to the MPT? [20:01:17] oh sorry [20:01:20] TLMCC opt 4 [20:01:20] didn't read that far up [20:01:35] you sure that maneuver was added to the MPT? [20:01:49] I feel like something about that should be in this RTCC log [20:02:10] on the other hand, something should complain if you try calculating the DMT for a maneuver that doesn't exist [20:02:11] yep CCSX01MCC [20:03:23] can you just try [20:03:25] MED U20,CSM,1; [20:03:29] U20,CSM,1; [20:03:56] those additional , might be doing something bad if nothing is entered [20:04:04] it shouldn't, but there could be bugs [20:04:46] MED U20,CSM,1; [20:04:46] MED U20 OK [20:04:50] byt MY is still bad [20:04:55] but* [20:04:56] hmm ok [20:05:17] its supposed to be the PTC REFSMMAT [20:05:48] if I go to the PTC REFSMMAT page, hit calculate, then come back and do U20 again then it looks good [20:06:03] so just the downlinked one is bad [20:06:21] uhhhh [20:06:23] It passed. [20:06:34] third row of your telemetry matrix [20:06:35] -1.6126493 +0.0823997 -0.0642283 [20:06:40] that should be normalized :D [20:06:50] so no value more than 1 [20:06:54] Suzuran, that's great! [20:06:58] nice [20:07:01] https://cirno.lunar-tokyo.net/NASSP/show-build.php?br=Orbiter2016 no messages [20:07:43] AlexB_88, are you running something in debug mode? I had this issue when the RTCC MFD and Saturn were not in the same build mode [20:07:47] Suzuran, the last post from NASSP BuildBot on the forums was Aug 12, 2020 [20:08:04] AlexB_88: Yeah, I'm locked out of its account, the forum upgrade probably broke it. [20:08:20] It's probably been detected as a bot (which it is) and banned. [20:08:37] indy91, VS build was in Release mode [20:08:40] It's not even a very smart bot, spam bots are far better. [20:09:12] AlexB_88, other theory, I got the REFSMMAT address wrong. That is a RTCC system parameter, maybe I did a goof with that [20:09:25] Suzuran, ah right the forum change [20:09:28] when I changed it to be a system parameter [20:10:17] hmm no, should be EMEM1733 [20:10:50] The way buildbot worked before was basically an auth replay attack so as the forum security gets better it's going to get harder to maintain. Remember, if buildbot can post, so can spammers. [20:11:03] If buildbot can find a way, so can China and Russia. [20:11:21] And they get paid very well to find ways. [20:11:40] luckily only flat earthers would have something against Orbiter [20:12:31] Forum spam is almost totally automated now, humans only set up the ad campaigns. All the finding and exploiting of vulnerabilities is entirely automated. [20:12:48] Same of most bulk messaging applications. [20:13:15] Spamming is a multibillion dollar a year industry. [20:13:35] It's almost as lucrative as drugs. [20:15:08] Anyway, I'll PM a mod about it, I need to get back to work [20:19:32] I'd hope spam is lucrative with so many spam emails being sent [20:19:38] AlexB_88, I think it's something really dumb [20:19:52] 1733 is an octal address [20:20:09] our uplinks use that directly, like a DSKY input [20:20:20] in C++ if you want that as octal you would have to use 01733 [20:20:33] ah [20:20:40] the RTCC system parameters I created is just 1733 [20:20:54] so when I changed it to use that for the "downlink" address I broke it [20:22:15] annoying mixture of decimal and octal [20:22:38] I guess it kind of makes sense, uplinks are strings, so you want 1733 in there not the octal equivalent of the decimal 1733 [20:23:19] is that MCCCRF? [20:24:01] yeah [20:24:23] so I need to implement some dumb code converting that to 01733 [20:29:41] might be easier to have the system parameter as 01733 and change the other code using it [20:31:05] hmm [21:00:19] there are lots of solutions, all of them stupid [21:02:11] haha [21:05:30] so I guess a question of picking the least dumb [21:05:55] yep [21:06:05] I'll do either [21:06:16] having two variables, one containing 1733 and one 01733 [21:06:29] or converting from octal to decimal each time the button is pressed [21:06:43] so converting 1733 to 987 [21:35:05] I'm doing the first option [21:38:33] AlexB_88, update pushed if you want to try it [21:39:02] sure [21:40:47] Ill try the same test [21:41:31] does the manual you referenced here have info about the GOST? [21:43:32] 19730062603, starting on page 906 [21:43:49] MED code is G10, so you can find that in the other document [21:44:44] ok [21:44:50] looks like it works [21:44:51] MED P80,1,CSM,4,16,1972; [21:44:52] MED P80 OK [21:44:52] MED P10,CSM,17:54:00; [21:44:53] MED P10 OK [21:44:53] MED P12,CSM,17:54:00,72.0; [21:44:54] NEW IMU MATRIX CUR001 CSM [21:44:55] GET = 000:00:00 [21:44:57] -0.6455088 +0.7628591 -0.0369370 [21:44:59] +0.2139425 +0.1341820 -0.9675866 [21:45:02] -0.7331759 -0.6324881 -0.2498236 [21:45:04] MED P12 OK [21:45:06] MED P10,CSM,17:54:0.370000; [21:45:07] MED P10 OK [21:45:10] CSM EPHEMERIS UPDATE COMPLETED [21:45:12] RMMASCND CONVERGENCE LIMIT [21:45:14] NEW IMU MATRIX TLM001 CSM [21:45:18] GET = 011:30:14 [21:45:20] -0.3356020 -0.9420039 +0.0000000 [21:45:22] -0.9420039 +0.3356020 -0.0000000 [21:45:24] +0.0000000 -0.0000000 -1.0000000 [21:45:26] MED G00,CSM,TLM,CSM,CUR; [21:45:28] NEW IMU MATRIX PCR001 CSM [21:45:30] GET = 011:30:14 [21:45:31] -0.6455088 +0.7628591 -0.0369370 [21:45:34] +0.2139425 +0.1341820 -0.9675866 [21:45:36] -0.7331759 -0.6324881 -0.2498236 [21:45:38] NEW IMU MATRIX CUR002 CSM [21:45:40] GET = 011:30:14 [21:45:42] -0.3356020 -0.9420039 +0.0000000 [21:45:44] -0.9420039 +0.3356020 -0.0000000 [21:45:45] +0.0000000 -0.0000000 -1.0000000 [21:45:49] MED G00 OK [21:45:51] CSM EPHEMERIS UPDATE COMPLETED [21:45:53] MED U20,CSM,1; [21:45:55] MED U20 OK [21:46:00] the first many lines of that are done automatically each time [21:46:13] CUR001 is always the launch REFSMMAT [21:46:26] oh and CUR002, what does the number meanÉ [21:46:31] ?* [21:46:36] just counting up [21:46:48] so that if you change the CUR matrix, that you know it's different from the one before [21:47:09] you might have a display open that still shows something relative to CUR001 [21:47:15] even if you already have a CUR002 [21:47:21] just helps keeping track [21:47:47] it automatically generates the CUR001 [21:48:01] the first time you downlink a matrix it saves that in TLM001 [21:48:10] and also in CUR currently [21:48:14] so that creates CUR002 [21:48:23] I guess you can go back to a previous one? [21:48:27] and if the current matrix is updated, it automatically saves a previous current [21:48:38] you can't go back to CUR001, no [21:48:47] but you can go back to PCR001 [21:49:05] I'm sure all the old REFSMMATs were printed out in some way [21:49:16] but in the computer it only keeps one previous current, the PCR one [21:49:42] so I guess the downlink button currently saves 3 REFSMMATs [21:49:56] TLM as it should, CUR right now, and PCR right now because CUR was updated [21:50:50] if I say calculate a PTC or Entry REFSMMAT does it always save in a specific code? [21:51:03] hmm, might not be fully implemented yet [21:51:11] most places will just save in CUR [21:51:15] ah ok [21:51:33] in doubt, check the online monitor [21:51:43] and it will say what it just did [21:51:57] once I have the REFSMMAT I want in CUR, I can use the GOST for the sextant angles [21:52:03] yep [21:52:10] you can also let the GOST display any of your matrizes [21:52:31] e.g. the GUIDO did that before launch just to see what was in the computer [21:52:55] in G10 that is the matrix 3. "MTX3 - DISPLAY ONLY" [21:53:10] so you might have to use 5x , lol [21:53:21] is there an example of the workflow to put in the data to the GOST? [21:53:22] G10,CSM,,,,,CUR; [21:53:26] hmm [21:53:39] I first have to check how I implemented it, it's been a bit [21:54:21] features I remember liking is that you can input landmark data (lat, lng, alt) and it gives you a point vector for e.g. P52 [21:54:33] or that it has a star catalog larger than the AGC [21:54:57] the ATT button is for the attitude of your burn [21:55:23] you want to calculate e.g. a sextant star check? [21:56:11] yeah you enter the attitude for the burn [21:56:16] probably as the first data set [21:56:17] yeah for the P30 pad [21:56:28] two attitudes are for other options of the GOST [21:56:29] and boresight star I guess [21:56:36] yeah [21:57:14] well, what you enter there is where in the catalog it should start searching for a suitable star [21:57:29] mainly useful if you don't like the choice of the GOST [21:58:22] probably should use 1 for the star if you are ok with any star [21:58:41] his is still the ATT button we are talking? [21:58:45] this* [21:58:57] no [21:59:11] ok, let me first figure out myself how far I even got with the GOST :D [21:59:26] sounds good :D [22:01:02] ok, seems easy enough [22:01:11] no MED type of input involved [22:01:16] you just enter your attitude [22:01:27] as data set 1 [22:01:44] so just a "1 Pitch Yaw Roll" [22:01:59] and then BST button [22:02:12] that calculates boresight (COAS) and scanning telescope data [22:02:33] hmm [22:02:53] that is the COAS data for the PAD [22:03:07] but then you want the SXT button for the sextant star check [22:03:20] and when you enter those numbers it already calculates the stuff [22:04:37] the display is organized in: sextant, scanning telescope, boresight [22:04:43] from top to bottom [22:04:49] is there a specific starting star I should use? Or 001? [22:06:12] yeah, just use 1 [22:06:23] ok [22:06:23] using 0 looks bad from the code [22:06:45] better don't do that before I prevent the user from entering 0 :D [22:07:09] I just tested with Apollo 11 MCC-2 scenario [22:07:14] it found stars 2 and 4 [22:07:27] if I wanted any other stars, I would enter starting star as 5 [22:07:33] I guess ANG button doesnt need to be used? Probably uses default values [22:07:36] and it will find me other ones, if available [22:08:00] that is for a different option of the GOST [22:08:06] that basically simulates a P52 [22:09:30] all I have as sources for the GOST is the programming requirements and the MED inputs. Which basically means I have quite a few information, but those make a terrible user manual :D [22:09:55] right [22:09:58] it makes sense though [22:10:07] looks very flexible [22:10:11] and the display takes a bit getting used to [22:10:20] mainly because it has various options [22:10:28] and parts of the display are reused [22:10:52] even for the sextant star check you need to search a bit on the display [22:11:11] the two stars it finds are S1 and S2 under SXT [22:11:16] but the angles are to the right [22:11:19] under RTCC there [22:12:01] ok [22:12:07] and GDC align stars? [22:13:35] not sure, I think that's not on the GOST [22:14:24] or maybe? I had trouble figuring out the SCT option of the GOST [22:15:07] I'll have to look through it again if I properly figured that out [22:15:24] don't really think so [22:16:11] what I know is that all the custom star vectors were generated with the GOST [22:16:26] if you use star code 0 in P52 it takes an input vector [22:16:41] it can do landmarks on Earth and Moon, and a vector to the Sun [22:16:59] Apollo 13 got Sun vectors, as they were more accurate than the one in the LGC [22:17:23] and the GOST can calculate a REFSMMAT from two sets of sextant angles [22:17:32] so basically like P51 [22:18:27] that's roughly when I stopped working on the GOST, when I was listening to the GUIDO audio to find out more about the backup GDC alignment [22:19:14] but [22:19:43] from the description in that RTCC document it looks like the SCT part of the GOST might be able to calculate it [22:19:55] but I definitely haven't implemented it yet [22:20:16] I wonder if you can use the GOST to calculate the ground portion of the "AGS star align" procedure in the LM G&C dictionary [22:21:51] basically 2 stars, ID line and AOT counter reported to MFSN [22:21:56] definitely not :) [22:22:11] because the GOST is 99% for the CSM [22:22:14] I present [22:22:14] no AOT stuff I guess [22:22:15] the [22:22:17] LOST [22:22:23] Lunar Optics Support Table! [22:22:25] ah [22:22:45] separate display, even more crammed iirc [22:22:58] I love its name [22:23:09] very ironic [22:23:19] ok, its LM Optics Support Table [22:23:30] page 958 [22:23:47] I guess it is to be used when you are "lost" :D [22:23:57] yeah haha [22:24:08] also makes clear what came first [22:24:14] GOST, Guidance, came first [22:24:24] for the CSM [22:24:34] and then they figured out they might want a separate one for the LM [22:24:44] but they hadn't called it COST :D [22:25:19] top of the LOST looks like it has the docked alignment for the LM [22:27:32] yeah, you can probably do that AGS star align procedure with it [22:30:07] I don't think the LOST has REFSMMAT display or landmark/sun unit vector options [22:30:18] so you would use the GOST, even if it was for the LM [22:30:33] that's why the GOST always has the option to use the LM MPT [22:30:49] anyways, thanks for the explanations on how to run the GOST, I think I should be able to find my way around it for Apollo 15 [22:32:20] sure no problem [22:32:25] wow it's late [22:32:38] good night! [11:37:13] Hi all [11:51:38] hey [12:40:14] I'm thinking about writing a joystick remapper module for NASSP. The reason for that my lovely VKB Gladiator stick is using a different channel for yaw axis as Orbitersim. However the tremendous amount of buttons are also tempting me to use them. My plan to build a module which could pick up vessel and joystick specific config files which contains [12:40:15] the axis and button maps to a certain function. For example, you would have a file like LM_VKB.cfg, and there would be maps like JoyRZAxis -> RHCZAxis or JoyButton14 -> THCForward. So it is very similar to how Digital Combat Simulator (DCS) is handling input devices. [12:40:58] But I wanted to discuss the idea with you before investing too much effort into it. [12:42:11] Certainly to make a module like this usable would require to alter the joystick handling of NASSP itself. [12:50:57] So for example, this GetManualControlLevel calls would be changed to some calls through this joystick remapper. [12:53:59] sounds interesting [12:54:53] yeah the joystick code is not very flexible right now [12:55:34] and as it's a fairly contained project, that wouldn't be too hard to be merged [12:57:03] oh, the latest about your Virtual AGC changes was that I asked thewonderidiot to look at it [12:57:21] and he did so, but I'm not sure if he wrote on Github about his findings [12:57:39] I found it in the chat log though [12:57:46] [18:38:48] hmmm, so I've started to take a look at ggalfi's agc_engine changes [12:57:51] [18:39:04] I ported them to standalone virtualagc so I could poke at them [12:57:56] [18:41:04] the instruction tests are all fine but hardware alarms aren't quite working [12:58:10] [18:42:55] any clue what is breaking the alarms? [12:58:18] [18:43:09] not really... there is a lot of changes here and it could be anywhere [12:58:23] [18:48:05] he also made the DV instruction take 7 MCTs instead of 6 for some reason... that's not right [12:58:59] that was actually a few months ago, I thought Mike and I talked about this not that long ago as well... [13:00:49] if you are here this evening you two can discuss this some more [13:01:14] and what I can do in the mean time is implement some of your non-Virtual AGC changes [13:38:04] Yes, I focused to make it work with NASSP and not intended to be a general virtualagc development. That's why I haven't tested any hardware alarm stuff (I believe only TCTRAP could be software-induced, but here we are using a very high quality sw unlikely to do so). [13:44:49] The DV with 7 MCT is intentional: it uses DV0, DV1, DV3, DV7, DV6, DV4 and STD2 steps. And an additional proof: bakc in 2012 I have written an AGC emulator based on the schematics and it worked pretty well (e.g. Colossus DAP and prelaunch alignment was working. And it certainly worked with those steps. [13:51:26] I'm looking forward to your discussion about that with Mike :D [13:55:42] I believe to make my CDU and PIPA simulation work with Virtual AGC without touching the AGC engine would be very difficult. Certainly my original plan was also to create separate commits for the peripherials and the agc itself. But my peripherial simulation is highly depending on working synchronously AGC. So you need to make AGC engine to do the [13:55:42] timing for CDU, PIPA, etc. [13:58:06] yeah, that's why I had never implemented Mike's Virtual AGC update that does everything with pulses [13:58:15] I think for example the improvement of PIPA accuarcuy in short burns (e.g. trimming) is due to the PIPA pulses in my implementation are precisely sit on a 3200pps pulse train and not written directly into the register at practically random times. [13:58:27] from one second to another we would go from a 99% realistic Virtual AGC emulator to everything being broken [13:58:39] and every single system in some way connected to the AGC needs updating [13:59:01] yeah, that PIPA update would be really nice to have [15:50:31] hey [15:56:45] hey Alex [15:56:59] https://i.imgur.com/yqlAVL1.png [15:57:05] notice anything? :D [16:00:19] the elusive "missing panel" [16:01:00] yeah [16:01:10] I wasn't trying to get it [16:01:28] it was not after a restart, but I had just build the VS solution [16:01:54] nothing weird in the DX9 client log [16:02:11] no differences in mesh being loaded etc [16:02:39] and it persists after staging [16:02:48] I kind of thought all meshes were reloaded [16:03:01] but maybe the DX9 client is more efficient than that [16:03:10] a new theory I had, maybe it's an animation gone wrong [16:03:24] the panel could be inside the SM [16:06:07] so when you separate the CSM from the SIVB, does the panel reappear? [16:06:50] hmm, haven't tried that [16:06:58] I'll do that next time it happens [16:07:08] or even at staging? [16:07:18] at staging it stays the same [16:07:22] panel gone [16:07:26] right [16:07:33] S-IC/S-II and S-II/S-IVB staging [16:10:40] must be something in AddSM() [16:11:45] yeah [16:12:18] which panel is it? [16:12:30] hSMPanel4 [16:12:50] if I can trust the DX9 client log, the mesh is properly loaded and added [16:13:01] so it can only really be a visibility mode or an animation or so [16:15:27] hmm but I can find any visibility mode calls referencing those meshes in code [16:15:31] cant* [16:16:11] it doesn't even have a mesh index [16:16:29] so it would definitely be some rather bad bug [16:17:21] ok of course the mesh has an index number [16:17:28] but it isn't saved in the Saturn class [16:17:36] so nothing manipulates that mesh directly [16:17:53] right [16:18:05] code that changes the wrong mesh by accident [16:46:36] I'm trying to not break old scenarios with the LVDC update, but it's going to be a bit difficult [16:51:05] actually, I can ask Mike another very specific question about the LVDC listing which can help me [16:59:19] morning! [17:00:47] hey Mike [17:01:40] what's up? [17:01:44] ggalfi was here earlier, said some interesting things about the DV instruction and it having 7 MCT intentionally in his code [17:02:51] I was hoping you two could have an interesting conversation about it, maybe he comes back later haha [17:04:30] and just a few minutes ago I said "actually, I can ask Mike another very specific question about the LVDC listing which can help me" [17:05:43] but it's not, it's only 6 MCTs [17:05:45] lol [17:05:53] I am 100% sure about that [17:06:27] virtualagc is definitely correct [17:06:58] what's your question? [17:06:59] I wouldn't know haha. I only know that the DV code is lengthly and the special cases are plenty [17:07:17] the variable TASEC [17:07:21] TIME ELAPSED FROM GRR IN SECONDS [17:07:42] it would help me to know where that gets updated [17:07:46] I have a good guess [17:08:00] and how often it gets updated, but that is basically the same question as where in the code that happens [17:08:30] during boost, it's probably doing during or before boost navigation [17:08:42] and equally, it might be updated in orbital navigation [17:09:09] hmm okay [17:09:15] just one of those boring time keeping questions. I could do it in more than one way, but it would be better if I do it the correct way [17:09:22] I don't have it on this computer, will check in just a bit [17:09:28] sure, no problem [17:10:25] previously that variable (we call it TAS) got updated on every timestep in the LVDC++ code [17:10:45] but I am fairly sure it acts as the time tag of the LVDC state vector [17:11:00] so it gets updated as often as the state vector itself [17:11:03] and not more often [17:11:31] so roughly every 1.7 seconds during boost, and exactly every 8 seconds during orbital navigation [17:12:32] if it only gets updated every 8 seconds, I need to change some more things in the code that use that variable, as +/- 8 seconds for "current" time isn't all that accurate [17:15:51] and depending on your answer I won't break all old scenarios :D [17:19:06] hehehe [17:20:50] oh actually [17:21:13] that document we found one NTRS with the LVDC code translated to other languages has the answer for boost [17:21:20] oh nice [17:21:23] it's in accelerometer processing [17:21:53] it calls that variable DVTAS [17:24:23] it reads the accelerometer data and then immediately saves the real time clock as DVACT [17:24:25] then it does [17:24:28] TEMP = DVTAS [17:25:25] but then it uses DVTMM "Elapsed time in mission from GRR at [17:25:26] last time update" [17:25:31] but I don't know where that comes from [17:26:30] indy91, PR sent [17:26:38] just a quick fix in my VC info code [17:27:05] was bad having that return in there [17:27:22] any thing placed under in the time step would be never reached [17:27:40] ouch, yeah [17:28:02] done [17:28:13] thanks [17:29:27] ok this might be different in the AS-206RAM listing, but there seems to be a "system time update routine" [17:29:53] thankfully the VC info stuff was the last thing in the timestep anyway, but still [17:30:00] that's basically what I am doing in the LVDC++ right now, the real time clock and the current timebase time get updated very often [17:30:11] AlexB_88, yeah, definitely [17:36:21] in the meantime I am making progress on interpretive code in pyul [17:36:27] it isn't close to working yet [17:36:35] but it's starting to recognize that it is not working and generating cusses [17:37:51] you know you are making progress when it starts shouting at you [17:37:57] hehehe yeah [17:38:20] 0316 10,2306 1 RRDESSM STQ CLEAR [17:38:20] 0317 10,2307 DESRET [17:38:21] C0317 REF 2 LAST 16 ■■■■ ■■■■■■■■■■■■■■■■ [17:38:21] 0318 10,2310 RRNBSW [17:38:22] 0o153 [17:38:22] C0318 REF 1 ■■■■ ■■■■■■■■■■■■■■■■ [17:38:23] 0319 10,2311 1 RTB SSP READ CDUS FOR SMNB. [17:38:24] E■■■■■■ # 130 POLISH ADDRESS(ES) MISSING PRIOR TO THIS OP PAIR [17:38:24] E■■■■■■ # 130 PREVIOUS POLISH EQUATION NOT CONCLUDED PROPERLY ■■■■■■■■PRECEDING CUSSED LINE IS ON PAGE 238 ■■■ [17:38:31] I haven't taught it how to read polish addresses yet [17:38:40] so it's getting mad when it hits the second op pair [17:40:39] right [17:49:13] indy91, the logic is TEMP = TB; TASEC = TEMP + TI [17:49:19] in accelerometer processing [17:49:57] TB is TIME ELAPSED IN CURRENT TIME BASE [17:50:12] separately TASEC = TB + TI happens as the first thing in the orbital processor [17:50:19] Hi [17:50:23] hello! [17:52:21] I'm not entirely sure what TI is, but it has to be the time since GRR when the current timebase was started [17:52:43] back in a bit [17:53:50] TI is "BEGINNING TIME OF THE CURRENT TIME BASE REFERENCED FROM GRR" [17:53:53] so yep [17:54:51] ggalfi: DV definitely only takes 6 MCTs to execute :) [17:57:27] Yes, I looked into it again. When I changed it, I've taken into account that DV is implemented by the steps DV0, DV1, DV3, DV7, DV6, DV4 and STD2. What I have skipped that DV0 and DV4 are half steps [17:58:12] I think that is the only case when you don't have a full 12 clock cycle steps [17:59:07] yeah, which is only DV [17:59:39] DV is a very weird instruction [18:00:29] Funny thing is that I have my own AGC implementation which is based on these control pulse sequences and it works correctly (with DV as well). And when I looked into my own source code I haven't noticed that it contains half steps as well. [18:01:13] I have written that AGC emulator back in 2012 [18:02:35] so I forgot a few things which I have taken very carefully then. [18:07:34] Indy told me that hardware alarms are not working with my modifications. That is true: I was focusing on make this thing work well with NASSP. And it is the TCTRAP only which can be raised I think. [18:08:21] we've seen almost all of them [18:08:23] But even that is very unlikely to happen with Colossus or Luminary [18:08:40] unlikely yeah, but in bad states they do happen [18:09:03] How do you see a parity error for example? [18:10:15] Except the TCTRAP , all others are hardware induced aren't they? [18:10:37] So won't happen if we don't simulate them? [18:11:00] parity is easy to get if you incorrectly enter an EMP, for example [18:11:40] other things like rupt lock and night watchman can happen if the software takes too long in certain areas [18:12:13] which can happen if your erasable gets into a bad state, which can and have happened through people making DSKY entry mistakes [18:12:39] Oh I see [18:15:56] I can help on that. What I can do is to implement the alarm logic in a similar manner as I have done for the different counter register signal. [18:16:53] I have already done that partially, but doesn't seem important to me, so I've omitted it from my public commits. [18:17:17] To be precise I have done it for TCTRAP, none the others [18:19:46] okay -- I'd very much prefer not to break existing working features of the AGC if we're going to merge your stuff in [18:19:53] are there any other things you know of that might not work as they used to? [18:21:06] Regarding NASSP i think everything is working correctly (I tested it with every mission phase) [18:21:20] Multithreading not [18:22:12] And it is a difficult thing, because in my version CDU, PIPA, Optics are working with AGC in a strictly synchronized way. [18:22:50] So you have to move all these codes into the AGC thread if you want to make it work. [18:23:42] I also have to look carefully to other (non NASSP relevant) features of Virtual AGC, like debugging. [18:24:39] I haven't taken care any issue that was not related to NASSP [18:26:42] What priority are you giving this multithreading thing? [18:28:16] that's a question for indy91 I think [18:33:48] Is this the goal here to keep the NASSP's AGC implementation compatible with VirtualAGC? [18:34:58] ideally yeah, that's what we want to do in the long run [18:35:51] Because my IO handling is totally different than the original one (for example I don't use those virtual registers for coarse align to collect the individual pulses). [18:37:16] So to keep the compatibility the AGC engine have to take care of them as well. I haven't done that yet, because it wasn't needed for the peripherials I have implemented. [18:38:08] yeah those are interesting, and I'm not sure what to do about them either [18:38:41] (I haven't implemented them in my counter refactor branch either) [18:42:49] Seem to me plausible. If I can compile it and run with Virtual AGC it is fine isn't it? [18:47:01] what do you mean? [18:48:48] If I create a new agc_engine.c which works both with my peripherials in NASSP and it also works with VirtualAGC (Ron Burkey's project), it is ok then? [18:52:30] Regarding the hw alarms: it would be a great help to have some test cases (like DSKY sequences or memory dumps). Like for TCTRAP: you load A=0 and make AGC to jump to address 0, and you are right in an infinite loop. But I don't have such scenario for other alarms. [18:55:13] I guess it depends on what the ultimate plan is, but if the goal is to just get this into NASSP then I think you don't have to worry as much about the virtual registers [18:55:27] the Borealis rope I made tests all of the hardware alarms -- that's how I discovered they didn't work [18:55:41] and we also have documents that describe how to manually trigger them with Aurora [18:57:15] here's one: https://www.ibiblio.org/apollo/Documents/dd_memo_409.pdf [18:59:25] Wow, yes, that type of document what I meant. [19:01:02] What is this Borealis thing? I can see it in Virtual AGC folders, but I never heard of it. Is it some sort of common ancestor to Luminary and Colossus? [19:01:24] no, it's a rope that I made based off of Aurora [19:01:44] it adds much more in-depth correctness checks for emulators [19:02:03] testing things that Aurora did not, like EDRUPT and hardware alarms [19:02:15] every time I find an emulator bug in VirtualAGC I add a new test case to Borealis for it [19:03:29] and also has a fun test to determine whether or not the AGC it's running on has had the DINC hardware bug fixed or not :) [19:04:38] I see. It is very interesting that no such thing existed back when human lives were depending on the quality of the hw/sw. [19:05:12] a lot of the things I test in borealis are only things that can go wrong in emulators [19:06:18] like for example, I wrote complex EDRUPT tests because its behavior is difficult for emulators to correctly capture -- but with a real AGC the fact that any interrupt works at all means that EDRUPT must also work fine [19:07:01] ggalfi, does your D3D9 hack work with the latest version? [19:07:47] and this may be a stupid question, but where do I find the D3D9 source code? :D [19:13:58] I'm mainly worried about performance, which I think multithreading greatly improves during time acceleration [19:14:23] people already have trouble running the AGC emulators stable during time acceleration [19:14:31] I never really had issues, but others have [19:15:00] so without multithreading time acceleration might be even worse for those people [19:18:39] AlexB_88: this is where I published it: http://absimp.org/orbitersim/d3d9hack.diff . However kuddel (orbiter forum user) created I complete branch of it: svn://mirror.orbiter-radio.co.uk/D3D9client/branches/floatElevTest , it may be more convenient than to messing with patches. [19:19:34] thanks [19:19:55] unrelated: pyul is now correctly assembling polish op pairs! :D [19:20:09] yay [19:20:33] first you taught me how to read it, and now an assembler [19:20:57] ggalfi: also, I was the Tranquility mesh/textures made by yourself? I was curious what the process is of making those and if it would be easy for me to make the other landing sites [19:22:06] thewonderidiot, one last thing about LVDC times. I'd like to figure out how and where TB is updated. Might be a special subroutine in interrupt processing. [19:23:50] although that could be different from the later generalized flight program [19:24:31] lol this will be tricky with a name like that [19:24:33] let's see [19:24:37] yep [19:24:59] system time update routine [19:25:09] TBUP, Time Base Update Routine [19:25:13] is where it happens [19:25:14] nah [19:25:17] well [19:25:25] it gets set to 0 there I would guess [19:25:52] nope [19:26:19] then I misunderstand the name of the routine haha [19:26:29] it certainly seems to be doing math there [19:26:45] ok, probably with the real time clock then [19:26:54] I think so yeah [19:27:03] it's talking about converting something to seconds [19:27:06] so that routine might be what gets called to update timebase relative parameters [19:27:11] mostly time stuff [19:27:37] and it would then be called quite frequently. Where does it get called from? [19:27:46] all over the place [19:27:51] hmm, right [19:28:10] probably means that it doesn't get called on a schedule [19:28:18] but whenever you need the exact timebase time right now [19:28:19] accelerometer processing, backup routines, liftoff search, orbital processor... [19:28:26] yeah [19:28:30] AlexB_88 : The process is the following: I select appropriate images from LROC NAC imagery (usually a left-right pair), convert them into a single large GeoTIFF with the help of ISIS package. Then with my own programs I fit the intensity to the surrounding lower resolution tiles of Orbitersim. After that the same program creates surf tiles for the [19:28:31] sim. For elevation, you start with a Digital Terrain Map (DTM) which is already a GeoTiff. Then again my program could generate the elev tiles as well. The only thing is that my program is an ugly written Java code, which I haven't published yet and have no intention to do so until I clean up it. [19:29:55] ok, I can work with that. Earlier you said "separately TASEC = TB + TI happens as the first thing in the orbital processor". That also confuses me, because that doesn't like it gets only updated on the same schedule as the state vector [19:30:06] doesn't sound like* [19:31:04] first thing in orbital processing would agree with the astrionics handbook [19:31:11] but not really with the EDD [19:31:50] ggalfi, ok thanks [19:32:01] I guess I should say, second thing after calling TBUP [19:32:12] will be nice to eventually get some good resolution for all landing sites [19:33:11] orbital processing gets called from the minor loop [19:34:24] oh [19:34:25] ONTAS 0000 0200 0400 15 SECONDS [19:34:26] * TIME OF LAST ORBIT NAVIGATION [19:34:39] so that's a separate variable from TASEC [19:34:48] interesting [19:35:42] I think I can work with that [19:35:46] thanks for the help! [19:36:30] AlexB_88: Thats my plan as well, I'm eager to see the Hadley-Appenine in its full beauty throguh the LMs window. However I just stuck in the problem, that Oribtersim doesn't use the very high resolution elev tiles when it calculates the surface forces, so objects sometimes sink sometimes float above the lunar surface. Which isn't very nice. [19:36:32] yup yup :) [19:36:59] I don't think the AS-206RAM software had an on-orbit state vector update capability, so useless to ask about that :D [19:37:06] hahaha [19:37:37] okay now pyul is actually assembling these pairs correctly and not just printing them in the listing correctly lol [19:38:09] 10,2300 BAD WORD C: 00510 0 00003 1 14076 0 02013 1 BAD WORD I: 43030 0 @ [19:38:10] 10,2310 @ I: 66224 0 @ @ @ @ @ @ [19:38:10] 10,2320 @ I: 77634 0 @ I: 77776 1 00004 0 04777 1 C: 00423 1 BAD WORD [19:38:19] getting some good I: flags in the octal listing at the end [19:38:38] nice. I guess you can make a correctly formatted Sundial listing, just missing comments [19:38:48] yep! [19:38:58] or is this all BLK2? [19:39:10] this is all BLK2, but Sundial is also BLK2 [19:39:34] oh, didn't know that [19:39:40] makes sense though [19:39:40] yeah [19:39:43] similar to Aurora [19:39:54] it was kind of rough transitioning from Sundance to Sundial because the interpreter encoding is slightly different [19:40:04] so I had to re-learn how to disassemble it lol [19:40:47] the main difference being that BLK2 interpreter is restricted to seeing erasables in the current ebank [19:40:51] instead of being able to use all of erasable [19:41:30] so it's using the ADRES of everything instead of the ECADR, and the store and load codes are all different [19:41:43] does the interpreter code deal with ebank switching? [19:41:47] in AGC [19:42:04] or whatever the later block 2 language was called :D [19:42:26] or how did they solve that issue [19:43:44] yeah, it automatically switches the ebank as required in "AGC" [19:45:16] uh oh [19:45:28] I think EBANK= cards might only be working right now because of a bug [19:45:29] lol [19:45:52] I'm about to start working on polish addresses and it's treating every EBANK= as polish [19:46:17] oh and not treating actual polish addresses as polish [19:46:21] Hey guys I have to leave now! I'll think over what we have discussed and come back when I'll have come up with some new results. [19:46:23] maybe I just have that comparison backwards [19:46:38] ggalfi, cya! Feel free to stop by whenever you want! [19:46:42] sounds good ggalfi! take care! :D [19:46:59] Thx, good bye! [19:53:10] oh man fixing that branch has greatly fixed the printing of this page [19:55:38] the two separate TAS might be a thing only in the earlier LVDC programs [19:55:53] so in the listing and the earlier astrionics handbook it would be that way [19:56:05] and in the EDD and the translated LVDC code it's only one TAS [19:56:30] the Apollo 13 Saturn Systems Handbook has LVDC telemetry [19:56:35] it only has TASEC [19:56:42] huh, interesting [20:01:02] yeah the EDD confirms that the "TAS" it talks about gets only updated every 8 seconds during the orbital phase, so as often as orbital navigation is done [20:18:20] Well, I suppose I should actually write some code, if I want to get anything done, lol [20:27:51] hehehe [20:34:43] night! [20:37:04] darn, I had a question for him. haha, whoops [20:46:51] haha [21:03:37] oh jeez [21:03:58] control flow for polish addresses is going to be hard to pythonify [21:11:42] I hope I can handle INT AD STO just with returning to the calling function [21:21:46] would something like this help https://github.com/snoack/python-goto [21:23:28] I was seriously thinking about that for a while lol [21:23:36] so far I have avoided it [21:25:21] the basic structure I'm using is gratuitous abuse of the fact that python functions that don't return anything implicitly return None [21:25:26] so if I define a label as a function [21:25:44] I can effectively do a goto by doing "return function()" [21:26:04] which works as long as eventually you end up back at the place you started [21:28:31] the problem I have right now is that there's a variable "STORE COM" that either contains 0 or an address to jump to [21:28:51] and there's checks to see if it's 0 or not all over the place, and will jump to the contained address if it is nonzero [15:42:53] hey [15:43:23] hey Alex [15:45:22] flying a Saturn V to TLI for the first time with the update [15:56:29] nice [15:57:20] going to launch Apollo 15 today [15:59:41] morning! [16:10:15] hey Mike [16:13:58] pyul is now assembling its first two polish equations completely [16:14:24] 0316 10,2306 43030 0 RRDESSM STQ CLEAR [16:14:25] 0317 REF 2 LAST 16 10,2307 00427 0 DESRET [16:14:25] 0318 REF 1 10,2310 00271 0 RRNBSW [16:14:26] 0319 10,2311 66224 0 RTB SSP READ CDUS FOR SMNB. [16:14:26] 0320 REF 1 10,2312 ■■■■■ READCDUS [16:14:27] E■■■■■■ # 130 "READCDUS" IS UNDEFINED ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■PRECEDING CUSSED LINE IS ON PAGE 238 ■■■ [16:14:27] 0321 REF 2 LAST 117 10,2313 00051 0 S1 [16:14:28] 0322 10,2314 00024 1 20D [16:14:28] 0323 10,2315 1 STOVL 20D [16:14:35] well, except for the undefined function [16:14:47] but if I change that to something that exists it gets encoded correctly [16:14:52] next up is that STOVL :) [16:17:09] awesome [16:19:34] I think Hugh gave up trying to name all of the functions for handling interpretive code in the assembler [16:19:54] I thought they were acronyms at first but I'm starting to doubt that [16:20:17] what are they called? [16:21:34] there are INT OP APE, INT OP DOG, INT OP BAT, INT OP CAT, INT OP FOX... [16:21:55] haha [16:22:02] I don't think those are acronyms :D [16:22:06] haha yeah [16:45:03] I think the main thing that can go wrong for TLI with the LVDC update is that the transition from coasting flight to powered flight isn't working correctly [16:45:26] with the two TLI opportunities that can even happen twice [16:45:40] if TLI is inhibited after TB6 was started [16:46:42] so a bunch of things to test. normal TLI, TLI inhibited before TB6, inhibited during TB6, second TLI opportunity [16:49:53] oh yeah that sounds not ideal haha [16:50:44] that phase transition from powered to coasting flight and back is changed quite heavily with this update I am working on, so a lot can go wrong [16:54:44] 03221 10,2315 77615 0 DAD [16:54:45] 0323 10,2316 1 STOVL 20D [16:54:45] E■■■■■■ # 131 PUSHUP ILLEGAL BEFORE STORE OP WITHOUT STADR [16:54:52] it's detecting the need for a STADR :D [16:55:20] this also works: [16:55:22] 03221 10,2315 47215 1 DAD VXV [16:55:23] E■■■■■■ # 131 RIGHT OPCODE'S MODE IN DISAGREES WITH MODE OUT SETTING [16:58:25] what's mode in and mode out? [16:59:18] oh, double, triple, vector etc.? [16:59:34] DAD is double, then a VXV is wrong [16:59:39] I think? :D [17:00:26] yep! [17:02:39] those will help make the disassembly better since sometimes the double and vector opcodes assemble to the same thing [17:02:54] right [17:03:14] powered flight init for TLI works, but I do have to come up with a number for how long a major loop takes to process [17:03:23] which I think is a mistake you saw me make a couple times in P10/P11 haha [17:03:29] yeah [17:03:31] nice :D [17:04:09] just when TB6 is started it should be very similar in load on the computer as just after S-IVB cutoff [17:04:27] still boost navigation, but already orbital guidance [17:04:48] and no IGM [17:04:50] EDD says that takes 0.98 seconds [17:05:00] and then when the IGM starts it should go up to 1.7 seconds [17:07:43] TLI steering was bad, but I know what I forgot to add [18:01:11] a Saturn V LVDC listing would help me with this work. On the other hand, a Saturn V LVDC listing would make this work pointless and the focus should be on running it in an emulator. [18:01:55] hahaha [18:02:14] a Saturn V listing would be so great [18:02:33] I still think it is funny and weird that whoever Ron got the listing from kept, of all things, a broken AS-206RAM listing [18:02:59] surely there were better options for holding on to :P [18:03:06] yeah, haha [18:03:12] or maybe nobody wanted that listing [18:03:20] nobody else [18:04:14] yeah maybe [18:04:18] I hope there are some people who loose the fear or doing something illegal once this listing becomes public [18:04:30] yeah that would be fantastic [18:06:16] and at least we can start an honest effort to get this one running in an emulator [18:08:55] any time now :D [18:09:06] lol yep, any time now [18:09:32] good Apollo 15 launch [18:11:06] I can confirm that the LVDC is working perfect, a few good days for it before Niklas's update :D [18:13:11] hehehe [18:16:44] I hope TLI also works perfect [18:17:31] the version of the LVDC that is currently in NASSP is essentially the same as before, with a few smaller changes because the LVDC timestep gets run 100 times per second [18:17:47] so it doesn't perform very well, but should be little different [18:18:21] lots of code that should definitely not be run 100 times per second [18:18:58] right [18:19:25] but TLI should be fine, not that I hadn't tested it much [18:20:18] btw is the LVIMU orientation at GRR now dynamically updated? Or is it still the fixed one we always had? [18:20:47] I remember there was discussion about that [18:20:58] already using the precise alignment in the Saturn V as well [18:21:25] is that already committed? [18:21:39] yes, that's what it currently uses [18:21:42] ah ok [18:21:58] what I said above all applies to that [18:22:18] after my Saturn IB LVDC update, but before the big one for the Saturn V that is still coming [18:22:30] so if you fire a thruster accidentally and it slightly moves the rocket, it wont affect the LVIMU at GRR [18:23:28] which is a possibility now that you can fire a CSM thruster before launch [18:23:35] yes, it uses the actual attitude of the Saturn on the launchpad for the initial LV IMU alignment [18:23:45] makes sense [18:24:11] calls GetRotationMatrix from the Orbiter API and lengthy math follows [18:24:46] only input value is the desired launch azimuth [18:25:23] right [18:26:03] that's what the real Saturn did as well [18:26:28] a precise alignment [18:30:05] I think you can still time accel through GRR, maybe we should put some better logic to limit it to 1x say under 20 seconds to go [18:31:13] unless we are sure there would be no issues with accuracy, but I am thinking a user with a slower system, using time accel up to liftoff...bad recipe lol [18:31:43] yeah [18:32:02] forcing time acceleration to 1x is easily done [18:33:30] maybe the Mobile Launcher code should do that [18:33:44] T-30 seconds seems like a good time, better have it a bit before GRR [18:39:12] right [18:45:44] I think there already is some time acceleration handling, maybe that should be removed and only have it in the ML? [18:56:53] yes [18:57:10] also because I want the LVDC timestep free of any oapi calls [18:57:30] kind of a requirement if it ever gets replaced by an emulator [19:10:29] ok time to use the GOST for my TLI+90 pad [19:12:12] so I guess I set MAT=CUR, then ATT= 1 PYR (burn att) [19:13:09] then BST/SXT is time of the sextant check, 1, CUR [19:14:12] sounds about right [19:14:53] although you don't need to do the first step [19:15:10] I think that just displays the CUR REFSMMAT on the GOST [19:15:39] you tell it which REFSMMAT to use in the last step there [19:16:15] hmm "two stars not available" [19:16:27] and I have code zzzzzzzz at the top [19:17:27] mind you I am doing this from before TLI, I have 3 maneuvers on the MPT [19:18:14] oh that was BST [19:18:22] SXT seems to have given results [19:18:38] I guess BST you can often get the stars not available message [19:18:42] guess you have no COAS star then [19:19:06] if it finds only one star it still will say "two stars not available" [19:19:12] but will show the one star it found [19:19:15] S1 says 221 and has data [19:19:23] S2 0 [19:19:29] ok then that makes sense [19:20:14] S1 says 221, SPA +29.4 SPX +0 and RT ASC 323:32:33 [19:20:27] and a declination probably [19:20:32] yes [19:20:39] ok thats not a GET [19:21:28] what is code ZZZZZZZZ? is that relevant? [19:21:47] all Zs is just no data there [19:22:29] and I'm not really sure what that is used for really [19:22:31] and then the SXT data I have 2 columns, INP and RTCC it seems [19:22:41] INP is for you simulating a P51 [19:22:48] INP is 0's and RTCC has the data [19:22:50] ah ok [19:23:04] which then lets you calculate a REFSMMAT from two star sightings that were actually done [19:23:23] those would always be inputs [19:23:26] with the ANG button [19:23:35] RTCC is angles the RTCC calculated [19:24:34] in this case for a sextant star [19:24:46] not sure if anything else uses the RTCC SXT values there [19:24:49] and then there is SCT, and S 1 2 below [19:25:08] yeah, that is not implemented yet. Might or might not be a GDC backup alignment :D [19:25:13] ah ok [19:25:17] makes snese now [19:25:21] sense* [19:25:53] about the Boresight section, my result is SPA +29.4, SPX 0 [19:26:36] I guess the SPA/SPX must be below a certain threshold for it to be a valid COAS star? [19:26:47] if (SPA <= 31.5*RAD && SPA >= -10.0*RAD) [19:26:59] if (abs(SPX) <= 5.0*RAD) [19:27:16] so it barely even found one [19:27:27] oh, that's for TLI+90, right? [19:27:35] ok so if it does display one then it is a valid COAS star [19:27:37] yeah [19:27:41] so the CSM would point almost directly at the Earth [19:27:49] right [19:27:56] so barely even found one [19:28:01] so it must be finding one right at the edge of the window [19:28:06] yeah [19:28:11] the real pad didnt include it [19:28:46] maybe they just didn't bother [19:29:05] or didn't want one at the extreme limit of the COAS [19:29:36] boresight star is a check that you are pointing in the right direction. I think in this case the Earth serves as a rough check :D [19:30:19] fair enough haha [19:30:47] anyways my PAD is very similar to the real one [19:30:57] nice [19:31:03] and I am glad my guide is helping remember all the steps [19:31:03] didn't totally screw that up then [19:31:20] found a similar sextant star as well? [19:31:24] not using any of the maneuver pad modes in the RTCC MFD [19:31:46] it found 33 and 37 [19:31:51] real was 40 [19:31:54] I used 33 [19:33:10] 40 is Altair, nice and bright. Who knows, maybe the GUIDO wanted to find it [19:33:27] maybe if I force it to start at 40? [19:33:31] yeah [19:34:38] hmm [19:34:52] I wonder if the input is octal or not [19:34:57] oh wow [19:35:23] real pad S40, S +77.5 T +35.9 [19:35:49] RTCC MFD: S +76.1 T +35.1 [19:37:00] and using 40 worked to force it to start searching at star 40? [19:38:42] yes [19:38:47] came up with 40 and 41 [19:39:39] ah yes [19:39:39] if (sscanf(data[2].c_str(), "%o", &star) != 1) [19:39:44] the %o is for octal [19:39:45] so the GET I use in the BST/SXT buttons is the GET of the check and not TIG, correct? [19:40:22] I guess its just so that you can specify a time when no planet is in the way [19:40:29] yes [19:40:40] although I just saw this in my code [19:40:41] TBD: Occultation check [19:41:10] I guess I wasn't fully done with the GOST when I moved on to other projects :D [19:41:24] so maybe stars 33 and 37 aren't actually available [19:42:02] shouldn't be difficult to implement though [19:42:17] already had that with the Maneuver PAD calculation [19:44:17] is that to check if the stars are in range of the SCT/SXT at burn attitude? [19:44:36] no if Earth, Moon, Sun are in the way [19:44:59] ah right [19:49:03] I'm surprised I didn't implement it then, I wonder what interrupted me. Maybe Sundance. [20:15:42] one thin I am noticing is there is a mis-match of about 5 seconds between the P15 countdown and the event timer ( ET set to count up from 51:00 when SII SEP light goes out) [20:28:53] I think I've seen that before [20:32:05] has TLI gone well? I have some problems, but it's probably one of my local changes [20:35:21] looks good [20:35:55] ill calculate MCC-2 once I get TD&E done [20:36:50] well for me it tries to do a 80° pitch maneuver when the IGM kicks in... [20:36:58] but I have an idea what it is [20:38:51] nope did not see that [20:39:19] I think there is a simplification of the code in the EDD that does not apply to TLI [20:40:32] of the equations* [20:45:12] yeah, I think I fixed it [20:46:33] if everything works I just need to fix some timebase 7 stuff [20:46:54] I really want to see the maneuver to the TD&E attitude with the new steering [20:50:50] there is a 5 second pause when I separate the CSM [20:52:10] that's weird [20:52:36] a lengthly pause there would only really happen if it is slow to load stuff from the hard drive or so [20:53:00] not sure what could really cause that [20:53:41] should suddenly start taking so long [20:53:44] shouldn't [20:55:23] in the spring it was only 1-2 seconds [20:55:54] might be the VC stuff [20:57:02] possible I guess [20:58:33] made it through TLI as well [20:58:45] 6km position error in the LVDC [20:58:51] without any state vector update [20:58:58] not that bad really [21:00:00] nice [21:05:11] and state vector update through the RTCC MFD is now implemented and working [21:07:49] do you have NASSP installed on a SSD or a HDD? [21:08:44] SSD [21:11:49] that should be quite a bit quicker with loading stuff [21:12:11] I'll also check what happens at CSM sep, I'm close to it anyway [21:19:06] nice maneuver to the sep attitude [21:26:56] hmm [21:27:10] I have more than 5 seconds, but 5 seconds would have been normal for me [21:27:13] maybe 3-4 [21:27:19] but I also now get more than that [21:27:22] quite a bit [21:28:05] must be VC stuff, wouldn't know what other changes could cause this [21:28:53] the DX9 Client log can help with this [21:29:26] (511: 1112.1s 2004.77ms)(0x3BC) Texture 0x2ACC86A8 (ProjectApollo\LM_Interior.dds) added in repository [21:29:44] this means it too 2 seconds alone for LM_Interior.dds to load [21:29:53] (512: 1112.3s 220.19ms)(0x3BC) Texture 0x2ACC9F08 (ProjectApollo\LMVC.dds) added in repository [21:29:57] 0.2 seconds for LMVC [21:30:14] was are the zzz ones [21:30:17] what* [21:30:28] Jordan's stuff [21:30:35] yeah those take long as well [21:30:46] almost a second for zzzECS [21:30:57] half a second for zzzNet [21:31:06] 0.9 seconds for zzzECS_FrontParts [21:31:28] half a second together for LMVC side bags [21:31:43] DX9 Client is super useful for this [21:31:49] but yeah, it's the new VC stuff [21:32:14] I mean, it makes sense, we are loading an entire new spacecraft [21:32:22] that now has a lot of complex modeling [21:32:40] it took from 1108.7 seconds to 1116.5 seconds simulation time [21:32:55] so about 8 seconds from pressing the button to it finishing [21:33:04] I just hope those pauses dont destabilize the sim [21:33:14] they might [21:33:23] I wonder if it is possible to preload the meshes [21:33:27] and textures [21:34:25] they would be in the LM module though [21:34:36] so that is really created from scratch at that time [21:37:52] right [21:38:49] we should really try to think of something to improve that [21:39:00] it's getting late, cya tomorrow. Good night!