[14:31:00] NASSP Logging has been started by n7275 [14:31:02] good morning [14:50:39] hey [15:57:59] hey [16:06:17] hey Niklas [16:08:37] I found something out about PTC REFSMMATs [16:08:48] I had to fix something there for the coordinate system change [16:09:10] you painstakingly figured out the correct times to get the mission specific REFSMMATs [16:09:35] that calculates the direction from Earth to Moon basically [16:10:05] what I found out was they basically used this as an angle, the phase of the Moon, and rounded it to the next 10 degrees [16:10:25] so it's rounded value like that for all Apollo 10-17 PTC REFSMMATs [16:10:41] not sure I can immediately make use of that information, but there you go :D [16:10:57] oh interesting [16:11:20] PTC REFSMMAT consists of two rotations [16:11:35] this and the other is fairly obviously rotating it into the ecliptic [16:11:52] so that it points right at the Sun at 90° pitch [16:12:34] ah interesting [16:13:02] for now I kept the current logic to calculate it and just added the conversion from old to new coordinates [16:13:36] but I might change it eventually [16:13:52] would still be a time input I guess [16:14:00] but it would round it as an angle [16:14:17] so that even an hour earlier or later input gives the same REFSMMAT [16:30:54] morning! [16:37:00] indy91, I want to talk about U31,7402 when you get a chance [16:37:27] I have spent a lot of time fighting with it and it is winning [16:39:08] hey Mike [16:39:11] oh no [16:39:34] oh that, what I thought might be Earth rotational rate [16:39:50] I think that's what it is too! [16:40:04] but I can't figure out the scale [16:40:09] or units or whatever [16:41:02] LAT-LONG takes in TET in MPAC when called https://github.com/thewonderidiot/virtualagc/blob/Corona261/Corona261/LATITUDE-LONGITUDE_SUBROUTINES.agc#L174 [16:41:06] immediately stores TET into LONG [16:41:22] and then after calculating LAT, calculates (TET - 0.01) * U31,7402 [16:41:47] and uses that to calculate longitude [16:42:08] it's the only time-varying thing so it must be the earth rotation rate [16:42:40] presumably with weeks as the time unit since we worked out that TET is in weeks [16:43:42] ...would this be using sidereal days? maybe that's where I'm going wrong [16:44:54] hmm probably not [16:45:14] why the 0.01 [16:45:24] that is also a mystery :D [16:45:30] if the unit is weeks that's 1.68 hours [16:45:33] quite a lot [16:46:23] could be some arbitrary Greenwich hour angle or something [16:46:34] ah no [16:46:50] then it would be added after the multiplication with rotational rate [16:46:56] so it's a time [16:47:13] an epoch? [16:47:23] like, that's the zero time for the lat/long conversion [16:47:37] possible [16:48:32] I need to write a program that brute forces figuring out scaling [16:48:38] hahaha [16:48:45] you give it the octal and an expected value [16:48:51] that would be awesome [16:48:52] and any factors that could be used [16:48:55] like 2, 100, pi [16:49:11] surely there's a 7 somewhere in there for this one, to deal with the weeks [16:49:42] only if it has to convert to days [16:50:07] how is TET initialized? [16:50:27] ah [16:50:32] INITTET 2DEC .077494159 [16:50:42] if you use V37E 17E to set up the default parking orbit, yeah [16:53:05] not a very nice round value [16:53:58] no, it is quite arbitrary :D [17:11:08] the other thing that I've been thinking about is an SGA memo I found last night [17:11:29] https://www.ibiblio.org/apollo/Documents/SGA_Memo34_640820.pdf [17:12:06] lacking star vectors and with just a small possibly landmark table we don't understand -- maybe it's doing something like this? [17:15:47] yeah that looks kind of similar [17:16:14] I just wished U24,7361 gave nice landmarks [17:18:43] maybe it has some term in its longitude making it inertial or something [17:18:57] then only the latitude would be correct without a conversion [17:20:38] yeah, that's why I was hoping we could figure out U31,7402 and that 0.01 [17:21:34] like if we knew the "time" of those vectors, we could feed them into LAT-LONG and see what it spits out [17:26:35] they could be like the AS-202 splashdown points, inertial from liftoff [17:27:23] why do you need a lat-long subroutine then though :D [17:27:52] hehehe [17:28:11] to your point, we could plot all three on a map, and then adjust their longitude until all three happen to land on interesting features [17:28:19] if there is such a longitude that exists, surely there aren't many [17:28:33] er, such an offset I guess [17:29:12] yeah I've been starting to manually look for that and don't find them particularly interesting really [17:29:22] not even the latitudes by themselves [17:29:57] hmmmmm [17:29:58] they would fly over them for sure from a KSC launch [17:30:05] so they aren't unlikely to be reached [17:34:50] the first one is pretty close in latitude to landmark 50, in the Bahamas [18:24:01] was trying to debug some coordinate stuff, just after Apollo 11 MCC-2. Compared against PAMFD/Map MFD and got different values [18:24:12] why do they switch to Moon reference so early!! [18:24:21] need to fix that, at least for the PAMFD [18:24:43] it shows latitude/longitude/altitude for the strongest gravitational influence [18:24:52] usually Earth, then the Sun for a bit and finally the Moon [18:24:58] but not usually the Moon so early... [18:25:19] But I can make it so that it conforms to the sphere of influence used by the RTCC [18:25:41] within 9 Earth radii of the Moon, it's the Moon. Otherwise Earth. Never the Sun. [18:28:00] oh [18:28:09] you can't actually easily change that [18:28:24] PAMFD calls Orbiter API functions for this [18:28:29] which just use the closest body [19:19:37] isn't there an oapi function for GravReference or something like that? [19:19:50] strongest gravity source [19:38:57] yes, GetGravityRef() [19:39:07] it's a bit confusing what the PAMFD does [19:40:03] it uses that API call for displaying velocity and the reference radius for apoapsis/periapsis height [19:40:30] but for lat/long/alt it calls GetEquPos [19:40:56] "Returns vessel's current equatorial position with respect to the closest planet or moon." [19:41:12] so I am pretty sure it shows a mixed set of values somewhere in cislunar space [19:41:20] lat/long/alt are already for the Moon [19:41:27] other parameters maybe Earth, or the Sun [20:10:14] thewonderidiot, haha, I didn't know the restricted NTRS had this [20:10:17] 19740085852 Revision 2 to the Apollo 9 spacecraft operational trajectory. Volume 1: Mission profile 1969 [20:10:20] revision 2 [20:10:24] the actual final one [20:10:27] not available [20:10:38] of course, very secret, as opposed to revision 1 [20:11:08] lol amazing [20:11:49] or I guess they potentially had added this to the public NTRS after the mass archiving was stopped [20:12:05] archiving by archive.org and such [20:12:48] There was a period of 1-2 years, maybe more, when that was prohibited but the great purge hadn't happened yet [20:13:07] 2011 to 2013 I guess [20:13:11] right [20:13:22] the dark ages :D [20:13:23] I definitely have a few select documents from that time period [20:13:30] because someone had saved them [20:13:38] maybe even myself already, but probably not [20:17:02] dark ages fits so well :D [20:54:06] 19750076661 Title is classified 1969 [20:54:14] not on the archived NTRS [20:54:16] surprise, surprise [20:56:21] was kind of wondering why a list of restricted NTRS documents wasn't a majority of titles classified, too [20:56:30] I guess there are at least some [21:02:31] night! [14:34:26] hey Alex [14:46:50] hey [16:05:18] hey my pipe update is done as far as I can tell, if you wanted to give it a test. [16:18:52] sure. Im in my Apollo 17 branch right now doing some tests but Ill switch to yours when I get a chance [16:18:59] anything in particular to test? [16:39:00] the goal is to have everything in the LM behave exactly the same as it did before the update. [16:39:32] CM should be fine [16:39:54] basically I'm just looking for instability or flow problems [16:51:44] morning! [16:55:25] hey Mike [21:36:54] n7275, do old scenarios work with the branch? For example can I a recent before PDI scenario for the test? [21:37:04] can I use* [22:01:46] AlexB_88, I've checked those, and most seem fine. Unfortunately because this changes valve sizes, it would be better to test with a fresh LM [22:02:29] which is a pain... [01:35:16] n7275, I did a bit of testing with the "Apollo 11 - 05 - Before S-IVB Separation T+3h15min" scenario, creating a fresh LM and activating it right there on the SIVB. I activated the ECS and took a look at things... everything looked pretty stable [01:36:12] of course its not an ideal test of it... we'll have to fly a full mission to see I guess. [01:46:44] night! [14:25:02] hey' [18:09:10] hello [20:15:59] good evening [21:00:25] hey Niklas [21:01:47] hi Niklas [21:03:59] what's up? [21:04:53] I've been looking into the LM behavior after touchdown & the "jittering" you sometimes see when landed on un-even terrain [21:06:37] Ive tried a way to "lock" the LM into a position after touchdown so firing RCS and save/reloading won't disturbed the landed state [21:07:21] works quite well in my testing branch: https://github.com/orbiternassp/NASSP/compare/Orbiter2016...jalexb88:NASSP:MakeLandedLMStable [21:08:22] it basically calculates the landed orientation right at touchdown and saves it and then forces the LM into a landed state so there isn't the jittering [21:09:35] but there is one side-effect, there can be a slight jerk as the LM snaps to the in-flight to landed state [21:09:59] but the advantage is that the LM is rock-solid on the moon on pretty much any terrain/slope [21:10:27] from the in-flight* [21:11:46] some of the code was taken from the LRV, which was itself added by Max-Q I think, some of it being from GeneralVehicle by fred18 [21:21:35] too bad we have to take actions like that [21:22:03] the only downside to this, it's probably going to break once Open Orbiter decides the current system is not so great.. [21:22:58] true [21:23:48] its definitely a hack that is ugly :D [21:25:10] but I've been looking at the touchdown points as long as Orbiter 2016 and finding that perfect balance is just so elusive lol [21:29:52] the main issue we have is that every save/loading or RCS firing (pre-ascent RCS tests) causes a few seconds of instability which slightly changes the position/direction of the LM on the moon. This means the MCC/RTCC stored position will be different, also 047/053 PAD values are invalidated. [21:31:38] position I am not worried about [21:31:50] a shift a few meters here or there won't make the difference [21:31:55] attitude is a bit more annoying [21:33:40] right [21:46:32] btw do we plan on migrating officially to Open Orbiter in the not too far future? [21:47:24] or is NASSP 8.0 release definitely an Orbiter 2016 lock? [21:48:10] not sure really :D [21:48:21] but the Orbiter 2016 route means we have to wait for a patch [21:48:26] there seems to be some things a bit unstable [21:48:33] in Open Orbiter [21:48:40] but haven't tried NASSP in it yet [21:48:53] I've tried Open Orbiter 32bit itself though [21:48:58] very nice [21:50:01] Open Orbiter 64bit, not so nice [21:50:11] the planets weren't moving how they should be... [21:52:24] right [21:52:47] I tried building an Open Orbiter environment but failed a while back [21:53:33] same [21:53:42] until I realized they have builds [21:53:46] https://github.com/orbitersim/orbiter/releases [21:54:00] haven't re-tried yet but CaptainSwag101 is flying 8 with it and that is inspiring me :D [21:54:07] ohh I didn't know [21:54:22] I guess that will make it easier [21:55:05] really the only thing stopping me from switching to XRSound is that my branch had some build warnings (not errors) I couldn't get rid of [21:55:08] do you think the RTCC in the present state can deal with Matt's lunar gravity change? [21:55:24] and switching to XRSound is nearly halfway to Open orbit [21:55:28] Orbiter* [21:56:20] I have some commented code in the RTCC to use the more advanced gravity model they had for the later missions [21:56:26] never tested it though [21:56:36] targeting for some maneuvers will have to be changed [21:56:55] short duration mission like Apollo 8 should deal with it already, even the simpler gravity model [21:57:21] ah nice [21:57:24] the LOI processor should be able to deal with it right away [21:57:56] it has some correction terms to account for the HA/HP change between LOI-2/DOI and landing [21:58:04] never tested those either though [21:58:10] they were always near zero [21:58:26] because HA/HP don't actually over time with the old gravity [21:58:32] actually change* [21:58:51] so I guess the real post LOI-2/DOI orbit can now be targeted with it? [21:59:58] in the processor for LOI yes [22:00:25] on Apollo 13 already they added an "integrated DOI" calculation to properly target that the same way that the LOI processor does it [22:00:32] but I haven't added that yet [22:01:09] I think on 11 and 12 they did this weird procedure to target LOI-2 as a CDH burn [22:01:43] with a fictitious target vehicle that is circular near the landing [22:02:02] ah interesting [22:02:17] but that wouldn't really work for us yet [22:02:43] I think just GPM the historical apo/peri should be good enogh [22:02:53] probably [22:03:04] it's also a question of where the apses are located [22:03:19] and not just how high they are [22:04:30] right [22:04:33] but long term that gravity should make things better for us [22:04:59] especially the longer missions [22:05:12] the good thing is, they never figured out the gravity during Apollo anyway [22:05:26] so we don't have to be super exact :D [22:05:30] haha [22:05:59] it will give an excuse to get MCC to spit out N69 updates :D [22:06:32] oh yes, we probably need those then [22:07:08] Just a note on 64bit OpenOrbiter, it should definitely be avoided until someone can re-create module code for Demos, Phobos, Ariel, and a few others. [22:07:49] yeah I think those mess with the gravity, right? [22:09:42] yeah, because Martin never had the source for them, the build process just copies the 32bit DLL, into the right folder. when 64bit orbiter looks at pointers to them, it gets 0s, NaNs, or random huge or small numbers back and those really mess with the propagator [22:10:00] I experienced that [22:10:13] was playing around with some planetary transfer [22:10:18] didn't go so well [22:10:25] much better in 32bit afterwards :D [22:10:33] and sometimes Phobos will show up as a gravity source between the earth and moon [22:11:06] haha [22:11:18] ok, cya guys tomorrow. Good night! [22:11:21] https://www.youtube.com/watch?v=B3S6ZECeomk [22:11:24] night [22:12:06] yeah, classic Mars physics [12:20:34] good morning [12:23:25] hey Matt [12:34:32] I need to figure out where to go next with my pipe update [12:38:07] what is left to do? [12:48:43] I have a high degree of certainty that the LM valve sizes are all updated, that was all copy and paste through ny calculator. I would really rather not update old scenerios, but there is some glycol instability in old ones under time acceleration. [12:49:14] nothin drastic, but it's noticably jumpy [12:49:27] s/nothin/nothing [12:55:35] maybe I should just make this part of the liquid update, and add a scenerio update script, to the existing script that I have [13:14:37] hey [13:26:13] hey Alex [14:34:20] hey [15:27:21] morning! [15:30:36] hey Mike [15:35:07] what's up? [15:35:13] I see you made some orbital integration discoveries? [15:35:16] flying Apollo 11 [15:36:49] I did :D [15:37:02] Sunburst to the rescue [15:38:40] ok but what is U24,7361 :D [15:40:25] actually two different tables [15:40:44] but I still think the first three must surely be landmarks [15:41:02] yeah [15:41:37] that radius with the position vector scaling can't really be a coincidence [15:42:15] could they be on the Moon? [15:43:07] I don't think so, because I now understand U31,7402 and it is definitely earth rotation rate [15:43:09] not really in the latitude band of Apollo landing sites though... [15:43:14] oh nice! [15:44:04] it is just revolutions per week scaled B-3 [15:44:33] sidereal days per solar week, 7.019.... [15:46:04] https://github.com/thewonderidiot/virtualagc/blob/Corona261/Corona261/B_VECTOR_ROUTINE.agc#L16 [15:46:08] ah [15:46:09] weird [15:46:50] so I called it WEARTH, the function that creates a rotation matrix from it EARTHMX, and U24,7361 tentatively LNDMKTAB [15:49:27] oh I also identified U31,7406 as ALTVAR, which is padloaded for Colossus [15:49:33] the hardcoded value is almost the same as what got padloaded [15:55:11] I think ALTVAR is a P20 thing [15:55:26] P-20 ALTERNATE LOS VARIANCE PAD LOAD***** [15:56:29] but I think there is also a landmark altitude variance of sort for P22/P23... [15:58:37] it's specifically the COAS angular error variance [15:58:47] aaah ok [15:58:52] yeah that's the alternate LOS [15:59:22] but I don't think there is any program to use the COAS for P22 or P23 [15:59:45] is ALTVAR in Corona even used in the midcourse navigation? [16:00:22] yeah [16:00:27] well, it's in B VECTOR [16:00:41] but compare U31,7142 and U31,7236 [16:01:09] first block is essetially the same, with one using SXTVAR and one using ALTVAR [16:02:22] SXTVAR is P22 only I am pretty sure :D [16:05:14] oh also [16:05:29] Tom Knatt responded to my email to the apollonauts mailing list [16:05:58] When I was presented with the task of writing P-23 in mid-1967, mo one ever mentioned or asked about the MID-COURSE CORRECTION GAME. I was in a corner room with Norm Brodeur, Jane Goode, and Sam Jennings. Sam had already programmed the Newtonian calculations, and I wrote the code to let the astronauts use the instrumentation and calculate the trajectory. There was concern about issues that might arise with the program running [16:06:01] ys, so care was taken in the end to insure there were no problems. [16:06:20] so he at least is not to blame for this code :P [16:06:31] so yeah, maybe this is P22 [16:08:47] indy91, in the Vector Panel Summary section of the RTCC MFD manual [16:08:51] "Pressing the TLM button will get [16:08:52] data from all computers in the vessel" [16:08:56] I wonder if bits of FFFLAGS are going to partly map onto flags used by P22... [16:09:23] does this work during powered flight as well? For example can I press that during powered descent and get a valid LGC vector? [16:11:04] nope [16:11:12] only gets the orbital integration state vectors [16:11:29] which is stored in a different location than the powered flight ones [16:12:20] powered flight state vectors are even in IMU coordinates [16:12:30] and not reference coordinates [16:12:38] we had some fun with that during the Sundance reconstruction... [16:13:00] ah [16:13:55] so say for a noun 69 update, I guess you need to put both vectors on the vector compare display right before PDI [16:15:18] or many minutes before PDI [16:15:37] we do not have the powered flight processor that calculates the N69 in real time [16:16:01] right [16:16:39] I am going to try an Apollo 17 landing in Open Orbiter if I can get it to run [16:16:48] hmm although [16:17:14] I think most of the data that lead to the N69 calculation were taken before PDI anyway [16:17:23] ground tracking after AOS [16:18:18] so you get a SV update ~15 mins before PDI [16:18:53] I guess the N69 was to account for the dispersions during that 15 mins up to PDI? [16:19:29] or maybe the SV update itself was still not fully accurate (less tracking time since AOS)? [16:24:04] this is covered in pretty good detail in the Apollo 15 navigation results document, let me check [16:27:22] the procedures they had to do were so complicated [16:27:27] for state vector biasing and N69 [16:27:41] because they never figured out a gravity model for the RTCC that really worked [16:49:59] ah ok [16:51:33] yeah I am not really sure [16:51:53] the uplinked state vector is based on tracking but then they have to do some additional biasing which leads to the N69... [16:51:56] not sure yet [16:57:27] btw you said yesterday there is commented code for the more advanced lunar gravity model, do you know exactly where that is? [17:03:06] yeah [17:03:25] right now there are really 3 trajectory integrators in my code [17:03:30] one is an old one based on the AGC [17:03:34] getting phased out [17:03:51] used in many places still, but doesn't have support for this gravity model [17:04:32] what you want to change is here [17:04:35] https://github.com/orbiternassp/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_rtccmfd/CoastNumericalIntegrator.cpp#L511 [17:04:44] and here [17:04:45] https://github.com/orbiternassp/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_rtccmfd/EnckeIntegrator.cpp#L597 [17:04:49] exact same change to both [17:06:17] you want to change GMO = 3 [17:06:27] and just uncomment the line with C[0] etc [17:06:35] I have not tested this much though [17:06:39] expect the unexpected :D [17:07:49] ok thanks a lot [17:08:52] right now targeting might not be able to account for anything interesting with it though [17:09:05] but e.g. using the MPT and generating an ephemeris should be interesting [17:09:14] and watch the HA/HP change over time [17:09:24] right [17:09:54] will that edit be used by MCC as well? [17:12:54] wherever it uses the RTCC own propagators and not the old AGC based one, yes [17:13:08] it should be using the updated one for TLMCC, LOI, TEI targeting [17:13:17] the RTCC ones* [17:13:39] GPM? [17:13:55] GPM uses the AEG which I have not made compatible with a higher gravity model [17:13:57] so sadly no [17:14:32] well I guess I would use it to simply target the nominal post LOI-2/CIRC CSM orbit [17:14:51] not circular [20:44:25] night! [14:41:20] hello [14:46:24] hey Matt [14:47:04] just did some testing with lunar gravity in OpenOrbiter [14:48:23] used my post-circ burn Apollo 17 CSM in a 70x54 orbit and watched its orbit evolve over time [14:49:49] just time accel 1000x watching the PAMFD GNC page, the orbit slowly went towards being more circular from 115:00:00 GET up to about 210:00:00 GET by which time it was about 62x58 [14:50:03] which was expected [14:51:12] and then over the next 15-20 hours upt to TEI (230:00:00) the tendency reversed and stated becoming more elliptical again, by TEI it had gone to ~75x65 [14:51:33] very cool watching it :D [14:53:16] yeah, it's very fun to play around in. [14:54:53] if you want a really crazy one, I do have a model in there for Vesta to. very realistic-lookig potato-orbit [15:01:04] ah cool [16:40:53] morning! [16:50:30] hey [16:50:36] hello! [16:51:14] hey [16:51:28] hey Niklas [16:54:43] hey, on the subject of migration to OpenOrbiter. when we get [16:55:27] around to officially doing that, it would be a great opportunity to make any changes that would benefit from a fresh install for our users [17:00:26] what do you have in mind? [17:01:29] nothing specific at the moment, more of just a general observation/note [17:02:08] indy91, if I want to simulate an impulsive maneuver with MCC? is ExecuteManeuver() with 0 mass the right way? [17:02:12] I don't think I'm getting out of making at least one more scenerio updater [17:05:17] n7275, my threshold for updating scenarios is pretty high, as long as it doesn't kill the crew and only trigger master alarms it's fine without update for me [17:05:38] AlexB_88, hmm zero could give you some divide by 0 issues. Do you have a LVLH or inertial DV= [17:05:39] ? [17:06:57] specifically, I want to simulate LOI using GET using GET_LOI and DV_LOI from the TLMCC output [17:08:01] unless the TLMCC already outputs an LOI burnout vector but I don't think so [17:09:11] it should actually write a pre maneuver state vector and a post maneuver velocity vector to a MPT transfer table [17:09:21] impulsive burn [17:10:32] you won't have any luck using the impulsive burn DV and the estimated actual TIG that is on the TLMCC display [17:11:01] ah ok [17:11:21] so either treat it as impulsive or you have to convert it to a finite burn properly [17:11:34] if you treat it as impulsive, that MPT transfer table has what you need [17:11:42] PZMCCXFR in the RTCC [17:13:51] hmm isn't that for the midcourse maneuver itslef though? [17:14:02] instead of the LOI burn [17:14:38] oh [17:14:42] yeah sorry :D [17:15:12] haha no worries :D [17:16:28] yeah the TLMCC processor does not really give you a LOI burn like you want [17:16:53] that's where the MPT would be useful haha [17:18:25] you could check the Apollo 8 MCC [17:18:49] For MCC-4 I have to calculate MCC-4 and LOI-1 to calculate the LOI-2 TIG to the get the LOI-2 REFSMMAT [17:18:56] to then* [17:20:27] right [17:25:19] I discovered a very important value to play with on Apollo 17 [17:25:27] SITEROT [17:26:18] fine-tuning that during TLC should get you a very good control of the desired post-DOI-1 orbit [17:27:16]