[15:34:17] NASSP Logging has been started by indy91 [15:34:19] hey [15:46:07] hey Nik [16:10:24] what's up? [16:11:27] morning! [16:17:49] hey Mike [16:23:33] hey [16:23:53] OO gravity model becoming annoying for the RTCC, as predicted :D [16:25:50] something you're working on or did I miss something on discord [16:26:52] it's quite the source of chaos [16:28:34] "Checklist Issues" thread on Discord [16:28:47] Ryan is flying in OO and getting 525 alarms with the RR [16:29:03] could be the gravity model [16:29:12] the solution would be procedurally [16:29:27] saving CSM and LM SVs at the same time in the RTCC, saving one for uplink later [16:29:44] so that, at least relative to each other, they are good [17:00:24] I have a silly question: is there ever any circumstance in which the IMU operate breaker would be closed but the AGC breaker would be open? [17:14:59] isn't that done on Apollo 7? or is it the other way around [17:15:09] I don't think so, unless it is part of a specific power down checklist [17:15:21] reply to Mike, not Matt [17:16:34] maybe in an emergency situation you first want to preserve the IMU attitude [17:18:43] does the IMU need any AC? [17:18:48] power [17:19:05] uhhh that is a good question [17:19:24] I don't think it needs bus AC; but it does need the AC produced by the PSA [17:19:37] which will turn on with IMU OPERATE [17:19:39] right, but no AC circuit breaker then [17:19:48] yeah [17:19:53] even in the emergency power down checklist the pull the IMU breakers first [17:20:03] followed by standby mode [17:20:07] they* [17:20:50] long lunar stay config for the LM is also IMU breaker open, LGC in standby [17:22:02] what I'm trying to figure out is if this is just a useless config that they never went into because there's no reason to, or if it is dangerous to the hardware to do this [17:27:27] not exactly what you are asking, but the LM AOH has this note [17:27:29] "The LGC must be in the operate mode when the IMU is switched to operate, because IMU moding is performed by LGC commands. If this requirement is not observed, the IMU, which places itself in the cage mode at initial IMU operate turn-on, will not disengage cage automatically" [17:28:27] the exact ask is "am I going to break my CDU if I'm not careful about having all AGC inputs supplied when I give it power" :) [17:28:43] haha [17:28:49] "The CMC must be in operation at any time IMU operate power is applied [17:28:50] to ensure control and protection of the IMU, including proper moding, [17:28:51] caution and warning functions, and synchronization pulses." [17:35:05] hmmm yes lots of concern about the IMU, which makes sense [17:35:19] CDU risk is a mystery though [17:44:24] hmm right [17:51:20] Apollo 13 had all these CBs pulled, I think [17:51:32] the famous activation checklist powers up CMC first, IMU later [17:53:18] much earlier, during power down: [17:53:20] 058:12:19 Lousma: Odyssey, Houston. We need a command reset on your - on your Comm, and then we'd like you to power down to CMC, power down the IMU, heaters off on the IMU, but leave the battery A on. [17:54:03] Jack switches the order on us [17:54:05] 058:14:52 Swigert: Yes, Jack. I read it back twice to you. Command reset, which I've done. I'm about to power down the IMU, power down the CMC, turn the IMU heaters off, leave Bat A on. [17:58:00] emergency power down checklist always has you power down IMU first [15:58:12] morning! [16:28:55] hello [16:29:04] why did I even join, I have no time for anything today :D [16:29:26] hahahaha [16:33:50] hell [16:33:52] o [16:34:11] o/ [16:34:31] lol [16:36:49] got a little too eager to hit the enter key [16:44:20] hell'o, sounds Hawaiian [16:54:26] it does, a bit [18:31:27] ok now I have time [18:31:42] your IMU PR is still not merged, sorry haha [18:31:52] but I think it's actually done now [19:05:29] yeah, it should be good to merge I think [19:11:01] you forgot to remove LoadIMU_AndPIPA_RatesAndBiases from Mission.h [19:11:08] interesting how that doesn't give a build warning [19:12:36] oof [19:13:26] sometimes that gives at least a linker warning or so [19:13:39] maybe it's disabled somehow, who understands the NASSP build structure [19:15:30] should be good now [19:16:48] it's possible that I commited and forgot to push. the branch on github should be okay now though [19:18:33] yep, I saw the update [19:20:45] sorry for micro managing, but there is another thing, must have gotten lost in a merge commit [19:20:49] GetLMCWEAVersion [19:20:54] got removed from upstream [19:21:01] you also only have it in the Mission.h left [19:21:04] not cpp anymore [19:21:09] https://github.com/orbiternassp/NASSP/commit/2f7587e3721c9e6cba689bd8e33dc79a5f34e450 [19:21:11] this removed it [19:22:46] yeah, I didn't do that merge very well [19:22:55] your PR adds it back is what I mean haha [19:23:14] I'm just going through this: https://github.com/orbiternassp/NASSP/pull/1030/files [19:23:43] satsystems.cpp still has a FILE *IMUDriftLogger; [19:25:30] if you want to make it 122 instead of 123 files changed by your PR :D [19:29:10] I'm slightly annoyed that the padload generator doesn't give the exact Apollo 9 LGC padload due to their "octal conversion tables" [19:29:48] but I am not sure I can do much except to make the engineering values worse to give the right octals [19:40:09] I've finished checking your PR. All mission files and scenarios are good now. [19:40:24] Just those two tiny pieces of obsolete code left. [19:41:23] after your PR is merged I will do that cleanup of the mission file so that you get all the correct settings for a specific LM (and later CSM) by specfying a LM number in the mission file [19:41:45] instead of having to set every configuration thing individually [19:42:26] I also need to check then what is left to get to the flown padloads [19:42:50] I think it's just the correction terms for Earth and Moon precession/nutation [19:42:57] and in the CMC the ephemerides [19:43:21] We don't have the real ephemerides tape data, if that even still exists [19:44:30] because of the universal vs. ephemeris time difference that we have in Orbiter we would at worst get a difference in ephemerides time tag in the padload, everything else could be identical to as it was flown [19:44:54] Maybe I will work out a precession/nutation system for OO, could be my contribution for it [19:45:08] wouldn't have to be much more complex than it is now, precession already is supported [19:45:25] was it just the declaration of GetLMCWEAVersion() in mission.h? [19:45:26] then those padloads can be exactly identical, too [19:45:52] and the code comment just above the GetLMCWEAVersion() [19:45:59] which you forgot to remove just now :D [19:46:11] /0 = LM-7 and before (ASC PRESS LOW before staging, RCS for HEATER FAILURE CAUTION), 1 = LM-8 and after (both cut and capped) [19:46:32] your PR also still adds [19:46:32] FILE *IMUDriftLogger; [19:46:36] in satsystems.cpp [19:47:13] Mission.h is perfect now [19:47:53] 122 / 122 files viewed [19:47:57] it's done :D [19:48:04] yay [19:48:21] I don't think we can do much more checking, we have done plenty [19:48:42] I could have flown a full mission with your PR I guess, uhh, but others have done it for me haha [19:48:44] thank you for that, by the way [19:49:15] yeah, Ryan has flowm a bunch of 10. I flew 11 through rendezvous [19:49:42] sure! I don't want people to complain about badly behaving IMUs any more than you do :D [19:49:58] like the antennas... [19:51:49] I like the HGA in reacquire mode at certain attitudes, drives back and forth haha [19:53:59] I think I can fix that one [19:54:40] the fact that the LM antennas can receiive signal through the moon is a bit more of an immediate concern [19:54:56] I think we were thinking about a more gradual skin reflection zone signal loss [19:55:08] oh that [19:55:11] uhh [19:55:27] could it have to do with the MCC not getting LOS during an uplink? [19:55:42] or is the AOS/LOS logic not done separately for the LM... [19:55:43] at least that's what discord says [19:56:03] I approved your PR and it can be merged when you want [19:56:40] I think it might be missing the check for the moon being in the way [19:57:10] I have a writeup ready to go when I get home later, you can merge it now if you want [19:57:22] hooray! [19:57:33] nice work guys :D [19:57:42] that's in "AutoUpdateXmitGroundStation" and it is done separately for CM and LM [19:57:59] but maybe there is a bug [20:00:22] n7275, does your readup include a warning not to update during a current mission? I guess that warning is relevant for all bigger NASSP updates though... [20:00:27] writeup* [20:02:03] that's a warning I include for all of my updates :) [20:06:04] I'm pretty sure the LM S-band antennas should have the "moon in the way" logic [20:06:08] that is done in the MCC [20:06:27] and the antennas should just get this [20:06:30] RFtemp->Gain = 1.0; [20:06:31] RFtemp->Power = 0.0; [20:06:35] with no transmitting ground station [20:13:58] hmmm [20:14:03] you're right [20:16:12] I wonder if it's a bug in the calculation of the Moon being in the way itself [20:16:19] maybe if you are below the Moon radius [20:16:55] I can check if that could be the case [20:36:55] oh [20:37:13] I think there is a bad math error if you are below the lunar radius [20:38:12] so none of your code at fault :D [20:42:33] I guess I can't come up with any excuse to delay the merge anymore, even if it's a scary PR to me :D [20:43:00] it's merged [20:46:06] padload generator main branch updated [20:51:28] night! [20:51:33] good work Matt [15:29:25] hey [15:42:34] morning! [15:42:59] hey Mike [15:43:53] what's up? [15:45:19] fixing a little bug with the AOS/LOS calculations in our MSFN [15:46:07] not something for n7275 to worry about this time, all my department :D [15:47:53] ah nice :D [15:48:49] and you? [15:49:20] ah nice [15:49:29] good answer :D [15:56:15] apparently the answer to that is "getting kicked off of IRC" lol [15:56:32] but, I have some boards to assemble today [15:57:46] oh fun [16:01:12] and if they work, we should be able to get the DSKY 100% powered up and working this weekend [16:01:31] and finally answer the longstanding "can you hear the relays when the display is updating" question [16:04:36] and then we start playing the game to guess a program based on sound [16:04:47] hehehe [16:05:48] if I hear nothing for minutes my guess is P37 [16:17:32] hey guys [16:19:46] hey hey [16:20:01] hey Matt [16:22:15] how does it feel, being out of a huge ongoing project to fix and keep up-to-date [17:55:57] indy91, it feels like I need to start another one soon :) [17:56:05] got any ideas? [17:56:49] well I keep saying telemetry will be next... [17:57:12] But I'd also like to not paint us into a corner with that [18:04:21] I also need to update the compressability for O2 and other cryo liquids [18:04:42] so that the fans behave better [18:07:03] I still like the idea of having a RTCC separate from Orbiter that is entirely standalone except for telemetry via TCP/IP and a plugin to get a bit of data from the Orbiter API [18:07:37] oh and it better has 4:3 aspect ratio displays :D [18:08:44] ECS stuff is probably a project where you need to understand more what you are doing, but it's less work [18:08:55] that's the pros/cons [18:28:31] I think for the external RTCC whatever data is going between the RTCC and Orbiter should be "packaged" with metadata [18:37:37] I wonder what data from Orbiter we actually truly need [18:38:00] state vectors of vessels, current simulation MJD [18:38:25] a lot of the other stuff in the RTCC MFD that it asks the Orbiter API for is only there for convenience [18:40:23] I should write a concept for this [18:40:39] like, which problems exist and in which order they should be solved [18:41:02] stuff like the loading of data from "tape", what format is the systems parameter file in etc. [18:41:17] followed by how inputs are done, how displays should work etc. [18:43:49] and before all that, how should it be started in Visual Studio [20:23:12] ahhh I will not be assembling the boards today, because in design I neglected to neurotically confirm that what KiCAD calls a 1206 resistor array matches what Digikey calls a 1206 resistor array [20:23:23] these parts don't even come close to fitting the footprints lol [20:23:25] whoops [20:30:10] oh no haha [20:35:18] https://i.imgur.com/RBhVnmp.png [20:35:44] sometimes you can solder components down to incorrect footprints... but not this time :P [20:37:15] https://images.dailykos.com/images/844266/story_image/BBNzkps.jpeg [20:38:09] hehehe [20:40:21] I think I understand why NASA loved their Gauss-Jackson integrator [20:40:24] https://i.imgur.com/HP4gWzm.png [20:41:09] definitely has its downsides, so it's not like superior to Runge Kutta in every way, but, apparently quite nice for orbital propagation [20:41:15] oh wow, yeah! [20:41:34] and that is with 2 instead of 4 calls of the acceleration function, usually the most expensive part of the integration [20:42:32] it's a backwards difference method, so you first need a different integration method (RTCC uses RK4) to generate a table of 7 acceleration vectors [20:42:41] and this method hates changing integration step size [20:44:19] it's a somewhat unintuitive method, but I am playing on easy mode, we have the Fortran code in the propagation control package MSC memo and a flowchart in the IBM RTCC document [20:44:50] just wanted to get a feel for it, it's the last complex concept from the real RTCC propagator that I hadn't really done a deep dive into [20:46:49] I can't say that I understand how to generate the integration coefficients, but, I managed to figure out the fractions that were used to generate the table for it [20:46:58] fun things like [20:46:59] 33953/518400 [20:55:34] night! [16:42:08] morning! [14:28:47] good afternoon [14:41:23] hey Nik [15:02:42] I should get the tweak burn displays, but I have too much fun messing around with the numerical integrators [15:02:49] displays finished* [16:40:54] morning! [17:30:00] hey Mike [17:57:02] hey Mike [17:57:08] what's up? [17:59:08] avoiding finishing projects :D [17:59:14] how is the DSKY? [18:00:06] Have you tried this by Pablo: https://dsky.ortizma.com/ It has DSKY relay sounds [18:00:13] nice touch [18:00:22] I saw it but haven't played with it yet [18:00:33] it makes me want to write EMPs to do funky things with the display :P [18:00:44] I immediately started P37 [18:00:51] took a minute to program alarm [18:01:02] doesn't work in lunar orbit apparently :D [18:01:07] hehehe [18:01:36] but DSKY is good, I need to test my board but I think we're still on track for a full powerup this weekend [18:03:33] also making good progress towards powering up the CDU [18:05:57] sounds like all up testing [18:09:29] I am going to run a few more individual module tests on the CDU... mostly just to make sure that the 14V rails are actually 14V, and the output waveforms from the input pulse transformers are within spec [18:09:45] but yeah, I'm not sure how else to really test a CDU without it being an all-up test [18:12:03] do you have the input signals from the AGC connected? [18:15:12] which of the three types of CDUs have you set it up as? [18:19:42] three types? [18:19:46] uhhh [18:20:09] my plan at first is to just connect the clock from the AGC [18:20:16] I think I can let the others retain their default states [18:20:36] IMU, Optics, RR CDUs [18:21:04] is this the whole box with 5 CDUs you are powering up or one of the modules in it? [18:21:13] I'm doing the whole box [18:21:20] so it will look like a LM CDU [18:21:30] right [18:21:39] well kind of [18:21:43] half LM CDU and half CM CDU :P [18:22:14] yeah I remember it being a wonky setup haha [18:26:26] if you want to be pedantic with your breakdown, there's really 5 types of CDU [18:26:42] LM IMU, CM IMU, optics shaft, optics trunnion, and RR [18:27:45] yep [18:29:30] good luck steering a Saturn with a LM ICDU [18:29:57] oh my god [18:30:12] I wonder if there is any way to make Sunburst steer a Saturn IB [18:30:30] with its abort programs, modified lunar ascent guidance [18:31:01] hahahaha that would be fun [18:32:05] it might fail due to some assumptions about thrust and weight loss rate [18:32:38] those saturn circuits also unfortunately aren't actually wired to anything on a LM CDU backplane [18:32:51] so even if you plugged the IU into the CDU, it couldn't do anything [18:32:59] it has a thrust filter, so it will use measured thrust [18:35:13] also updates exhaust velocity [18:35:28] haha there might be no guidance reason why this wouldn't work :D [18:36:29] nothing hardcoded that only works with a LM, I think [18:38:50] so basically I would have to inhibit LM separation in the contingency orbit insertion sequence [18:39:02] better also inhibit RCS... [18:42:05] lol [18:42:07] ah we have no LM to IU connector yet [18:42:12] that is a big missing piece [18:42:47] we only have a LM to SLA connector [18:42:53] for LM/SLA sep [18:43:00] which Sunburst can command [18:44:51] that wiring probably didn't exist for a LM on a Saturn IB, but wouldn't have been difficult to add I imagine [18:44:57] they had it for CSMs [18:45:13] and some signals from the LM went to the SLA, why not a bit further to the IU [18:46:07] but yeah definitely some code missing for this, so, not something I would just try right now :D [18:46:22] but definitely possible, even pretty realistic [18:48:08] lunar ascent algorithm isn't as DV optimized as the IGM algorithm but I think it would still work pretty well all the way from S-IB/S-IVB staging to orbit insertion [18:48:27] it only doesn't work with the LM alone because it misses the thrust and total DV [20:14:24] it would be really interesting to see how it performs [20:50:31] I do at least have a bit of hope that it would work [20:50:45] night! [13:18:02] good morning [13:25:49] hey [14:32:46] indy91, you and I should try to figure out what an orbiter to external-rtcc interface would look like at some point [14:35:23] maybe a little plugin that you activate in Orbiter that sends the data? I have no clue about the exact interface protocol to use though [14:35:47] there is really only a small number of Orbiter API calls that you need to forward to get started [14:36:09] we, not you [14:36:22] basically sim MJD and state vectors [14:36:43] of course there are more things the current RTCC gets from the APIs, but only for convenience [14:36:45] like masses [14:37:28] data directly from the AGCs that should actually be taken from telemetry, so once that can be processed we easily get it in the external RTCC, too [15:09:55] my thought was that we'd send something that roughly approximated the frames that the ground-stations send back to GSFC [15:10:24] with a bit of Orbiter metadata in the headers [15:11:20] by frames you mean the telemetry? [15:11:55] that can be done as you like it, I am more thinking about how to get ground station tracking data to the RTCC [15:12:23] easy way is Orbiter API state vectors, difficult way is radar measurements [15:13:32] but radar measurements still would have to be faked with Orbiter API data [15:16:18] morning! [15:16:24] hey Mike [15:17:04] Pablo's DSKY thing inspired me to make something stupid last night [15:17:24] by frames I mean the "packets" of network data that the MSFN forwarded back to GSFC [15:18:04] is that both telemetry and radar data then? [15:18:31] ooh what did you make Mike haha [15:19:36] telemetry, ranging, station ID, time [15:20:13] then the plugin or whatever we will have on the Orbiter side will have to generate data for that [15:20:44] for ranging specifically [15:20:55] yes, exactly [15:21:25] should it maybe access the MCC list of ground stations? It will need to use coordinates [15:21:37] or should be it be separate [15:22:32] the branch I'm working on right now has this running in a thread in the MCC class, so it has access to what the active ground-station is [15:40:54] ah fun [15:41:04] from there it would also be easy to include other Orbiter API data [15:48:48] lol, Ron accidentally linked the Skylark source code as "Artemis048" [16:31:08] heh [18:10:59] I bet Artemis 48 was full of MINKEY bugs [18:11:55] oh man yeah [18:12:00] ...if it even had MINKEY [18:12:15] apparently that was added between revisions 46 and 51 [18:12:25] so maybe not even quite there, but if so, certainly a mess :D [20:17:01] night! [15:55:12] morning! [16:04:04] good morning [16:42:19] hey guys [16:47:58] next RTCC project would be a descent planning processor cleanup up oh man, it has the worst ratio of "implementing directly from a flowchart" to "understand what the hell it even does" ever, I really made a mess of it. [16:50:05] I think that was the last project before I decided that everything new I would implement had to be done a bit more structured [18:26:08] hahaha so you mean that it is highly flowchart-derived without a lot of thought behind it? [18:37:00] Yes. I thought there was thought. Trying to use any of the non-standard modes of it... apparently not. [19:28:20] hehehe [21:10:15] night! [16:53:00] good evening [17:13:05] morning! [17:13:28] today we potentially get a DSKY fully working :D [17:14:39] hey Mike [17:14:43] oh awesome :D [15:35:17] thewonderidiot, nice N18 you got there :D [16:15:30] morning! [16:15:32] thanks haha [16:17:02] what is that driven by? [16:17:19] The DSKY being a dumb relay box without its own brain, unless you put one in :D [16:18:20] it's connected to this through a harness I built up: https://i.imgur.com/5eiwziO.png [16:18:26] that FPGA board is running my FPGA AGC [16:18:48] and the rest of the circuits on there implement the I/O circuits in the AGC interface modules [16:20:01] awesome [16:22:11] and then of course I loaded into that the Apollo 11 PDI erasable state that you gave me like 6 years ago :P [16:25:38] I don't think our current scenario has a much superior erasable than that haha [16:25:58] P63 ignition algorithm is happy, so most things have to be right [16:56:26] hey guys [16:59:16] hey hey [17:05:18] hey Matt [19:40:42] I might have to rewrite the LDPP from scratch just to understand all parts of it :D [19:42:08] hahahaha uh oh [19:43:36] the three modes of it we commonly use work well, everything else is really garbage [19:48:56] the other modes are mostly for salvaging a mission after a bad LOI. Plane changes, Hohmann transfer back to a reasonable orbit etc. The LDPP could have had its shining moment when there was such a case on a mission by Residuals... and it failed in all regards :D [19:58:08] lol [19:58:22] good work, LDPP [19:58:44] p for pain, not for planning [19:59:16] I should call it LDP, they always leave out the "processor" when the FIDO talks about it in the MOCR [21:09:59] night! [15:29:17] hey [18:22:42] thewonderidiot, if there are descriptions of each variable, what is D.VTIB in the SA-512 lisiting? [18:23:26] TIME-TO-GO TO S-II EMRC IF GUIDANCE FAIL. [18:23:55] ah right, the backup to the new "characteristic velocity" accumulation I have no sources about :D [19:19:15] hi guys [19:28:34] hey Matt [19:33:33] hey hey