[13:48:41] NASSP Logging has been started by thymo [13:48:56] Yeah, had to do some rewiring in the house. All good now [14:11:26] ahh, okay [14:13:07] .tell indy91 looks like I'm having weird pannel problems too, in my own branch. something I'm doing is making them only display for one frame when swithced to via F8, not sure why yet [16:32:47] good morning [16:38:15] Hey Alex [16:47:27] OrbiterSound 5.0 is now released it seems, has anyone tried it with NASSP yet? [17:14:13] morning! [17:15:17] Niklas used it for a bit when he was doing landings with Sundance306ish [17:18:25] hey Mike [17:18:26] nice [17:25:17] the only thing he mentioned about it was that it reset all of his settings to defaults when he installed it [17:25:21] but otherwise I think it worked fine [20:55:04] if it works well enough I guess we can abandon the XRSound plans [03:12:40] making good progress on the CSM & Saturn Integrated Tests in Sundial :D [14:58:27] . [14:58:51] that sounds weird [15:43:47] morning! [15:54:44] indy91: I finished the first-pass disassembly of V47 in Sundial last night [15:54:53] it is less scary than I thought it was going to be :) [15:55:05] we should definitely be able to get it working [15:58:56] ah nice [16:00:10] V47 was the one we didn't have much information about, right? [16:03:35] yep [16:04:07] have we ever done V47 in Aurora? because getting that to work first would help [16:04:14] 2 of the 4 data structures are completely identical [16:04:25] and the others are structured similarly [16:10:08] I don't think I have tried it [16:10:32] okay [16:10:57] for that one we have example tables in engineering units [16:11:26] what does it do? [16:11:31] in Aurora I mean [16:12:42] oh it's that test [16:12:48] I have definitely tried it [16:12:54] in Aurora it's the LEM Flight Control System Test [16:13:33] so it spawns 4 tasks that might all act at the same time -- one uses a table to fire RCS thrusters in some combinations for some time, one turns the engine on and off, one moves the gimbal around, one moves the throttle around, and one monitors channels 30-33 [16:13:41] 5 tasks that is [16:14:01] but first it wants me to do some inputs [16:14:03] like in Sundial [16:14:10] yeah so the way that works [16:14:40] it places you on the first location of the first table (for RCS jets) and you can enter in the values for that table one at a time [16:14:48] when you're done with the table, you do V34E [16:14:59] and it will then show you V21 N30 [16:16:14] on that display, if you enter the address of the next table you want to fill, it will take you there and go to the first loop so you can fill that one in [16:16:33] if you do V34E on the 21 30, it will stop entry and start the tests [16:17:23] so what are the values I am entering. [16:17:28] RCS jet IDs? [16:17:59] http://www.ibiblio.org/apollo/hrst/archive/1708.pdf [16:18:09] that memo has the tables and example values [16:18:10] THE REGISTER JETSTEP IS USED TO INDEX THE 8 SETS OF REGISTERS, THE ALLOWABLE VALUES OF JETSTEP ARE +0 THRU 7 [16:22:17] that document isn't really helping me [16:22:37] haha [16:22:50] I can help translate it in a bit [16:23:19] I have [16:23:23] V21 N02 [16:23:29] R2 is 00103 [16:23:37] R3 is 02007 [16:24:26] so R3 is the current address you're loading -- which is JETSTEP [16:24:33] R2 is I think the current value it stores [16:24:46] you can V33E to accept that value, or enter your own in R1 and hit ENTER [16:25:06] so you'd be filling in the data on page 21 of that document [16:26:47] so I can enter 0 to 6 [16:26:52] and it would do different profiles [16:28:05] something like that yeah [16:28:44] but that is just engineering values [16:28:59] yep [16:29:07] so we have to work out octals for them [16:29:08] probably centiseconds for all the times [16:29:30] hmm. managed to fix my issue [16:30:32] yeah, centiseconds -- they're times used for WAITLIST calls, so scaled like TIME3 [16:31:11] n7275, what was it? [16:31:37] thewonderidiot, all the variables except for JETSTEP have 8 addresses [16:32:05] yeah [16:32:14] so you can put in that entire table [16:32:45] and it just counts JETSTEP down from whatever you loaded into it and executes each column one at a time [16:32:56] isn't it missing a column [16:33:19] oh, if a column is 0 the test stops there [16:33:45] either the column was cut off or they didn't use it for this profile [16:35:48] indy91 I'm not positive of the cause, which worrys me a bit, bit this https://drive.google.com/file/d/1yRNcHERIY53qlaA4YMD5woGV2x9CbBdV/view?usp=sharing works, and what's commented out causes the issue [16:37:52] called here: https://drive.google.com/file/d/1Qej5VTcXZzyYO3N-aT-wFBLEcZ9yvOM4/view?usp=sharing [16:38:18] (pardon the interuption) [16:38:59] no worries on interruption. :) are any of those being used uninitialized? you're moving around where they're stored in memory there, which could change uninitialized values [16:40:24] the main interruption is me cooking dinner while looking at my PC every few minutes :D [16:40:50] hehehehe [16:41:13] so that code works when directly giving those public variables values [16:41:26] but it causes issues when doing it through the function? [16:42:08] csm_rrt is a pointer [16:42:24] is that initialized to NULL? Or could be doing something wrong? [16:47:42] thewonderidiot, it seems to want me to enter the entire table, so what is the point of entering a value for JETSTEP? [16:48:08] I am entering the values for all test profiles, but I am also choosing which one it's going to execute? [16:48:39] I'm not entirely sure [16:48:49] maybe so you can select a particular profile to begin with [16:50:58] I think I'll edit the scenario to enter the values from the table [16:51:01] seems easier [16:51:10] I can still check them all in the simulation [16:51:39] yep, I highly recommend that lol [16:51:44] It's probably an initalization thing. I set it with the constructor, but maybe that's too late [16:51:46] then you can just V34E twice to start it [16:59:37] hmm, I would be surprised if constructor was too late [17:04:37] do you have this code on a branch somewhere? [17:18:49] any idea what to use for XJETS and YZJETS? [17:19:04] oh [17:19:07] channel 5 and 6 format [17:20:04] yep [17:21:07] I have it in a branch. I need to commit my latest changes and they I could share it. itll be a few hours before I'm back home [17:21:39] okay, I'll take a look whenever you get around to pushing it :) [17:22:28] same [17:24:09] awesome, thanks :) [17:36:59] ok, table is in the scenario [17:37:18] but it won't fire the RCS anyway [17:37:35] for some reason Aurora doesn't like PGNS mode control in auto [17:40:38] keeps on throwing restarts in anything but off [17:43:38] hmm [17:43:40] weird [17:44:01] Sunburst still has this test, so if it is our weird Aurora causing problems that might be more stable [17:45:52] both Sunbursts? [17:46:16] yep [17:46:36] I already named the scenario Aurora FCS Test, I have failed [17:46:42] hahaha [17:47:48] I can take a look at that though [17:48:01] I'm curious why that would be [17:49:00] ok [17:49:08] so when I have done V34 twice [17:49:11] nothing happens [17:49:28] hmm [17:49:32] why twice anyway [17:49:55] the first time terminates the current table that you're loading [17:50:05] on the 21 30, you can enter the base address for the next table you want to loda [17:50:37] hmm [17:50:44] what about V33 on the 21 30? [17:51:30] it shows a V47 then [17:51:38] oh perfect [17:51:44] then it started [17:52:40] oh wait I did something wrong with the "padload" [17:53:13] JETOFFTM comes after the thrusters [17:53:17] unlike in the table [17:55:54] but in Sunburst I didn't get a restart at least [17:56:07] cool [17:57:05] still no thruster firing [17:57:53] hmm [17:58:03] what value did you put into JETSTEP? [17:58:17] 0 [17:58:20] in the scenario [17:58:27] should I V33 on that? [17:58:57] hmm [17:59:10] so JETSTEP counts down from the number you put into it [17:59:17] and it's used with INDEX [17:59:21] so I think the table my run backwards [17:59:55] V33 on what? [17:59:58] THIS JOB WILL BE ENTERED BUT IMMEDIATELY ENDED IF THE INITIAL VALUES OF JETSTEP AND NTIMES ARE +0. [18:00:16] guess I'll try something higher than 0 then :D [18:00:23] V33 on JETSTEP I meant [18:00:54] oh, yeah you should put something higher lol [18:01:37] jet on commands might be too short for the first test to work in Orbiter [18:01:45] the others might [18:02:23] you can always make them longer :D [18:02:49] yeah [18:02:59] it should be starting with the RCS test, right? [18:03:21] lol so [18:03:25] I'm not completely sure [18:03:31] I think it might do all of them at the same time [18:04:01] oh ok [18:04:13] maybe some input bit is wrong for the test [18:04:39] still haven't gotten it to do anything [18:04:47] Sundial, unlike Aurora/Sunburst, has a lot of "please perform" prompts to get the switches set up right [18:04:50] which will be useful [18:08:35] not even seeing anything from the tests other than RCS [18:09:06] what was that about TIME3 scaling? [18:09:19] is that not 1 centisecond per bit? [18:11:20] it should be [18:11:59] yeah definitely is [18:13:44] ok back to Aurora [18:14:02] I do also get some alarms in Sunburst when I switch to auto mode, but they don't persist [18:14:32] what should I look at in Aurora for the restarts? [18:14:54] Aurora doesn't have anything useful there I'm afraid [18:14:59] that will need more in-depth debugging [18:15:04] you could also try Borealis -- I'm guessing restarts are related to the incomplete DAP that Aurora has [18:15:30] I mercilessly removed all of that for Borealis :P [18:16:15] ok back to Sunburst :D [18:17:06] hahahaha [18:17:30] I wonder if something in the erasable in this scenario is causing weirdness [18:17:43] I should get rid of the whole erasable state except for what I want [18:17:48] I get 1110 alarms in Sunburst [18:17:55] oh yeah that would definitely be good [18:18:42] almost all of the JDCs for doing tests with these programs tell you to do option 15 for V57 before doing the test [18:18:49] that zeroes erasable [18:19:56] aaaaaaah [18:19:58] that did it [18:20:03] deleting erasable stuff [18:20:07] it's doing the tests now :D [18:20:11] nice!! [18:20:17] well RCS is definitely firing [18:20:38] seems like the patterns from the table [18:20:46] great [18:20:58] so that table you've made can be directly copied into Sundial, same addresses and everything [18:21:54] same goes for the engine on/off [18:22:45] the gimbal test table is different because the CMC has to use CDU counters instead of discrete outputs [18:23:04] yeah [18:23:09] and then the S-IVB table has pitch/yaw/roll commands which doesn't really have an equivalent in the LM [18:24:03] I'll put in the other tables first [18:24:24] I want to see those in action in the LM too :D [18:24:44] :D [18:25:01] by the way, something I never noticed before [18:25:20] that document has a stamp from "WSU Special Collections" on the first page [18:25:25] I don't think I knew they had any Apollo stuff [18:25:30] I'll have to email them [18:27:47] yeah [18:39:07] this is more work than a normal padload haha [18:39:37] hahaha yeah [18:39:41] these are big tables [18:39:56] there is so much erasable to go around, no way they would ever run out [18:40:33] or having to use overlays [19:11:47] all tables loaded [19:13:01] haha, everything is happening [19:24:34] thrusters firing, engine switched on and off, throttling up and down, and it drove the DPS gimbals into a stop [19:26:42] nice! :D [19:26:49] so I was right about it all going at once lol [19:28:13] yeah definitely [19:28:28] I didn't enable the input channel monitoring task [19:28:33] probably doesn't do much for me [19:28:56] I would just have to load QUITLOOK to something positive [19:29:49] so for the Sundial test I better use an on orbit scenario [19:30:07] so far I have always used a prelaunch one, but that won't do for any flight control tests [19:37:34] yeah Sundial is interesting [19:37:48] I think it might only do subsets of the tests at the same time [19:37:55] I have a bit more reverse engineering work to do there [19:38:53] it goes off of some variable called TESTIDX [19:46:53] Sundial firest RCS thrusters [19:46:55] fires* [19:48:50] and the SPS [19:51:21] and obviously spins out of control like the LM, as the RCS tests isn't designed to keep the attitude rate low [19:54:47] oh you got it working already? [19:54:48] nice [19:56:48] well I just did what you said [19:57:04] I copied over the erasables for the RCS and engine tests [19:57:26] and then did the same procedure as in the LM [19:57:37] great :D [19:57:55] I have to look at it again to see the order things happened [19:58:04] but it essentially was both at the same time again [19:58:34] I didn't have everything in place for the SPS to be started right away [20:00:18] it started the SPS right away [20:00:28] RCS tests came in a bit later [20:00:34] SPS is off, more RCS tests [20:00:55] well it will be the same as I saw in the LM [20:01:05] I think [20:01:38] yep that sounds right [20:02:45] so TESTIDX can be 0, 1, or 2 [20:03:33] how do you know it's called TESTIDX? :D [20:03:44] oh I was really happy about that one [20:04:08] http://www.ibiblio.org/apollo/Documents/Aurora88SundialCCards.pdf [20:04:13] pdf page 4 [20:04:31] this location is checked and generates a 1401 alarm if it is too big [20:05:18] ah, that makes it pretty clear which one is TESTIDX [20:05:23] yep [20:05:36] as I have deleted all the other erasable, I did it with 0 [20:05:45] what's the erasable address of it? [20:06:25] E4,1547 [20:06:34] of course I have only 2 tests working so far, might not make much of a difference [20:07:21] I think options 1 and 2 might be how you start the saturn stuff [20:07:32] ah, well, that would be working [20:07:38] I just have to put it in a debug string [20:08:03] it needs big erasable tables too for the time-tagged roll/pitch/yaw commands [20:08:10] unless you've already jumped way ahead and have those ready :D [20:08:11] ah right [20:08:15] nope [20:08:17] definitely not [20:08:18] heheh [20:08:38] I'll sit down tonight and start naming things to get a better feel for how this flows [20:08:40] I was mainly thinking about the output bit that enables control of the IU [20:08:45] right now it is a big mess of U07,xxxx labels [20:08:46] oh yes [20:08:53] but without the erasables it won't do that [20:09:01] not following any specific timing anyway [20:09:04] if you do TESTIDX 1 or 2 it will start giving you please perform prompts [20:09:15] and eventually set that bit [20:09:35] yeah, I have seen that in V57, so I think I'll wait until you are a bit further [20:09:56] sounds good [20:10:05] luckily all of these are structured similarly [20:10:13] so it should be pretty quick to figure out what the tables are [20:10:34] I'll leave it up to you to come up with interesting values to put into the tables :D [20:11:44] I'll stick as close to the LM table as possible I guess [20:13:59] for both the SPS and Saturn steering tests, the values in the table go directly into the CDUxCMD output counter registers [20:14:45] good to know [20:30:28] also I think there's a bug with the 1403 alarm [20:30:50] there is a TC 0 where I think they meant to have TC +0 [20:31:05] so I'm pretty sure if you get the alarm it will also restart the AGC [20:46:07] ouch [20:46:23] good night! [01:20:30] I think it works now: https://github.com/n7275/NASSP/tree/RRT_CONNECTORS_PANELBUG [01:23:26] It definitely works now. Completely confused here as to why, or what I could've missed the first half dozen tests or so... [16:28:28] morning! [17:08:24] hey [17:08:40] hey [17:08:54] what's up? [17:15:29] I tried again and couldn't replicated my issue. so I'm assuming it was either something really dumb, that I didn't see the first time, or some sort of "forgot to rebuild something" issue [17:16:01] ahhh, I hate when issues just disappear [17:16:05] it is unnerving, haha [17:16:43] it usally happens just after I publiclly ask for help... [17:17:18] but anyway, I'm inching ever closer to having this done [17:17:50] hey guys [17:17:59] yeah I had some of that kind of issues in the last time as well [17:18:02] really weird [17:19:37] indy91, I mostly finished reverse engineering and naming things in V47 last night [17:19:51] so I'm ready go give the other tests a go whenever you are [17:21:18] hey [17:21:37] hey Alex [17:23:56] hey [17:25:07] thewonderidiot, sounds good, we can do that in an hour or so [17:25:07] congrats on getting Sundance working guys! [17:25:19] thanks! [17:25:21] thanks :D [17:27:01] indy91, I heard you have tested OrbiterSound 5.0 with NASSP? [17:28:06] yeah, it is a pretty simple change [17:28:19] although the auto builds might need a change [17:28:38] have to ask dseagrav about it some time [17:30:13] I havent been amble to test it yet but I guess that is good news if it pretty much works out of the box [17:30:17] able* [17:30:56] is the low fps without sound issue still there? [17:31:32] well it's hard to reproduce [17:31:43] and I haven't tested it much yet [19:07:59] thewonderidiot, I am ready [19:08:07] woo! [19:08:12] so, first, TESTIDX [19:08:38] it can be 0, 1, or 2 [19:08:41] right [19:08:51] that was EMEM2147 [19:09:04] 0 runs jets, engine on/off, and channel monitor [19:09:33] 1 is the same, but also includes SPS steering [19:10:02] so I basically already ran a full option 0 [19:10:10] 2 is just Saturn steering and channel monitor [19:10:11] yeah [19:10:42] so I guess let's do SPS steering first [19:11:19] E4,1510 is TRIMSTEP [19:11:31] E4,1511 is NUMTIMES [19:11:56] E4,1517 is STEPDLYT [19:12:21] E4,1525 is TRIMONT [19:12:33] E4,1533 is TRIMPTCH [19:12:38] E4,1541 is TRIMYAW [19:12:53] seems straight forward [19:12:55] the first four are essentially the same as described in the Aurora PDF [19:13:14] TRIMPTCH and TRIMYAW are OPTXCMD and OPTYCMD count values, respectively [19:14:10] the time between steps is kind of dynamically calculated based on which of the two CDUnCMD commands is larger [19:14:17] have to read the Aurora doc again to see what STEPDLYT and TRIMONT really do [19:15:30] well the Aurora source code [19:15:45] the document does give a verbal description of them I think [19:15:56] pdf page 10 [19:16:38] that's copy and pasted from the listing :D [19:16:42] hahahaha [19:16:44] fair enough :D [19:18:57] I don't really get the difference between STEPDLYT and TRIMONT [19:19:12] I think STEPDLYT is the wait time in between columns [19:19:27] and TRIMONT is the delay between repeats of the same column (dictated by NUMTIMES) [19:19:52] ah, that makes sense [19:20:58] hmm, but that doesn't work that well for the CSM [19:21:10] uhh, yes it does [19:21:17] TRIMOFFT wouldn't make sense [19:21:38] right [19:21:49] I think I'll use 1 for all TRIMONT though [19:22:03] or I could use really small increments [19:22:14] like I was alluding to, TRIMOFFT is dynamically calculated in the CSM based on the magnitude of the count commands [19:22:17] like 1 time 2° and then 10 time 0.2° [19:22:38] yeah [19:25:22] ok, I'll come up with some numbers [19:25:56] maybe just one test at first, to see what it does [19:27:07] about TRIMSTEP, if that is 0, will that execute 1 test or no tests? Still a bit confused about that [19:27:16] THIS TASK WILL BE ENTERED BUT IMMEDIATELY ENDED IF TRIMSTEP AND NUMTIMES = +0. [19:27:21] I had first read that wrong [19:27:29] but that's an AND, not an OR [19:27:54] so if TRIMSTEP is 0 but NUMTIMES is 1 or more it will do the one test? [19:28:00] hmm [19:28:09] I think it will probably do one test [19:28:13] ok [19:32:43] got an alarm [19:32:44] 400 [19:32:59] nope, not an alarm [19:33:06] that's a please perform checklist code :D [19:33:10] ah of course [19:33:19] was just thinking that [19:33:26] whenever it's not 05 09 I am confused :D [19:33:30] hehehehe [19:33:34] okay so what's 400 [19:33:41] haven't gotten used to anything else, although I should have seen enough in Sunburst [19:33:58] bit 3, channel 30 [19:34:18] SPS ready [19:34:21] it wants that to be 0 [19:34:21] ah [19:34:42] that's the first CMC program I have seen that needs that I think [19:34:54] but I did indeed forget to make the SPS ready [19:34:59] hehehe [19:35:08] yeah I think this might be the only place that checks it [19:35:11] in all of the CMC code [19:35:36] weird that I haven't seen this in TESTIDX 0 [19:35:43] maybe I didn't forget [19:35:52] lol [19:35:53] TESTIDX 0 doesn't do this because it doesn't include SPS steering [19:35:55] now I get 401 [19:36:04] but TESTIDX 0 fires the SPS [19:36:14] heh, true [19:36:24] 401 wants channel 31 bit 15 to be 1 [19:36:55] sorry [19:36:57] wants it to be 0 [19:37:02]