[00:25:16] NASSP Logging has been started by thewonderidiot [00:25:20] Guenter! [17:35:54] morning! [17:37:01] hey [17:37:31] what's up? [17:38:50] I don't know, just got home! Looks like I am still going to do a change to the AGC state loading. And then something with Apollo 8 venting I guess. [17:39:51] hahaha [17:40:31] your answer to Thymo could have been MORESTATE, followed by EVENMORESTATE :P [17:45:13] not that we are going to reach 32 bits in "ADDSTATE" in the next 30 years [17:45:21] haha yeah [19:12:41] hey guys [19:19:44] yo [19:20:05] hey Matt [20:03:03] what's up? [20:03:46] radar interrupt fix is merged, so people can now fully enjoy Skylark [20:04:01] but right now I am looking at some Apollo 8 issue, back to Skylark after that [20:17:46] thewonderidiot: ADDSTATE-Final, ADDSTATE-Final-Final, ADDSTATE-Final-Final-Complete [20:18:52] for all those AGC bits we add in the year 2809 [20:30:41] :D [20:39:00] I've got banks 0 through 10 fully disassembled in Skylark [20:39:09] last night I did all of P55, which was entertaining [20:39:38] I think I'm going to skip ahead and do banks 40-43 to take out pinball and get locations for all of the extended verbs next [20:39:50] haven't tried P55 yet, it's one of the next few things on my list though! [20:40:07] excellent :D [20:40:19] I am going to be asking for your help naming a couple of things [20:40:29] there are places where Norton inlined functions and omitted their names [20:42:08] with P55? Oh boy, a program I have never even tried yet... [20:42:14] I guess I did a bit of reading in the GSOP [20:43:18] hahaha no rush. I probably won't ask until I'm done with disassembly and getting into source reconstruction [20:43:24] just in case he did include the name on some other page it's called [20:44:19] the specific function I'm thinking of is not complicated. it simply calculates the first row of NBOA, which I guess isn't stored anywhere, from the second and third rows which are padloaded [20:45:15] https://github.com/thewonderidiot/skylark/blob/main/skylark.disagc#L9608 [20:45:21] very simple little guy, which is why Norton inlined it :D [21:08:38] yeah I guess two vectors are enough to define a coordinate system. The third defining vector can always be calculated from the other two. [21:08:59] what's P55? [21:10:14] P50 establishes the relative orientation of the CSM and Skylab. So sort of a P51. [21:10:36] and then P55 can calculate e.g. star tracker angles for Skylab [21:11:06] P55 Option 1-Star Tracker Gimbal Determination Using an Aligned [21:11:10] IMU [21:11:19] Option 2-Star Tracker Gimbal Angle Determination Using CSM [21:11:21] Optics [21:12:02] so I guess with option 1 you don't need to do anything extra [21:12:26] it's just like the CMC being able to calculate a star direction for the sextant, assuming a valid REFSMMAT and IMU attitude [21:12:36] it just converts it to star tracker angles [21:12:52] with option 2 you use the sextant, don't even need a good IMU then [21:14:10] P50 option 1 calculate a sun vector... I think we can already use that with Skylab being in the right attitude, solar inertial [21:14:31] P50 option 2 would use star tracker angles as input, so we can't use that yet [21:15:03] we need to make some star trackers :) [21:15:58] P50 option 3 use the docking (roll) angle as input [21:16:08] so sort of a onboard docked alignment calculation [21:16:37] doesn't calculate an attitude for the other vehicle though, just a relative rotation matrix between CSM and Skylab [21:18:58] Skylab flight plan has a P50 option 1 scheduled not long after docking [21:19:06] makes sense, establish the relative orientation [21:19:24] P55 is more a backup, so I don't expect much of that was ever done [21:29:53] ok before someone else becomes the first person to do this... [21:29:58] let's try a P50 option 1 :D [21:30:02] hahaha [21:30:21] how is your throat btw. Feeling any better? [21:30:45] I was totally fine yesterday and now feel sick again today. although not anywhere near as bad as Monday [21:31:01] I knew yesterday that getting away with just one night of sickness was too good to be true :D [21:31:12] oh that sounds like my Covid. Never knew what the next day brings. [21:31:31] I should do another test now that it's been a couple of days [21:31:54] first day was negative, but that's pretty normal I think [21:36:01] P50 gave me 145.99°, 178.99°, 000.02° as N23 [21:36:26] if Skylab is currently deadbanding, I believe nominal would be 145°, 180°, 0° [21:36:29] but I have to check [21:36:37] not too bad then! [21:36:41] probably not the most accurate method, just using the Skylab attitude [21:37:03] we are also only simulating the thruster attitude control system [21:37:12] I believe the CMGs had a smaller deadband [21:38:32] also, I haven't verified yet that the solar ephemeris is all that accurate [21:40:07] CC: "Those Noun 23's look very good, Joe" [21:40:11] tell me the numbers! [21:41:44] but yeah, I think it was at the edge of the deadband [21:42:04] did another few P50, now I got 145.73°, 179.07°, 000.02° [22:06:10] night! [16:29:52] hey [16:55:46] hey Nik [17:07:10] morning! [17:15:39] got through all of bank 40 and half of bank 41 in skylark last night/this morning. nothing particularly interesting other than the new ATTERROR routine for output, which is only two new instructions [17:21:36] oh interesting [17:21:38] is that N56? [17:21:57] good question, I haven't gotten to the noun tables yet :D [17:24:15] nope, it's N04 [17:24:19] according to Norton [17:25:15] ah yeah, that is attitude error, didn't see it [17:25:22] N56 seems to be attitude rate, also new [17:26:27] is N04 just the negative value of N05? [17:26:31] yep. that looks like it uses existing routines (DPINSF/DPOUTSF) with a new scale factor [17:27:22] uhhh it might be [17:27:28] they do use different erasables [17:27:36] AK for N04, vs. DSPTEM1 for N05 [17:27:40] oh it seems like N04 and N56 are new because they are from the Docked DAP [17:28:28] N05 is P51/P52 of course. Just confused me for a moment because they added a R2 [17:53:09] you know, it would be nice if Orbiter has some better controls for limiting time acceleration [17:54:57] ah yeah, like a limit you can set [17:55:12] as it stands NASSP code would have to do that I guess [17:56:02] uhh [17:56:06] we already have that haha [17:56:12] is that even properly enforced... [17:56:41] oh yeah it is [17:56:49] in CSMcomputer::Timestep [17:56:55] because that makes sense... [17:57:26] yeah, but it's not a real limit. i.e. it has to run one timestep at the higher time acceleration to check if it's above the limit [17:57:55] I'd like to be able to set a hard maximum [17:58:10] and control what r and t change [17:58:16] true, true [18:00:24] I added the Apollo 8 LVDC venting model as a separate PR, I tested it with good results. I like PRs where you can see with one look what they all do :D [20:01:59] approved! [20:03:55] thanks! [20:04:10] I've started to create an ASTP scenario [20:04:26] ... but I am not going to give it Apollo number 21 and use that for the mission file [20:04:52] I'm going to implement mission names instead of number. We were already partially there. [20:05:07] the number is going to be 0, but it doesn't matter too much anymore [20:07:39] oh nice! [20:07:58] hmm, I requested some Soyuz 19 TLEs from Celestrak, I found at least one on the Internet. I thought the request was pretty much automated, but I just got an email with nothing attached. Maybe they just don't have any... [20:08:12] let me see what space-track has [20:09:03] the TLE I found was the last one before they deorbited probably [20:09:09] I'd rather have one after launch [20:12:04] oh nice, thanks! [20:12:48] launch targeting is unhappy, but why... [20:15:25] ah because I am too dumb to use my own MFD [20:15:32] hahaha [20:17:04] now I got a solution, 19:52 GMT optimum launch time [20:17:16] 19:50 was actual, but that's the beginning of the launch window [20:17:19] so pretty close [20:17:25] might even be better with the earlier TLE [20:19:59] one slight complication is that the Soyuz did a burn after the Apollo launch [20:25:32] I'm fairly certian that the Project OctoberSky meshes included a 7K-TM. now that we have Skylark, it might be a good time to talk one of our forum comrades into developing one [20:26:03] What we need to develop is VHF ranging that can be attached to any vessel [20:28:00] it could maybe even be a standalone vessel [20:28:11] that you just attached to the Soyuz for example [20:28:20] like you would attach a VHF antenna haha [20:29:57] not much change in launch time with a TLE closer to launch, but the phase angle definitely shifted [20:30:22] actual launch time is definitely usable [20:38:29] 60° phase angle only [20:38:34] But the DH isn't large [20:39:28] hahaha oh man, 2009 https://www.orbiter-forum.com/threads/soyuz-7k-t-mesh-and-octobersky-questions.6553/ [20:40:28] n7275, when will the secret project be revealed????? [20:45:02] oh wow [20:45:06] I forgot about that [20:46:12] I think I got as far as a 2d panel, but not a very good one (Ms paint texture, imagine the worst) [20:50:02] https://djvader.blogspot.com/?m=1 [20:59:33] my one and only published orbiter addon was a scenerio pack for Salyut 6 missions using the Soyuz addon for Orbiter 2003 [20:59:47] thewonderidiot how did you find that thread lol [21:00:08] I was curious what project octobersky was, and that was one of the first few google results haha [21:02:02] oh interesting [21:03:43] yeah, it was the "NASSP of the Russian space program" developed (without ever releasing anything) from 2005 to 2008 iirc [21:04:23] too bad it wasn't finished, that would have been very cool :D [21:26:21] night! [14:35:23] good morning [14:35:29] hey Matt [14:38:06] it's good that someone other than us is interested in this : https://www.orbiter-forum.com/threads/what-would-be-needed-for-creating-ellipsoid-planets-in-orbiter.41607/ [14:41:38] yep! [15:46:31] morning! [15:50:28] hey Mike [15:51:23] what's up? [15:54:03] ASTP scenario tweaking... once Ryan and others doesn't distract me [15:57:18] hehehe [18:22:42] thewonderidiot, oh btw, I did get my Soyuz ASTP TLEs yesterday after all. Just took an hour and wasn't instant haha. I thought with automation it would be nearly instantly, but I guess it isn't always like that. [18:22:52] oh weird [18:23:03] are they more or less the same as the space-track ones? [18:23:06] yep [18:23:10] I think exactly the same [18:23:34] just on the TLE format only [18:23:36] in* [18:23:44] and nothing in addition [20:14:24] cya! [13:15:47] good morning [13:18:45] hello hello [13:19:09] thinking about the shape of the Earth? :D [13:22:20] yeah. aparently there are some challenges [13:31:50] I'm so tempted to look at atmospheric rendering code [13:34:28] yeah I guess rendering is the issue [13:34:39] you could build any terrain that matches the ellipsoid [13:34:53] and use any atmospheric density model that takes latitude into account [13:35:30] but atmospheric rendering would have to match [13:37:06] I suspect it would be fairly noticeable visually on Earth [13:37:36] I would hope so, for P23 :D [13:38:36] well yes, but also the sky atcthe equator [13:38:52] looking like it was at 20km [13:39:01] *at the [13:41:06] maybe I'll make a version of that terrain just to experiment with [13:44:08] moon geometry has never been an issue for us right? [13:45:18] correct [13:45:20] selenometry, I suppose would be the correct term [13:45:26] it has the correct shape [13:45:41] and we can use the right radius in the config, for actual size and gravity [13:50:09] random question: does P57 expect the gravity vector to be perfectly normal to the reference lunar shape? [13:52:50] oh that's a great question! [13:53:13] GSOP: "It is assumed that the gravity and landing site position vectors represent the same direction in space" [13:57:10] orbiter doesn't apply and perturbation forces when vessels are in landed states [13:57:27] *any [13:57:48] do you mean J2, J3 etc.? [13:57:51] or other bodies [13:58:16] has to be other bodies [13:58:34] pretty sure that would have been noticable with the EMS bias for ground testing [13:58:39] on the body one is currently landed on [14:01:10] Moon J2 and mascons are still fairly weak over all. I doubt it causes much errors that they aren't taken into account. [14:07:21] yeah I figured, the actual displacement of the gravity vector "off center" should be very small [14:08:33] I discovered this looking at a debug string of the gravity vector [14:09:19] interestingly there are some "flat" spots on Vesta where one can roll "downhill" toward the equator [14:11:01] haha I guess P57 would have a bit more trouble on Vesta [14:12:10] orbitMFD is pretty useless there [14:26:14] okay, now back to fixing my own bugs :) [14:57:50] I found one bug with the Saturn IB LVDC orbital guidance so naturally I am completely rewriting the orbital guidance now [17:07:11] morning! [17:07:16] naturally :D [17:10:17] hey Mike [17:10:44] still the better option than to start with rewriting everything as task based, like the generalized flight program [17:39:41] thewonderidiot, I have some overwritten erasables in Skylark. I wonder if this is just an overlay though. [17:41:20] I guess I can compare in Artemis for now, if it's the same there already [17:41:26] looking at SATRLRT [17:42:28] ah yes haha [17:42:32] Artemis program note 1.3.3 [17:45:23] https://i.imgur.com/MoME6C7.png [17:45:32] that's the relevant part of the erasable memory map [17:46:17] I loaded a V49 per checklist, before actually separating from the S-IVB [20:03:33] I've stumbled into orbital integration routines [20:03:40] lots and lots of moon removal here :D [20:05:48] haha I bet [20:06:29] aside from that not much should have changed [20:06:37] for ASTP it could have used some drag calculations [20:06:42] cruising at low altitude a lot [20:52:51] night! [14:12:50] hello [14:16:31] hey Matt [14:19:44] encountered a problem with the LVDC orbital guidance flowcharts. So I will have one of those "where is this flag being set" questions for Mike, from the listing :D [14:51:20] oh interesting [14:52:06] the Saturn IB flowcharts are missing something that is definitely required for some attitude hold stuff [14:52:40] the AS-513 (Skylab) listing should be pretty similar for orbital guidance, so I hope I can find my mystery flag [15:01:04] did you ever acquire the listings? [15:13:38] morning! [15:14:27] hey Mike [15:17:28] what is this flag? [15:17:53] I have not yet [15:18:32] I don't know what this flag is, the Saturn IB EDD flowcharts don't mention it. The generated Saturn V flowcharts sort of have it :D [15:18:43] I know exactly where it would be set [15:18:45] I think [15:19:02] AS-513, Orbital Guidance Maneuver Processor, label MP020 [15:19:16] is a flag being set here for orbital guidance first pass? [15:20:04] the EDD typically has variable (and flag) names for basically everything that is being input and output, but here it seems to be missing something [15:21:08] F.FPIH, "1st pass flag for inertial hold" ? [15:25:44] aha! [15:25:52] that's exactly what I am looking for :D [15:26:19] is that always set there, or on some kind of condition [15:26:36] the very first thing MP020 does is unconditionally set that to 0 [15:26:51] to zero... [15:27:24] I know some other first pass flags already [15:27:30] F.SLR for example [15:28:26] apparently for this flag, 0 means first pass [15:28:34] that is good haha [15:29:10] they must have forgotten this flag somehow in the Saturn IB EDD flowcharts [15:29:15] it must exist [15:29:52] know the variable name already helps a lot [15:29:55] knowing* [15:29:57] thanks :D [15:30:17] I know there was a discussion about generating the flowcharts, on the mailing list. did Ron ever figure that out? [15:30:46] the Saturn IB version also has "Initialize for first pass orbital guidance" at MP020, but nowhere does it say which flag [15:37:00] I guess I am also going to unconditionally set that flag then [15:37:38] thewonderidiot, is the flag then set to 1 in orbital guidance somewhere? [15:39:06] either in OG110 or OG3000 [15:40:41] ah OG110 sets that and also the MC27 bit then, interesting [15:41:07] but they aren't the same flag, right? [15:41:27] F.FPIH and the MC27 bit for inertial hold? [15:44:55] right. OG110's logic is: [15:44:56] * Set MC27 bit [15:44:57] * is FPIH zero? [15:44:58] * Yes, call U.FR00 to perform attitude freeze, then set it to 1 [15:44:59] * No, jumpt to OG115 and call M.CC10 to telemeter guidance chis [15:46:18] yep, that's basically how I have set it up now, too [15:46:35] should work, just needed some first pass logic [15:49:40] n7275: kind of. https://ibiblio.org/apollo/LVDC.html#Flowcharts [15:50:03] as Niklas is observing, they're not perfect haha [15:51:13] yeah sadly haha [15:51:14] ahh cool. yeah, the accuracy seems to be a theme with flowcharts [15:51:30] but as I am also observing, not even the official Saturn IB flowcharts are perfect [16:25:44] the Skylark docked DAP is using a way to set the accumulator to zero that I haven't seen in any other rope [16:25:59] which is pretty strange haha [16:32:01] oh that's interesting [16:32:18] they're doing XCH 7 [16:32:29] where 7 is hardwared to provide 0s in the computer [16:32:50] LXCH 7 and QXCH 7 are very common, and Yul/GAP even gave them their own mnemonics, ZL and ZQ [16:33:01] but there was no ZA, so they have to have actually been typing out XCH 7 [16:35:05] and they do it a lot [16:35:16] why don't they just CAF ZERO like all of the rest of the programs, and all of the rest of Skylark haha [16:35:32] might have been some new developer that just had a creative new idea [16:35:39] yeah, that's whawt I'm thinking [16:35:44] -w [16:40:05] ok now I can go back to this LVDC guidance testing. My first test case was already failing, giving control to the CMC and then back to the LVDC [16:46:14] it should go into att hold [16:46:25] and guess what didn't work right because of a missing flag... [16:47:54] hehehe [16:48:18] but now I have basically implemented the orbital guidance 1:1 from the flowchart [16:48:30] including maneuver uplinks, but I still have to test those [16:51:05] awesome! [21:30:32] night! [16:30:37] morning! [17:01:25] hey [17:08:21] hey guys [17:25:53] I had been thinking the P50s/R50s would be relatively safe from changes. I was apparently very wrong haha [17:37:49] oh? [17:39:45] yeah. R50 was basically rewritten, lots of changes to R52, a decent number of changes and reorganizing to R51 [18:31:05] looks up what those routines are [18:31:56] oh, that is indeed surprising that R50 got a rewrite [18:36:31] haha yeah [18:37:11] where am I expecting impacts from the coordinate system change? is it just in the ephemeris routines? [18:38:16] PIOS [18:38:48] gotcha. and nothing else really would have been affected? [18:39:01] and I guess in coasting integration and some other parts it uses part of the RNP matrix now as a z-axis unit vector [18:39:18] instead of using the small correction angles or even [0 0 1] [18:40:09] LMATRIX [18:40:24] some programs where this would also be used got deleted, like P23 [18:42:08] another place would be Average G but it's the same again, it just uses a part of LMATRIX [18:42:44] cool, so mostly small changes elsewhere :D [18:45:34] there could be places I am not thinking of where it uses [0 0 1] vector previously but the same part of LMATRIX [18:45:38] in Skylark [19:25:25] thewonderidiot, a LVDC question you should be immediately qualified for. What values can the flight mode indicator (D.FMDI) have. Does it only have the flight vs. repeatable vs. non-repeatable indicator or something else, too? [19:26:29] I'm adding that variable. I could make those 3 modes have the values 0,1,2 but I could also make it "correct" [19:27:17] it's a bitfield [19:27:35] ah so there is more information in it [19:28:00] the EDD might define some of the bits -- but it's not concisely defined in one location in the listing [19:28:15] I can go through and scrape all of the bit positions and what they mean tonight, but it will take a bit [19:28:22] ah Ron has some stuff about it on the website [19:28:28] actually not something I can immediately answer haha [19:28:36] Bit 26 is 1 = normal flight mode, [19:28:40] # 0 = flight test mode. [19:28:43] # Bit 15 is 1 = repeatable, [19:28:44] # 0 = non-repeatable. [19:28:46] # Bit 11 is 1 = Cape Canaveral, [19:28:47] # 0 = Huntsville. [19:28:52] that's all I really need for now [19:29:31] don't need any other bits or now, but I will make it a bitfield, too, with the right size and use those 2 bits [19:29:35] for now* [19:30:59] I'm not implementing the test modes, but I am encountering enough if-else cases where these bits get checked that I might as well add those checks for completeness [19:36:18] makes sense! [20:12:56] indy91, this table has gotten a bit outdated :D https://www.orbiter-forum.com/threads/nassp-and-a-real-agc.37240/#post-558450 [20:13:16] "Please someone find a Skylark listing" [20:13:56] hahaha to be fair, you could still say that. a proper listing would be fantastic to have for the comments [20:13:58] fixed! [20:14:11] ah wait [20:14:17] we also have LM131R1! [20:14:20] yep [20:15:28] turns out ropes are more durable than listings [20:16:27] but only if the part number is >= 2003972 :P [20:16:41] listings don't lose random bits lol [20:17:58] oooh yes very true [20:24:40] the Skylark readings gave us 2568 more reasons why switching diodes was a good idea :D [20:25:25] good long term testing [20:25:30] I'd consider it flight worthy by now [20:25:52] hehehe [21:33:11] night! [16:51:34] hey [17:01:19] morning! [17:07:24] I was thinking about how the RTCC lunar surface alignment display can process AGS data. Not that we can do that with our RTCC, but now I am thinking about the biggest missing feature in our LM: AGS telemetry. [17:10:40] oooh interesting [17:11:53] that is something I don't know anything about :D [17:15:10] I will have to do some reading, the main challenge might be timing requirements [17:42:28] hello [17:49:21] hey [18:12:48] hey Matt [18:13:52] I think I can already forget the AGS telemetry thing. The AEA doesn't run its timestep together with the PCM. [18:14:09] this would require LGC, AEA and PCM to run together [18:14:25] which would also solve a PGNS to AGS downlink issue, but it's a bigger project [18:37:31] combining timesteps you say? [18:37:35] thinks about counters [18:37:37] :P [18:39:07] yep, it would help with that PR :D [18:39:20] if I were to do this, I would immediately include the CTE as well [18:39:29] timing pulses to drive the timers etc. [18:44:41] oh, before we get too far away from it -- would you mind making one of your videos showing off Skylark features at some point? as part of giving back to the museum :) [18:47:36] sure, I can do that [18:48:32] thanks! [18:50:54] I would imagine that mostly the rendezvous calculations and the docked DAP that you can put in a video [18:51:15] there are lots of other small things, but they are difficult to show off [18:52:00] maybe P50/P55 somehow, but they require explanations [18:52:03] oh yeah definitely [18:52:39] Skylark is even more different than I was expecting, there's no way to capture it all haha [18:52:44] I think just hitting the major things is fine :D [18:53:18] I am very happy with the special short burn routine giving small residuals, but that's all you can show, small numbers on the DSKY :D [18:54:58] hehehehe [18:56:07] R27 is something you could probably show, but to be honest, I have still some learning to do there myself [18:56:45] I think you can use it even if the state vectors are total garbage. It has some features that go really nicely together with rendezvous chart solutions. [18:59:15] like with a failed IMU [18:59:22] oh wow [19:00:08] ASTP IMU fail rendezvous checklist just calls the rendezvous programs like normal lol [19:00:21] oooh of course [19:00:25] they just use P77 [19:00:39] after each burn [19:00:51] and VHF ranging has no attitude data, so, works fine without IMU [19:01:40] that's sound fun to do [19:01:55] hah yeah, that would be entertaining :D [21:47:26] night! [16:42:24] hello [16:55:46] morning! [17:38:30] hey Mike [17:39:19] what's up? [17:41:56] lunch [17:46:14] one of the best times of the day :D [17:49:30] definitely :) [15:52:50] hey [17:18:50]