[11:20:48] NASSP Logging has been started by n7275 [11:20:50] good morning [14:06:55] hey Matt [14:27:55] Earth orbit maneuvers [14:28:01] bane of my existence [14:47:30] haha. SPS-7? [14:48:25] yep [14:49:01] I'm following the operational trajectory. SPS-6 set the orbit up for 95 NM perigee, which has been going down a bit due to drag [14:49:14] and now apparently I should get a 97 NM perigee with SPS-7 [14:49:27] and the maneuver is normally near perigee [14:50:02] of course you can't do the maneuver below 97 NM then [14:52:32] which really limits the options [14:53:00] the actual mission was different. I thought it was mostly due to the lower than planned orbit (SPS-5 residuals) [14:56:49] seems like the sort of thing that is difficult to automate [14:59:42] for our MCC that is [15:03:42] yeah, if we ever get the audio tapes for the Apollo 9 FIDO I expect/fear a lot of manual tinkering with the maneuvers [15:04:00] and them referring to some internal memos I don't have... [17:39:43] MPT is also not so helpful in this case, but I noticed some things aren't according to spec. I can improve that... [18:04:17] good evening [18:05:53] good morning! [18:09:08] what's up? [18:09:21] not much [18:09:31] I've been bouncing back and forth between Sunrise and Aurora disassemblies [18:09:39] too many interesting things to look at :D [18:11:09] how large is Aurora? Not filling all modules, is it? [18:11:17] same as the DAP Aurora? [18:11:19] 3 modules [18:11:33] no, DAP Aurora spilled into 4 modules because there wasn't really any space left in the original 3 [18:12:06] I wonder if/when they started thinking "shit, the whole lunar landing mission software has to fit in 6 modules" [18:12:25] haha that's a good question [18:13:39] in doubt you could get rid of the DAP I guess [18:13:56] and use the analog circuits, like Block I CM [18:14:31] slight ATCA redesign, but not much [18:14:53] but they had trouble on all fronts anyway. Memory, CPU [18:15:46] I've decided to cheat just a little bit with the Apollo 9 MCC [18:16:14] operational trajectory has SPS-6 perigee at 95, SPS-7 raises it to 97 NM [18:16:21] I'll just switch that :D [18:16:45] that makes sure even with SPS-6 residuals and drag that you have a perigee above 95 NM before SPS-7 [18:16:54] and that means, the maneuver works at any point in the orbit [18:17:21] if you are in a 97 x 130 orbit, then you can get to a 95 x 210 orbit at any time [18:18:37] if the right rotation that SPS-7 does happens only at 95 NM altitude and you want a 97 NM perigee... that's slightly difficult :D [18:23:43] that revision to the Apollo 9 operational trajectory has been steadily dropping in price on ebay [18:23:51] I've been keeping an eye on it [18:25:03] what I mostly need is just one more page :D [18:25:14] they were showing the first page of the summary [18:25:25] the lower half has the changes from the previous revision [18:25:34] there probably are a few more on the next page [18:25:51] but over all, I don't really expect any major changes [18:28:17] does any of that other stuff seem interesting/useful? [18:28:36] it all started out as expensive as the SCOT and has been similarly dropping [18:29:29] nope [18:29:40] except for the fact that there even was a AS-502 flight plan :D [18:29:45] haha [18:30:06] yeah I was checking the old auction [18:30:15] is that how things work on ebay usually? [18:30:21] depends on the seller [18:30:29] high initial price [18:30:35] wait for someone dumb enough to pay it [18:30:38] wait, put it up again [18:31:26] oh wait a minute [18:31:31] there are detailed maneuver tables [18:32:42] revision 1 didn't have that yet [18:32:49] that alone makes it more interesting for sure [18:32:57] not $300 more interesting [18:33:38] but if it drops a lot more [18:34:20] for the SCOT? [18:34:33] yeah [18:34:43] look at the example pictures [18:34:47] page 113 [18:34:57] detailed maneuver table, that's one of the MOCR displays [18:35:19] oh nice [18:35:21] revision 1 doesn't have those yet and they do contain useful trajectory numbers [18:36:19] I would say, let's watch the price dropping some more :D [18:37:22] haha sure [18:37:26] I'll keep it in my watchlist [18:41:03] good old NTRS randomness [18:41:28] revision 2 does appear in the restricted list [18:41:48] but not available of course, or else we would have long had it [18:42:40] almost worth requesting it, but they have removed ALL SCOTs from the current public NTRS [18:43:06] so maybe not much hope of getting this one, which might have never been public, back on there [18:45:41] yeah the DMTs would tell me a little bit more about the trajectory, but also not a huge amount. A lot less than some memo detailing how the FIDOs dealt with the targeting [18:47:38] UHLC has some memos dealing with that, but only for SPS-3 and 4. If Apollo 9 had launched later into its launch then they would changed those burns to get back to normal lighting for the later rendezvous [18:47:47] launch window* [19:14:12] unrelated, but one thing that would be very useful to find that I'm shocked I haven't been able to find yet [19:14:18] is the Sunrise 45 or 69 downlist [19:21:24] what sort of document would that be in, for early AGC [19:22:47] useful for erasable names mostly? [15:15:40] .tell Pewte looks like you're having some connection trouble [16:17:28] hey [16:31:36] morning! [16:35:17] hey Mike [16:35:20] sorry about yesterday [16:35:27] lost Internet connection [16:35:41] oh no worries [16:35:55] I didn't see your responses from the flood of Pewte joining and leaving [16:36:53] to answer your question -- we have a lot of downlists through JDCs and procedure specifications [16:37:26] I've found some with Sunspot, Solarium, Aurora, Sundial... [16:37:32] just nothing with Sunrise [16:37:49] and yeah, it would be very helpful with variable names [16:37:58] I currently don't know the name of a single erasable on the downlist :D [16:39:23] haha, ouch [16:41:03] I'm already almost a third of the way through the disassembly though [16:41:21] er [16:41:26] yeah getting there [16:41:31] I have about 4/15 banks done [16:43:19] I can't say I have seen any erasable names for Sunrise in any document sadly [16:43:33] we have one extremely good document for that [16:43:49] it has the name of basically everything below address 1000 and what it's used for [16:43:58] but most of the things in the downlist are above 1000 haha [16:44:18] is it one downlist or multiple? [16:44:42] https://www.ibiblio.org/apollo/Documents/agcis_15_errata.pdf#page=49 [16:44:43] just one [16:56:39] hello [16:57:55] yo [17:29:57] n7275, first time doing the Apollo 9 HGA test properly [17:30:02] works great [17:33:59] awesome [17:37:14] hmm, uh oh. Carnarvon LOS was a whole minute later than MCC predicted [17:39:45] RTCC calculation does use 5° elevation angle from the station [17:39:51] MCC AOS/LOS message uses 0° [17:40:07] maybe that is the difference. But a whole minute is a big difference [17:44:09] we don't do any checks for terrain or keyholes also [17:47:08] yeah [17:47:22] RTCC should check for keyholes actually [17:47:26] but doesn't yet [17:48:25] I'm still a bit suspicious. One minute between 5° and 0° elevation seems a lot [17:48:34] need to check with Hawaii [17:48:48] if both AOS and LOS time are early/late by the same amount then it's ok [17:53:29] AOS Hawaii [17:53:33] one minute early [17:54:22] so all good, no RTCC issue :) [17:55:26] of course I might change the 5° elevation logic [17:55:35] most of these actual RTCC calculations would use 0° [19:05:58] well that's starting to get annoying... [19:07:32] yeah it's kinda making the channel unreadable :/ [19:14:46] I have some powers for that, need to figure out which is the best one to use [19:25:06] looks like that one didn't work, haha [19:27:55] this is not a strong selling point for Quassel, I think I'll stick with ZNC haha [19:30:25] oh I didn't even realize they were behind a bouncer [19:30:31] yeah usually bouncers are supposed to prevent this haha [20:05:36] hmm, I don't think I have as many options as I thought. I guess I'll have to use ban? [20:13:44] yeah maybe a temporary ban that we rescind in a week or something? [20:14:41] yeah, I'll have an eye on it. Unbanning shouldn't be difficult [20:15:01] or if it's an actual NASSP user, might as well complain on the forum :D [20:17:23] hmm, maybe I don't know how it works yet after all. I thought the user name would now be on a ban list [20:19:02] hmmm [20:19:38] there might be a ban system with ChanServ and one without... only just starting to read into this haha [20:21:01] well [20:28:26] that seemed to have worked. Just waiting for the alternate nicks to join... [20:28:41] I feel like I am making a mess that Thymo has to clean up at some point :D [20:30:19] hmm [20:30:23] that doesn't make it better [20:30:27] still showing the messages [20:31:05] just getting instantly kicked now instead [20:45:13] indy91: Channel ban list is empty? What needs fixing? [20:45:46] seems like the problem is finally solved, but it took a while [20:45:54] just Pewte joining/leaving got on our nerves [20:46:24] I tried 3 different ban methods haha [20:46:49] the last one finally did it. If they ever want to be unbanned, I am not sure how many layers of ban I added... [20:47:30] I guess anything to do with ChanServ is just automating something that all OPs can do [20:48:18] but then I did something with channel modes, which probably works with the IRC system directly [20:48:39] using the Hexchat interface and click ban did not work [20:49:12] what seemed to have worked in the end was the same method but banning Pewte!*@* [20:49:26] so a total ban of that username in any combination, I think [20:51:24] Should be unbanned now [20:51:54] thanks for undoing my work? [20:52:29] would still be auto kicked by ChanServ now I guess though. But that also shows messages, so that ban method was defeating the point [20:53:38] haha, knew it [20:54:25] I guess we need to do the ban on Pewte!*@* until they have their tech fixed with the constant rejoining [20:54:53] How often is he rejoining? [20:55:54] every 4 minutes and 40 seconds, for ages now [20:55:57] making chat a bit unreadable [20:56:17] Mike and Matt complained so I had to put my OP hat on [20:57:07] Right, you guys are not used to channels with hundreds of users :P [20:57:12] if they come back again I will do the channel mode +b thing on Pewte!*@*, that is the one thing that actually prevented the join messages [20:57:29] and we also have longer breaks in conversations [20:57:36] so that makes it difficult to read [20:57:58] if 90% of a daily chat is join/leaving of one user [21:00:28] This may help https://wiki.rizon.net/index.php?title=Disable_JOIN_and_PART_Messages [21:01:19] except I do want to see the legitimate join messages [21:02:30] do we have another way to contact them? [21:03:01] I think he's a friend of James [21:03:15] Pete on Discord [21:03:36] oh, I didn't realize it was actually someone we knew [21:04:13] Last I spoke to him was about a half year ago I think [21:04:26] in any case, unbanning is just the same command but -b instead of +b, right? Would be easily done [21:04:36] Yep [21:04:46] we should definitely send a message through discord [21:05:02] and I removed the ChanServ ban thing, so that's the only step needed [21:05:20] I almost know what I am doing now. almost [21:38:16] night! [15:50:00] hey [15:52:59] morning! [15:54:05] what's up? [16:13:12] just one more little part of this Sunrise bank to go [16:14:27] nice :D [16:15:18] hey [16:15:56] hey Matt [17:14:36] finally, last Apollo 9 rest period started [17:15:29] I'll get into the deorbit stuff tomorrow I think [17:15:30] :D [17:15:49] lost a bit more apogee altitude due to drag than RTCC predicted, but I was expecting it [17:16:24] RTCC uses hardcoded drag coefficient of 2 and for the CSM it uses the 129.4 square feet area, which is the same as the CM alone area [17:16:56] and according to the CSM Data Book aerodynamic model, even in the optimum attitude it would have a bit more drag than that [17:17:10] and in the worst attitude quite a bit more [17:18:44] so everything going to plan. Apollo 9 can be flown with the full drag model [17:18:57] that's weird [17:19:00] but nice! [17:21:54] if you fly with the CM forward or with the SPS engine forward then you have the exact drag area that the RTCC is using [17:22:14] with CM forward it has a drag coefficient of 2.41, SPS engine forward 1.96 [17:22:23] so not too different than the hardcoded 2.0 [17:22:48] But only if you fly SPS engine forward all the time would you ever get less drag than the standard RTCC settings [17:23:10] worst case, sideways, is CD of 5.01, using the same reference area [17:24:02] but you would have to do that on purpose. In drifting flight that attitude would give you a big moment [17:24:13] CM forward is (somewhat) stable [17:24:38] right [17:24:48] air density is not high enough to stabilize you completely though [17:25:00] if you start at 90° AOA it wants to get to 0°, but it wouldn't stop there [17:25:24] but with elliptical orbits this is somewhat random. Very interesting to watch [17:26:30] so best case is 98% drag, worst case is 250% of RTCC predicited drag. I'm probably getting 150% on average, maybe even less [17:27:53] now, if I could find any source from Apollo 7 or 9 that talk about this, that would be nice haha [17:28:41] I'll continue looking for some FIDO post mission report I guess... [17:32:26] the RTCC does have a drag multiplicator though, which you can adjust. They likely did that to get closer to actual [17:40:59] the RTACF can do that too, has a special processor for it. For that I have a post mission report! [17:41:05] And what can I know from it? [17:41:17] FIDO requested RTACF K-factor processor 18 times [17:41:20] Trajectory 5 times [17:41:22] MPAD 2 times [17:41:27] that's it :D [17:42:28] hahaha [17:42:31] RTACF post-mission report is all about how much work they did on Apollo 9 :D [17:42:35] very helpful [17:42:58] they ran 173 entry computations [17:43:06] but deorbits are also in that category [17:43:10] so all the block data I guess [18:38:57] Evening! [18:59:40] Hey Thymo [18:59:46] you brought back the spam :P [19:00:59] thewonderidiot, so you are probably not going to update your NASSP install for demonstrations, but do you still want a modified Apollo 13 PDI scenario that can land with Auto P66 [19:01:14] for myself I used that old scenario and ran Matt's script to update the ECS and such [19:01:45] But I can of course do the padload changes only to that scenario if you want [19:02:42] your install might still have the AGC version used hardcoded, so you would have to change that [19:04:34] oh yeah! that would be awesome :D [19:06:26] yeah I hadn't added the mission files yet where you can change that without building [19:06:27] https://github.com/thewonderidiot/NASSP/blob/agc_bridge/Orbitersdk/samples/ProjectApollo/src_lm/LEMcomputer.cpp#L98 [19:06:37] this is where that's done in your version [19:09:34] hmm, I had two scenarios. One normal one and another where I deleted CSM and S-IVB so that you have only the LM, maybe for performance reasons [19:09:44] or maybe difficulties with also having a CMC running [19:09:47] which one do you want? [19:21:00] I think the one with the CSM and S-IVB deleted would be better [19:22:32] sure thing [19:23:03] didn't you show an LM abort staging in a demo and said you could now fly back to the CSM :D [19:23:22] luckily you didn't have to demonstrate it haha [19:24:25] hehehehe I need to learn a looooot more before I can do rendezvous [19:33:46] sweet, thanks! [19:34:20] I figured I'd unban him to see if he fixed things [19:34:26] Apparently noy [19:34:31] s/oy/ot [19:53:30] yeah, we can check periodically, or at least not entirely forget about it [21:08:59] I've sent Pete a message [23:22:36] that's good. I'd imagine he hasn't looked at in quite a while and is completely unaware of the issue [00:15:11] n7275: you around? [00:24:07] yes [00:24:12] hi [00:24:30] hello! [04:05:00] goodnight! [15:30:48] good morning [15:30:56] hey [15:34:38] do you know if the scenerio editor's orbital elements are somehow left-handed like Orbiter coordinates? [15:38:15] I think they are [15:38:35] in the Orbiter manual it has equations for getting orbital elements from state vectors [15:38:40] also left handed, pretty sure [15:39:27] although, which of the elements would even be affected by that... [15:40:04] I guess the question is, could you convert those elements directly, without any conversion, to a right-handed state vector, using the established right-handed equations... [15:43:27] I'm trying to set up a test in GMAT [15:43:40] to verify my gravity model [15:46:15] maybe I can just define a moon-centric coordinate system, orbiter-like coordinate system [16:09:05] in the very early days of doing Orbiter development stuff I was using the left handed coordinates in my code [16:09:10] and everything became a mess [16:09:39] Because of course any equations I got from textbooks or so that depend on the handedness have problems then [16:10:08] but I don't really remember if the orbital elements had a problem like that... [16:39:05] morning! [16:41:38] hey Mike [16:41:50] what's up? [16:43:04] oh just pondering reconciling Orbiter's nuances with GMATs nuances [16:52:34] hey [16:53:04] n7275, so I can tell you that Inc, LAN and longitude of periapsis are no problem [16:53:21] so I think the orbital elements essentially don't care about handedness [16:53:36] the way they are calculated from a state vector of course differs [16:54:11] But I can take a state vector from Orbiter, convert it to right-handed, and am getting the same orbital element angles as the scenario editor [20:44:58] indy91, I looked through your LM131R1 changes and it all looks good to me [20:46:57] great, thanks! [20:48:21] 2/3 of the changes weren't even for LM131R1, but, definitely all improvements [20:52:12] oh wait. I better announce this on the forum [20:53:25] yeah! first new rope in a while :D [20:55:12] also, if there are people with an active Apollo 13 version [20:55:20] they will have a problem when they want to land [21:39:37] night! [13:47:38] hello [13:47:44] hey [13:51:27] time to pick my local changes apart and put them into PRs that can actually be checked [13:54:40] oh fun [14:01:12] and I am already changing my mind on the first one :D [14:01:21] one of the bugs that gondos found [14:02:49] if we could use the Orbiter sim time (instead of NASSP mission time) for AGC timesteps the bug would just go away [14:03:11] but changing anything with AGC timesteps is a bit scary [14:17:13] so much bad code.. [14:20:44] yeah, that probably deserve its own project/rounds of testing [14:31:49] yeah [14:32:11] I'll push a bit of extra apolloguidance class cleanup [14:32:24] but won't change how the timestep works [14:32:37] the bug doesn't go completely away on its own actually [14:32:52] on the first timestep "simt" is always 0, and simdt is 0 [14:32:58] simdt is 0.01* [14:33:27] simt being 0 means, with the current PCM code, that the first timestep would do no telemetry [14:33:44] so a bit of a fix for the unpowered AGC is needed anyway [14:51:19] n7275, what about this that gondos found: https://github.com/orbiternassp/NASSP/commit/d7bbd12c9d02a513999e7b170798ad5cbe09fc9c [15:29:43] oh that should be good. I'll approve it. [15:30:06] oh wait [15:30:30] is there a pull request for that? [15:30:47] no [15:30:57] I don't know how that can appear as a NASSP commit lol [15:31:47] but I wonder if we can just use this commit directly instead of replicating it [15:32:06] I'm sure the is some git dark magic way [15:41:25] I'm sure. [15:42:25] cherry pick the commit ID? [15:43:38] probably? I have never tried cherry picking before [15:47:23] oh that commit is from his linux branch [16:17:27] morning! [16:24:24] hey Mike [16:46:18] I finished disassembling banks 1 and 4 of Sunrise [16:46:26] the AGC Information Series docs are incredible [16:46:59] there's a whole section, PROGRESS CONTROL, that does not exist anymore in any rope we have, even Solarium [16:47:28] and worse yet the broken core in this module lost us an instruction from right in the middle of it [16:47:51] but despite that with the relevant AGCIS section, I have names for every single thing and am 100% confident in my substitution for the missing word [17:07:21] oh that is great :D [17:07:28] what is PROGRESS CONTROL doing? [17:07:46] it's the predecessor to RESTART CONTROL [17:08:11] it's like the capabilities of V37 and phase table management merged into one [17:08:36] it actually manages the major mode like a bitmask instead of discrete numbers [17:08:58] so major mode 1 is prelaunch alignment and major mode 2 is orbital integration [17:09:05] but if the DSKY says 03 that means both of them are running [17:09:26] and then 04 is system test [17:10:09] this is the AGCIS that talks about it: https://www.ibiblio.org/apollo/Documents/agcis_16_fresh_start.pdf [17:11:21] I guess that works until you need a lot more programs [17:13:45] but in a sense useful [17:13:58] How do I know P20 and P34 are both running?? [17:14:28] haha yup [15:05:10] hey Nik [15:16:25] hey [16:11:56] https://imgur.com/a/BYuCDqh [16:12:59] I still have some work to do on this project apparently [16:17:58] blue is Orbiter with my changes, orange is GMAT with the same state vector, red on the left is the same keplarian state +180 true anomaly [16:33:39] interesting [16:34:14] blue looks like red but inverted [16:34:53] and you are sure you have the coordinate systems figured out? [16:35:10] maybe that is why there is a difference between Orbiter and GMAT [16:36:36] do you have the state vector? I could do some cross check with the equations I put in the RTCC [16:49:45] what sort of format do you want for that [16:50:22] and no I am not sure I have the coordimate systems figured out haha [16:51:55] if you tested with Orbiter then you probably have something in J2000 ecliptic [16:52:05] just tell me if it's left or right handed haha [16:52:15] and a MJD [16:54:07] one sec [16:55:11] MJD 52006.76966 [16:55:30] X 1776536.8 [16:55:38] Y -41749.0 [16:55:46] Z -286547.3 [16:55:54] Vx 212.55 [16:56:01] Vy 1161.10 [16:56:08] Vz 1148.60 [16:57:12] that should be right handed [16:58:19] 45 deg circular orbit crossing through the 0,0 long lat point with a 62km altitude [17:08:10] hmm [17:08:30] my R2 model is shy today, I don't see any change in apo or perilune [17:08:38] I must be doing something wrong [17:13:16] swapping Y and Z should be all I need to do right? [17:13:33] and swapping them back for the aceleration I get [17:13:55] maybe it's just a sign error with the aceleration.... [17:17:24] can you check that state vector, for me it's a 62 x 47 kilometer orbit [17:17:29] position is probably right [17:17:35] but velocity seems strange [17:20:13] oh hang on [17:20:27] I think I gave you bad data [17:20:34] can't be a big error, but definitely off [17:20:41] is it Moon fixed? :D [17:20:56] RPOS 1799981.989 142.933 142.933 RVEL -0.1853 1167.0110 1167.0110 [17:21:10] is what's saved in the scenerio file [17:21:26] it should've been moon rotating [17:21:43] that state vector is easy to convert left/right handed [17:21:55] MJD was correct? [17:22:17] must be [17:22:23] it starts at 0° lat [17:22:25] yes [17:22:39] oh weird [17:23:11] is the scenerio editor's "frame" menu wrong? [17:23:57] I don't trust anything now... [17:24:27] haha, I'm not sure. Wrong in what way? [17:25:51] my R2 model still gives very different results. But the initial conditions are the same now [17:26:04] so might just be that the R2 model isn't good enough [17:27:04] never mind, I think the editor is fine [17:27:37]