[16:29:06] NASSP Logging has been started by indy91 [16:29:08] good evening [19:48:07] afternoon! [19:49:54] what's up? [19:52:34] making progress on building replica PSA modules to power the CDUs [19:52:39] and you? [19:53:14] I finally found something useful on LGC lunar ephemeris calculations [19:53:17] in the large contents_of_luminary_1e.pdf [19:53:39] a memo complaining how it was bad and inaccurate during Apollo 13 [19:54:34] about some constants in it: [19:55:03] "They were determined empiricially in Reference 2 by "eyeballing" a plot of the error function before the terms were included, but they do have a real physical meaning" [19:55:16] very sophisticated :D [19:56:37] hahahaha nice [19:56:48] oh wait a moment... [19:57:01] the memo gives some 1973/1974 values at the end [19:57:23] that's what I mainly was trying to calculate [19:57:24] buuuuut [19:57:34] it's for a slightly modified version of the equations [19:57:39] for the Skylab era [19:57:52] might still be the same, just with a new correction factor [19:58:03] oh weird [19:59:33] it also gives some procedures to use least squares instead, that is really the method I was thinking of using at first [19:59:43] probably better overall [20:02:48] nice Apollo 17 scans btw [20:03:10] one page gives some great hints what to adjust in the RTCC if you wanted to fly a CSM alone mission [20:03:39] a different, pseudo landing site to target with MCCs and LOI to meet all the orbital science requirements for such a mission [20:03:59] sorry, one page of the alternate lunar mission profiles document [20:09:07] oh great :D [20:09:19] yeah the price of those three got cut in half -- cheap enough that I figured I might as well haha [20:54:55] night! [16:08:06] hello [16:33:01] hey Matt [17:05:52] the moon's about to get right in the way of the sun here [17:08:09] I'm calculating its mean longitude of the ascending node, that's all I will get of the Moon today :D [17:16:06] for me it's the Sun getting in the way [17:16:42] the most complicated part of the LGC constants for the lunar ephemeris is the correction factors, which I believe comes from Sun gravity [18:05:01] oh interesting [20:42:54] night! [14:58:38] morning! [14:59:18] hey [15:09:09] what's up? [15:19:27] looking at one of my WIP projects again, the Apollo Generalized Optics Program. Still missing a few modes. [15:19:35] RTACF program [15:26:37] nice :D [15:27:49] hey guys [15:33:36] hey Matt [15:38:16] yo [16:34:32] thewonderidiot, I have a general PSA question. How stable is the voltage it outputs? [16:34:49] depends on which voltage you're asking about! [17:18:51] I was looking at the inputs to the IMU resolvers [17:20:32] that is quite stable -- there's an automatic amplitude control loop that is actively maintaining that at 28Vrms [17:26:07] okay, that confirms my thought that making they constant values in context of NASSP is probably for the best [17:28:14] oh yes definitely [17:28:45] it should be bang-on 28Vrms (I think the spec is +/- 1%) without much variation at all [20:56:00] night! [14:50:40] hey [14:52:22] morning! [14:54:38] what's up? [14:55:36] not a whole lot on the Apollo front this week [14:56:11] other than some noodling around on power supplies to drive the resolvers/CDU [14:57:02] making my way through the AGOP modes, I am (back) at the dreaded "point AOT with CSM" option again :D [14:57:32] hehehehe [14:57:43] why is it so dreaded? [14:57:58] because I still haven't figured out the rule behind deciding how to "roll" it [14:59:16] There are infinite solutions because there isn't one (3 axis) orientation to point the AOT. You have the choice how to roll the AOT view around. [14:59:40] I see [14:59:51] there are many potential solutions [14:59:55] heads up/down for CSM or LM [15:00:08] minimizing the yaw angle for the CSM to avoid gimbal lock [15:00:48] in the actual examples of CSM attitudes from the Apollo 9 transcript it looks like they tried to put the CSM in front of the Sun [15:00:55] which can help with daylight AOT sighting [15:01:13] but that only really works with the first instance of pointing the AOT with the CSM [15:01:18] not so much the later case [15:02:00] in the ideal case I find a calculation that agrees with all the IMU angles from the actual Apollo 9 misison [15:04:46] sounds like an interesting puzzle :D [15:07:44] yeah haha [15:08:37] it's tempting to just find "an" solution, because calculate "a" CSM attitude to put a star at the center of the AOT is a solved problem. [15:14:04] in another RTCC calculation like this they basically try to make an attitude heads up, but if that leads to gimbal lock they switch to a different calculation method. If that happened in one case from Apollo 9, but not the other, then I will never figure it out as the two attitudes have nothing in common. Besides pointing the AOT at the star of course. [15:15:29] was this only done on 9? [15:16:20] I think so [15:17:18] because LM test flight [15:17:48] first case is a Daylight AOT Star Visibility Check, before the docked DPS burn. LM not really powered up, so, CSM has to do the pointing. [15:18:49] second case is after CSM and LM docked after the rendezvous. Testing how LM P52 works (with LM attitude control) while docked. They let the CSM do the main maneuvering to the attitude and LM just uses minimum impulse during P52. [15:42:46] I guess what is going to work the most reliable (also for the MCC) is an attitude that avoids gimbal lock. That is really the safest method. [15:44:57] how do I do that... [17:02:09] good afternoon [17:09:47] hey Matt [17:19:01] hey hey [18:52:28] hmm [18:52:39] C1061. compiler limit: blocks nested too depply [18:52:41] deeply* [18:53:21] RTCC MFD display code [18:53:51] I know it's all very inefficient, it's basically 100 if, else if, else if etc. deciding which MFD screen to show [18:54:00] but not 128 [18:54:17] but it's having a problem with a random else if inside that 100th screen [18:54:46] maybe, counting from the first if in the function, I am up to 128 including nested ones. [18:55:41] I guess I need to find a better solution for all the different MFD displays, one that scales properly [18:56:00] maybe a small class for displays and then have them on a vector or so [19:03:54] what about just a screen index number, switch(index) [19:04:49] enum screenIndex {...} [19:13:12] yeah switch is probably already an improvement [19:20:08] Are the actual MCC displays handeled differently than the regular RTCCMFD displays? [19:24:26] nope [19:24:34] I'd like a different system for them [19:24:59] with something equivalent for the background slide and a more generic system with the placement of the dynamic data [20:48:14] night! [13:32:26] good afternoon [17:39:21] hey Nik [18:06:09] what's up? [18:25:25] not too much. I have Monday off from work so I'm hoping the weekend is good for projects [18:26:59] ah nice [18:27:19] optics calculations are getting tiring, so I am looking at a bit at panel switch code [19:00:55] ooo continuous rotary switches? [19:01:07] yeah, I am trying haha [19:01:23] can I make a tiny request there? [19:01:30] best time to do it! [19:02:38] if those switches are e_objects (I can't remember if they are), can they have an output voltage that scales 0-100% of input with rotation? [19:03:57] all switches are from the PanelSwitchItem class and PanelSwitchItem is an e_object [19:04:12] yeah I was just looking at the best output method [19:04:23] working with the SPS gimbal trim thumbwheels [19:04:53] how that works might depend on the specific switch [19:08:07] for those the TVC servo power supply uses +/- 15 VDC [19:08:14] so that would be the correct output from the switches [19:09:06] There already is an issue [19:09:15] redundant power supply [19:09:51] both thumbwheels control two sets of voltage each [19:10:19] how do we handle that with e_object? [19:13:14] and that isn't like some other two input or output switches we use [19:13:27] it's two inputs and two outputs, separate from each other [19:56:14] yeah, there a few different permutations [20:00:57] could be as simple as a special new class where one e_object is the thumbwheel itself and the second one lives inside a new class [20:25:26] I might have a half-finished branch for this on github [20:25:57] more likely it's a half-started branch though... [20:35:17] haha [20:35:54] I've got something going in the VC. Already encountered some floating point stuff with switch positions being for the first time a double instead of an int. [20:36:15] it's only playing the click sound if the thumbwheel has been moved [20:36:35] if I go from -4.0° to 4.0° on the gimbal trim then it actually goes to 3.99999999° [20:36:44] so I get another click when it actually runs into the 4.0° limit [20:54:21] night! [12:56:48] good morning [13:01:31] hey Matt [13:06:10] making some good progress I see :) [13:12:58] yeah, I think so. Still a way to go, but, the good thing is that there aren't really a ton of switches that this affects. Not too many special case. [13:13:00] cases* [13:15:42] speaking of special cases, with the rotational switches I have to check about any output voltage [13:18:17] if there is one one source then output voltage should be pretty simple for these classes [13:18:22] all switches really [13:18:29] WireTo the switch to something [13:18:44] and then there just has to be a simple function for the output voltage [13:19:48] HGA pitch and yaw controls are of course a bit of a blackbox in the Systems Handbook, the whole HGA is [13:20:23] AOH doesn't even give a power source [13:23:23] schematics having wiring from the HGA itself [13:23:29] makes sense [13:34:01] for the HGA switches I wonder if it's like a synchro with an AC signal coming in and sine and cosine outputs going to the HGA resolver inputs [13:35:42] yep, schematics say 26 VAC [13:35:55] and the resolvers are in the panel [13:36:26] so power from the HGA and the HGA gets the resolved signals back [13:37:41] so again not a simple case of WireTo the switch to something and whatever wants the output from the switch does a WireTo the switch. Wouldn't work. [13:37:53] I hear your suggestion with the scaled output voltage, but, it's complicated :D [13:43:20] maybe we make keep that one simple [14:46:36] hmm, it might be time for me to work on some HGA projects again. [15:02:27] sounds fun! [16:40:35] morning! [17:09:13] hey Mike [17:25:03] hi Mike [19:21:48] ah classic, I had most things working with the new rotational switch class, but I didn't like something so now I am rewriting everything again :D [20:06:39] cya! [14:39:25] morning! [14:39:49] good morning [14:40:02] what's up? [14:40:04] hey guys [14:40:50] VC and 2D are both happy with my new thumbwheel and rotational switches classes. A bit of cleanup to do, now I will try to use it for the LM steerable antenna knobs, too [14:41:06] still have to test with the checklist MFD [14:44:33] checklist MFD complicates things. [14:44:56] we already have a solution [14:45:00] EMS DV counter [14:45:14] if you want e.g. 130.1 ft/s on it then you need to put 1301 in the checklist file [14:45:25] I am doing the same, in degrees, for these new classes [14:45:39] so 3151 for 315.1° [14:45:56] all checklist have to be changed, but the new system is more intuitive [14:46:20] previously it was the integer switch positions counting from the first one, so the conversion from switch position to degrees wasn't easy [14:47:43] as long as there is no rotational switch that needs finer adjustments than 0.1° that should be fine [14:48:50] it's only a few rotational switches and thumbwheels I will use these new classes for [14:48:57] all the lighting knobs, too [14:51:19] the worst new code in all of this is converting a double animation state to the rotational switch bitmap [14:51:31] it used to have 30° increments from left to right [14:51:44] we added a second row of 15° increments in between [14:51:59] our standard rotational switch class simply maps one switch position to one bitmap [14:52:13] of course that doesn't work with my new class [19:34:23] sizeof(IntegralLights_P8)/sizeof(IntegralLights_P8[0]) [19:34:32] apparently sizeof is evaluated at compile time [19:34:40] so that makes this ugly, but efficient :D [19:34:50] what do you think thewonderidiot n7275 [19:35:29] these come from arrays like this [19:35:30] DWORD IntergralLights_P8_NTex[] = { [19:35:31] // TODO Material List [19:35:31] VC_MAT_CWLights_P8_t, [19:35:31] VC_MAT_EMS_Scroll_Timer_P1_t, [19:35:32] VC_MAT_FDAI_Ball_t [19:35:32] }; [19:35:50] globally defined, which is probably not so good either... [19:37:41] I'm having a hard time coming up with something that is really better [19:39:35] that's a pretty standard way to get at array length in C [19:39:39] hmm, why do we need sizeof again? [19:39:43] usually it's wrapped in a macro -- e.g. https://github.com/thewonderidiot/magc/blob/main/src/utils.h#L6 [19:40:16] oh I missed that it was for array length, my bad [19:40:56] there is an automatically generated header file from meshes, in this case materials [19:41:09] like these VC_MAT_CWLights_P8_t [19:41:12] they are all #define [19:41:46] And then these arrays are meant to combine all materials that are manipulated by a specific function, e.g. a lighting switch [19:42:13] the function to manipulate the material is then doing the same thing to all materials in the array and for that it needs the size of the array [19:42:49] the code to update the material property is run on every timestep [19:42:59] so I thought this might be a very inefficient way of doing it [19:43:29] thewonderidiot, I like that macro solution. Also at compile time, right? [19:43:40] yep! [19:44:17] so it just becomes NUM_ELEMENTS(IntegralLights_P8) and is just as efficient as if you use a hardcoded array size value [19:44:29] exactly [19:44:34] that's great [19:44:40] I think I will do that [19:44:46] yeah, that sounds like the way to do it then [19:46:19] we have a nassputils.h which currently just has a vessel class comparison [19:46:44] nasspdefs.h has a bunch of defines, but not really macros [19:47:27] I'll put it in the utils I guess [19:51:03] good spot for it [20:53:23] night! [15:17:00] hey [15:29:49] hey Nik [16:08:39] hmm, I'm getting some cunfusing results from some P22s [16:12:31] *confusing [16:14:34] this is why I should do a bit more flying, and a bit less "messing with the systems code" haha [16:15:45] is it not pointing right? [16:17:07] no, I'm getting all 0's for N49 [16:17:18] w-matrix issue? [16:17:30] on most missions this is on purpose [16:17:39] the W-matrix init values are padloaded as zero [16:17:56] the P22s aren't really done for onboard navigation but more for landmark and landing site measurements [16:18:30] ahh, okay [16:19:04] well that makes sense [16:19:44] in all CMC padloads we have they are zero [16:19:57] on 7 and 9 they wouldn't be zero [16:20:04] probably also not 8, not 100% sure right now [16:21:24] I'm probably remembering those then [16:22:23] morning! [16:24:58] hey Mike [16:27:55] hey [16:29:22] yeah 8 is a bit of a question mark. For 7 we have some documentation for the W-matrix init values for P22. [16:29:53] but as far as I can tell, from 10 on they were always kept zero so you would always get zero N49s in P22 [16:30:02] leading to some people thinking they have done perfect P22s :D [16:32:29] I'm not really sure what that means for the state vector [16:32:39] if it isn't getting updated at all by P22 [16:35:39] probably [16:35:46] N49 zero = no change in state vector [15:08:13] good morning [15:10:00] hey hey [15:17:27] morning! [15:27:55] hey Mike [15:40:13] what's up? [15:45:01] trying to come up with a more efficient method of getting a list of active cue cards, for internal cockpit lighting [15:45:37] right now it generates a new list on every timestep [15:45:48] it would be good enough if the list changes when cue cards change [15:46:29] I'm good at prototyping solutions that work, I am bad at finding efficient solutions I am happy with :D [15:52:43] hehehehe [16:22:21] I'm making some progress on how I want to power these resolver -- getting close to the point of ordering parts for breadboarding :D [16:23:09] that's exciting [16:23:17] oh yeah, that is getting close :D [17:27:39] I'm happy to report that DOI works way beter when the DPS gimbals aren't at their limits at ignition [17:40:37] that is good to hear :D [20:46:12] night! [14:54:25] good afternoon [16:16:01] hey Nik [16:44:56] morning! [16:52:06] hey Mike [18:16:36] n7275, do you know anything about the DX11 client for Orbiter? We are talking about it on Discord. [14:02:12] .tell indy91 https://www.orbiter-forum.com/threads/d3d11client-download-and-installation-instructions.23925/ [15:33:14] hello [15:36:05] hello hello [15:36:51] like I said, Dan's graphics client knowledge was about 10 years outdated :D [15:37:06] I've never tried to install this haha [16:18:50] yeah, I it looks like it never even made it as far as O2016 [16:19:44] the last post on that thread was someone trying to update it to R55, which is still 7 versions before the O2016 release [16:29:33] I wonder why that is. Is DX11 more difficult to work with? [16:33:52] morning! [16:43:49] hey Mike [16:44:08] what's up? [16:49:11] still tinkering with these rheostat-type switches [17:19:30] and you? Ordered something yet for a breadboard? [17:20:00] not yet, scanning the Block I AOH is taking too long [17:21:59] ah I had instantly downloaded that, but haven't had a look yet [17:23:10] some interesting stuff in there. "Targeting Worksheet P24 Orbit Change" [17:23:45] some onboard techniques that you never get later as the programs for it were deleted [17:53:04] nice :D [17:53:13] yeah I haven't really looked through it much either [17:54:06] but just having a little bit of nominal procedures for Sunspot will be super helpful [17:54:10] I need to get back to that [20:30:11] night! [17:15:30] good afternoon [17:17:38] hey hey [17:23:04] what's up? [17:28:07] oh not too much. I've been super busy lately, hasn't left much time for projects unfortunately [17:28:32] booo [17:29:03] exactly [17:30:25] I have been making some slow but steady progress on my Apollo 11 mission with IMU drift though [17:31:09] drift compensation works so well I keep thinking I'm in the wrong branch [18:04:40] that is excellent :D [18:05:02] I'm excited for that to make it into the main branch :D [19:04:50] I am too. I was planning on taking Apollo 12s out rather than re-scaling, however....I'm now thinking I might leave it in [13:00:05] good afternoon [13:32:56] good afternoon [13:33:55] I guess we should update non T-4h, but still prelaunch scenarios more often? :D [13:43:46] yeah, I think so [13:44:05] I thought I did that actually. I guess not. [13:44:31] not completely from scratch I guess, just with the script [13:52:51] the ORDEAL altitude control is currently giving me trouble with its animation range [13:53:53] I'm probably doing something the Orbiter API doesn't want me to do [13:54:06] standard rotational switches have a 360° animation range, always [13:54:31] and you then have to set the animation state (0.0-1.0) to the reasonable values for the limits of a specific control [13:55:00] my new class defines the correct rotation range [13:55:08] and uses animation state 0.0-1.0 for it then [13:55:49] problem with the ORDEAL, in the mesh the knob is set to 0 NM altitude [13:56:06] which is beyond the lower limit of the switch [13:56:22] so I would have to to -0.03333 as the initial animation state, which is apparently illegal [13:57:09] oh, maybe 0.9666666 actually works [13:57:22] ah no, doesn't make sense [14:04:01] I think I will check if at least my math is correct by allowing the altitude range 0-310 instead of 10-310 [14:23:11] my math was indeed right, you just can't use a default animation state outside of 0-1 when using CreateAnimation [14:34:10] ahh okay [14:40:11] I'm still having a weird PDI issue [14:41:21] attitude? [14:42:41] I had loaded your scenario, I thought maybe it was just the ORDEAL leading you to a wrong pitch, but I couldn't tell exactly without checking and asking more [14:44:32] for about 1 second I thought you had set the ORDEAL altitude wrong, but then I remember what I was working on... [14:44:40] remembered* [14:49:45] it's probably my branch, but that scenario really enjoys CTDing upon load [14:50:46] something with VC redraw events I need to check, maybe I broke somethng [14:50:58] the scenario loaded once for me so far, after a full rebuild only [14:54:46] yeah atr [14:54:51] attitude [14:54:59] is wrong [14:55:22] 180 180 0, rather than 180 287 0 [14:56:08] almost exactly prograde [14:56:38] sounds like REFSMMAT or IMU [14:56:41] but alignment was good, good sun check. and the state vector appears to be okay [14:56:43] hmm [14:56:54] and this is the attitude that P63 gives you? [14:57:01] yes [14:59:12] I've re-run DOI all the way to PDI and it appears to be consistent at least [14:59:36] I always tend to suspect I'm the problem but this is an odd one [15:02:26] debug mode had me crash again, another undebuggable issue [15:02:44] I have to review the panel areas I changed in my branch, probably some issue with that [15:03:06] full release rebuild worked the last time though, hopefully it loads now [15:03:42] I doubt it is any IMU scenario changes from your branch [15:03:50] those look simple [15:03:56] ok, it loaded [15:04:51] REFSMMAT looks fine [15:05:05] IMU alignment fine [15:06:06] RLS fine [15:07:11] good state vector [15:07:34] good clock [15:08:39] good TEPHEM [15:09:58] hmm I guess next I would actually check some of the P63 padloads [15:12:32] I can double check those later. I wonder how I would've messed those up [15:13:19] wrong address at first when loading TEPHEM, or something like that [15:13:33] but the PDI TIG looks right, so [15:13:48] at least mostly the P63 targets have to be correct [15:16:37] I'll do another P52 option 1, maybe it's some new IMU math code that broken something [15:17:49] P63 padload looks right [15:20:37] morning! [15:23:02] hey Mike [15:23:06] n7275, P52 was happy [15:23:16] really strange, what else could cause this... [15:25:08] the trajectory can't be too bad, or else the PDI PAD would have something similar [15:25:51] and more crashes [15:27:59] I might need to check this in the Orbiter2016 branch if my branch is too buggy haha [15:36:59] still crashes [15:37:04] something really buggy is going on [15:37:59] I think my branch is behind a bit, that might be the issue [15:38:04] with the crashes [15:38:45] hi Mike [15:43:57] would be nice if an outdated scenario is the explanation and not terribly buggy code... [15:58:06] ooooh [15:58:12] I should have remembered [15:58:30] scenario crashing plus debug mode leading nowhere equals Checklist MFD change breaking something [15:58:40] I need to try if that is the issue [16:00:30] if not, well, I am 2 out of 7 for actually loading your scenario without CTD... [16:00:57] am I allowed to blame the missing SM panel on Checklist MFD code? :D [16:01:43] sadly more CTD [16:02:21] so not the checklist [16:12:28] the missing panel is the final boss of NASSP [16:15:13] right now loading your scenario already feels like a boss fight :D [16:15:39] I can sort of accept it might be because of an outdated branch, but, I still want to know how it faisl [16:15:41] fails* [16:32:41] the failure is in the code for the new integral lights [16:35:46] oh, that makes more sense than anything IMU related [16:36:18] that's probably broken some old scenarios then [16:37:31] it shouldn't, but it has. Have to debug deeper. [16:38:12] DEVMESHHANDLE hMesh = GetDevMesh(vis, meshidx); [16:38:20] on this step it crashes [16:46:59] I think it is as simple as "vis" not being initialized to NULL [17:00:04] why I do have the feeling the majority of our problems are uninitialized variables [17:00:33] that plus checklist stuff and you got the worst bugginess in NASSP described [17:11:05] now I can actually load your scenario n7275 haha [17:11:20] nice [17:11:25]