[13:47:52] NASSP Logging has been started by n7275 [13:47:54] hey [13:49:39] hey Matt [14:42:55] I started a small project last night, which was originally intended only to improve code readability [14:43:14] but I couldn't resist adding features [14:43:47] ...somehow it *still* improves readability though [14:44:35] the radiative function in thermal.cpp [14:45:15] the premise of how it works is fairly solid, but it was hard the read. the compiler might even like my changes too [14:46:28] the feature I added was albedo+IR heat from the moon and other planets not just earth [14:47:03] I'm really interested to see what this does to LM temps in lunar orbit and on the surface [14:47:44] so maybe my LM cabin won't be -40F at LM activation anymore? :D [14:54:22] an extra 600W/m^2 should help [14:58:58] also. our thermal radiation polars are basically just cos(theta) for everything. so no heat if your more than 90deg away from the sun. I'm going to add a "cardioid" and an "omni" pattern. [15:35:43] how's LM activation on Apollo 9 look for temps? [15:40:34] hmm haven't flown 9 in ages [17:13:27] do you think there's any practical reason not to convert our Vector3s to VECTOR3s, it does make things more oapi dependent, but we are an Orbiter addon after all [17:58:03] good evening [18:04:58] hey Nik [18:05:38] what's up? [18:06:52] messing with physics again [18:08:16] sounds fun [18:09:17] https://github.com/n7275/NASSP/tree/rewrite_radiative [18:10:14] ha [18:10:22] Earth, Sun and Moon sounds reasonable [18:10:58] but I feel like the contribution of Mercury to the thermal environment of Apollo is not very big :D [18:11:33] can't hurt to have those values in there of course [18:12:04] it would only contribute heat if you were in it's SOI. haven't added a check for it yet haha [18:13:28] we should get a slight seasonal variation in solar flux now [18:14:49] due to the distance to the Sun? [18:14:56] yes [18:24:35] hey Niklas [18:46:35] Ive been testing with Apollo 11 late launch in lunar orbit [18:48:08] how is it holding up [18:48:25] mostly been going well, abort PADS are more consistently valid [18:48:46] the only issue is the hard-coded times for things like DOI, map updates, tracking pads etc [18:48:48] but [18:49:07] https://github.com/jalexb88/NASSP/commit/57aa094a17a122c2446298c16e522f3db1538960 [18:49:40] I just made small cganges to the 1st guess/threshold times [18:51:19] with those changes everything works perfectly, tested up to the DOI pad [18:52:32] yeah those look all good [18:52:54] at some distant point when the MCC is using the MPT properly it can access the rev crossing table [18:53:07] RTCC is storing those times for up to 30 orbits [18:53:33] because then you can just say, event X should happen e.g. 25 minutes into rev 10 [18:54:16] right [18:54:34] I was actually looking for a way to do that [18:54:36] the MCC keeps track of time into current rev [18:54:44] but not any later ones [18:55:44] oh and one other thing [18:55:57] the LS RESMMAT before MCC-4 [18:56:07] it uses a hard-coded landing time [18:56:59] or not really hard-coded [18:57:09] but the original is not updated yet by the LDPP [18:57:49] so its not really that big of a deal since the LDPP calculation after LOI will update it before the 2nd LS RESFMMAT update [18:58:48] but on really late launches the LOI pitch will be a few degrees different from the FP [18:59:02] hmm right [18:59:43] like I said not that big of a deal, but if something could update it before the 1st LS REFSMMAT update it would be corect [18:59:55] for late launches [19:00:42] I know there is a LOI calculation before it, but all it does is print the TLAND on the online monitor [19:01:00] I wonder if it should also update the actual TLAND? [19:01:09] like the LDPP does [19:02:25] the "LS during TLC" option the MCC uses there didn't exist in reality [19:02:36] so the MCC should run the LDPP and get an updated time that way [19:02:50] right [20:41:58] night! [12:51:37] good morning [12:53:48] hey Matt [13:39:27] there's like 4 levels of converting back and forth between oapi and systemsSDK vector types in some places lol [14:23:38] sounds very efficient lol [15:15:18] hey [15:16:25] hey Niklas [15:29:37] hey [15:30:45] Thymo_, we need to have a look at this branch: https://github.com/orbiternassp/NASSP/pull/661 The last we did about it that we wanted some scenario versioning in place, that was in February. We can't let n7275 keep adding PRs that we aren't merging :D [15:33:28] agreed... my Apollo 16 astronauts were very grumpy about the cold LM cabin pre-PDI :D [16:16:46] I don't think a lot needs to happen for it. I'll dig into it this evening and if things still need changing on my end I'll have a PR up by the end of this week. [16:21:30] awesome. thanks. [18:42:17] hi gondos [18:55:13] Hey gondos. Didn't you port the NASSP solution to CMake in your linux branch? [19:10:17] indy91, did extensive testing with the MCC changes I did, both on-time and delayed scenarios work with it. PR sent [19:10:52] ah great [19:11:33] did you do any more changes from when you showed it to me yesterday? [19:11:41] no [19:12:11] ah good haha, I had already crosschecked those times [19:13:49] n7275, your groundstation tracking branch, do you consider that ready? Last time I checked I didn't see any issues with it anymore [19:14:09] I can do one last pass looking at the code and then that can also be merged [19:15:50] i believe so. I got a little sidetracked trying to fix the antenna animation, but I'm like 70% certain it's a d3d9 client bug [19:16:45] oh that thing with not closing Orbiter completely? [19:16:51] yep [19:17:16] it's probably an NASSP bug, some memory not being freed properly [19:17:23] but unrelated to you PR [19:17:45] approved. Should I just merged it or do you want to write something for the forum? [19:17:48] I did confirm that it happens in the Orbiter2016 branch too [19:18:01] merge* [19:18:59] you can merge it. I have some text for a post saved somewhere. I'll post it later tonight [19:19:35] ok [19:19:48] finally merging some of your PRs [19:19:56] wooo [19:20:06] done [19:21:47] now you only have 4 PRs... [19:22:23] I would hold off on merging the nitrogen system update, only because it will need to be updated after the specific heat update [19:22:58] oh yeah, I would say your specific heat one is next [19:27:17] indy91, was the scrubbed PDI logic already supposed to work in MCC tracking (recycle to next attempt) [19:27:25] ? [19:27:35] or was that not implemented yet [19:29:04] oh [19:29:21] I guess despite the message that isn't actually supported yet [19:29:30] in the MCC there is no logic like for TLI [19:29:41] right [19:29:58] I think it works for ascent as well [19:30:02] lunar ascent* [19:30:11] it would need to go back all the way to the PDI PAD [19:30:30] there is a PDI2 PAD section in the code [19:30:32] and there is probably some things I need to do for the abort PADs so they work for PDI-2 [19:30:46] right [19:31:06] ah yeah, I had added a MCC state for PDI PAD 2 [19:31:10] yeah the abort constants would change I think [19:31:44] but it doesn't go to the MCC state for it yet [19:32:07] ok yeah thats what I figured [19:32:10] and it then goes to the following PAD [19:32:40] so there is probably still some things to do for proper support [19:32:45] but not a terrible amount [19:33:07] yah, Apollo 11 seems much better for late launches then 8 [19:33:14] abort pad-wise [19:34:00] on a very late launch TLI-2, the only one that failed in my tests was TEI-31 [19:34:15] yeah, I didn't have that in mind yet when I did the Apollo 8 MCC [19:34:42] one thing I was thinking, could we have the MCC survive through a failed iteration? [19:35:03] or rather, not lock the thread [19:35:28] that would require proper error checking in all RTCC processors [19:35:33] which we should have, but we don't haha [19:35:48] right [20:31:59] night! [21:03:43] hi Thymo [21:03:58] I have some CMakefiles to compile it on linux but it's untested on windows [21:04:33] plus there are some issues with XRSound and it ends up recompiling a lot of stuff even if nothing changed [21:05:38] you can check it here: https://github.com/TheGondos/NASSP/blob/linux/CMakeLists.txt [13:56:33] hey [13:57:11] hey Niklas [13:57:49] n7275, now that your ground station PR is merged I will try to fix the telemetry scaling [13:58:07] it should be somewhat simple. In one place in the CSM, one place in the LM and in both telemetry clients [14:00:40] and I think I had worked out exactly which values we need, let me scroll up in the chatlog :D [14:03:51] hey guys. I do recall discussing that. definitely in the logs somewhere [14:13:13] we have [14:13:14] double step = ( ( high - low ) / 256.0); [14:13:20] return static_cast( ( ( data - low ) / step ) + 0.5 ); [14:13:26] I think changing it to [14:13:31] double step = ( ( high - low ) / 253.0); [14:13:35] return static_cast( ( ( data - low ) / step ) + 1.5 ); [14:13:38] does the trick [14:14:50] 1 byte of data [14:14:53] 0 is offscale low [14:14:56] 1 is 0% [14:14:58] 2 is 0.4% [14:16:16] with the logic above we would get a 1 for just above 0% to 0.2% [14:16:24] and 2 for 0.2% to 0.6% [14:16:30] I hope that is the correct rounding... [14:20:44] how does IBM 360 single precision float work again... [14:24:10] I am not too worried about the unscaling [14:24:21] with 1 bytes you are just going to loose information [14:26:23] right [14:27:04] the unscaling should be exact, no rounding on that side [14:47:27] oh yeah [14:47:50] ok done, that little branch can be looked at for a while if my brain did that right, I'm still a little bit confused haha [15:02:20] I spent a solid 3 hours last night failing pretty hard at some very simple vector math [15:04:20] I know some vector math :) [15:04:55] I might run away if it is left-handed vector math though [15:08:28] almost as bad. converting Vector3 to VECTOR3 operators and not getting expected results, even though it obviously should... [15:09:41] oh fun [15:37:16] the code may give bad results, but at least I'm moving in a direction of making it less obfuscated [15:40:15] coding with MFC in Visual Studio in C++ is the worse experience possible [15:40:30] no way this would be feasible for a full mission generator [15:40:39] would need to be C# [15:40:50] every little thing I want to do involves 100 steps [15:41:19] just want to load some mission defaults into the text boxes for my padload generator... [16:01:07] UIs are a pain [16:06:39] I'm just hiding the bad conversions in sub-functions [16:06:49] CString and string and char array... [16:07:01] but first I have to figure them out [16:37:06] morning! [16:37:26] hey Mike [16:37:42] what's up? [16:38:23] todays goal, finish the padload generator far enough so that it gives me an Apollo 12 padload that is identical to the flown one (minus things that we want to be different) [16:40:11] I need to generate one for a rope we have though, haven't tested my modifications to the ephemerides generation [16:40:19] need to check if it can still point at the Sun [16:41:17] oh nice :D [16:43:18] I believe we could use the flown CMC sun and lunar ephemerides actually [16:43:32] bodies in Orbiter move pretty realistically [16:43:36] but there is a timing issue [16:43:45] due to leap seconds or something [16:44:02] we would probably have to modify the time tag (TIMEM0) of the ephemerides [16:44:17] I need to do a comparison some time [16:44:33] take the octals from the padload, convert them and then see if it agrees with Orbiter [16:50:02] you know, I almost want Comanche 67 more because we are going to have a fun reconstruction project than just to use it in NASSP. That is hopefully a drag-and-drop process that is going to be very quick. But reconstructing, that is fun and challenging :D [16:51:57] of course I'm talking about myself. For you getting C67 is a bit more involved haha [16:53:54] hahahaha [16:53:58] no I definitely feel that [16:54:06] I am very excited to try to reconstruct Comanche 72 [16:56:20] I have a copy of Comanche 55 locally that I've artificially turned into a rope that looks like Comanche 67 from a bugger word point of view -- by changing random octal constants or adding new ones to make the banksums match [16:56:44] not trying that one in NASSP [16:57:32] and then have been trying various Comanche 72 reconstruction ideas on that to see what happens. it's imperfect because of the way the summing equation works, but for several of them making the expected changes has resulted in correct (or very close) Comanche 72 buggers [16:58:00] oh that's very interesting [16:58:39] reconstructing before we have the basis for the reconstruction [16:58:42] really next level [17:07:06] hahaha [17:07:13] more impatience and less next level :P [17:07:40] a bit like creating a padload for a rope we don't have? [17:08:45] or making changes to our LVDC to Saturn interface to make integrating a LVDC emulator easier [17:11:01] hehehe [17:52:37] I need to talk to Debbie [17:52:44] I was looking over the MIT Museum collection index again [17:53:21] * Anomaly reports COLOSSUS 2C 2D and 2E, July 1969 to March 1970. [17:53:23] * Assembly control board requests, COLOSSUS 2D and 2E. [17:53:44] I think I may have skipped over those due to limited time and them not being useful for the Comanche 67 reconstruction attempt [17:54:54] but now they are going to be very useful :D [17:58:19] oh those are surely useful [17:58:50] when you asked me what I wanted from Don to scan then in like 90% of the cases I had to think "will this be ever useful" and not "can I use this right now" haha [17:59:02] hah yeah [17:59:15] I'm kind of surprised I don't appear to have pictures of those [17:59:26] so that's the only reason I can think of [18:00:33] I'll probably wait to bother her until we actually need them -- the MIT Museum just finished their relocation and they're having an opening celebration at the new place on September 30 [18:00:40] so I'm sure she's swamped with that [18:06:00] oh yeah, that sounds busy [18:07:21] party on the 30th, hangover on the 1st, asking her on Sunday the 2nd is optimal :D [18:07:28] hehehe [19:32:38] UHCL finally got back to me [19:32:46] they definitely don't have it [19:33:30] however they believe it may have been returned to JSC, and I have the phone number and email of the JSC historian... [19:35:33] oh that's weird [19:36:35] is the historian Mark Scroggins? [19:36:54] it's been many years, but he was very responsive to me in the past when I was still trying to locate PGNCS engineering drawings [19:37:38] Jennifer Ross-Nazzal [19:37:51] is the name UHCL gave me [19:37:54] oh hm [19:38:44] according to their website, Mark is listed as their archivist though [19:38:53] oh great, that means I only have to wait a few more weeks until I get a response [19:39:16] lol [19:40:58] oh boy. I'm copied on a "did you ever answer this one" email from the library director. [19:41:27] hope I didn't cause too much chaos [19:47:05] I hope you did cause chaos [19:49:30] if that's the case, I hope that chaos results in us getting a scan of the document. [19:51:12] well no chaos results in no documents [19:51:16] with chaos there is a chance [19:51:21] that is my reasoning anyway :D [19:52:09] can confirm, my life has been chaos the last few years but it's resulted in a lot of documents :P [20:03:56] indeed [20:04:01] lots of documents [20:05:14] still not enough of course :D [20:05:17] but that's not your fault [20:05:20] there will never be enough [20:05:39] knocks on UHCL and NARA doors [20:12:39] I should be grateful that we got so many things from those sources [20:13:05] like NTRS in 2013, it might suddenly be gone as a resource [20:14:31] luckily unlike NTRS, I don't think the documents themselves are disappearing in either case.... they just might get progressively harder to get to, without going there physically [20:14:52] NARA is responding with scans these days [20:15:02] they're still charging their exorbitant fees, of course, but they are scanning things [20:15:58] I have too many projects going on using documents I got for free... maybe I'll consider it some time again though [20:16:38] there's definitely been a bunch of times were I was staring at the NARA front pages, it's been a bit though haha [20:25:34] I'm always happy to foot the bill if there is something immediately critically useful (and it's not ridiculously expensive lol) [20:30:50] I'm just a cheapskate [20:32:14] although, I have cancelled my credit card a while ago, I only ever needed it for outside of EU online shopping and I haven't done a lot of that. No idea if payment to the US is actually difficult then :D [20:32:19] probably not with Paypal etc [20:33:32] if I can get a document for free in a few years by asking Ron nicely instead of in a few weeks by paying overprized fees I'll always be rather patient and do something else in the mean time [20:35:09] hah that's fair [20:38:49] right now if I wanted a document from NARA it would probably the 1976 Shuttle deorbit targeting memo [20:38:55] several hundred pages I am afraid [20:39:20] that is the one still referenced in the 2007 FIDO Console Handbook [20:39:56] still got shuttle on the brain with the SSV release? :P [20:40:11] sure [20:40:32] not like I have too many projects or so [20:40:37] hehehe [20:41:20] have been working on a few smaller FDO MFD updates, but that's probably all I can do until I would tackle that deorbit targeting properly [20:44:02] in the late 70s they had an extensive project called the Flight Design System. A pilot project to develop Shuttle flight planning capabilities. [20:44:12] So not operational software, but more the stage before that [20:44:22] and it has a lot of good stuff that is like RTCC Requirements [20:44:36] the launch window planning is what I used in both FDO MFD and now also for Skylab in the RTCC [20:44:42] oh nice [20:44:56] and then it has a 330 pages section on the deorbit planning processor [20:45:33] which should essentially be good enough to implement that [20:45:46] But the real RTCC Requirements document would probably still be a bit better [20:46:10] ah, wasn't called RTCC requirements anymore haha [20:46:22] "OFT MCC Level C Requirements for the Deorbit Planning Processor" [20:48:05] but I've had that with some RTCC documents too "this is almost good enough to start work on this... almost" [20:54:25] hehehe [20:54:29] yeah I know that feeling [21:01:21] inspirational tweet of the day: https://twitter.com/NASA_SLS/status/1565444247192576000 [21:04:25] if I print that out and hang it over my bed, I think I can be a 50% more productive member of society [21:05:58] and with that, good night! [12:42:26] hey Alex [12:42:53] hey [13:52:34] indy91, if you need a break from any of your projects, I'm completely stumped by an error in mine and could use a 2nd pair of eyes on it. [13:52:44] sure! [13:53:01] if it involves vector math or C++ weirdness I might even be able to help [13:54:50] oh, so much vector math [14:00:57] I guess my first question is, in the rewrite_radiative branch, do my changes to Radiative() make it more readable w.r.t. what the intent of the function is [14:02:30] but the primary issue is that I need a unit vector to the planet and to the sun, and oapiGlobalToLocal isn't giving me a vector that changes with vessel orientation change [14:05:41] ok, let me look at the vectors first [14:05:53] SunPosition is the global position in global coordinates [14:06:26] oapiGlobalToLocal both makes it a vector pointing from the vessel to the Sun and converts it to body coordinates [14:07:11] hmm [14:07:33] the vessel is the body used with oapiGlobalToLocal [14:07:39] I have to check if that really works [14:09:08] alternatively I could do this with a rotation matrix, but this seemed cleaner. [14:09:46] OBJHANDLE works for both bodies and vessels [14:10:05] but usually with this function you have e.g. Earth as the hObj [14:10:08] and not a vessel [14:11:11] we do that in mcc.cpp [14:11:20] uh oh [14:11:40] well I am checking the Orbiter code itself now [14:11:53] and the first thing it does with OBJHANDLE hObj [14:11:58] if (((Body*)hObj)->s0) { [14:12:08] and I'm not sure the VESSEL class is derived from Body [14:12:57] and I am not seeing that in MCC [14:13:02] oapiGlobalToLocal(Earth, &CMGlobalPos, &CM_Vector); [14:13:08] hObj is the Earth [14:13:23] in your case it is the vessel [14:13:28] and that doesn't work I think [14:13:31] yeah, that's what I meant. it works the other way around [14:13:54] yeah it only works with bodies [14:14:02] I'll just do it with a rotation matrix then [14:14:32] ...and make an issue on the Orbitersim GitHub [14:14:34] yeah, I guess that's why the old code needed to do it that way [14:14:57] the issue is that it allows you to do this haha [14:15:59] confusingly the API documentation says that vessel::GetGlobalPosition returns a vector in the current gravity reference ecliptic frame [14:16:26] which it doesn't, it's in the sun ecliptic frame as far as I can tell [14:16:44] yeah, it's global [14:17:04] the math is essentially the same as it would happen in oapiGlobalToLocal [14:17:17] you get global vectors for vessel and Sun [14:17:25] subtract, apply the rotation matrix [14:17:46] and you have a left handed, body vector pointing from vessel to Sun [14:18:16] I'll just do it that way then. it worked for the antennas so it should work here too. [14:18:56] I suppose it's almost exactly like an Omni antenna haha. different wavelength though [14:19:45] maybe you could use GetRelativePos? [14:20:01] then you got a vector pointing from Sun to Vessel [14:20:09] cuts out one step [14:20:58] and then tmul the rotation matrix [14:21:13] yeah that should work [14:21:45] Thermal_engine::Radiative is called every timestep for every thermal object like tanks? [14:33:46] there is definitely a lot of inefficient things in that function now that need to be improved for performance [14:33:52] like [14:33:53] char planetName[1000]; [14:46:28] indy91, the hard-coded DVMAX for TLI+90/+4hours [14:46:33] in MCC [14:47:06] if I up it to 9000, all the PADs come out k for my late launch test scenario the other day [14:47:11] ok* [14:47:19] yeah [14:47:37] but 7000 is correct for Apollo 8 [14:47:49] so they wouldn't have landed at the AOL [14:47:56] for late launches or 2nd TLI opp [14:48:27] right makes sense [14:48:56] so the logic should then find a different landing area [14:49:02] yeah [14:49:11] well at first it should probably generate a failure [14:49:59] with this type of abort you specifiy an estimated landing time and it needs to find a solution +/-12 hours of that time [14:50:03] within the constraints [14:50:07] and that should fail [14:50:28] but I need to do a lot of restructuring to properly allow this to happen [14:53:24] it's not very well coded, I just copy and pasted the P37 code as much as possible [14:53:45] If I would start this Earth centered RTE logic from scratch I would do it quite differently [14:54:05] in fact I have started it from scratch with the RTCC Requirements documents [14:54:11] but that has some issues [14:54:20] I'm not allowing it near the MCC yet :D [14:54:54] in the mean time, maybe we could do is make DVMAX a value that is read in the RTCC init file [14:55:05] so the 7000 not hard-code but set in the init file [14:55:17] I don't quite understand the char[1000], it only needs to fit the name, not the whole wikipedia page [14:55:23] 1968-12-21 Init [14:56:28] n7275, well the worst thing it, this function gets called many times per timestep and it creates a new char array every time [14:58:43] yeah we can do better [14:59:20] part of my goal in making the code easier to read, was making it easier to know what we can change [15:00:57] the compiler probably does something clever with this function, but it's such a large array that it's definitely causing some cache-ram transfers every call [15:06:36] yeah... although, is it really better to move that to the class definition? Then every instance of a thermal class has this large array. Better for CPU, but worse for memory... [15:07:06] there has to be a better way [15:07:56] well it would have it any way, [15:08:24] it could be char[16] and still work [15:09:13] yeah, no big deal leaving that in the timestep [15:09:58] a much more efficient way would be to search for handles for all the planets in the init function, then the comparison is only an int == [15:11:05] diminishing returns tho [16:11:10] did this update you guys recently did add countdown holds, or does that still need to be done manually? [16:18:14] don't remember the update you mean, but we can't do countdown holds yet. So the procedure is still to edit the mission time in the launch scenario [16:43:20] morning! [16:52:16] oh. I ment the work you and Alex were doing recently. I haven't updated my Orbiter2016 branch recently. [16:57:40] I misunderstood [16:58:20] hey Mike [16:58:39] n7275, yeah you have to edit the MJD in the mission file [16:59:00] scenario file* [16:59:39] I use date.exe [17:08:00] only if you don't want to wait haha [17:08:26] all you actually need to do is change the mission time, but then you potentially are at T-7 hours or so [17:17:37] but I guess moving the MJD forward instead of the mission time backwards works, too [17:24:19] yeah im lazy :D [18:18:32] Good evening! [18:18:48] Time to dig up my scn_check branch [18:22:44] n7275: Do you have something in place to allow people to update their current scenario's to work with your update? [18:27:06] indy91, been working one something...of course it doesn't fix the issue of the RTE not properly error checking...but I thought of a system where the MCC knows the launch azimuth and makes RTE requests accordingly. For now in this test I just simply made it add 24 hours to the earth landing times. [18:27:09] https://github.com/jalexb88/NASSP/commit/5709702ccc32eb4b4692282feec722911e0f7295 [18:29:44] How about we keep track of any breaking changes here? https://nassp.space/index.php/Scenario_File_Updates [18:29:56] And then start maintaining this page again: https://nassp.space/index.php/Scenario_File_Options [18:31:23] AlexB_88, interesting stuff. First, you couldn't know this because it's a bit hidden in the RTCC, but the IU launch azimuth is stored as a system parameter already. [18:31:54] gets saved in the mission init logic during the MED input [18:32:08] oh [18:32:09] in the RTCC class it is [18:32:14] SystemParameters.MCLABN [18:32:28] I was hoping there would be a way to avoid adding stuff to MCC [18:32:40] https://github.com/orbiternassp/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_rtccmfd/RTCCSystemParameters.h#L706 [18:32:48] in radians [18:51:20] changes pushed to my testing branch [18:51:48] or rather, reductions pushed [19:16:15] the only thing I don't like about it is that I also want it to be able to handle other launch days. And this is quite specific to the December 21 launch [19:18:59] true [19:20:05] but this is quite difficult to achieve, maybe with a lot more launch day specific MCC variables [19:25:06] I do think the same code would work with Apollo 11, to make the TEI pads work for late launches. But yeah its the same mission profile, might be different for a non-FR launch window [19:32:11] Thymo https://gist.github.com/n7275/8cab7e348507ff4bce4749d09e2c3894 [19:36:18] I like the idea of using that wiki page [19:55:47] ah according to the Apollo 11 SCOT vol. 3 launch windows summary, Apollo 11 should have the same re-entry time regardless of launch time/TLI opp [19:56:21] TEI-31 is damn near the VRMAX though...and MCC cant handle it [19:56:49] with the default VRMAX that is [20:01:02] probably some conic approximation [20:01:45] that document has the reentry speed of 36209.4 ft/s for 108° launch and 2nd TLI [20:02:35] right [20:03:21] still a bit to go to the limit from there [20:04:37] that document also has -6.5° for all reentries [20:04:48] that's not exactly the target line used [20:04:56] a bit steeper at the higher speeds [20:05:06] and I think that could make a difference for the total speed, too [20:05:12] as targeted with TEI [20:05:53] in reality they might have either relaxed the speed constraint in general or set it high for the calculation, if it's only an issue with conic [20:08:58] Thymo, I was also going to strongly suggest that if people needed their scenarios updated, that I would happily just do it for them. [20:10:03] I don't know how to make this into a smooth experience without having to do a lot of extra work so I guess that's going to be it [20:10:25] You might get flooded with requests [20:14:01] indy91, anyway I think this MCCwork will only live in my testing branch :D as said better RTE handling is the way to go I think [20:14:24] error handling* [20:14:27] yeah, for the TLI+90 definitely [20:14:45] error return and then it looks at the next best target line [20:15:05] which should be further... west [20:15:14] likely MPL [20:15:17] like Apollo 16 [20:15:48] I could just put the allowed DV to 10000 [20:16:00] and then check after the calculation if it was below 7000 [20:16:18] more of a workaround though :D [20:16:56] I do want to make the RTE a bit more stable, I'll work on that some time [20:19:08] Makes sense. For now if I anyone wants to try some late launches/2nd TLI they can try my branch [20:19:19] might put up some numbers for Apollo 11 [20:20:13] its fun messing with MCC code lol [20:21:01] feel free to do it some more. Just be prepared for the constant fear of breaking something [20:23:38] for Apollo 11 I actually attempted to get it to do a DOI calculation at MCC-4/REFSMMAT uplink time [20:23:56] LOI-1+LOI-2+DOI [20:24:19] to get the proper TLAND in before the LS RESMMAT calculation [20:24:28] but failed miserably :D [20:24:41] Ill try again sometime [20:24:55] yeah that isn't so easy if you aren't 100% familiar with all the functions involved [20:26:15] btw are the LOI/LDPP processors operable by only MED entries yet? [20:26:51] as I think they would have been in reality? [20:26:54] no, I don't think any of the big maneuver calculators are [20:27:07] available as MED for us I mean [20:27:13] right [20:27:44] https://i.imgur.com/uC8Ojan.png [20:27:51] the two MEDs for the LDPP [20:28:35] nice [20:29:03] I don't know if there was a person who had to always type these things into a console every time [20:29:12] the FIDO often talks about "making a tape" [20:29:24] I think once we have full MED access to the processors, the mission specific RTCC sequencing could be much easier [20:29:26] and then he gives all the inputs like on a MED [20:29:48] but leaves one thing out, like the threshold time for the lunar launch window processor [20:30:17] so they probably had a way to load that "tape" and then the person in the RTCC only had to manually type the threshold time for the specific rev? [20:30:45] I don't know more about these tapes, I only know you could do it with punch cards though [20:54:34] a lot of punched card operations could do replace operations [20:57:21] the EDIT utility is also very similar to the unix "ed" program [20:58:19] I wonder if they were entering a line replace command into a dataset of pre-written MEDs [21:00:53] you could listen to a few 100 hours of the RTCC supervisor audio to maybe find out haha [21:01:26] "datasets" are the OS/360 nomenclature for files. they consist of "records" which are basically lines or virtual punch cards [21:02:01] yeah, that does sort of sound like pre-made MEDs [21:02:06] I've made it through about 20 hours of computer supervisor loop audio for Apollo 11 [21:02:44] so that's about 20 times the FIDO is annoyed that he gets asked for checkpoints [21:03:26] also, the inputs to OS are symbolic, so even if SYSIN1 is normally the card reader, it can be reassigned by a JCL statement [21:03:31] yes haha [21:03:46] the only thing the FIDO was more annoyed about was Goddard Maneuvers [21:03:57] at Goddard was the emergency MCC [21:03:59] note to self: if you are too damn lazy to do prelaunch checklists when testing...at the very least turn on the EDS :D [21:04:31] and whenever they were coming up to a maneuver, so a busy time for the FIDO, Goddard needed a bunch of information from him about the burn to simulate it, too [21:04:54] AlexB_88, did your countdown got halted [21:05:01] yep [21:06:06] I love our automatic prelaunch. "I'll be back in 20 minutes" [21:07:21] I made a LCC and a LCC MFD, but it's sort of optional right now [21:07:36] that MFD could at least tell you that the countdown is halted [21:07:46] doesn't right now though [21:08:03] all I ever taught it was some I/O [21:08:16] mostly for automated checkout programs [21:09:58] good night! [21:10:05] night [21:11:58] Thymo, I expect I'll get a bunch of requests. I'll probably make a thread for it. When we merge the update I'll let people know on the forum, Reddit, discord, Facebook, Twitter etc. [21:12:57] this'll teach me not to mess with the scenerios in the future haha [10:33:03] good morning [10:34:11] hello hello [10:42:09] i figured out my vector problem [10:42:49] specifically, why trying it several other ways didn't work [10:43:16] wrong vessel... [10:44:12] how does that work? :D [10:46:43] I had accidentally set the debug flag to true for *all* systems, so the debug string that was printing was not for the system...or even the vessel, that I thought it was [10:48:22] oh, in the debug string only [10:50:44] there were several other issues. but I tried about 10 different permutations of the orientation code that we looked at yesterday, and most of them were probably good [10:55:43] but it worked out in the end, and I got a funny little lesson in making sure that what I'm looking at is what I think it is. [11:36:42] my thermal radiation polars appear to work as advertised [12:33:50] ah, very nice [12:43:55] power interruption [12:44:03] we don't get those more than once a year [12:44:11] this and last year, a lot more often [12:44:19] society is really falling apart :D [12:54:57] oh oh [12:55:45] we get a fair number of those here in Maine [12:56:31] not so much where I am, but my brother, who lives about 30 miles north looses the power like once a week [12:56:47] too many trees... [12:56:48] hey [12:57:32] hey Alex [12:57:45] I think Germany has the most reliable power grid in the world in terms of average outage minutes per year. But it's not heading in the right direction it seems [12:57:48] hey [16:36:20] morning! [16:36:33] im thinking the best way to set the directionality of these polars is just with an optional 4th parameter in the position vector [16:36:36] hey Mike [16:43:04] I've distracted myself so much with this project, that it is highly likely that you will have Comanche 67 by the time I'm ready to resume flying 12 [16:46:57] hehehehe [16:47:05] we'll see! [16:47:19] board assembly tracker is still at 10% [16:51:38] going to be doing some FPGA and sense amplifier chip testing today... [16:59:12] there seems to be some supplychain issues with some components, I've noticed [17:00:12] yeah, that has definitely impacted the component selection for the rope reader [17:00:51] the only part I used that ended up being totally out of stock when the assembly house started ordering things was the LTC4231-1 [17:01:24] but, luckily I'm a hoarder and bought a bunch of every part needed for the rope reader when I noticed they were in stock... so I'm just having them DNP those and will add them myself [17:03:35] and these sense amplifier chips have been out of production for 40+ years but there were enough on ebay :) [17:28:26] eBay has everything...well mostly [14:09:53] morning [14:55:49] good afternoon [15:00:29] hey Niklas [15:02:06] question about SSV, does it have the implemented radar for rendezvous ops? (Ku-band) [15:02:27] radar implemented* [15:03:46] not really [15:03:51] it can track and all [15:03:58] even search for the target [15:04:08] but not state vector updating or anything [15:04:18] useful for range and range rate display though [15:04:24] and something like the cross pointer [15:04:26] for docking [15:05:10] hmm, they use it to keep on a specific approach path I think...R-bar or something [15:05:20] Im really not up to speed on shuttle ops :D [15:07:29] I wouldn't say it's quite like keeping the target centered like with the LM and CSM [15:07:49] early Shuttle missions did the brute force approach like Apollo I believe [15:08:22] but you use it for approach speed etc [15:08:35] when the manual phase begins, after MC4 usually [15:08:50] up to MC4 can be done by the FDO MFD? [15:09:26] up to MC4 can be done with the onboard software [15:09:35] it could be done with the MFD I guess [15:10:00] usually on the day of rendezvous you have a ground targeted NH maneuver, height maneuver [15:10:16] then a phasing maneuver at 40 NM behind the target, called NC [15:10:20] also ground targeted [15:10:33] hmm, the SSV can do the onboard solution already I guess [15:10:39] yeah [15:10:49] it's not so great yet with non-spherical gravity [15:10:51] but just no SV updating by the Ku [15:11:00] yeah the state vector is always perfect [15:11:06] oh ok [15:11:19] so it directly grabs it from orbiter [15:11:22] yep [15:11:47] on a cycle of 4 seconds the Shuttle computer integrates the onboard state vector, using drag and attitude and everything [15:11:53] a bit like the LVDC or Block I AGC [15:12:08] but instead of that SSU/SSV get it from the Orbiter API [15:13:50] Ill have to give it a try [15:14:28] ascent is annoying because the guidance can't do any yaw steering [15:15:01] one thing that turned me off from SSU is it seems that you had to use default Orbiter MFDs for certain burns [15:15:05] so using the historically correct launch time with a historically correct e.g. ISS state vector doesn't give great results [15:15:29] but now with FDO MFD that makes it feel more like NASSP, just using one dedicated MFD for maneuver targeting [15:15:41] yeah, it can definitely do that [15:16:11] might need a hefty plane change burn, depends on the scenario [15:16:38] I can't 100% recommend using non-spherical gravity. More because of SSV than the MFD [15:16:49] although the MFD does have some small issues with that still [15:16:54] if you launch at the corrected time that should take care of it? (plane change) [15:16:57] I have an update in the pipeline [15:17:46] with non-spherical gravity disabled and using the launch time calculated by the MFD you will get a good insertion [15:18:03] I'm porting over some stuff I had figured out for the Skylab launch targeting [15:18:28] right now in the FDO MFD you need to do some trial and error to get the orbital plane right [15:18:56] with non-spherical gravity [15:19:08] ah ok [15:22:08] do you have a mission in mind to start with? [15:22:29] probably STS-1 type [15:22:34] just to get the hang of things [15:25:35] not much to do with the FDO MFD there :D [15:25:44] but it has two ground targeted maneuvers [15:25:48] just short OMS tests [15:29:26] can be targeted with the MFD [15:29:30] so can OMS-2 I guess [15:30:54] hey guys [15:31:15] hey Matt [15:37:38] morning! [15:38:08] and hello Mike [15:54:20] hey guys [15:56:08] alright finally got my SSV up and running [15:56:40] trying the "Launch test" scenario [15:57:06] could use some of ggalfi's shaking effects :D [15:57:27] gotten so used to it now, kind of weird without them [16:16:28] https://www.dropbox.com/s/bwd25ca76lzpgy5/Screenshot%202022-09-04%2012.15.15.png?dl=0 [16:18:33] that was quick [16:19:44] the EDW 22 TAEM scenario [16:20:29] from an onboard computer perspective the entry guidance is really the most impressive and complete piece [16:21:42] when I tested my deorbit opportunities feature I had a bug [16:22:06] instead of nominally about 4000-4500 NM range from EI to landing I had more than 7000 [16:22:21] but it still got there [16:22:34] by doing things like using 37° AOA instead of 40 [16:24:01] oh man the mission editor is amazing [16:24:25] indeed [16:24:38] if doing rendezvous, can you use the LWP and then set the values in the mission editor? [16:25:46] I haven't tried that. What I did instead was go to the LCC in-sim and hold the countdown [16:26:17] does the LWP output an inclination? [16:26:33] yep, it shows it [16:26:55] and the calculated launch time was tweaked to work best with the current, lacking ascent guidance [16:27:02] to give the smallest plane error [16:27:11] ah so you could just load a scenario, find a valid window then exit and plug it into the ME [16:27:34] I guess [16:28:14] the default STS-126 for example has a launch time that is a few minutes too early, at least with the ISS state vector [16:28:59] my MFD comes with a modified scenario to solve that, but you could just halt the countdown or edit the scenarion (with or without mission editor) [15:26:25] good morning [15:53:47] hey [16:00:44] good afternoon [16:10:39] hey Alex [16:12:18] morning! [16:17:00] hey Mike, how is the board assembly going [16:17:57] still at 10% on "Production files preparation" [16:18:36] they sent me a clarification email last night about the orientation of the transformers so I think they're almost done with that [16:20:16] and about your Comanche 67 to 72 work, I am not useful anymore! When we had very little information about e.g. bug fixes I could help by interpreting the title of PCRs correctly [16:20:24] but now you have all you need without me :D [16:20:51] hahaha [16:21:31] well we still might need you to help think of implementations, like with Comanche 45 [16:26:07] so implementations that are creative, but very much a hack [16:26:18] hehehehe exactly [16:26:37] I am a little worried about banks 41 and 43 -- they both have multiple unknowns in them, which will make things tricky [16:27:00] a module B6 dump would have been WAY more useful than a module B2 dump [16:30:11] but I still have some hope that perhaps the anomaly reports and ACBs that Debbie apparently has will be useful [16:33:57] unknowns in what way [16:34:12] changes to something that you can't pinpoint to a PCR or anomaly fix [16:35:50] I hope there's none of that [16:36:32] like COM 26 -- Extended verb 92 flag 6 is changed while job is not in INHINT [16:36:53] was the fix to add an INHINT? if so where? [16:37:08] our Colossus 2D flowcharts only have the 2C version of that page [16:37:13] and V92 was completely deleted for 2E [16:43:13] my Google Chrome now autocomplex Artemis to the Artemis 1 wikipedia article instead of the Artemis source code [16:43:15] Not useful! [16:43:20] autocompletes* [16:43:54] hehehe [16:44:04] Artemis also deleted V92 [16:44:27] I'm fairly certain that the relevant piece of code is EXDAPOFF in EXTENDED VERBS [16:44:51] which is indeed executed under INHINT when it gets used in Artemis [16:46:30] I'm surprised they deleted V92 [16:47:24] apparently chunks of system tests became EMPs [16:47:31] so they could delete V92 to save space [16:48:55] and maybe they could use Sundial [16:53:42] COM 27 is a fun anomaly [16:53:55] I get the feeling that whoever found that was confused what kind of sim they were doing [16:54:22] "Ah I am running a P3X program, so naturally I should do a V32E a few times" [16:54:34] hahaha [16:55:11] I really hope that one is the same as Artemis [16:55:46] it doesn't look like they refactored that section of code much or at all for Artemis [16:57:05] was a busy time for them to keep track of the CMC versions [16:57:12] Comanche, Artemis, Skylark [16:57:45] or maybe when the final Comanche version was done they were just starting with Skylark?! [16:59:52] the Colossus memo before the one for Comanche 90-96 was one from Margaret titled "AAP Assembly" [17:04:31] so definitely 3 separate developments at the same time, even if Skylark was maybe not very far yet [17:09:50] hmmm [17:09:53] yeah [17:10:11] it looks like the first Skylark PCRs weren't formally approved until Artemis was up into the 60s [17:10:32] so I think maybe they were planning but not actively making Skylark revisions [17:10:38] right [17:11:28] but yeah lots of stuff in CMC land [17:11:32] there was also R40ARTMS [17:12:04] which was the Artemis they built to be identical to and possibly replace Comanche 108 [17:13:58] haha [17:14:05] we made something like that ourselves :D [17:14:17] hehehe [13:52:01] hello [13:54:04] hey [14:43:07] hey [14:51:59] hey Matt [15:03:56] I resumed work on my gravity model integration into Orbiter yesterday [15:06:07] ah fun [15:08:06] was there much left to do? [15:15:18] ah, another FDO MFD update [15:15:30] this is distracting me from Apollo :D [15:16:48] sorry :D [15:16:59] it's just things working better than before [15:17:06] nice [15:17:07] not much in terms of new features [15:17:13] there won't be any [15:17:47] I think you said there was an issue with deorbit times, was that fixed too? [15:18:20] hmm, the only issue was that it also showed some deorbit opportunities before the input time [15:18:34] I want to fly STS-1 today or tomorrow [15:18:50] I added a file for that [15:18:54] it's quite simple really [15:19:05] or at least the same profile, simple just go into orbit, then come back [15:19:06] OMS-2 was used to circularize at 130 NM [15:19:16] OMS-3 raises it to 150 [15:19:21] OMS-4 circularizes at 150 [15:19:34] I place OMS-3 at 81°W longitude [15:19:44] gives about the right TIG [15:21:37] there were some sort of RCS test, but other than that, no major trajectory changes until deorbit [15:22:30] right [15:22:48] not as ambitious as Apollo 7 :D [15:23:09] the ambitious part was flying that thing with humans [15:23:34] OMS-1 to 4 are all done with FDO MFD? [15:24:38] I see in the ME OMS-1 and 2 have a calculation tool in the MECO (Legacy) tab [15:25:23] OMS-1 and 2 can be done onboard with PEG-4 [15:25:56] the numbers are in the ascent checklist [15:26:04] ah [15:26:12] I downloaded the STS-134 ones [15:26:22] well, I did OMS-2 with the FDO MFD and PEG 7 [15:26:32] but OMS-1 is at a fixed TIG from MECO [15:27:18] TIG = MECO + 2, C1 = 0, C2 = 0, HT = 130 NM, THETAT = 160° [15:27:32] normally these values would have been I-load (= padloaded) [15:27:37] but they don't have that implemented [15:27:41] which is quite annoying [15:28:00] that was probably one of the things where they were waiting for the onboard computer simulation upgrade [15:28:02] but that never came [15:28:15] so you basically have no choice but to use 0.1x time acceleration [15:28:23] can't do all those inputs for OMS-1 otherwise [15:32:26] seems like such a basic thing [15:33:06] but that was the old SSU philosophy it seems. Better to not have a useful feature for a decade than to implement an intermediate, not perfect solution [15:35:45] thats how I remember it lo [15:35:48] lol* [15:35:54] on the other hand, NASSP has so many mediocre solutions piled on top of each other that it's sometimes difficult to change anything :D [15:36:07] its what turned me off of SSU [15:36:27] but SSV is impressing me [15:37:00] it helps that it's a one man project haha [15:37:16] simplifies the decision making process [15:37:46] I think NASSP used to suffer the same issue really [15:37:59] up until 2014 [15:38:51] too many people with different ideas of things and no clear direction [15:39:27] there were also the problem with the Apollo 7 ground-calculated maneuvers [15:39:47] and that one problem stopped everything because clearly, Apollo 7 needs to be fully supported first before anything else can be done :D [15:40:58] haha I remember that [15:41:12] I was flying Apollo 8 back then, I felt like a rebel :D [15:47:08] how dare you [15:50:37] ah found my favourite sentence of the day [15:50:49] from a document about the Shuttle rendezvous onboard targeting [15:51:21] "An infinite software loop is possible when targeting Lambert MNVR's with a 180° transfer angle, but another coding error accidentally prevents the software from getting into the loop" [15:52:56] so 2 coding errors cancelling each other out :D [16:48:05] haha [16:52:14] does PEG-4 work in SSV? [16:52:46] yes [16:52:59] used for OMS-2 and deorbit burns [16:53:14] works good enough, having looked at the code if I couldn't call it perfect haha [16:53:19] -if [16:53:30] and OMS-1 [17:00:30] so it PEG 4 I would just put in HT 130 [17:03:06] yes [17:03:34] C1 and C2 zero so that you have zero altitude rate at that 130 NM point [17:03:48] and 160° is an angle measured from the launch site [17:03:52] the THETA [17:04:03] oh where does the 160 go [17:04:29] Item 17 [17:05:02] ah! [17:05:35] so my CUR orbit 70x30 [17:05:47] TGT 135x53 [17:06:06] re gravity model: the only thing I have left to do is the brain-melting coordinate system stuff [17:06:29] oh and btw I guess for the OMS-1 TIG you have to write down your insertion TIG [17:06:37] MECO* [17:06:40] just look at the event timer [17:06:44] it counts up from MECO [17:06:48] oh [17:07:12] n7275, my brain has already melted from it years ago, so coordinate systems can't hurt me anymore [17:10:03] this will probably give me immunity by the time I'm done [17:11:43] performance-wise a 120th order model seems runnable [17:11:56] (7200 coefficients) [17:14:18] haha nice [17:20:44] time complexity is quadratic with respect to order, and linear with respect to number of vessels. [17:23:24] this is a model with both degree and order right? Or that that be separately chosen [17:23:34] Or can't* [17:24:46] hmm burn attitude seems wrong [17:24:54] yaw of 45 [17:25:07] how did you do that :D [17:25:34] what is the DV that got calculated? [17:25:37] vector [17:26:22] +159.6, +0, -112.9 [17:26:31] seems ok [17:26:47] DAP in Auto? [17:26:59] and you did Item 22, 23, 27 [17:27:09] yeah [17:27:20] my orbit PFD orientation is weird [17:27:33] R077 P129 Y014 [17:27:52] and the A/E PFD show 180,0,0 [17:28:40] can you show me a screenshot of your OMS 1 MNVR EXEC display [17:29:50] be prepared for the Orbit PFD not to make much sense in general [17:30:06] it always shows LVLH, but only works right near 0° and 180° really [17:30:35] and maybe your DAP isn't set up right [17:30:38] https://www.dropbox.com/s/l8fs98onu64j5r3/Screenshot%202022-09-06%2013.30.10.png?dl=0 [17:31:08] btw I am in 104 [17:31:15] or should it be 105? [17:31:27] thought that would be just for OMS-2 [17:31:34] 104 for OMS-1 [17:31:37] right [17:32:20] DAP in Auto, three Rotation buttons in Disc Rate? [17:33:06] are you sure you did Item 23 [17:33:14] I see no countdown [17:33:35] maybe you need to clear your illegal entry or something [17:33:42] yeah [17:34:01] that came up when I tried doing item 5 +180 [17:34:18] something is screwy with my orbit ball [17:34:34] it doesnt rotate at all when I maneuver [17:34:42] its frozen [17:34:56] weird [17:35:06] I have done an STS-1 launch just a few days ago [17:35:11] although that was with SSV 1.0 [17:35:24] kind of doubt it, but maybe 1.1 broke something [17:35:28] this is a quicksave right after MECO [17:35:29] if you use 1.1 [17:35:43] maybe it has a saving/loading issue before OMS-1? [17:35:47] maybe save/reloading broke something [17:36:02] not like NASSP would ever have something like that... [17:43:33] I am trying the Atlantis in orbit testing scenario, the orbit PFD looks good there [17:44:53] oh actually [17:45:07] the Orbit PFD might not work yet during the OMS-1 burn [17:45:30] or during OPS 1 at all [17:45:46] that is normal behavior I think [17:55:08] ok good burn [17:55:19] although I did it in 105 [17:55:29] only way to get it to go to burn attitude [17:55:41] in 104 the DAP wouldnt do anything [17:58:32] hmm just did it again and now the DAP is working in 104 [18:01:22] so its just the "BURN ATT" RPY that is confusing me, its not what the DAP maneuvered me to on the A/E PFD which is 180,026,000 [18:03:26] BURN ATT is inertial I think [18:03:32] PFD shows LVLH or something [18:03:37] and only that [18:03:54] the switch to choose REF or inertial doesn't do anything yet [18:06:17] right [18:06:21] ok so for OMS-2 [18:06:42] circ burn [18:18:21] ah there is a walkthrough for it in the manual [18:22:36] indy91, to add a maneuver in the FDO MFD I am doing MCT-> ADD-> HA [18:22:59] is that correct? Its giving me a chime [18:23:48] type of maneuver and name [18:23:50] so like [18:23:51] HA OMS-2 [18:24:36] oh [18:24:49] well I guess that should be CIRC for OMS-2 [18:25:14] well the onboard solution with PEG 4 would be like a HA [18:25:25] if your apogee is perfect at 130 NM then it would be the same thing [18:31:39] so I used T as a threshold, with a TIG before the burn [18:32:19] do I need to specify something for "secondaries" or is that optional? [18:42:04] you want OMS-2 at apogee I gues [18:42:24] that would be SEC button and "1 APO 1" [18:43:52] otherwise it would do the burn at the time you specified as the threshold [18:44:17] right [18:44:19] whoops. stepped away again. yes both C(m,n) and S(m,n) [18:45:14] nothing happens when I click CLC [18:46:17] Ive got: 1 CIRC OMS-2 T 000:00:35:00.000 APO=1.0 [18:46:52] when I hit CLC it should show up on the MET? [18:46:58] yes [18:47:03] have you initialized the MFD [18:47:08] config page [18:47:14] it doesn't do anything automatic there [18:47:15] I put in the launch time [18:47:24] and chaser and target [18:47:27] and both cahser/target Columbia [18:47:33] chaser* [18:47:42] and you also have a launch day there [18:48:05] ohh [18:48:17] that's the most important thing on that page :D [18:48:26] when I hit DLO and put it to 0 it auto-populates the launch date [18:48:53] there we go! [18:49:00] oh 0 works too [18:49:04] I just leave it blank [18:50:05] 137 ft/s at 44:24:00 [18:50:15] looks good [18:50:32] the only thing I see is a -nan(ind) in the DH [18:50:40] on the MET [18:51:56] ah yeah, I have seen that bug [18:52:08] it's trying to calculate relative data between chaser and target [18:52:12] but those are the same thing [18:52:28] something probably doesn't like that it's identical [19:01:18] damn it [19:02:04] got everything input TIG and PEG 7 data but item 22 and 23 doesnt do anything [19:04:29] ah! [19:04:44] I forgot to clear out my PEG 4 targets from OMS-1 [19:06:08] for the deorbit burn, is that best done with PEG 4 or 7? [19:08:48] PEG 4 because there is no way to calculate it yet otherwise [19:09:18] PEG 7 is External DV [19:09:25] right [19:09:37] deorbit opportunities display only gives you a TIG [19:10:01] in my post on the forum I gave a bunch of sets of PEG 4 targets for deorbit [19:11:36] does the deorbit need to be from a specific orbit height/eccentricity? [19:12:45] TIG from deorbit opportunities probably won't be super accurate with high eccentricity [19:12:53] but height isn't much of a problem [19:13:21] the theta in PEG 4 will force the Shuttle to travel that angle from deorbit to EI [19:13:26] so the burn is calculated that way [19:21:14] ok [19:24:57] so I have a deorbit opportunity for KSC on the 4th orbit [19:25:18] LIGHT 5:00BR XRNG 1AL [19:25:46] 5 hours before sunrise [19:25:53] crossrange 1(!) nautical mile [19:26:03] hmm [19:26:08] A for ascending node [19:26:09] rather a daylight landing [19:26:16] I'd rather* [19:26:23] this is STS-1? [19:26:55] yeah [19:27:06] well Im skipping OMS-3 & 4 [19:27:17] just want to practice re-entry now [19:27:40] AS = after sunrise? [19:27:46] yes [19:27:48] AL* [19:27:51] uh [19:27:57] 1AL, 1 nautical mile crossrange [19:28:03] A for ascending node [19:28:08] L for left of groundtrack [19:28:16] right [19:28:21] so you are coming from the south going north [19:28:42] there are too sets of PEG 4 targets, for low and high inc [19:28:45] two* [19:28:56] they aren't too different from each other [19:29:25] STS-1 has 40° inclination [19:29:29] which is like... middle [19:31:04] can it handle up to 800 NM crossrange? seems like a lot [19:32:31] it can [19:32:43] STS-1 limit was 690 NM it seems [19:33:10] https://balettie.com/wp-content/uploads/2015/03/dops.gif [19:33:34] this one was run with even more than 800 [19:34:07] nominal range from EI to landing is something like 4400 NM, which is a bit more than Apollo, too :D [19:34:20] right [19:34:59] so AS is after sunrise, whats AR? [19:35:36] oh sorry [19:35:39] r = rise [19:35:42] s = set [19:35:45] oh ok [19:36:03] The light condition at landing is written in a coded format where a stands for after, b [19:36:04] for before, r for sunrise, s for sunset. So e.g. 3:02ar would mean the landing time is 3 [19:36:04] hours and 2 minutes after sunrise. For the crossrange, A stands for ascending node, D [19:36:05] for descending node. L for landing site left of groundtrack, R for right of ground. [19:36:12] So e.g. 102DR means at closest approach the landing site is 102 NM to the right of the [19:36:12] groundtrack, during the descending pass. [19:36:16] to quote my manual ;) [19:43:07] so TIG MET 103/00:26 [19:43:24] tahts 103rd day of the year [19:44:35] can I enter it exactly like that in item 10? [19:45:56] check you config page again [19:45:58] your* [19:46:00] launch day [19:46:09] ugh [19:46:45] nevermind I found the reason [19:47:28] I thought you had to start from the launch day for the start/end times of the deorbit calculation [19:47:41] so I was doing like 102:0:0:0 to 103:0:0:0 :D [19:47:44] ooh [19:47:51] nah, it's MET [19:48:14] or GET as I wrote on the display [19:48:21] probably should change that to MET [19:48:27] not sure they really used the term GET [19:49:29] somehow you got a case where 103 days from now your groundtrack passed exactly above KSC, impressive [19:50:06] I think only on the config page will you have to deal with the day of launch [19:50:17] everywhere else it should be days/hours since launch [19:50:22] and with that found a nice once at 8:37 MET [19:50:42] KSC 4:41 BS 378DL [19:50:49] so daylight [19:53:13] in the summary schedule in the flight plan it also has deorbit opportunties, landing times only [19:53:35] 5:37h MET landing at KSC [19:56:43] that would be the opportunity you are using, the calculated landing time on the display might not be very accurate [20:00:18] gotta go, cya! [12:03:58] hey [12:31:47] hey Alex [12:33:49] are the moon gravitational features a mod to Open Orbiter, or can it be applied to Orbiter Beta as well? [12:38:28] OpenOrbiter only. [12:39:02] it's pretty tightly integrated into the celbody class [12:45:32] but....when OpenOrbiter releases, we shouldn't have to do anything to make our accelerometers work with this this, since it's just a perturbation like the J coefficients already do [14:03:41] hey guys [14:05:06] hey Niklas [14:05:34] I'm a bit confused by the graph you posted on the forum with the gravity model [14:05:41] that orbit is loosing energy [14:05:58] I thought it would just change its shape, eventually becoming eccentric enough to crash [14:06:07] hey [14:06:34] did your STS-1 have a good emergency, early landing? [14:06:45] I'm not convinced it's right yet [14:08:36] https://www.dropbox.com/s/e5e7cd1vz38k29s/Screenshot%202022-09-06%2018.39.39.png?dl=0 [14:09:13] flying over SFO at 350000 feet :D [14:09:32] good landing at KSC [14:09:44] any idea what the range at EI was [14:09:57] hmm good question [14:11:24] can't be too bad if you reenter on the west coast [14:11:48] at 400000 feet: 7.622M on the map MFD [14:12:55] which is 4100 NM [14:13:01] pretty good I would say [14:14:16] used the generic PEG 4 targets [14:14:45] the trajectory plot was pretty centred the whole time [14:15:14] the most challenging was figuring out how to gonfigure the major modes [14:15:22] configure* [14:15:37] there is no real tutorial for re-entry [14:15:51] or checklist other then the flight data files [14:16:06] which I tried to use but the format needs some getting used to [14:16:18] the flight data files are the checklists [14:16:31] I have some for STS-1 [14:17:00] can't be 100% used with SSV though [14:17:16] that Shuttle is basically the last version of everything and not the first [14:17:59] the main thing to get used to is figure out what actually can/needs to be done and what isn't implemented yet in SSV [14:19:22] so I just discovered the config files [14:19:39] I guess I could have loaded the STS-1 file yesterday [14:19:47] oh for the FDO MFD? [14:19:51] yeah [14:20:14] I thoughtyou knew and just you wanted to learn how to use the MFD :D [14:20:33] it was for the best...better to learn how to do it manually :D [14:20:44] but its convenient [14:20:47] it gets tedious with rendezvous plans with 9 maneuvers [14:21:54] can the plan for STS-126 (ISS rendezvous) be used for another ISS mission say STS-120? [14:22:15] with corrected launch dates of course [14:22:48] what frustrates me in the default SSU/SSV scenarios is that there is no consistent system with the ISS state vectors [14:22:56] yeah [14:23:09] so not even with non-spherical gravity disabled will you get a good insertion at the historical liftoff time [14:23:21] and e.g. the STS-114 launch scenario doesn't even have an ISS! [14:23:30] yeah I saw [14:23:52] for STS-120, I actually based the generic rendezvous plan "PlanB" on that profile, so that is the best to load [14:23:57] I made myself an STS-120 launch scenario with a corrected launch time based on LWP [14:23:58] fairly small phasing angle [14:24:07] ok plan B [14:24:08] and what did you do with the ISS SV [14:24:27] I kept the same MJD as the original scenario [14:24:30] I believe that state vector is quite off [14:24:35] well, it's nearly in-plane [14:24:43] but the phase angle is about 180° wrong [14:24:50] ah [14:25:02] I use Scenario Editor TLE to update it [14:25:08] but with the LWP finding the correct launch time? [14:25:38] with LWP finding the correct launch time you will at least have an in-plane launch [14:25:47] even if it's at the wrong time [14:26:01] and you should then have a look at the phase angle in the LWP [14:26:12] I added a section to the manual with the generic rendezvous plans [14:26:35] PlanC is for 175 to 327° [14:26:57] will still need a lot of tweaking for each mission, but it should at least converge [14:30:57] whats the phase angle supposed to be? [14:33:20] actual STS-120, something like 70° [14:33:32] but I think with the ISS in the scenario it's 300 or so [14:33:48] 307.5 [14:33:57] so in the scenario editor TLE? [14:34:23] it's an addon called "Scenario Editor TLE" [14:34:36] oh [14:35:34] how do you even find that these days... [14:36:09] found it [14:36:17] https://orbiter-forum.com/resources/scenario-editor-tle.2073/ [14:36:37] from 2006, that's the version I still have [14:40:30] do you import some real data with it for the ISS position? [14:41:56] yeah [14:42:06] I found a collection of TLEs from 1998 to 2005 for the ISS [14:42:22] and after that, there used to be a website that posted updates when a Shuttle launch was coming [14:43:05] 1 25544U 98067A 07296.50916219 .00020000 00000-0 20000-3 0 9017 [14:43:06] 2 25544 51.6378 162.1486 0002165 121.1642 238.9735 15.75910150 31028 [14:43:10] this should be good for STS-120 [14:43:21] 07296.50916219 [14:43:26] year 2007, day 296 [14:44:13] thanks [14:44:25] where do you load the data exactly? [14:45:38] I see the Load TLE button on the SV page but its greyed out [14:45:56] change the coordinate system [14:46:12] it only allows one type there then the button appears [14:46:19] ah [14:46:31] ref. equator (fixed) [14:46:43] put the TLE in a text file, first line needs to be the name (ISS or Zarya), other two lines the TLE [14:49:09] aha! [14:49:13] phase 76.2 [14:50:06] how does the launch time look [14:50:15] without non-spherical gravity it is earlier [14:50:18] hopefully not too early [14:51:51] 15:44:50 [14:52:20] real: 15:38:19 [14:52:37] before the ISS update I was seeing 16:03:00 [14:53:39] oh ok [14:53:54] they probably launched at the beginning of the launch window [14:53:57] and not in the middle of it [14:54:02] we have to launch in the middle [15:12:05] ok so I guess I need to set the "Legacy MECO" fields in the ME to match the LWP output [15:13:09] coordinate system question: does Orbiter's planetary z axis point to the south pole, or is it the x axis that's backwards? [15:16:17] y and z are switched [15:16:35] polar axis is [0 1 0] instead of [0 0 1] [15:17:31] that would explain some things.... [15:17:50] oh no haha [15:19:53] so no axis is backwards, just y and z switches and with that you need to use your left hand for the X x Y cross product to get Z instead of the right hand [15:20:40] yep [15:21:03] I have {-x y z} right now [15:21:30] which is left handed, but not the "right" left [15:22:07] indy91, does FDO MFD use mean earth radius 6,371 km? [15:24:09] yes [15:25:19] ok [15:30:58] n7275, do you not have to convert back to global coordinates in your system? [15:33:07] in my RTCC system, derived from Shuttle onboard equations, I calculate a local referenced vector [15:33:23] that's your lpos [15:33:54] that is given to pinesAccel [15:34:31] that function returns dg [15:34:52] but does that not have to be converted back to global [15:35:07] or is that done in the function [15:38:15] it probably needs to be converted [15:39:49] so [15:39:53] Vector lpos = tmul(rot,rpos); [15:39:57] switch y and z [15:40:10] do your Pines calculation with that right-handed, body fixes position vector [15:40:14] fixed* [15:40:17] switch y and z again [15:40:32] dg = mul(rot,dl) [15:40:40] at the very least it needs a coordinate system transformation on dg [15:40:41] I'll have to read through the Jcoeff perturbation code and see if it's in planet or global acceleration [15:41:55] if it's anything like the Shuttle Pines equations I put in our RTCC code then the non-spherical gravity contribution is entirely planet fixed [15:42:09] and then is converted back [15:42:21] and added to the Earth point mass gravity [15:43:47] you know what would be fun for this kind of thing, the RTCC ground tracking residuals display [15:44:11] which shows you in real-time if the trajectory agrees the RTCC acceleration model [15:44:14] agrees with* [15:44:23] they could even see mascons on that [15:45:36] https://i.imgur.com/Qzzziz3.png [15:46:35] or maybe this wasn't real time, but a processed batch of data [15:54:08] alright got a STS-120 launch scenario set up [15:54:49] https://www.dropbox.com/s/n7ivi2a8rg68dp4/Screenshot%202022-09-07%2011.54.09.png?dl=0 [15:55:01] thats from before launch using the LWP output SV [15:55:27] plan B [15:57:05] looks right [15:57:23] on-orbit it will need TI lighting and DVZ tweaking [15:57:27] after OMS-2 [15:58:03] manual has a tutorial on that [15:58:12] better is the real FDO handbook, did I ever give that to you [15:58:14] right I will follow that [15:59:51] for the SPEC 34 I think I need to edit the scenario to set the target ISS, or is that already the default? [16:00:09] The SSV manual is a bit unclear about that and how to do it [16:01:07] the scenario will need a StateVectorSoftware section [16:01:48] not even seeing that in the scenario [16:02:00] below a [16:02:01] @ENDSOFTWARE [16:02:01] line [16:02:10] add [16:02:11] @BEGINSOFTWARE StateVectorSoftware [16:02:15] TARGET_VESSEL ISS [16:02:18] @ENDSOFTWARE [16:02:22] I hope that works [16:05:45] ah ok [16:05:47] thanks [16:06:07] save/reloading seems to show it got it [16:06:34] including T0_POS 0.000000 0.000000 0.000000 [16:23:38] ooo l like that residuals display [16:24:27] thank you for your help on this [16:31:52] sure, no problem [16:46:44] morning! [16:48:11] hey Mike [16:51:19] hey [16:59:32] still at 10%? [17:00:23] yup :( [18:08:42] holy cow Block I rope addressing is a nightmare [18:58:02] indy91, back to Apollo questions [18:58:06] TEPHEM0 [18:58:32] what is that again? [18:58:42] I see 40403 for Apollo 11 [18:58:47] that's a MJD [18:59:02] midnight, July 1st before the flight [18:59:04] usually [18:59:17] is that the same for other missions? [18:59:22] say Apollo 12 [18:59:31] all missions between July 1st 1969 and July 1st 1970 [18:59:40] right [19:01:36] Skylark also would use that system actually. But Skylark has nothing hardcoded that depends on that number [19:01:45] so they just use it for time keeping [19:02:08] July 1st before whatever year the mission would be in [19:02:49] and Apollo 17 fell out of the norm because they didn't want to make new ropes for the new year [19:03:00] so they still used July 1st, 1971 as their TEPHEM0 [19:03:08] and not 72 [19:04:19] are you building a padload? [19:06:13] more ambitious [19:06:25] I am trying my hand at an Apollo 12 MCC [19:06:32] Ive got up to TLI pad [19:07:04] that is more ambitious :D [19:07:20] just start like I did with Apollo 11, copy and paste from Apollo 10 [19:07:27] yeah [19:07:41] the mission is very similar to 11 up to the landing I think [19:07:54] except the TLMCC calculation [19:07:57] the MCC is very "handcrafted". If you are wondering if there is a better way to do things, I wonder that, too [19:08:47] but it works [19:08:51] more often than not [19:27:17] right [19:27:34] I noticed MHVCCG is abscent in Apollo 12 Constants [19:27:46] isn't that the CG? [19:28:43] *Absent in 12,13,14. Are those missions using defaults I guess? [19:30:05] yeah, that is the CSM CG [19:30:13] default table is different [19:30:20] not sure why I added that for Apollo 11 [19:30:29] maybe that is an actual Apollo 11 CG table [19:30:44] I doubt the difference to the behavior of our CSM is very different though [19:32:06] what I added to simulate the SIM bay is [19:32:08] EmptySMCG=913.9687 1.6681 1.0488 [19:32:10] in the mission file [19:32:19] CG of only the empty (no fuel) service module [19:32:38] because the SPS trim gimbal angles are quite different for Apollo 15+ [19:33:15] but through Apollo 14 they should be all the sam [19:33:16] e [19:34:23] ah ok [19:34:46] got up to TLI pad ok [19:38:19] it would be nice to get this working in time for Comanche67 [19:39:01] I'm thinking the same thing working on my padload generator right now :D [19:41:39] maybe Apollo 12 could make it in as a "bonus" MCC tracking mission for NASSP 8 [19:42:32] sure [19:42:44] another MCC tracking that I think could simple enough to make is Apollo 13 with failure [19:43:09] the reason to not have added it so far is that I didn't want to support yet another MCC mission [19:43:22] and not a dogmatic "we only support up to 11" [19:44:00] but it wouldn't be such a terrible thing to have it [19:44:02] :D [19:44:14] we can leave it in the WIP scenario folder [19:44:42] "use at own risk" [19:45:22] these magical PADs may or may not get you to the Ocean of Storms :D [19:45:45] it might get you into a storm [19:54:31] thewonderidiot, lol, how did I never noticed that our Apollo 11 CMC padload document is missing page 14. I am looking at these so much! [19:54:43] wait really? [19:55:03] huh [19:55:49] also already found a typo in our Apollo 11 padload [19:55:59] I'm running a diff comparing to one automatically generated [19:56:23] do you know what's on the missing page? [19:56:26] and nice haha [19:56:34] well, the last 2/3 of the RLS vector [19:56:45] but we have that in the LM one [19:57:04] AlexB_88, P35 in the CMC, Apollo 11. Time delay from pressing PRO to TIG [19:57:11] there is a typo [19:57:16] instead of 180 seconds it takes [19:58:12] 180.56 [19:58:20] how can I ever forgive myself [19:58:26] wow that's horrible [19:58:32] wow [19:59:32] I always felt it was half a second off [20:01:02] I wonder if that missing page is my fault. I'll have to check that packet next time I'm at Don's [20:07:35] I'll try to remember to remind you [20:14:39] oh god between 11 and 12 was also the EKTLX scaling change [20:14:48] EKTLX/I [20:15:20] not sure CaptainSwag's scenario will like that [20:19:50] that must be a software change and not just an updated value [20:20:02] all three numbers of EKTLX/I were halfed [20:20:35] ah PCR 811, "TVC DAP gain change" [20:20:39] must be it [20:39:49] indy91, Apollo 12,13,14 are all "H" missions in MCC's mind [20:40:30] Im using H for Apollo 12. I guess it doesnt matter for now [20:41:22] yeah we can change it to H1, H2, H3 [20:42:02] right [20:43:51] good night! [21:13:46] n7275: I've pushed the scenario version check as is. It would still be better to let NASSP automatically migrate the scenario's. I have not decided how that should work yet but atleast you can get your systems update in now. [21:39:31] awesome. thanks. something automated would definitely be the way to go. for things like this it's probably fairly straightforward, but I'm not sure how you'd make that general-purpose. [21:40:52] but we should have that eventually, especially once we start supporting more missions [21:43:13] I have some rough ideas but don't yet know when and how NASSP should scan the scenario's and what should execute. Some kind of external updater script preferably. [22:55:02] I think it should be as independent of the vessels as possible. [14:25:08] hey Niklas [14:27:38] hello [14:27:48] your newest graph looks more like it [14:35:17] yes that's a significant improvement [14:52:06] if you have some time, do you think you could get about 6 hrs(at 100x) of flight recording, on the R2 model? [14:53:01] I want to play back the recorded flight, with another vessel starting at the same position [14:56:13] the Orbiter recording feature? [14:56:17] using your branch? [14:57:20] using your plugin [14:57:36] the one that uses addforce [14:58:32] oh [14:58:37] right, I had that one [14:58:49] AddForce is probably not perfect [14:58:59] but hopefully it's comparable [15:00:01] I want to make some plots showing diverging velocity and position for: spherical gravity, Boeing R2, LP165 under my implimentation of Pines' [15:03:24] any specific scenario? [15:31:26] hmm [15:33:17] maybe the one I posted. or something equatorial [15:34:00] ah yes, the one you posted makes the most sense [15:40:04] I have to admit, I haven't really used the recording feature [15:40:09] what is it saving and where [15:41:57] oh, under Flights [15:42:20] if I recall, it saves position and velocity vectors to the Flights folder [15:42:38] oh [15:42:42] yes haha [15:47:59] so you want the folder in Flights? [15:48:11] it also saves a scenario under Playback [15:49:40] only saved like 150 state vectors [15:49:47] didn't change any settings [15:54:04] hmm [15:54:13] I think I can do something with that [15:54:21] if I am interpreting the data correctly then the orbit is rising [15:54:34] haven't looked at the R2 model plugin code in a while [15:54:40] I might have to fix it [15:55:11] of course this potentially is due to AddForce being applied on the next timestep [15:55:21] so the direction of that force could be wrong [15:55:33] which would be worse with time acceleration [15:59:29] oh yeah. that would tend to accumulate error over time [16:01:13] recording file writes polar data? [16:01:21] so the first two columns are time and radius [16:12:34] ahh I seem to remember that. somewhere I have a Matlab script for processing that data. [16:14:58] maybe I am looking at the data wrong [16:15:03] semi-major axis doesn't increase [16:15:10] over time, on the Orbit MFD [16:18:58] yeah the in-sim flight data monitor makes a lot more sense [16:20:57] yeah, was looking at the wrong data [16:21:33] I was trying to make sense of that and wasn't getting far [16:22:49] https://i.imgur.com/sIybeTk.png [16:26:28] nice [16:28:15] that's what you meant with 6 hours, right [16:28:25] now 6 hours in real-time at 100x, so 600 in-sim hours? :D [16:28:28] not* [16:29:25] yes [16:29:45] I was not trying to occupy your entire evening with this project [16:33:37] So you want the playback folder scenario and the folder under Flights? [16:34:53] I like how the largest file from that recording by far is the Luna-OB1 attitude data [16:35:03] because it's spinning for artificial gravity :D [16:35:30] and it stores more data if the attitude or position/velocity changes by a certain degree [16:36:54] haha [16:37:02] sure, I'll take that folder [16:46:39] I always forget about Luna OB1 [16:48:03] https://drive.google.com/file/d/1RsI6nWQpEXKfHjq3BBr0zolfXy7Gdees/view?usp=sharing [16:50:21] awesome. thanks. [16:52:23] morning! [16:54:50] n7275, 6 hours isn't a lot, but I guess it's enough to do a comparison of the biggest orbit changes [16:54:52] hey Mike [17:02:09] I'm continuing to backtrack on how smart I want to make the Block I rope reader software lol [17:02:32] I have gone from "attempt to read the banks in some sort of order" to "just read the banks in any order and deal with it later" [17:04:54] I also like option 2 [17:05:52] looking at padloads, I am kind of wondering why they padloaded PIPTIME [17:06:13] that's the state vector time tag when Average G is on I think [17:06:45] they load TEPHEM as midnight before the day of launch, so the AGC clock is syncronized to that [17:07:00] PIPTIME also reflects that TEPHEM, PIPTIME is set to the time of launch [17:07:11] I just wonder if there is any real use for that number [17:07:20] any of the test programs [17:07:29] P03 or something [17:07:45] hmm [17:07:47] we have never bothered padloading it [17:08:04] it gets overwritten at liftoff anyway [17:08:23] oh really? wow yeah it must have been useful for some of the prelaunch stuff then [17:09:11] well, I assume it gets overwritten [17:09:18] it's definitely not required for launch or anything [17:09:39] at liftoff it should add TEPHEM to the AGC clock for the new TEPHEM, the liftoff time [17:09:45] and PIPTIME might be zeroed then [17:20:23] I think I'll add it to any future padload, but, still not sure what for :D [17:25:21] they also put strange data in the REFSMMAT in the padload [17:33:50] oh wow [17:33:58] the Queen has died [17:40:00] yeah, crazy [17:45:44] n7275, about the scenario version checking, only NASSP 7 scenario get completely broken by your specific heat PR? I forgot [18:31:35] stuff from before the vap press, hvap update is worse [18:32:13] nothing that I've tested kills the crew or makes the mission uncompletable [18:32:29] but you will have very high cryo pressures [18:43:11] yeah, was just curious, no objections about anything from me [15:29:31] hey [15:39:53] hey Matt [16:17:48] I need to rework my writeup for the specific heat update and put something on the wiki and then I think we can merge it [16:29:34] morning! [16:29:38] hey [16:32:47] hey Mike [16:56:05] I'm very close to having a full handle on Block I rope reading [16:56:18] going to try to design the mechanical side of things tomorrow [16:56:38] the mechanical side of this is also going to be very awkward haha [17:01:00] and the bank order is a game of memory [17:01:52] that's easy enough to fix in a postprocessing script :D [17:11:45] hey [17:13:18] yo [17:31:22] hey Alex [17:31:36] AlexB_88, I saw a MCC-2 related commit [17:31:44] ... that might not be easy to automate :D [17:32:09] hey Niklas [17:32:16] I got something working for that [17:33:29] I used a loop to iterate the midcourse processor to the correct LOI GET [17:34:15] I guess you kind of have to simulate the manual process [17:34:34] yeah [17:34:52] I got it to calculate MCC-2 with an LOI within 5 seconds of flightplan [17:35:49] the code I added for that is already in the commit line 528 or so [17:36:15] still improving it though [17:38:11] yeah, that should work [17:38:20] even in the case the TIG goes to the other limit [17:38:44] depending on the TLI the optimum TIG it is finding within the limits could be at the min or max time [17:38:59] but the way you are doing it should be able to deal with that [17:39:00] I force the F23 times to before the LOI time and then scan forward [17:39:04] yeah [17:39:19] I think I can take out the OR condition in the loop [17:39:30] I mean just have while (PZMCCDIS.data[0].GET_LOI < LOIFP) [17:42:20] btw for MCC-1 I used option 9 [17:42:39] but maybe option 6 is better? [17:42:47] pretty sure it was to get you to FR [17:44:28] I don't think they would have done a MCC-1 flyby maneuver [17:44:37] not unless they had already decided to actually do a flyby [17:44:48] MCC-1 would target the same thing as MCC-2 [17:45:20] the mission techniques document says [17:45:34] "Is MCC-2 DV minus MCC-1 DV less than * ft/s?" [17:45:46] *real-time decision which depends on SPS reserves [17:46:05] right [17:46:06] basically, they would do MCC-1 only if that rescues the mission [17:46:11] because MCC-2 would be too large [17:46:22] but the flightplan says MCC-1 is nominally 0 [17:46:39] yeah, because you don't do it :D [17:47:09] so maybe I should put the same calculation in as MCC-2, but with a much higher DV threshold [17:49:12] higher scrubbed DV limit* [17:50:01] the consumables analysis for Apollo 12 lists the hybrid transfer as 68.8 ft/s [17:50:12] and then in addition to that it has TLMC (120 ft/s) [17:50:29] so the total DV budget is 188.8 ft/s [17:50:40] if MCC-2 is high than that, you would do MCC-1 I guess [17:50:46] if MCC-1 is higher than that, you abort [17:50:57] makes sense [17:52:55] that nominal MCC-2 DV doesn't vary much in the launch window [17:53:02] because of the constant pericynthion height [17:53:09] 62-69 ft/s the SCOT says [17:53:17] if its higher then that I'll have it print "Go back to TLI school" [17:53:49] I can't imagine many things to do wrong during TLI :D [17:53:52] before, sure [17:54:22] I am one to talk, I once had an Apollo 16 MCC-1 at 190 ft/s if I remember :D [17:54:34] after a manual TLI [17:54:50] that's what the 120 ft/s allowance is for :D [17:55:22] Im pretty sure I busted my allowance on that one [17:55:41] J missions must have been even smaller then 120 ft/s [17:58:12] I think for MCC-1 it may be best to not force an F23 time [17:58:27] since your trajectory is already quite bad at that point [17:58:42] probably best to get an optimized LOI time for it [18:00:18] hmm well in any even I have a check to see if its +/- 30 mins of the FP LOI time so maybe it cant hurt [18:02:01] maybe put fixed limits of +/- 10 minutes [18:02:04] for MCC-1 [18:02:15] then it would at least find a decent solution [18:02:34] ok [18:02:38] you burn MCC-1, it does the fine tuning for MCC-2, so you probably would get a MCC-2 then, but not too big [18:02:49] right [18:12:08] since now there is a small possibility of MCC-1 being the hybrid transfer, I wont make MCC-2 mandatory, but with a small scrubbed limit [18:14:50] hmm yeah, should never be mandatory [18:16:44] and they wanted maneuvers to be with the SPS [18:16:48] to conserve RCS [18:17:15] I was under the wrong impression they would have corrected the FR for a bad TLI so thats why I thought MCC-2 would be the hybrid transfer in all cases [18:17:26] after a bad TLI* [18:19:17] do you have the mission techniques document? [18:19:26] not that FIDOs ever followed it closely... [18:20:23] or that it would provide simple guidelines to follow [18:20:26] but it's still useful [18:20:43] Ive got the "Final Flight Mission Rules" [18:20:52] Sept 10, 1969 [18:20:58] not the mission techniques though [18:21:15] I don't have 12, just 13 [18:21:19] but should be the same really [18:21:58] hmm dont think I ever got that one [18:22:01] have a link? [18:22:07] I got it from UHCL [18:23:55] thanks! [18:55:52] "In the unlikely event the flyby mode were used due to some contingency" page 26 in that document [18:57:06] talk about jinxing it [19:54:15] yeah what could happen to cause that. An exploding O2 tank? Ridiculous [20:37:55] night! [12:57:12] good morning [13:27:00] hey Alex [13:31:17] MCC-2 will be 68.4 ft/s [13:31:25] FP 68.8 [13:33:25] I guess that shows that TLI put us on the expected trajectory [13:36:12] ah yeah, very nice [13:39:44] post TD&E is a bit more simple on Apollo 12, compared to 11 [13:40:29] I think on 11 you have to know if you're burning MCC-1 before getting the PTC REFSMMAT [13:40:48] but on Apollo 12 you always get it after TD&E [13:43:08] I guess because MCC-1 was even less likely [13:53:04] the yaw angle for MCC-1 is showing 320 on the PTC REFSMMAT [13:53:21] I guess thats still above the limit [13:54:38] I mean thats from a perfect trajectory where you wouldnt burn it anyway...maybe a bad trajectory would be different [13:55:22] but I dont think it warrants having the alternative sequencing for PTC REFSMMAT after MCC-1 [14:01:52] right [14:02:18] if anything there should be a general logic for TLC and TEC, uplinking a P30 REFSMMAT if the yaw angles if bad with PTC [14:02:28] yaw angle is bad with the PTC REFSMMAT [14:02:39] yeah [14:36:23] I see in the transcript they generally used -168 for mid pacific [14:47:37] hmm actually it varied quite a bit [14:47:57] L/O+25 -169 [14:48:04] +45 -166 [14:48:08] it's only a fixed 165°W for the first few missions [14:48:10] +35* [14:48:14] then it's a function of latitude [14:48:51] right [14:49:00] I believe we simulate that [14:49:08] I put a fixed 165°W in the Apolo 8 RTCC config [14:50:02] 40°N/175°W [14:50:08] 15°N/175°W [14:50:20] 0°N/165°W [14:50:25] 40°S/165°W [14:50:32] are the defining points [14:50:54] which is not identical to what you are saying, hmm [14:52:34] for the block data I hard coded -165, but I guess it show be MIDPAC or something to have it vary by latitude? [14:52:43] should* [14:54:03] ah because it uses AP11BlockData [14:54:18] and in there is entopt.entrylongmanual = true; [14:54:50] yeaaaah [14:54:55] too many old functions [14:55:58] although that one could probably be changed without too much trouble [15:29:43] indy91, is there a way to save the output SV of the MCC-1/MCC-2 calculation outside of the RTCC calculations function? [15:30:33] calcParams.SVSTORE [15:30:36] I would like to use an output SV from the TLMCC processor [15:30:43] for the block data [15:30:56] ah [15:31:14] so for like the L/O+35 that takes into account MCC-2 [15:31:54] so that would hold the output of the last calculate maneuver? [15:32:15] that's just a state vector for temporary storage, saved/loaded in the MCC [15:32:23] well [15:32:28] in the RTCC section for the MCC [15:32:35] ok [15:33:27] SVSTORE1 [15:33:54] I am using it to e.g. save the LM insertion state vector during the Ascent PAD calculation [15:34:00] gets then used by the CSI PAD calculation [15:34:39] right [17:18:30] morning! [17:41:18] hey [19:02:20] hey Mike [19:06:41] ok should have things working up to LOI-1 [19:06:55] including the no MCC-4 alternate timeline [19:08:18] SV uplinks including the V66 is normal for 12 [19:14:37] very nice [19:18:42] hmm what was the inclination constraint for Apollo 12 TEI's? [19:18:54] its hardcoded to -40 for Apollo 11 [19:20:00] I think technically you don't have to hardcode anything [19:20:09] it automatically constrains it [19:21:27] ah [19:37:33] actual reentry was 18.8° inclination, ascending [19:37:47] that doesn't mean that all preliminary TEIs are in the limits [19:37:53] but they could be [20:58:17] night! [12:29:49] good morning [13:11:06] good morning [14:31:29] hey Matt [14:43:46] doing some comparisons with the Apollo 11 padload again [14:43:55] diff between our current one and an automatically generated one [14:46:00] there is still a bunch of differences, but a lot of them are really small. So small that it wouldn't even make a difference if we used the numbers from the actual Apollo 11 padload [14:48:19] might be nice if we used the real numbers, even if they are slightly off [14:48:46] yeah [14:49:40] like the trim angle of attack of the CM [14:49:47] in the past we used 20° for all missions [14:49:55] I'm guessing stuff like nutation and gravity coefficients are the biggest offenders [14:49:59] pretty sure the CM aerodynamics were adjusted to that [14:50:06] our CM* [14:50:28] yeah the nutation/precession correction vector is of course different from actual [14:50:40] for both Earth and and Moon, more a libration correction vector for the Moon [14:50:51] and yeah, the two erasable numbers for the R2 model are zeroed [14:51:00] of course no IMU biases [14:51:12] the lunar ephemeris [14:51:27] I wonder if we would use the real one there, need to do a comparison [14:51:33] it's a scaling nightmare though [14:51:42] I bet [14:51:45] we potentially have a timing issue with the ephemeris [14:51:58] oh? [14:52:02] ephemeris vs. universal time [14:52:13] in a way, time moves different in Orbiter [14:52:17] because of leap seconds [14:52:35] I think MJD is accurate [14:52:51] I think the conversion to UTC from MJD isnt [14:53:07] right [14:53:15] maybe it is also precession of the ecliptic or something [14:53:24] I found a fairly simple set of equations for a solar ephemeris [14:53:28] in a textbook [14:53:37] similar to what the LGC had hardcoded [14:54:08] but it is off over longer periods of time, by the same amount the Earth precesses [14:54:18] maybe just a coordinate system thing more than anything [14:55:23] the ephemeris tapes they used were in ephemeris time [14:55:34] so the padload was the numbers from that tape, biased by the DT [14:55:36] https://en.wikipedia.org/wiki/%CE%94T_(timekeeping) [14:55:52] just the time tag of the ephemeris biased [15:08:39] I wonder if there's anything to be gained by increasing the precision limit for VSOP87 in the config files [15:10:33] I could analyse that [15:10:36] the Orbiter.log shows how many terms it loads [15:10:45] I put the Orbiter implementation in MATLAB [15:10:59] maybe I would see a difference [15:13:14] ErrorLimit = 1e-8 [15:13:16] that, right? [15:17:35] yes [15:19:46] hmm [15:19:52] I'm seeing ALL the terms already with 1e-8 [15:19:58] no difference if I make it smaller [15:20:02] not sure if that is correct... [15:20:13] that is for the Sun [15:20:17] or I guess [15:20:19] Earth :D [15:31:08] hmm maybe I was looking at other planets. [15:38:33] yep. it loads all of them for Earth [15:38:41] but not for the moon [16:10:02] morning! [16:27:32] hey Mike [17:03:07] hey [17:12:34] yeah I think I am happy now with this automatically generated Apollo 11 padload. Just need to make sure it can find Sun and Moon [17:14:21] I also made it so the lunar ephemeris is variable in its time span [17:14:34] previously all our padloads were valid for 14 days [17:14:43] the lunar ephemeris [17:14:46] starting with launch [17:14:56] but on Apollo 11 they had that set to 10.5 days [17:15:00] Apollo 12 and later 14.5 [17:15:15] makes it a tiny bit more accurate over the shorter range I guess [17:35:56] is this with your new padload tool? [17:41:44] yep [18:26:11] I just added the specific heat update to https://nassp.space/index.php/Scenario_File_Updates [18:32:20] ah nice [18:32:31] I saw that change to the version number [18:32:40] does that mean we have to call it NASSP 8.0.0.0.1 Beta now :D [18:35:35] that would be a bit of a pain haha [18:36:35] The intent is 8.1= 81XXX, where XXX = breaking change number [18:37:04] sounds good to me [18:39:36] writing up a draft post on O-F now [20:10:05] great. time to merge it soon haha [20:10:14] only took [20:10:17] months [20:10:28] after it was already done :D [20:31:07] night! [14:37:52] good morning [14:39:21] hello hello [15:22:13] I think my radiative branch is done. I've tested it quite extensively. [15:24:49] wait, radiative? [15:24:55] I'm getting your branches confused now [15:25:07] there are too many ECS related ones :D [15:25:36] I thought it was all about "Update Specific Heat model" at the moment [15:57:17] well yes. the specific heat one should probably be merged first. [15:58:40] the radiative one could use a 2nd pair of eyes to make sure I'm not getting us into some kind of ironic "Daedalus and Icarus" situation with my ambitious physics updates. [15:59:31] haha, yeah, I'll have a look [15:59:43] I like how the specific heat one is basically a two lines change [15:59:54] and then a few lines more with comments and the numbers for it [15:59:57] and then 110 scenarios :D [16:01:15] got my approval. Maybe Thymo has some last word on it, but then it's getting merged. [16:01:24] yep haha [16:01:37] okay cool. thanks [16:26:56] morning! [16:35:01] hey Mike [17:03:13] Let me take a look [18:58:27] good catch. I will update those in a bit [21:53:33] Thymo, I have forum post ready to go, just give me a heads up when you're ready to merge and I'll post it. [14:39:33] hey Niklas [14:39:49] hey [14:39:55] I think your update is finally done [14:40:36] I'll merge it when you give me the go [14:41:14] yay! go for it [14:42:50] done [14:42:56] time to tell people the good/bad news :D [14:46:06] it'll probably cause less contention then the dsky color updates though haha [14:49:07] especially because in updated scenarios nobody will notice a difference [14:50:47] or only a good difference :D [14:54:09] I'll be checking the forums every hour for the next few days or so... [14:54:20] hahaha [14:55:07] every 108 minutes will be enough [15:07:13] I'm confused about the sun ephemeris in Orbiter [15:07:19] it's using VSOP87B [15:07:29] Heliocentric ecliptic spherical coordinates for the equinox J2000.0 [15:07:40] but I am reading that is for the Earth-Moon barycenter [15:30:39] hmm no, it is the true position [15:31:01] I just feel like the sextant should point exactly at the Sun [15:31:16] it does point at the sun, but not exactly center [15:31:26] with old and updated padload [15:31:38] that's why I thought there might be some barycenter stuff going on, but no [16:11:48] if I use the sun in P52 I am getting a 0.11-0.12° star angle difference [16:12:26] but calculating the error from the AGC sun ephemeris I should get 4 arc seconds error at most [16:12:40] that is about 0.001° [16:17:45] hmm that's odd [16:18:27] does Orbiter simulate the Sun's position with respect to the actual solar system barycenter? [16:18:45] I think so. But I just did a check [16:19:00] called GetRelativePos with Sun and Earth to create a vector pointing from Sun to Earth [16:19:26] and then compared it to the function I use to generate the AGC ephemerides [16:19:28] and it's identical [16:20:25] so unless GetRelativePos doesn't return the actual relative vector, that part should be right [16:20:41] I can test for that of course. rotate GetRelativePos into local coordinates [16:20:56] and see if pointing exactly at the Sun gives the right direction [16:33:06] I think there's a dedicated get barycenter function in oapi so that would be odd [16:37:52] yeah, pointing exactly at the sun gives the right result [16:38:11] I wonder if it's some AGC precision limitation or something [16:57:53] is the solar ephemeris just a position and velocity vector for the duration of the mission. so linear solar motion? [17:01:08] a position vector, a velocity vector and angular velocity at mid mission. And then it does a calculation assuming a circular orbit [17:12:48] that seems like too big of an error to be precision though. [17:14:08] morning! [17:15:06] 0.12 deg would be a 170000 nmi position error [17:15:09] hey Mike [17:15:26] hey [17:17:45] yeah as I said, in the function that generates the padload there is a deviation analyis and it should be 0 mid mission and 4 arc seconds at +/-7 days from that [17:17:53] or +/- 5 days with the old padload [17:17:54] new* [17:18:38] maybe it applies the star aberration calculation to the Sun, too :D [17:31:08] hmm [17:31:17] it's not the same in the Apollo 11 MCC-2 scenario [17:31:22] acceptable error there [17:31:32] but in the MCC-5 scenario, quite off with old and new padload [17:31:41] pointing at the same spot on the edge of the sun [17:31:45] or halfway to the edge [17:42:19] you know what [17:42:29] I probably just used the worst possible scenario for testing [17:42:52] because an even later scenario is fine again [17:43:53] not sure how though, the scenario is fine [17:44:11] the state vector* [18:55:47] Evening [19:02:31] hey Thymo [19:40:08] hey Thymo [20:31:28] night [14:45:28] hey [14:46:35] hey Alex [14:48:09] hey guys [14:51:19] hello [15:01:26] should I spend a lot of time figuring out the "not quite pointing at the center of the sun" mystery or not... [15:01:52] it even happens with the flown padload, so the problem is not the ephemerides [15:30:56] how certain are you that it *should* point to the center of the sun. [15:32:34] our state vectors work. and I can't see doing P52s with the sun that often [15:32:51] just from the padload and the equations in the GSOP [15:35:21] the equations to calculate a position vector of the sun [15:39:42] the weird thing is that it's only a problem in this one scenario [15:49:24] it's probably not worth a huge amount of effort [15:52:58] yeah [16:02:52] ok, I guess I am happy with my auto generated Apollo 11 padload then [16:03:34] will work on a PR for that one. Mainly the ephemerides changed, slightly more precise for the mission timespan and using the proper technique to generate it (minus the ephemeris minus universal DT) [16:04:03] and it seems like our landing site vector in the padload was off in altitude, too [16:04:10] about 1000 feet [16:04:25] that still leave 2000-3000 feet error to the actual landing site radius [16:04:30] but that's realistic [17:10:23] morning! [17:19:03] hey Mike [17:35:08] any update about the rope reader? [17:37:10] nooooo [17:37:20] they still haven't started assembling it :( [17:39:56] damn [17:40:27] I'm making progress on figuring out how I'm going to build the Block I version though [17:41:29] I forgot, does that need to be an entirely different reader or some kind of adapter [17:41:52] it's going to need a totally different mechanical structure and backplane board [17:42:10] I can use the same driver board but it's going to take some rework [17:42:51] namely, I need to tune the drive currents lower (e.g. 300mA for SET instead of 450mA) [17:43:19] and I also need to disconnect the filtered 14V from the sense line returns, and hook it up instead to the module select driver -- since Block I doesn't have module selection [17:43:23] at least I'm pretty sure that should work [17:43:48] Block I has the sense line return connected to the 3V power rail [17:44:51] hmm yeah, sounds different enough [13:48:35] hey Alex [13:53:51] hey [14:53:03] hey Niklas [14:53:58] question for you: In the DMT if I do U20,CSM,1,,TLM; does that use the REFSMMAT in the CMC? [14:55:55] hey [14:55:59] TLM is a slot in the RTCC REFSMMAT table [14:56:41] when you press the DWN button on the REFSMMAT page the REFSMMAT gets saved there [14:56:48] ok [14:57:05] I am programming the Apollo 12 SEP PAD [14:57:09] and then, unrealistically but for simplification, it also saves it as CUR right now [14:57:18] Im using the MPT with input maneuver [14:57:37] but the TLM slot will always have the REFSMMAT you last downlinked from the CMC or LGC [14:57:52] MPT, interesting :D [14:57:56] right [14:58:19] I was going to remove the use of the MPT by the MCC for the TLI PAD at some point [14:59:23] for Apollo 12 the SEP PAD is just undock time, sep time, sep attitude [14:59:51] for Apollo 11 MCC it is a whole P30 PAD [15:00:09] right [15:00:10] so I made a new PAD with just the 3 items [15:01:23] is there a way to calculate a direct input maneuver without using MPT? [15:02:34] just calculate a Maneuver PAD [15:05:10] right thats what the Apollo 11 SEP PAD does [15:05:27] I guess I could just then feed the 3 items from it into my custom PAD' [15:05:51] yeah. Oh and about the custom PAD [15:06:09] maybe this would be a good opportunity to have the abbreviated Maneuver PAD [15:06:34] which should just print fewer items [15:06:40] same calculation to simplify it [15:06:48] and then the undocking time as a remark maybe [15:07:03] that would not even require adding a different PAD [15:07:38] thats how I did it yesterday :D [15:07:49] I added the undock and sep times as remarks [15:07:53] to the normal PAD [15:08:40] sep time as remark? [15:08:45] isn't that just the TIG? [15:08:48] but when I looked at the transcript they only said the 3 items so I felt like trying a different format [15:08:52] sorry just undock time [15:09:09] in the flight plan I am seeing some pre-printed values for the rest of the abbreviated Maneuver PAD [15:09:15] but otherwise it's the same form [15:09:19] but I think we can just use the same PAD for now [15:09:58] CSM SEP [15:10:03] RCS/G&N [15:10:10] weight and trims are N/A [15:10:19] ugh [15:10:20] then GETI need to be written [15:10:24] DV is printed [15:10:27] what page? [15:10:29] attitude needs to be written [15:11:03] I am looking at Apollo 17 actually, I wanted to check if your new PAD applied to all later missions [15:11:16] ah ok [15:11:34] Apollo 12 CMP Solo Book has it basically like you said [15:13:54] Apollo 14-17 have the abbreviated Maneuver PAD printed in the flight plan [15:14:58] right [15:15:03] Apollo 13 has it printed like that in the CMP Solo Book [15:15:31] you can of course add it as a special type of PAD [15:15:49] and let it calculate the Maneuver PAD and then transfer the data to your PAD in code [15:16:03] like the TLI PAD puts the data from the DMT on the PAD [15:17:14] but that PAD would probably only be used on Apollo 12 [15:19:57] yep I made a custom one [15:20:11] AP12SEPPAD [15:20:31] with just 3 variables [15:29:24] is the Descent Abort calculation compatible with Apollo 12? [15:30:04] for the abort constants [15:30:15] yeah, I think it's still only compatible with 11 and 12 [15:30:44] maybe I can try and get the MCC to feed updated values into the AGS activation PAD [15:32:32] that would be fun [15:32:56] for now I just gave it hardcoded numbers from the activation checklist [15:33:11] but Ill revisit that later [16:45:13] hmm I guess 12 did not get a CSM rescue PAD [16:46:56] actually the PAD is in the CMP solo book [16:47:11] just not listed as an MCC update in the FP [16:49:18] but was it read up? [16:53:31] doesn't look like it seeing the transcript [16:58:41] makes it easier [17:07:56] morning! [17:18:10] hey Mike [17:18:30] getting padloads to agree with the flown one down to each bit is difficult... [17:19:51] I even rewrote the functions converting to single/double/triple fixed point precision to get more consistent results [17:20:46] the problem was that we truncated where it should be rounded [17:20:54] but then there are special cases [17:21:36] z-component of the UNITW vector is so close to 1 that properly rounded it would overflow 037777 and become 040000, so I needed to limit it properly [17:23:03] the old method just looked at the whole, scaled number and removed the upper bits. So instead of the desired 37777 or even 40000 I got 0 instead, with proper rounding, just not doing double precision properly... [17:23:32] hello [17:23:36] hey Matt [17:24:33] and then, for the Apollo 11 padload only, someone calculated the landing site vector from the latitude, longitude, radius. But then it got rounded to full meters and then converted to padload scaling. So from the original lat/lng/radius there is two losses of precision. [17:25:08] drove me half mad until I discovered that they rounded it before converting to the octals :D [17:28:05] is that what's causing the sun angle error? [17:28:20] nah [17:28:45] the sun angle error was even occuring when I put the actually flown erasables in the scenario [17:28:52] was pointing at the same spot on the Sun as before [17:33:03] ahh okay [17:33:10] got excited for a bit [17:33:28] hah, that sounds like fun :D [17:33:45] reverse engineering in a different sense -- trying to figure out how the hell they got their numbers :D [17:35:58] yeah [17:36:31] and two numbers somehow use two's complement, so I just manually added 1 to them with no special handling :D [17:37:11] hahaha [17:38:09] TAZEL, the angles to point the sextant at a alignment target on the VAB [17:39:01] I understand why they did it, but it's too bad they didn't include this section in all of the programs https://github.com/virtualagc/virtualagc/blob/master/Luminary069/PADLOADS.agc [17:43:00] yeah, that's quite useful [20:38:36] night! [21:05:01] .tell indy91 Apollo 11 T2 TPI time is saved as T3 TPI time in the Lunar Surface PAD [13:25:35] hey guys [13:28:08] hey [13:29:31] hey [13:30:49] I'll push that fix together with my Apollo 11 padload update that is now finally done [13:31:00] and Apollo 12 padload is also done [13:31:08] for Comanche 67 [13:31:37] ah nice [13:38:36] I've been trying to troubleshoot the weirdest bug in the OpenOrbiter main branch https://github.com/orbitersim/orbiter/issues/243 [13:41:21] does it happen only in OpenOrbiter? [13:42:14] and that is without your gravity update [13:54:19] got Apollo 12 MCC working up done to lunar landing [13:54:55] oh great [13:55:22] all in all I just had to make 2 custom PADs so far [13:55:44] the PDI abort and lunar surface card [13:56:02] both are much shorter then Apollo 11 [13:56:18] no phasing, CSI, orbit period etc [13:57:30] what's the PDI abort one [14:03:14] <10min and >10min TPI times [14:03:55] I think the Apollo 11 one also included the phasing TIG [14:19:34] the Apollo 12 equivalent is probably the booster maneuver, but that happens at a fixed time after insertion, not a fixed TIG [14:19:40] boost* [14:20:25] right, and you calculate that yourself [14:20:58] The lunar surface card has the P22 acquisition time, Ive hard-coded the real one for now [14:21:17] but there should be a better method to find it dynamically [14:24:02] where do we have the lunar surface data card book [14:24:07] -book [14:24:12] it's not in the data card book? [14:24:28] oh Abort/Ascent Card [14:25:02] right T2/T3 PADs [14:25:58] the acquisition time is probably the P22 PAD time for T2 [15:20:44] yeah, only OpenOrbiter, and in the main branch without my gravity stuff [16:55:39] morning! [17:22:33] hey Mike [17:22:39] what's up? [17:46:50] hey [17:47:07] got my automatically created Apollo 11 CMC padload done [17:47:17] and I also checked the one for Comanche 67, it's ready [17:51:02] nice :D [17:51:07] rope reader, not so ready yet [17:51:21] haha [17:51:28] although my Block I ambitions are growing. I think I should be able to finalize the mechanical and backplane design this weekend [17:51:42] which means I might reorganize plans a little bit and try to dump Sunrise 69 at the same time I dump LM131 [17:52:13] oh awesome [17:52:40] Sunrise, that's so early [17:52:44] pun intended [17:52:52] er, I think it was Sunrise 69? let me check my pictures [17:52:56] hahaha [17:53:10] one last thing I should do with the padloads, transcribe the actual Apollo 11 and 12 padloads and do a diff, just as a nother cross check and to see that every difference is one I actually want there to be. [17:53:13] yeah the only earlier thing is Eclipse [17:53:34] yeah that makes sense :) [17:53:58] alright what do I have pictures of here.... [17:54:25] module B21, p/n 1003133-19 [17:54:34] module B22, p/n 1003733-071 [17:55:01] module B28, p/n 1003133-20 [17:55:10] module B29, p/n 1003133-18 [17:55:28] B23 and B24 unpopulated [17:56:11] didn't even fill the smaller Block I memory [17:56:18] haha yeah [17:56:23] yeah this is Sunrise [17:57:11] Skylab should have been called Sunset [17:57:14] B29 is from Sunrise 33, B21 is from Sunrise 38, B28 is from Sunrise 45, and B22 is from Sunrise 69 [17:57:15] Skylark* [17:57:23] because it's the last [17:57:40] hah, yeah that would have been perfect [17:58:09] that's quite a motley set of modules, but the deck numbers confirm that that is correct for a full set of Sunrise 69 modules [17:58:49] what's 1003133 vs 1003733 [17:59:20] just one module being a different version? [17:59:37] I believe 1003133 modules have a slightly different type of core in them? [17:59:47] 1003733 was what ended up flying [17:59:53] motley indeed then. And I just learned that word. [17:59:57] hahaha [18:06:38] that is a good point though. I need to go in and make sure it's definitely just the cores [18:06:45] and not something that will mess up the reader somehow [18:07:12] yeah, I guess especially with Block I that is a potential issue [18:07:25] Block II ropes developed in the same sort of way [18:07:37] 2003053 was the first revision, that had the sketchy diodes [18:07:52] 2003972 upgraded the diodes and also added extra diodes on the strand select lines [18:08:16] and then 2010802..... I have no idea, because NARA is missing every drawing that might tell me something, but I think they most likely changed the cores again [18:10:29] I know at the minimum that the part number for the sense wiring assemblies changed [18:10:48] and I can't believe that they changed anything about the wires in between Apollo 12 and 13 [18:16:22] I don't think that is the kind of detail that gets mentioned in the mission report CSM and LM change lists :D [18:20:14] no definitely not haha [18:20:51] the MIT status reports would have been perfect, if they hadn't gotten lazy and stopped doing them just before Apollo 11 [18:24:14] SIT, SFRR, CARR [18:24:26] SFRR is software flight readiness review? [18:24:37] these are related to the AGC [18:25:33] Customer Acceptance Readiness Review [18:25:46] almost, FSRR [18:26:25] tell that to the person from MSC who wrote SFRR :D [18:26:32] hehehe [18:26:38] was just looking at a random Apollo 8 document [18:26:45] "flight ropes devilered October 14, 1968" [18:26:55] "SIT performed October 29, 1968" [18:27:04] surely means software integrated testing or something [18:27:12] oh yeah that sounds right [18:27:18] also interesting, a rope delivery date [18:27:21] "SFRR and CARR concluded satisfactorily November 8, 1968" [18:27:25] I've had a hard time finding those [18:27:28] yeah, that's why I am mentioning it haha [18:27:29] what document is this? [18:27:46] Apollo 8 Mission Planning Briefings [18:27:55] that's going to be the only things interesting for you [18:28:11] everything else talks about mission design and alternate missions [18:28:29] I don't suppose we have those for later missions do we? [18:28:38] I know for sure for Apollo 10 [18:29:49] doesn't mention any dates [18:29:57] damn [18:30:00] was just in the Apollo 8 one because it was the first lunar missions [18:30:04] yeah [18:30:05] so it had a page on AGC capabilities needed [18:30:22] I am still very very very interested in finding when the Luminary 99 module swap happened haha [18:30:59] didn't we find some pretty good clues? [18:31:24] in the FSRR or so [18:32:31] we're missing the Luminary FSRR for Apollo 11 [18:32:49] we found a memo that said it happened in the week following CDDT [18:33:17] right [18:39:49] oh shit look what I just found https://www.thevillagesdailysun.com/news/local/computer-systems-analyst-for-apollo-11-remembers-mission-as-a-marvel-of-primitive-technology/article_923cb62a-a013-5568-9aae-1fadb7cf1f56.html [18:41:15] ah great, the EU saved me from viewing that website [18:41:52] got around it [18:42:11] wow [18:43:15] so they did know [18:43:16] fascinating [19:25:56] oh by researching a lot about ephemerides in the padloads, Sundisk seems to have had the same sort of scheme as the LGC always had. A lot simpler (and less accurate) than Colossus and probably also hardcoded. [19:26:16] But at least it doesn't take up 100 erasables for the whole mission as it does in Colossus [19:26:42] you need the high accuracy ephemerides for cislunar navigation [19:27:06] Shuttle has the same sort of equations, too, but not hardcoded [19:27:16] and Skylark [19:27:24] all the simpler equations [19:36:25] landmark tracking pad code was useful to get the P22 ACQ time [19:37:05] 28 elevation instead of 25 [19:37:13] instead of 35* [19:40:45] I found something really interesting about Sundisk the other day that is possibly related [19:40:55] but exactly what it was is currently escaping me haha [19:53:24] haha [20:19:12] oh that's right! [20:19:23] I was looking at the Skylark programmed guidance equations from Norton [20:19:43] and he had a section in there of "commented out" code that had been present in Sundisk but had been removed for Colossus [20:20:16] I found it while trying to dig up clues for Comanche 72 [20:20:36] and thought it might be helpful in Sundial E disassembly [20:20:39] where was that... [20:21:00] here: https://www.ibiblio.org/apollo/Documents/programmed-guidance-equations-skylark-003.pdf#page=234 [20:21:44] I think I might be able to pin down a lot of erasable names in Sundial from that.... maybe [20:28:36] yeah, could be [20:45:05] night [10:51:07] good morning [11:55:23] hey Matt [12:28:17] I'm rather supprised by the lack of messages on the forum from people asking me to fix their scenerios. [12:30:30] 2 possibilities: everyone either ran my script or waited to start a new mission, or no one read my post. [12:31:48] or people don't update their NASSP install that often [12:32:11] or they read your post and decided to not update [12:42:27] I hope it's a good sign. we know from the various DSKY updates that people do speak up if they don't like sonething [12:42:28] hey [12:42:33] hey Alex [12:43:34] hello [12:44:06] I got PDI-2 working with Apollo 12 MCC [12:46:56] fun [12:47:03] does that include the abort constants? [12:47:10] yep [12:47:55] I stole some code from ARCore to make the uplink work :D [12:50:21] yeah I really to implement the generic erasable uplink feature of the RTCC to make this a bit easier [12:53:30] I have the abort constants calculation working...I think [12:53:59] it spits out DEDA numbers close to the pre-mission values for PDI-1 [12:54:47] but other then that its hard to know if they are accurate other then flying it I guess [12:55:43] Apollo 12 has 2 targets for PDI-1 [12:55:48] but only one for PDI-2 [12:56:17] so I set dt_2CSI and dt_2TPI to 0 for PDI-2, I think thats correct? [12:57:13] it might not even get to the point where it would use those variables for PDI-2 [13:02:26] hmm [13:02:36] it would actually [13:03:35] but that abort would be quite a while after landing [13:04:26] no need to set them to zero then [13:05:02] the second phase aborts it generates are just later than you would ever use P70/P71 [13:05:43] right so after PDI-2 + 14:24 [13:06:36] T2 time I guess, yeah [13:06:41] last opportunity for that profile [13:06:49] or is that T1 [13:07:07] T1-2 [13:07:15] right [13:07:40] ok I will not set them to 0 then [13:09:44] yeah I am not sure, what you might not actually want to happen is that the LM launches for a rendezvous profile they wouldn't use [13:11:44] but procedurally you shouldn't use P70/P71 after T1 [13:14:41] if you launch at exactly T1 with P70 or P71 it could randomly be using the first or second segment [13:16:01] later missions had a profile like the second PDI [13:16:06] how was that solved there... [13:19:16] ah, not true [13:19:31] switching point was at PDI+6 minutes for e.g. Apollo 1 [13:19:32] 14 [13:19:34] just earlier [13:20:59] the safest option would be to have a constant apolune of 30NM for the second segment [13:22:32] one thing I wondered was the bool IsTwoSegment, but that should always be true I think for Apollo 12 [13:22:42] yeah [13:22:58] the NASA document I have for the descent abort constants is for Apollo 12 [13:23:07] and I hacked in the calculations for Apollo 11 [13:23:24] Apollo 11 had a different scheme, a polynomial [13:23:28] I guess this is a good MCC mission to have it working 1st then :D [13:23:29] with just one segment [13:24:00] right [13:28:01] "constant apolune of 30NM" is that set through the program options, or directly into the erasable memory? [13:30:47] it would be K2PARM set to 0 [13:30:58] and J2PARM to the semi-major axis to get to 30NM apolune [13:33:14] but I need to do some more research to see if that's how they would have actually set those parameters [13:38:01] but it's a rare case of course [13:43:00] it would kind of be the best outcome if the second segment is never used [13:43:21] then the semi-major axis becomes too small, but there is a limit, the 30 NM in the LGC code [13:56:35] I pushed the latest state with the abort constants stuff [15:07:19] cya! [17:15:45] morning! [17:16:55] hey [17:19:32] what's up? [17:22:13] hey Mike [17:22:15] thinking about flying Apollo 7. Naturally I am coming up with 10 things I want to improve before I am doing so, so I am looking into curve fits for reentry used by the deorbit targeting, instead of flying Apollo 7. [17:24:13] that happens to me every time I go to fly a mission [17:25:28] hehehehe [17:27:03] I'm still using the Augekugel routine from the AGC for this [17:27:17] which is very nice and simple, but not quite good enough for slightly off trajectories [17:27:36] like if you do a deorbit burn with the SM RCS, you usually have a fixed DV and come in very shallow [17:28:08] Augekugel just makes the reentry range very large in this case [17:28:41] a lot larger than realistic, so that defeats the whole purpose using curve fits and such for a first guess deorbit TIG [17:28:51] because the TIG is so bad [17:29:53] so bad that the first time it goes through a fully integrated trajectory it might not even reenter at all, if the orbit is elliptical [12:55:06] good morning [12:58:16] hey Matt [13:08:53] hey [13:10:55] hey Alex [13:19:34] hey [14:31:43] these curve fits could be complicated [14:31:59] it's basically reentry range and time as a function of EI velocity and flight-path angle [14:32:18] for each kind of entry profile [14:32:26] max and min lift for example [14:33:16] but you can't just simulate reentries in the total range of velocities and angles [14:33:30] because a bunch of combinations are outside the entry corridor [14:33:51] the strange thing is, I have a document with coefficients that potentially could already be these curve fits [14:34:05] but I don't have the equations that go together with the coefficients :D [17:11:35] how many terms/coefficients? [17:16:58] https://web.archive.org/web/20100523174825/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740074552_1974074552.pdf [17:17:17] Table I is reentry angle as a function of velocity [17:17:29] I know the RTE calculates it as a parabolic interpolation of those numbers [17:17:36] so no lengthy polynomial [17:17:55] second page of table II and table III are for calculating reentry range, crossrange and time [17:18:11] but what the numbers on the first page of table II are for is a mystery to me [17:21:07] https://archive.org/details/scans_171.png/page/n231/mode/2up?view=theater [17:21:23] here are some of the same numbers from the known tables and the function that uses them [17:35:08] morning! [17:44:49] hey Mike [17:45:14] I launched Apollo 7 to replace scenarios and some MCC work, but of course got a bit distracted again [18:02:54] of course :D [18:04:28] recovery zone display [18:05:06] I already implemented the recovery target display, which lets you input a longitude and it gives you the time and latitude and so on, on the groundtrack [18:05:20] recovery zones are contingency zones, not a normal landing zone [18:05:27] usually there was a ship at the center of it [18:05:44] the display even has a bearing from the center of the zone to the closest approach [18:06:08] so that's a number you could give quickly to the ship in cases the CM is coming down there [18:08:10] I think that is how they actually generated the lat/long for the block data, one contingency deorbit opportunity on each orbit [18:08:28] not targeting a longitude like coming back to the Moon [18:08:40] but just the closest landing point available to a recovery ship [18:25:41] oh that's cool [18:25:46] sounds like quite a distraction haha [18:26:54] nah, shouldn't be that big of a project [18:27:04] I saw before even starting to implement the display itself [18:27:06] say* [18:33:08] hehehe [19:51:27] cya