[15:23:13] NASSP Logging has been started by n7275 [15:23:15] good morning [15:55:51] hey Matt [16:18:00] got most of the network stuff moved over and updated yesterday [16:32:09] ah nice [16:32:13] progress :D [16:37:56] morning! [16:57:09] hey [17:15:27] there are two nice books by Jonathan Ward about Saturn countdown and that sort of stuff, but he doesn't list it as one of his references [17:15:56] when I was reading about the EDS test especially I kind of wanted to send him an email to ask if he knows more about it [17:16:14] never got around to it, didn't really know what to ask for either [17:16:41] oh really? I'm surprised he didn't reference it [17:16:43] so I just checked if he had it as a reference, then maybe he would have had a copy of it haha [17:17:49] he lists stuff like "Launch Vehicle Operations for Support of Space Vehicle Countdown Demonstration [17:17:50] Test and Launch Countdown" [17:18:04] yeah those documents look pretty much identical to this one [17:18:12] just, more Saturn-focused [17:18:55] I've seen a bunch of those on auction throughout the years [17:19:06] yeah [17:21:30] well even if you don't get it, now we know what to look for [17:21:37] because it looks really useful [17:23:34] I'm taking a bit of a break from panel stuff, reading more about Skylab rendezvous instead [17:24:15] just figured out something about how they chose the trajectory [17:24:48] they launched at the middle of the in-plane launch window, so when the orbital plane of Skylab passed over the KSC [17:25:19] but there also is a phase window, so when the CSM reaches orbit, the phase angle to Skylab which can't just be any angle [17:26:05] hmmm [17:26:16] oh yeah that makes sense [17:26:36] and they seemed to have adjusted the insertion velocity, so the apogee altitude after Saturn IB cutoff, to make the nominal launch time (optimal in-plane) the same as the opening of the phase launch window [17:27:06] the Skylab launch window processor document says, the phase window opens when the NCC maneuver has 30 ft/s [17:27:16] and in the nominal flight plans, the NCC maneuver has 30 ft/s [17:27:49] so that's definitely something to keep in mind for Saturn IB launch targeting to Skylab :D [17:28:54] so basically, run the launch targeting, there will be a plane launch window opening and closing time and a phase launch window opening and closing [17:29:18] and then you would adjust the insertion velocity until the middle of the plane launch window is identical to the phase window opening [17:29:31] so they can launch optimally (yaw steering during ascent is costly) [17:29:40] but if they launch slightly late, the phase window had just opened [17:31:05] this is all relevant because rendezvous happens just a few hours after launch [17:31:15] Will be the same for that short Soyuz rendezvous profile [17:31:47] if you are doing the rendezvous on day 2 or 3 of your mission like the Space Shuttle, then the phase window is not important, it can be basically anything [17:32:06] because you can adjust it enough with on-orbit maneuvers [17:32:13] and lots of time coasting [17:33:16] on the other hand, the phase launch window is the only thing that mattered for the LM liftoff from the Moon [17:33:19] Moon rotates sloooow [17:35:35] We're going to need an updated Skylab at some point [17:36:18] yeah, as soon as we can stop and continue with countdowns haha [17:36:35] then nothing is stopping me from developing the proper launch window and targeting [17:37:37] And I need to make the Saturn V stages able to launch while docked to each other [17:37:44] like I did with the Saturn IB for Apollo 5 [17:38:14] because otherwise there is a whole invisible CSM running in the background in that Saturn V [17:40:22] That should simplify some classes a bit. [17:41:23] likely a good point to upgrade the connectors to use clbkGeneric() [17:43:24] ah right, yeah I could wire the connections together with that [17:43:35] just testing how it goes using that [17:53:15] would be nice to find some software for these too: https://archive.org/details/bitsavers_ibm4piTechBMSystem4PiComputers1967_10147919/mode/2up [17:54:18] we have one routine of the Skylab computer in several languages [17:54:38] in the same document that had a bunch of LVDC code converted to other languages [17:55:06] "ATM Task Keying" [17:55:10] so like priority control [17:55:36] but it's very little, only two pages [19:35:40] but yeah you definitely should :D [19:37:03] did we have that particular AOH before? [19:37:16] I think that was added to the AFJ a while ago [19:37:19] but not that long [19:37:44] taking up 655 MB of my space... [19:37:51] hehehe [19:37:55] but I guess you can't have enough AOHs [19:38:02] we need some more CSM Volume Is [19:39:30] thewonderidiot I have no idea. expected to find some clues here http://www.bitsavers.org/pdf/raytheon/ but nothing looks even close [19:40:30] mmmm interesting [19:40:41] the RT logo up at the top is probably a clue -- I don't think I've seen that before on any other Raytheon material [19:40:52] and the stack-based nature of the machine is pretty interesting [21:00:28] night! [15:25:54] Hey Niklas [15:27:47] hey [16:26:25] went down a bit of a rabbit hole on skylab computers last night. there is a frustratingly small amount of info avaliable on the TC model [16:28:53] the larger, EP model is more or less an IBM 360/44 with a small memory and a lot of IO [16:29:21] even had the same instruction format and interupt levels [16:31:21] all i can find for the TC is instruction names [16:34:49] what is TC and EP? [16:37:22] there were 4 different models of the System/4Pi: TC (tactical computer), CP-1, CP-2 (cost performance), and EP (extended? performance. [16:38:46] i was trying to assess how hard it would be to write an emulator and a simple little cross-assembler [16:39:35] which model did eventually fly on Skylab? [16:39:47] TC [16:53:29] I'm still looking at Skylab rendezvous stuff [16:53:57] because of the phasing constraints with the fairly short rendezvous profile they did, the number of days that actually had a usable launch window was actually quite low [16:54:19] once or twice a month [16:59:42] why did they opt for such a short rendezvous? [17:02:38] "The first mission, SL-2 (May 1973) had a [17:02:39] requirement for a flight day 1 docking so that medical [17:02:40] samples taken could be placed in the Skylab freeze r [17:02:41] within 24 hours of collection." [17:03:13] but slightly longer rendezvous were ok, too [17:03:29] they used the M=5 opportunity, so on the 5th orbit [17:03:36] but M=6 to 8 were also planned for [17:03:54] morning! [17:03:58] hey Mike [17:04:21] indy91, I was doing more research and found a guy on twitter who would be worth trying to talk to [17:05:15] still active [17:05:39] that document looks familiar [17:06:54] ooooooo [17:08:56] so how do we approach this? [17:09:56] good question :D [17:10:19] "can you please send everything you have to Mike for scanning" [17:10:34] I am about as unfamiliar with twitter as it gets -- does it have DMs? if not I guess one of us just tweets at him [17:11:10] it does have DMs [17:11:11] there's other things we can do, like organize for professional scanning at the Gainesville FL branch of the internet archive, like we did for the older ND-1021041/ND-1021042 binders [17:11:19] my only ever Twitter DM was Apollo related :D [17:11:42] I had asked for a contact to the people who restored the MOCR [17:11:58] but I'd start with just broaching the subject of possibly having them scanned and work out the details from there [17:34:43] yeah that makes sense [17:38:48] I'm also curious what else he has, if he calls himself a hoarder :D [17:54:18] thewonderidiot, did you ever get anything useful from that guy I emailed you about? [17:55:03] nope [17:57:56] I sort of suspected that he might be a dead end [18:02:24] it happens :) [18:02:32] there are way more dead ends than not dead ends haha [20:08:57] Evening [20:28:19] Thank you [20:28:23] Hey Thymo [20:35:46] hey hey [20:48:41] night! [20:59:01] .tell indy91, bad news (potentially) from UHCL. aparently they can't find the document, although they said that they are looking for it... [20:59:48] oh jeez [21:16:04] well it does say "Oversized, store on shelves". I would imagine it's a matter of "which shelves?". fingers crossed [21:24:38] they probably have at least a few of those [14:47:14] hey [15:39:33] morning! [16:05:02] Hey [16:13:49] hey guys [17:18:43] hey [17:21:39] hey hey [18:43:29] well I got my computer back up and running just in time. phone decided to go into fire-starter mode and I have to give it the ol'e coup de grâce [18:45:38] hahaha oh no [20:39:56] how is it that we've gone 15 years with no 2d panel optimizations, and now we have two people working on it [20:40:14] it's like the time we all created telemetry clients in the same week [20:49:25] Anyone here selfhosted a mailserver before? My new ISP doesn't provide SMTP relaying to send wiki mail [21:11:12] I don't, but I was considering it. I had actually been thinking about asking you for advice on it haha [21:12:38] I've never done it before since my ISP blocked outgoing mail. My new one doesn't. I do know the easisiest is things like mail-in-a-box but you'l have most trouble making sure you stay off all the spam lists. [21:12:45] Especially when using a residential IP [21:29:01] Wiki is open again. Set up some permissions and captcha [21:29:11] Don' [21:29:24] Don't know how to delete the old spam accounts yet [21:36:33] maybe you can just deactivate them. I'm sure there's database associations that mediawiki doesn't want to let you break [15:31:00] hey Nik [15:35:01] hey [15:46:26] looks like you have some competition for panel optimization [15:54:16] kind of haha [15:54:36] the approaches are so different, they aren't even hurting each other [15:54:50] although hopefully my update makes his idea unnecessary [17:02:13] morning! [17:32:06] hey Mike [17:32:11] what's up? [17:54:33] hey [17:54:57] kind of alternating between CSM main panel and figuring out Skylab launches haha [17:55:38] hehehe [17:56:01] of course I am finding more MSC memos I want... [17:56:08] of course [17:56:19] better than me finding more AP-M memos that I want :P [17:57:43] yeah, although this one doesn't appear in the front pages scanned by Ron [17:57:49] so there is a chance that not even NARA has it [17:57:57] ahhh, yeah, maybe not better then [17:59:11] but I could go back to Gemini documents that are being referenced [17:59:15] could have the same calculations [17:59:51] Gemini really had to deal with more of the same as Skylab than Apollo [18:00:36] yeah that's a good point [18:04:39] I spent the night last night really digging into the ECDU configuration history [18:04:49] and holy cow is it a mess, compared to what I'm used to with the AGC and DSKY [18:05:56] maybe I'm reading too much into these drawings, but it feels like a lot of the changes they made were kind of controversial [18:06:03] because they'd be introduced but then disappear later [18:06:29] or, like, there was a transformer that they had some reliability issues with so they replaced it with a different one [18:07:10] but through the end of the program they continued to make new module revisions with *both* the original transformer and the replacement [18:07:36] and in some cases, other changes were mutually exclusive with the transformer change, so you could e.g. either have the new transformer, or the resistor change, but not both [18:07:55] and the exact meaning of different CDU dash numbers changed sometimes [18:07:58] it's a disaster :D [18:08:44] CDU gave more trouble during actual flights than AGC or IMU ever did. I wonder where that comes from :D [18:09:00] hahaha yeah, suddenly it is maybe not so surprising [18:10:10] but yeah as far as I can tell, every CDU is a box of mysteries and you'll never know which channels have which transformers, or the resistor change or not, until you open it and look [18:10:59] the CDU's dash number will rule some options out, probably, but will definitely not narrow things down to one option [18:12:30] now all of that being said: I don't think any of this, except for maaaaybe the resistor change, have any real impact on behavior if the parts aren't broken [18:13:21] and it seems like the resistor change was the most controversial of all, and from only a month or two after it was made through the end of the program there was no model of the CDU that had that change as the default option [18:13:51] I think we talked about that change a while ago [18:13:54] yeah [18:14:05] didn't that have to do with the switch betwee coarse and fine system or so? [18:14:10] yep exactly! [18:14:29] when I was trying and failing to replicate exactly the Apollo 11 situation in simulation [18:16:29] right [18:17:46] The coarse-fine crossover for the ECDU was originally designed to take place at a maximum coarse error of 9 degrees. System tests showed that, under certain conditions, an oscillatory limit-cycle condition developed between the coarse and fine systems. A design change made to reduce the crossover point to 7.5 degrees from null corrected the problem. [18:17:58] and then they apparently just stopped caring about it? [18:18:04] CDUs are weird, man [18:28:00] haha [22:11:21] i should probably ask this of the whole group, but do you guys see a good reason not to consider adding githubs recomended "code of conduct" to the project? [22:13:37] hahahaha I have never heard of this and google auto-completed "github code of conduct controversy" for me [22:16:29] I dunno, seems fine to me [22:16:38] have we ever had any problems? [22:17:49] also do you have a link to the current copy of that? [22:22:24] There's a default CoC? [22:24:23] yeah [22:24:24] I found it [22:24:58] from the main repo page, if you do Add File and then type out the name CODE_OF_CONDUCT as the filename, a button to choose the template appears in the top right [22:25:36] it's basically this: https://www.contributor-covenant.org/version/2/0/code_of_conduct/ [22:31:00] I'll give it a proper read in the morning. I don't see anything obviously wrong with it, probably fine [22:34:03] I think the controversy was mostly over previous versions [13:27:59] hey Nik [13:46:25] hey [15:42:24] it would be really cool if we could auto-generate diagrams like this https://nassp.space/images/1/1e/CSM_systems_diagram.gif [16:04:19] morning! [16:11:08] hey Mike [18:05:06] hey hey [18:42:16] I think I want to get serious about the launch targeting [18:42:40] I'll write myself a little tool that builds a state vector for scenarios [18:42:52] so that it is exactly in-plane at a specific time [18:43:32] that way I can put e.g. a DeltaGlider in the scenario and I can launch to it without having to launch at some random time [18:44:09] and everything else can be done, including LVDC targeting update [18:44:31] just needs a bit of work in the RTCC MFD [19:43:58] so this will be generating your own presettings? [19:49:07] nah, this is for Skylab launches [19:49:13] or any vehicle in Earth orbit [19:49:37] launches to the Moon require very different calculations. Not trying to tackle that right now [19:50:24] I mean, the launch targeting was probably part of the LVDC presettings for the Saturn IB [19:50:36] but it would have been updated an hour before launch or so [19:53:56] gotcha gotcha [19:58:12] where it gets difficult is the orbital plane to insert into [19:58:23] because with non-spherical gravity, the plane wobbles [19:59:12] and shifts over time, nodal precession [20:46:13] night! [17:04:07] morning! [17:46:00] hello [18:25:19] what's up? [18:26:18] Doing some reading on gRPC to see if it's a good candidate for the new NASSP API [18:36:35] n7275: Did you create a second account on the wiki? [18:41:27] uh oh [18:41:33] yeah probably [18:45:27] Thymo, gRPC for a telemetry API? [18:45:42] Telemetry will be a part of it, yes. [18:47:11] I want it to be sort of modular so I can also export data relevant to RTCC etc. if we ever want to do an external MCC simulation like Reentry has [18:47:42] REST is a no-go since you can't really do streaming data required for telemetry. [18:48:16] WebSockets could work but that's a bit meh. I don't want to push everything through a stream. [18:49:01] gRPC/protobuf allows you to generate bindings for any language you want basically. So server will be C++ (obviously) but clients could be in Go/Rust/Python/whatever. [19:04:09] this is very much outside of my area of expertise [19:35:14] but that definitely soulds like the way to go [19:35:25] *sounds [21:49:09] gRPC uses HTTP/2 so it allows multiplexing requests over the same connection. So you can have both vehicles telemetry, and any other stuff without having to open multiple sockets. [21:49:29] HTTP/2 Server Push is also nice to use for streaming the telemetry. [21:50:02] It is based on TCP though. So it would need to run in a separate thread with some buffering in order not to hang the sim under time acceleration. [22:52:49] I don't think the extra thread would be a big deal though [01:08:49] Hey [01:15:56] hey [01:17:11] I've been trying to figure out how to rework the 2D panels to use Sketchpads to try and improve performance, but as near as I can tell, the Sketchpad object has no methods for drawing textures whatsover. It seems to be exclusively used to draw basic shapes and text [01:17:46] you can still use GetSurface() on a Sketchpad to get a SURFHANDLE object but I don't know if that just brings us back to square one [01:19:26] it's possible that using GetSurface() on a sketchpad allows for oapiBlt() calls to be batched, but attempting to release the Sketchpad seems to cause bad things resulting in some kind of assertion failure in the D3D9 graphics plugin. However, NOT releasing the Sketchpad also results in an assertion failure because now we're not cleaning up. [01:20:29] Overall, NASSP's drawing logic is godawful, and I have basically no way of knowing if I'm doing something wrong or not, because I would probably need to rewrite the entire drawing method to be actually sane rather than the spaghetti mess of switch cases like it is now. [01:22:36] Don't get me wrong, I mean no disrespect to whoever wrote this, since given the complexity of things I don't know how I would implement it myself, but there's basically no way to try new things here because if I want to mess around with surface handles I would need to add cleanup code to EVERY SINGLE SWITCH CASE [01:22:55] and there's dozens of those [01:23:33] Also, looking at the Orbiter code on GitHub, it looks to me like they are just using the old oapiBlt() methods for all of the built-in crafts anyway [01:24:28] so I don't even know if using Sketchpads would be a viable or worthwhile change over tearing out the rendering logic and starting over with a better implementation, even if it uses the same API [01:38:42] so funny thing. most of this code is like 15-17 years old [01:39:09] and you, Nik, and one other guy are all looking at it, within the span of like a week [01:39:41] I would talk to indy91 before you put too much work into this. [01:44:51] yeah I think I'm probably gonna throw in the towel already lol [01:45:08] let someone who can actually understand how this drawing code is supposed to work take care of it [02:14:33] currently I think everything is redrawn every frame. Nik was working on a method to redraw only on state change [02:14:56] stillusing oapiblit() but with significant performance gains [02:35:08] Seems like a fairly sensible decision, though I still definitely think that we might be able to make things better if we can find the time to start from scratch and throw out all the legacy code decisions [02:35:37] there's so many hard-coded values and non-scalable ways of doing things [02:49:51] no disagreement here. huge project though. [02:50:03] not that we're too afrade of those these days haha [02:56:34] hahahaha [02:56:37] that's for sure [02:56:45] and I'm confident we'll be able to do it someday [02:57:00] perhaps when we try getting it working with the GitHub branch of Orbiter Beta, etc. [14:53:11] hey [15:00:13] hey [16:03:34] do I need to announce more publically what I am working on? Is everyone working on the 2D panel right now? :D [16:04:10] it's not like I am really enjoying working on that lol, personally I have mostly switched over to the VC [16:05:52] what I am enjoying is that I have mostly figured out Skylab launch targeting. [16:18:16] morning! [16:19:54] nice :D [16:22:19] hey [16:22:29] hey hey [16:22:36] At insertion I am getting a plane error of 0.13° compared to the target [16:22:55] not bad! [16:22:57] But due to differential nodal regression that becomes almost 0° on its own [16:23:03] oh very nice [16:23:14] 0.13° would be somewhat bad haha, that's like a 50 ft/s plane change maneuver [16:23:36] When we found the Skylark GSOP I immediately implemented it in the RTCC MFD if you recall [16:23:44] the rendezvous calculations I mean [16:24:01] hahaha right [16:24:24] and to test it I maneuvered a CSM to get into the same position relative to the target that the Skylab Saturn IB missions would have, at orbital insertion [16:24:34] and of course that was completely in-plane [16:24:48] that's how I discovered that, in-plane at insertion is not so good :D [16:26:27] hehehe [16:26:36] because the longitude of the ascending node shifts due to nonspherical gravity and that shift is different for lower vs. higher altitude [16:26:57] For Skylab that value isn't even too large, it calculated as 0.11° [16:27:08] fairly small phasing angles and short rendezvous [16:27:16] in some Shuttle documents I saw 0.7° [16:27:37] you can spend almost all your OMS propellant fixing that :D [16:28:21] what I also found is, there must be a typo in either the Skylab IB EDD or the ASTP operational trajectory [16:28:33] a sign error, always fun [16:28:55] oh yes, always a whole bunch of fun [16:29:13] LVDC inertial coordinate system is established at GRR [16:29:21] so it's basically bound to the launch longitude [16:29:40] so to get into a specific orbital plane you need to account for the Earth rotation [16:29:56] and that's where the sign mismatches [16:30:33] I changed it in the LVDC code and not in the presettings. Not sure if that is correct, but the presetting would now have physically the correct definition [16:32:56] I have an early display for probably AS-258 prelaunch targeting, and there the presetting is minus also [16:33:14] Presetting minus, code plus, then it makes sense :D [16:33:19] EDD has a minus [16:34:37] and I guess I never completely flew a Skylab rendezvous with the Skylark calculations, because one of the maneuver calculations was a bit broken [16:35:55] actually, I'm not sure if the Skylark calculations are much longer going to be in the RTCC. I know which existing processor they modified to get the ground solutions for that rendezvous profile. [16:36:04] RTCC should have the RTCC calculations not AGC calculations [16:48:20] hmmm yeah that sounds like it's probably the EDD that is wrong [16:49:22] well, hopefully by this weekend I will have a brand new distraction for you -- I won that countdown procedure [16:51:05] awesome :D [16:51:58] will be interesting what that all includes [16:52:23] how early it starts [16:52:35] maybe we can even update our startup checklist based on it [16:53:09] our startup checklist is not based on real procedures, it's just a short checklist to get the CSM from cold and dark to the state it was in when the backup crew did their prelaunch checklist [16:53:26] like starting up the AGC [16:54:14] yeah I am pretty sure this is the real procedure for all of that [16:54:18] and of course, that EDS test. Would be really fun to implement that light show [16:55:35] it was an automated checkout program for sure [16:55:47] https://i.ebayimg.com/images/g/-zEAAOSwjthiUvCZ/s-l1600.jpg [16:55:49] but the LCC crew went through it step by step with the astronauts [16:55:59] looking at this picture -- it's not the best but you can make a lot out [16:56:08] third row from the bottom is PGNCS stuff [16:56:33] starting with IMU performance tests, then getting into gyrocompassing, with a couple of entries for E-memory verify [16:56:59] a lot of gyro compassing [16:57:23] but we knew that, the TEPHEM they loaded for clock sync was always midnight of the day before launch [16:57:48] so that's when they would have started it up [16:57:53] the day before launch [16:58:13] that interruption with the red box must be a countdown hold? [16:58:13] the middle row that has the most in it is also interesting [16:58:20] some entries for e.g. "center couch installation" [16:58:29] I guess they kept the couches out until fairly late [16:58:40] yeah I think so? I'm not sure [16:59:34] couches would get in the way and there was still quite a bit of activity inside the CM [17:01:12] cant really spot the EDS test, it went for like 30 minutes near T-2h [17:02:36] but I have seen other charts like this that have it [17:03:31] just that any procedures documents we have right now say something like "request and execute VAED (EDS Test) per V-21096)" [17:03:51] hmmm [17:04:15] and even if we don't get V-21096, having the crew procedures or at least what they would expect to see is basically just as good [17:12:20] VAED is the name of the automated checkout program used for it [17:31:55] unrelated to everything [17:32:10] I've never really looked at the CSM/LEM 5-Axis Moding engineering drawings before [17:32:23] and wow they have way way more detail than I was expecting [17:33:37] interesting. Which 5 axis is that? [17:33:43] Does that refer to 5 CDUs? [17:34:34] yeah [17:34:58] https://archive.org/details/apertureCardBox472Part2NARASW_images/page/n49/mode/1up?view=theater [17:35:03] that and the next 7 pages [17:37:18] you wouldn't think that something for all CDUs has more details [17:37:31] yeah, exactly haha [17:37:55] but this is so detailed it lists out the pins for the intertray connectors inside the CDU, which is something we have never found for the AGC [17:37:59] but those moding drawings tend to be quite nice, lots of crazy lines, but also good detail [17:38:04] and shows the order of pins for power wiring and things [17:38:13] yeah for sure [17:38:34] I already forgot which one I was looking for, something with the optics panel [17:38:58] pin numbers are good [17:44:12] intertray connector even wow [17:44:33] I guess the lesson there is, sometimes if you search for a specific tree you must look at the whole forest [17:44:42] at once [17:45:47] or, just randomly look at every drawing [17:47:34] hahaha yeah [17:47:56] or zoom in on the wrong page by accident [17:48:14] I was looking at this document that I scanned at Don's while working on CDU things last night https://www.ibiblio.org/apollo/Documents/blk2_cm_lem_mechanization_diagrams.pdf [17:48:22] because it has newer versions of some drawings than NARA [17:48:38] and I accidentally zoomed in on the wrong page, and then went "wait what the hell is this??" haha [17:49:48] November 1965 is newer?? [17:50:21] I think that some of the drawings in there are newer than what is printed on the title page [17:51:09] right, I had that a lot with IBM RTCC documents [17:52:21] can't update the title page every time you change 10 pages of a 1000 page volume [17:53:07] although actually [17:53:20] I might be wrong and the title page might be accurate lol [17:59:05] nothing useful ever comes from 1965 or earlier, you know that. Or was it the other way around for you :D [17:59:37] Although there is some good Gemini stuff from that time, but Apollo it's also preliminary ideas [17:59:40] all* [17:59:57] it's the other way around for me haha [18:00:13] 1965 is prime PGNCS engineering detail time [18:01:24] makes sense [18:01:42] and what year would that be for Block I? [18:02:15] uhhhh [18:02:39] 62 maybe? I'm not sure, I haven't spent much time looking at Block I stuff [18:02:58] and also there were several "Block I"s [18:04:21] ah right [18:05:19] Block "not good enough for lunar missions" [18:45:23] so what's your plan for the Skylab stuff? just targetting now or trying to set up some demo missions of it? [18:52:39] I could maybe put together some demo scenario [18:52:48] right now I was just using the Apollo 7 launch scenario [18:53:01] put a DeltaGlider in there in the right orbit [18:53:23] And there is an option to input a lift-off time [18:53:43] won't be the ideal time, you really need to tweak the target orbit for that [18:53:48] but it's flexible enough [18:54:08] it can calculate targeting parameters for any reasonable launch time [18:54:43] not sure which CMC software would be the best though [18:54:52] Artemis comes the closest, but P34 is broken in Earth orbit [18:55:02] So that would basically mean, no onboard calculations at all [18:57:28] I also want it to be backwards compatible enough for missions like AS-258 [18:57:48] That might be the more doable demo scenario actually [19:03:17] hmm nah [19:03:32] AS-258 is CSM launch first [19:03:54] and the rendezvous is set up more by CSM maneuvers, not launch targeting [19:04:30] although, it would be a launch at a specific phasing angle [19:05:53]