[14:42:58] NASSP Logging has been started by indy91 [14:43:00] hey [14:50:49] happy with dockings? [15:06:03] yes [15:06:16] took me right to the front door [15:06:59] the MCC uplink to SWS worked perfectly [15:08:08] docking target isn't remotly clos to where it should be. that'll require a mesh modification [15:08:19] hmm right [15:08:26] is it at least oriented about right? [15:09:14] "not remotely close" probably isn't accurate [15:09:37] "took me right to the front door" yeah I noticed that, too. You are arriving on the right end of it and don't have to maneuver much, right? [15:10:19] might just end up this way because TPI is based on lighting and Skylab is oriented for specific lighting as well [15:10:38] that's probably it [15:11:03] the Skylab orientation is such that at orbital noon the docking port end will point close to the velocity vector [15:11:25] and you arrive roughly from that side and you arrive roughly at orbital noon [15:11:59] I need to add some lights at some point [15:12:12] we have good info on them [15:12:28] pretty easy to see in the day, not so much at night [15:13:42] I would say with this merge, Skylark can come [15:16:51] I'm probably going to work on closing out my open projects next [15:17:17] yeah, potentially I will do some Skylab RTCC projects still, but we don't 100% need them [15:17:43] more interesting for the additional Skylab missions or custom ones [15:17:47] launch planning [16:17:57] morning! [16:21:26] hey Mike [16:23:01] what's up? [16:28:20] eagerly awaiting Skylark :) [16:32:04] hey Mike. Yeah I think we have now achieved the very minimum to be ready for it [16:39:31] yeah I'm anxiously awaiting it too lol [16:39:37] going to make some more phone calls today [16:58:05] I got an email from WSU [16:58:45] they're doing construction on their library until early 2024, and asked that I check back then [17:18:33] ha, well at least not an outright no... [20:42:40] night! [14:40:44] hello hello [16:18:32] hey Niklas [16:21:11] what's up? [16:23:00] lunch, but not too much else [16:29:07] I was going to make a small update post on the forum about our recent Skylab changes [16:30:19] sounds good. No checklists yet, but the MCC should take you to it [16:31:38] yeah, that's probably the most important point if people want to fly it, don't follow the Apollo 7 flight plan [16:32:00] people should really just wait for November anyway :D [16:32:37] we are not using the modified Artemis, so P34/P35 don't work either [16:35:59] yeah, I'm hoping that my skylab posts are a nice foreshadowing for Skylark. I'll let Mike make that post :) [16:46:27] morning! [16:48:10] hahaha I appreciate that :D [16:53:20] hopefully two posts this year :D [16:54:28] what are the chances we are finding Comanche 108 ropes/listings first lol [16:54:43] that would be a bit of a twist haha [17:09:24] hahaha that would be a huge twist [17:09:38] I've gotta say it's pretty close to 0 [17:09:57] but I also wasn't expecting to suddenly find Skylark during a flickr image search so who knows [17:10:37] also really it's hopefully 3 posts this year [17:11:01] reconstructed Comanche 72 should hopefully follow behind 67 pretty quickly [17:11:11] yeah that would be awesome [17:11:38] I'm definitely not going to make an update for Apollo 13 to use Comanche 67 [17:11:46] and this time around we have more people that know AGC assembly, and so more people to come up with possibilities for 72/3 [17:12:24] and then we'll be down to only two missing ropes, I think? Sundisk 282 and Comanche 108 [17:12:31] and Sundance 306 with an asterisk [17:13:01] maybe we can make a Comanche 72 version that gets closer to 108 than Artemis is to 108 [17:13:20] maybe! [17:13:24] we do have all of the change memos [17:13:35] ....but that's about it. no flowcharts or Norton or banksums [17:13:39] as it stands I would still not use Comanche 72 for Apollo 14, not even with the constants for that year [17:14:46] that at least is an easy fix [17:14:53] oh yeah [17:15:08] no P24 and no P29 in Comanche 72, but 108 and Artemis have them [17:15:21] that one, maybe not quite as easy :P [17:16:34] deleting P31, P38/78 and 39/79 should be easy though :D [17:16:53] when did that new P31 even get added... [17:17:43] doesn't appear in the Apollo 14 checklist [17:17:49] so must be new for Artemis [17:19:16] oh and I forgot, P17/P77 also didn't get deleted until Comanche 108, Apollo 13 still has them [17:19:26] I've never properly used that program [17:21:57] and we do know where module B2 is so anything in banks 6-13 we can have real Comanche 108 for... if/when I ever make the trip to read that [17:22:13] sounds like a 2024 sort of project [17:22:25] hahaha maybe! [17:25:51] kind of a funny coincidence that module B2 is also the only module of Comanche 72 I've found [17:35:36] maybe some had a stack of modules and the ones called B2 got sold together, because clearly they belong together [17:35:41] someone* [18:00:36] hahaha maybe! [21:13:39] night! [16:18:36] morning! [16:21:44] hey Mike [16:29:24] what's up? [16:33:11] thinking about various RTCC projects to do next [16:33:13] and you? [16:34:01] lots of emails and planning, but not really working on anything [16:34:27] if everything works out I'm about to have several large projects dumped on me, so I've mostly been relaxing lol [16:34:53] haha, calm before the storm [16:37:48] pretty much :D [17:22:50] hey guys [17:30:12] hey [17:34:15] yo [21:05:39] night! [15:25:19] hello [15:27:25] hey Matt [15:29:49] I was thinking about some of my more long-range projects this morning, specificially telemetry logging [15:31:06] if we had a database that we could log telemetry data to, is there any realtime data that our RTCC generates that would be useful (for making graphs after a mission) to save? [15:32:45] hmm [15:34:15] I don't know about after a mission [15:34:44] I'm sure there are applications that I am not thinking of [15:35:10] during a mission, during powered flight, there would be plots that are written with nominal MPT data and actual AGC state vectors [15:35:41] I think a lot of analog data are plotted in real time [15:36:02] but they are wrote data to tape [15:36:05] they also* [15:36:26] after the explosion on Apollo 13 they talked a lot about looking at the data from the last hour [15:38:07] There are many displays, not just ones that purely show telemetry data, that are at least driven by telemetry data [15:38:13] like [15:38:15] https://cdn.arstechnica.net/wp-content/uploads/2019/06/console-row3-wide-procedures.jpg [15:46:03] I was talking more about MPT data, monitor output, MED input etc, than telemetry [15:46:34] There is a RTCC debug log that we save some of that to now, right? [15:47:38] yeah RTCCDebug.log [15:47:45] resets when you reload the sim [15:48:16] I didn't really understand the connection between telemetry and data generated by the RTCC in your question [15:48:34] ahh [15:49:27] I'm pretty sure that, aside from being available on a display, all the stuff that is shown on the online monitor (same as written to RTCCDebug.log) is always immediately printed out [15:49:29] If I add a more robust logging system for logging telemetry, it would open the door for better logging of other things too, besides telemetry [15:51:21] IBM 1443 [15:52:26] aside from that, every 1-2 hours they wrote the complete memory state of the RTCC computers to tape, as "checkpoints". In case the computer goes down they could reload it from that [15:58:35] so the RTCC data you are talking about weren't really logged specfically [15:58:59] MED inputs and lots of other things are on the online monitor and gets immediately printed out [15:59:19] the entire RTCC memory gets backed up as well [15:59:25] on those tapes [15:59:36] but not like the MPT individually [16:00:59] okay, that makes sense [16:01:31] there is one thing I never managed to figure out how it works [16:01:38] MED inputs on "tape" [16:01:44] there are quite lengthy MEDs [16:02:18] they had some sort of way to prepare a MED input with everything but e.g. a time of ignition already set [16:02:36] the FIDO always said "write a tape" [16:03:11] I know they could also read punch cards with MED inputs [16:03:37] but with those tapes, how are you then filling in the remaining number(s) [16:03:59] and were they really inputting MEDs in the same way as we are doing in the MFD or was it a bit more comfortable [16:04:03] I have no idea :D [16:06:53] I need to book a tour of the RTCC [16:07:01] brb going to my time machine [16:07:29] If you find a time machine, take me with you [16:07:54] I know JCL has dynamicially replacable symbols [16:09:28] googles JCL [16:09:33] yeah that sounds about right [16:10:38] so maybe the MED has something like &BURNTIME in it, and RTOS was configured to grab those off the card reader or wait for input on a console [16:59:24] morning! [17:19:19] hey Mike [17:21:28] hi Mike [13:57:22] good morning [14:08:38] hello hello [16:07:29] morning! [16:28:46] hello [16:42:56] this week has been pure chaos, hopefully I have a bit more time this weekend and next week [17:57:28] yeah I feel that haha [18:26:57] feeling a bit under the weather. And I'm busy tomorrow, so, cya on Sunday! [14:01:25] good afternoon [15:08:25] hey [15:13:28] what's up? [15:19:13] not much yet. i did listen to the EECOM loop from -10ish hours on 11 yesterday [15:19:34] super exciting stuff [15:20:14] but i feel better about my cryo pressures on the pad in my branch [15:22:15] i think our tanks may be too full at liftoff [15:25:39] Apollo 11 or 13 EECOM? [15:26:12] 11 [15:27:25] yeah you can learn so much about how they were actually operating [15:29:29] i could make graphs from some of the numbers thry say haha [15:29:59] I can basically track down all RTCC inputs from FIDO, RETRO and GUIDO [15:30:21] they definitely filled the cryo tanks from the MSS [15:30:25] when the FIDO audio first became available for 11, that really caused the MPT to get implemented [15:31:03] that makes sense [15:32:50] if it makes behavior better we can of course adjust initial masses in tanks [16:08:40] morning! [16:09:39] hey Mike [16:11:02] hey [16:50:41] hey [16:54:38] oh hello Alex! How is it going? [16:55:22] hey Niklas! going good going good [16:55:50] how about you? [16:55:52] unfortunately I have been quite busy this summer, training on a new type [16:56:19] all fine. Yeah that can happen haha [16:56:43] Did you hear the good news yet? [16:56:59] Skylark ropes have been located. There is a decent change we can get them. [16:57:15] That's why there has been a bit of Skylab activity recently... [16:57:32] ah yes I have been heard that is great! [16:57:47] should give us a bunch of new fun things to do [16:57:54] also looks like Commanche67 is around the corner too? [16:58:15] good chance for that, too. Not quite sure when [16:58:28] Comanche 72 reconstruction likely possible [16:58:35] for Apollo 13 [16:58:45] Comanche 108 for Apollo 14... not so much :D [16:58:48] we will see [17:00:09] Skylab rendezvous don't take 300 hours, so, maybe you will have a chance to try that as well :D [17:00:32] ah yes [17:00:49] once the ropes are out then I will try it for sure [17:01:14] do we have checklists for skylab? [17:01:52] some, yeah [17:02:25] a SL-2 launch checklist and a SL-4 rendezvous book have really been my main sources for that so far [17:04:05] I added MCC support already for Skylab 2 [17:04:09] but no Checklist MFD yet [17:04:12] nice [17:04:24] a bit hard to do without having the right CMC version available [17:04:29] so many noun changes [17:04:49] right [17:04:53] speaking of earth orbital missions, I downloaded the latest SSV [17:05:01] ah nice [17:05:21] and noticed you added further deorbit functions to the FDO MFD I think [17:05:50] yeah I did. Was nearly done with that at the beginning of the year already, but never really had a chance to properly finish it [17:06:03] but now it's basically done [17:06:15] maybe prettier output displays, but, it works [17:06:56] if I recall, we had to use backup data for it previously [17:07:05] is that not the case anymore? [17:07:10] yeah [17:07:16] ah nice [17:07:25] I had already implement a feature called deorbit opportunities last year [17:07:33] I might re-try a simple STS-1 style mission again [17:07:37] it gives estimated TIGs but nothing else, for multiple orbits and landing sites [17:07:45] that is still useful [17:07:55] to roughly determine when and where you want to deorbit [17:08:05] right [17:08:12] and then you get the TIG and DV and such with the full deorbit targeting [17:08:51] so I guess you can now fly a full ISS rendezvous and back with the FDO MFD [17:09:34] yeah should be possible [17:09:45] the majority of the ground support in terms of maneuvers [17:11:29] SSV still has no proper ascent guidance [17:11:37] so prepare for mighty plane change maneuvers [17:11:44] in case of rendezvous missions [17:12:11] ah right [17:12:33] are those incorporated into the FDO MFD calculated maneuvers? [17:13:09] yeah you can target NPC burns [17:13:42] might be the most complicated (and in the past) most buggy part of the MFD lol [17:16:43] I guess if the launch is timed correctly, the plane error should be minimal despite the simple ascent guidance? [17:16:51] yep [17:17:30] I think I remember using the launch window processor with your help a while back, to get a proper launch scenario [17:18:20] I never ended up actually flying it though [17:18:54] I was already overwhelmed simply truing to fly STS-1 :D [17:19:17] yeah the LWP can help with that [17:19:34] the MFD can also calculate non-rendezvous maneuvers for STS-1 [17:19:50] I think I even included a mission file for the MFD to load [17:23:22] right [17:26:17] still a lot missing from SSV that I could probably help with... maybe at some point [18:36:22] indy91, must non-spherical gravity be disabled for FDO MFD in SSV? [18:37:54] hi Alex! [18:38:37] the MFD works with or without non-spherical gravity. But on the config page you have to choose the same option as for Orbiter itself. [18:39:27] that options gets also saved/loaded in the mission file [18:39:42] n7275, hey Matt! [18:40:48] indy91, ah ok I see. I was just wondering if there was a reason one would want to have it disabled, maybe earlier versions were not as compatible with it? [18:41:15] SSV itself isn't fully commited to non-spherical gravity yet, although it's not far off to do that [18:41:37] ok [18:41:38] some things are easier with it disabled, so some SSV users might choose to have it disabled [18:41:43] just wanted to support that as wel [18:41:46] l [18:41:56] I prefer using non-spherical gravity of course [18:43:39] thewonderidiot, getting back to Comanche 45 padloads. Didn't have the scaling of everything figured out yet. Do you see the fun difference in V6N99INP between Comanche 45 and 55.... [18:45:25] I think I how how to convert engineering value to octals and back now, but it doesn't give any nice engineering unit. Not feet, meters or nautical miles [18:45:30] know how* [18:46:40] indy91, just as a heads up, i did recently add the EGM96 model for earth to OO. i dont forsee thst causing many issues though. [18:48:02] oh ok. I think I have some commented code in place that eventually can be used by the RTCC integrator to take that sufficiently into account [18:48:44] AEG will never get it, not even during the Shuttle program. So really just has to be implemented in two places in the entire RTCC [18:49:01] earth is mostly J2, unlike thr moon [18:49:06] indy91, oh yeah lol. annoying factor of sqrt(3) [18:51:23] Colossus 237 and 249 are the same way there I think [18:52:51] n7275, J3 and J4 are definitely relevant for Earth as well. That's mostly what you need to be accurate over maybe 1 day [18:53:07] but J2 is a lot stronger than J3 and J4 for sure [18:58:07] early in Apollo they used the same model for Earth and Moon [18:58:25] so the RTCC has J2, J3, J4 and J22 (tesseral harmonic) [19:08:20] thewonderidiot, the engineering values at least seem to agree very closely with the Apollo 8 CMP checklist, it basically suggests the same values for V67 inputs as the octals of the Apollo 10 CMC padload [19:09:04] not exactly for the velocity because of the precision of the display [19:09:17] somewhere between 5.7 and 5.8 ft/s [20:47:21] night! [15:39:39] hey [15:48:15] hey Niklas [16:17:09] morning! [16:21:39] hey Mike [16:32:54] what's up? [17:13:33] not too much. was reading the Skylark users guide earlier [18:12:20] hey Mike [18:12:31] n7275, looking for anything specifically, or just making yourself familiar with it [18:21:40] just familiarization right now [18:24:49] your MCC calculated burns spoil me :) [18:26:53] im not super great with P3X programs, so wanted to read up [18:30:59] there are plenty of P3X in Skylark, more than anywhere else :D [18:31:52] and for the most part the onboard solutions are primary [18:32:16] I believe they would take the ground NC2 TIG over the onboard calculated one, as part of the NC1 calculation [18:32:42] but that is the exception [18:52:41] hey [18:55:52] hey Alex [19:05:31] hi Alex [19:43:24] hey [19:50:43] indy91, dumb question, but could MCC uplink the PEG-4 or PEG-7 data? [19:51:42] yeah [19:52:10] pretty sure at least haha [19:53:28] I wonder if there could be a way for the FDO MFD to load the desired burn's data directly into SSV [19:53:47] I'm very hesitant to make the MFD specific to any Shuttle addon [19:54:00] right [19:54:08] unless it's going to be a somewhat common interface, I'd rather not [19:56:39] you would have to ask GLS for uplink capability [19:57:07] the only real common interfaces would be TCP/IP like most of NASSP uplinks [19:57:21] or with an Orbiter way, maybe clkbGeneric function call [20:03:28] right makes sense [20:04:57] also, is entering the DV's directly into PEG-7 the standard way? the maneuver transfer table seems to only allow P7, not P4 [20:07:40] The OPS 2 software doesn't even have any PEG 4 [20:07:53] so it's only available for OMS-1 or 2 burn and the deorbit burn [20:08:52] OPS 2 has Lambert aimpoint guidance like the AGC, for rendezvous burns. But that's not fully implemented in SSV, as there is no full closed loop guidance for burns yet [20:10:21] ah ok [20:10:24] so all the ground calculated burns on-orbit are PEG-7 [20:10:32] External DV [20:14:35] using clbkGeneric for uplinks would be interesting. I wonder if we could create that functionality as just a header file or header+ static library [20:18:15] does SSV have variable CG and a good OMS TVC to handle that as of now? [20:19:04] clbkGeneric would at least be an Orbiter internal solution. And doesn't require you to make functions virtual to call them across modules [20:19:12] SSV does have variable CG I believe [20:19:37] TVC is fine, as I said not closed loop, but the residuals aren't too bad [20:20:30] right [20:29:38] still planning on flying a short test STS-1? [20:35:35] well I ended up launching an arbitrary mission built with the mission editor [20:36:09] standard profile OMS-1 & 2 with a 160 NM orbital height post OMS-2 [20:37:33] I tried the OMS-1 & 2 ascent targets calculated in the mission editor and loaded as I-LOAD [20:37:41] does a pretty good job [20:37:58] thank god I didn't have to manually enter the OMS-1 PEG4 data [20:38:03] haha [20:38:09] very tight on time [20:38:15] you still have to do items 22, 23 though [20:38:21] which in reality you didn't for OMS-1 [20:38:22] yeah [20:38:33] and the attitude maneuver rate is low right now [20:38:36] ah was it automatic? [20:38:50] because SSV only has the Orbit DAP, not the Transition DAP for ascent and descent [20:39:10] I think all you had to do for OMS-1 burns in reality was the item 27 for auto maneuver [20:39:38] ah [20:40:13] Im just playing around with the FDO MFD now, I made myself a height adjust burn [20:40:22] now in a 250x160 orbit [20:40:55] now I will try the new deorbit functions [20:41:30] do you think it can handle an elliptic orbit, or should I circularize first? [20:41:37] I was about to say [20:41:53] it should be able to handle it, but I didn't test anything that elliptical [20:42:08] as always you are pushing my MFDs to a limit :D [20:42:33] haha so I guess im not circularizing :D [20:43:36] I guess the normal flow for deorbit is to first use DOP to find the window, then the DMP to actually calculate the tragets? [20:44:00] the FDO handbook says that quite elliptical orbits might not converge on their own in the real thing either. And you would then have to input initial guesses for PEG 4 targets, but that isn't implmented in the MFD [20:44:18] yeah, DOPS first [20:44:40] ok [20:47:26] unless you already have a good idea of the TIG [20:56:41] would "TIG fixed" be normally used? it seems to give a higher DV then "TIG free" [20:58:47] TIG free for sure [20:58:53] TIG fixed means you input the TIG [20:58:58] ah ok I get it TIG free needs a threshold time [20:59:11] yeah, for TIG free the input time is the threshold [20:59:15] I was inputting the exact time from DOPS [20:59:31] and of course it was giving me an ignition on the next REV [20:59:35] conveniently the DOPS TIG seems to be earlier than the actual TIG for the most part [21:00:52] I could input that as the threshold time [21:00:56] but a few minutes earlier is safer [21:01:30] so that it doesn't find a TIG on the next rev [21:10:05] night! [21:34:32] thewonderidiot, do you know if there is some of the real shuttle GPC software out there somewhere? [15:39:34] hey guys [15:44:07] hey Alex, Niklas [15:50:32] hey [16:03:56] I started working on more PanelSDK code cleanup last night. not changing functionality, just trying to make it easier to follow [16:04:30] that's good [16:04:43] I'm trying to make it easier in the padload generator to support custom ropes [16:05:59] no special logic then for e.g. Artemis072NBY71, because all we have done is switch out a data set that is identical to what some earlier ropes had [16:27:43] AlexB_88, got a good deorbit yesterday? [16:34:24] it went great! I did it from a ~750 NM crossrange and 250x120 orbit [16:34:29] landed perfectly at KSC [16:34:53] I used the PEG 4 data [16:35:20] good to hear [16:35:38] I mean 250x160 NM orbit [16:54:19] It's been so long since I flew a shuttle reentry. I imagine it's much more realistic now. [16:54:42] I gotta try this out [16:57:05] the entry guidance is very realistic [16:59:37] morning! [17:02:56] hey Mike [17:03:42] the Apollo 11 error in the planetary orientation constants (CMC and LGC) is making my life more difficult with the padload generator :D [17:03:50] hehehe [17:04:05] if only there had been a Luminary 99 rev 2 :P [17:04:13] because I can't just say "these are always constant for this launch year" [17:06:01] that concept was already breaking down with a Artemis 72 modified for NBY 70, because I had to invent a number not found in any other NBY 70 ropes [17:34:24] I do notice that SSV entry guidance is quite good [20:36:11] AlexB_88, now you can fly a super complex rendezvous mission :P [20:56:09] night! [21:34:33] thewonderidiot, is the W-Matrix always in the same location in memory? [21:35:09] my gut answer is no, but let me check [21:36:52] hmm, let me amend that to maybe [21:45:58] n7275: for manned missions (assuming Sundisk 282 doesn't deviate), yes, it is always in 2400 [21:47:07] Sunrise had it in 1457; Corona and Solarium had it in 1561; Aurora, Sundial, and Sunburst had it in 2230; Sundance, Colossus and later all standardized on 2400 [22:00:12] cool [22:01:02] i had a crazy idea for a visualization during marking [22:11:46] uh oh lol [22:11:51] what's the idea? [22:44:42] I think just showing how the ellipsoid changes with marks over time [23:02:30] oh, that would be cool :D [14:53:02] hello [15:09:57] hey Niklas [15:43:28] trying to solve these issues with my MPT PR [15:43:29] not so easy [15:52:58] what's the issue? [15:55:39] when you have a maneuver on the MPT that is more than 48 hours away (imagine a TEI) and then want to simulate any maneuver after it (imagine a MCC-5) then the state vector used for the MCC-5 calculation is from before TEI [15:56:41] there is a function I know only the name of that I hadn't previously implemented and potentially is the RTCC way of dealing with this [15:57:45] that function itself is somewhat simple, but I will have to change a lot of places where another function is currently used... [16:09:34] ahh, that kind of problem [16:10:08] yeah the kind of problem where I would really like certain IBM RTCC documents that we don't have yet [16:10:15] and the ones we have are too outdated [16:10:46] eventually I'll have to ask NARA again if they have it somewhere [16:11:26] that's the only hope I have to find it [16:11:38]