[16:00:56] NASSP Logging has been started by thewonderidiot [16:00:58] morning! [16:01:11] hey [16:01:14] what's up? [16:01:17] lol 50 MB operations checklist [16:01:25] I prefer your version, thank you :D [16:01:38] compared to the 1GB with most pages upside down... [16:01:54] great service for the money we get from NARA... [16:02:33] "great service we get from NARA for the money" is a better order of that sentence [16:02:41] I mean, at least this one scan is decent resolution [16:02:51] everything else we can fix :) [16:03:02] nothing we can do if they give us a bad scan [16:03:29] very true [16:03:34] NTRS is hit and miss [16:03:47] usually a good quality vs. file size tradeoff there [16:03:54] but sometimes I really needed better scans [16:04:05] yeah [16:09:31] I came up with a method to have fewer lines of code per MED processing function. Of course that means I have to rewrite a lot of code, but, I am doing this type of cleanup too rarely. [16:09:48] but for at least a few hours my NASSP won't build :D [16:10:24] oh nice! yeah cleaning things up every now and then is good :D [16:11:22] I got started on it when thinking about RTCC mission phases [16:11:42] we don't simulate that at all yet, but it's sort of relevant to some automatic processes, like the ascent rendezvous monitor display [16:12:27] RTCC had a lot of mission phases like prelaunch, launch, Earth orbit, lunar ascent etc etc [16:12:34] and in each it does different processing [16:12:46] probably the most obvious is the selection of plotboards up in the MOCR [16:13:04] either low Earth or lunar orbit maps, or the translunar coast graph [16:13:12] or during a maneuver some monitoring displays [16:21:06] so is the plan to automate more things based on the phase, that you're not currently automating? [16:23:59] probably at least for these displays. Otherwise I need a bunch of special logic to switch the processing of it on/off [16:25:48] also the state vectors supplied to it are based on the timing of the FIDO switching his Thrust switch to No Event [16:26:12] and the tweaks burns aren't calculated until he does that for the first time [16:26:27] that would be some tweak burn if it gets calculated before lunar liftoff :D [16:27:11] hahahaha interesting [16:31:59] my got-carried-away little diversion project is almost done. the only thing I'm missing for subroutine support in pyul is the list of subroutines printed as the very last page of a listing that uses them [16:33:02] oh very nice :D [17:15:43] hey guys [17:17:05] hey hey [17:17:20] n7275, I have some documents being delivered today that you might be interested in [17:18:58] two volumes of "Orbital Workshop Design Data Document" from McDonnell Douglas [17:19:00] :) [17:19:09] covering Habitability Support System, Illumination System, Refrigeration System, Stowage Systems, Thruster Attitude Control System, Orbital Workshop Systems, Atmosphere Control System, Communication System, Experiment Accommodations, Electrical System, Data Acquisition System, and Crew Accommodations System [17:19:18] I am very interested [17:20:16] I should be able to get them scanned this evening :) [17:24:32] that sounds amazing [18:26:13] hey Matt [18:27:52] let's see how badly I broke MED processing with these changes... [18:35:20] a little bit [18:38:14] 00/09/32/19.04 )GMGMED( MED P81,PRELCH; [18:38:14] 00/09/32/19.04 )GMSPHASE( PHASE CHANGE TO PRELAUNCH I [18:38:16] 00/09/32/19.04 )GMGMED( MED P81 OK [18:38:19] 00/09/32/29.13 )GMGMED( MED P92,SET,CSM; [18:38:21] 00/09/32/29.13 )GMSPHASE( CONDITION FOR LAUNCH [18:38:23] 00/09/32/29.13 )GMGMED( MED P92 OK [18:38:24] 00/09/32/39.13 )GMGMED( MED P92,CLEAR,CSM; [18:38:25] 00/09/32/39.13 )GMSPHASE( RECYCLE TO PRELAUNCH I [18:38:26] 00/09/32/39.13 )GMGMED( MED P92 OK [18:38:36] some RTCC phase switching :D [19:04:14] good that they had a MED to simulate MOCR console switch changes, also as a backup. I can just implement that instead of simulation actual switches. [19:04:24] simulating* [13:44:21] good afternoon [15:43:30] morning! [15:47:13] what's up? [15:55:22] all done with subroutines in pyul [15:55:39] so, not sure :D [16:00:36] haha nice [16:00:56] I'm getting serious on testing these new displays for the RTCC, but, still a few steps required [16:01:33] like, actually implementing the display, and not just the calculation for it... [16:01:53] hahaha that is an important step :D [16:06:19] also a step I would like to reduce the special coding for [16:06:33] every new display is so much work [16:15:36] hello [16:16:40] hey hey [16:21:38] we almost need some kind of display drawing API [16:38:50] we could call it display formatting language ;) [16:39:15] but yeah, something that makes it much easier and more importantly fewer lines of code to generate new MCC displays [17:13:15] from what I've seen of thr documentation on DRAFT it looks almost easier to use than the MFD api. bit less flexible though [17:19:09] I probably just need to get in the habit of writing little utility functions instead of doing a lot of copy and paste of display code [17:20:46] but beyond that maybe also something that simulates the background slide, anything that doesn't have to be driven dynamically can surely be done in a more efficient way than I am doing it [18:05:25] the features sure are creeping in my branch right now [18:05:46] with MED changes and display formatting in the branch for the tweak burn display :D [19:41:26] ahh feature-creep. I've heard of that :) [19:53:11] oh you've heard about it. But it happens so rarely! [19:54:51] cya! [14:09:24] hey [14:13:42] hello hello [14:40:08] exhausting day of Turry mission support :D [14:40:40] the good news is we can't ever miss a LM DOI again because this is the last mission with a LM DOI... [14:40:42] he* [14:50:43] morning! [15:00:03] hey Mike [15:04:45] what's up? [15:06:40] only really mission support for Turry today haha [15:12:18] this has been quite an RTS haha [15:13:31] mostly unrelated, I forgot if we had any more infos about later Comanche anomalies. Anything on COM 36? [15:13:54] one sec [15:15:10] yeah I have pictures of COM-36 [15:15:20] I'll put them in discord since that's easy [15:16:10] I am sure I downloaded these photos, but I don't know where to :D [15:16:46] this is my google photos album you are likely to find such things in: https://photos.app.goo.gl/wT78dHgEyEFkUsEn6 [15:18:30] yeah [15:18:35] I'm downloading the album [15:18:54] Turry had a strange backwards integration in P20, probably was just a bad manual state vector uplink [15:19:00] wasn't this anomaly at least [15:20:39] hmmm would that have been COM-21? [15:20:54] that was the backwards integration thing fixed in Comanche 72 [15:21:29] hmm [15:21:37] it was definitely in P20, not P27 [15:22:16] and not even at the start of P20, but a bit later [15:22:23] which is weird [15:22:25] the "cause" field of COM-21 says "POO integration's ten-minute loop checks only for MODREG = 0 to prevent backwards integration" [15:23:20] ...does that mean P20 could also be affected? [15:23:36] if background integration is still happening but MODREG is 20 [15:23:57] it was definitely backwards integration long into the past [15:24:03] it was at 10 hours in the past [15:24:09] but it was a time tagged state vector [15:24:15] so something could have happened [15:27:19] 1.7GB and downloading, quite the album :D [15:28:42] you can probably reduce that size by quite a bit by cutting down the resolution of all of the pictures to 25% or so [15:28:53] they're pretty high resolution from my DSLR haha [15:29:54] seems like it :D [16:20:07] cya! [15:58:17] morning! [15:59:32] hey [15:59:58] what's up? [16:00:35] feeling quite motivated to improve all my MOCR display code. Dynamically loading them, background slide of sorts, display formatting language and all this stuff [16:00:47] oooo nice :D [16:00:51] RTCC and ApolloRTCCMFD classes have gotten quite slow in VS for me [16:00:59] I think I can reduce the amount of code a lot [16:01:23] half of the answer is also to move all processors to their own classes instead of being in the RTCC class I guess [16:01:37] not sure what makes it slow, large class or large .cpp files [16:01:58] Intellisense or whatever it is called is what is slow for me [16:02:33] I also have so many structs in the RTCC [16:02:45] for data tables (these will stay) but also for displays [16:02:59] and the MFD code for one single display is also substantial. So, lots to improve haha [16:04:38] hahaha yeah that sounds like it can be broken apart a bit :D [16:05:34] of course at the start of it all will be the 10th method to implement a MOCR display [16:05:40] I have changed my mind so often [16:05:52] but this time I want to actually clean up and rewrite it all to one standard [16:39:47] hey guys [16:49:12] hey Matt [16:54:53] yo [17:14:09] one of these days I have to write my own version of the External MFD so that we can have the correct MOCR display format haha [17:45:30] testing one of the two tweak burn calculations at the same time, seems to work [17:45:52] I've build in enough error checks so that you can safely run it before lunar liftoff :D [17:45:55] doesn't converge of course haha [17:46:14] not until a few seconds before insertion really [20:26:14] night! [14:51:41] n7275, I'd like you read your technote in OO about the gravity models, is there a PDF of that somewhere or do I have to build the documentation myself? [15:01:45] http://mwhume.space/Files/gravity.pdf [15:05:06] great thanks! [15:05:31] I want to compare R2, L1 and this model using the state vector they put in the RTCC on Apollo 11 to become circular at the time of rendezvous [15:05:44] becomes very circular with R2 [15:05:49] but in reality it didn't [15:06:01] I just want to see what we theoretically get in OO [15:14:00] oh actually R2 and L1 should barely differ, L1 is mostly an improvement in the change of the orbital plane [15:14:18] I think on github, I have a C++ version outside of Orbiter. [15:14:53] PinesnormOrbiter? [15:15:04] https://github.com/n7275/PinesnormOrbiter [15:15:07] yep [15:15:09] haha [15:23:09] hmm I barely see a difference between R2 and L1 [15:23:16] in any orbital element [15:25:30] ah no, the extensions of L1 helped with the orbital plane [15:25:36] L1 was a downrange error improvement [15:25:45] maybe I see a difference in semi major axis variation [15:30:09] yep, that's the main difference [15:31:42] now to include your model in this comparison... [15:58:55] I know why it isn't, but I wished this gravity model was in spherical coordinates, then I could use the function I already have [16:07:12] morning! [16:19:16] hey Mike! [16:21:31] indy91, you could try it with the GRAIL 1200x1200 model, that should in theory be about as close to the actual moon as feasibly possible to simulate [16:25:57] https://pds-geosciences.wustl.edu/grail/grail-l-lgrs-5-rdr-v1/grail_1001/shadr/ [16:26:27] this particular one: https://pds-geosciences.wustl.edu/grail/grail-l-lgrs-5-rdr-v1/grail_1001/shadr/jggrx_1500e_sha.tab [16:26:47] --big download warning-- [16:30:16] hey Mike [16:30:30] haha thanks, but I was actually going for a model with less fidelity, simulating what typically we are (going to) use in OO [16:30:59] I found some MATLAB code in one of the sources you used to develop your model, I am going to try using that [16:36:08] DeMars? [16:36:12] et al [16:36:56] I took a lot of inspiration from that one [16:38:52] not the paper from DeMars, but apparently that's the source of the MATLAB code, so, yeah [16:41:28] I didn't want to spend that much time on this today, so, I might try the comparison another day if I don't get it to work quickly [16:43:19] I probably have the matlab code transcribed somewhere. I can look tonight [16:43:38] also, MATLAB is slow if you want good accuracy with numerical integration haha [16:44:04] I probably set the accuracy too high anyway [16:47:37] I use Octave which is matlab-compatable, but even slower [16:48:18] same. I always same MATLAB out of habit, but, I do use Octave [16:48:24] always say* [17:10:04] hmm, I have a first result, not sure I can trust it [17:11:11] https://i.imgur.com/61sLhCQ.png [17:16:07] might actually be correct, I have some Apollo 11 orbital elements [17:16:26] I see a minimum eccentricity at 115 GET and then it rises again [17:26:41] but it didn't got this low on the actual mission [17:27:02] ah well, I'll have to continue with it another day [17:39:27] I lied [17:39:29] https://i.imgur.com/gFZswvF.png [17:39:36] the first pic was 10x10 model, this one is 20x20 [17:39:40] quite the difference [17:39:44] but more what I expected [18:09:05] interesting [18:12:36] I know there is quite a bit of detail in the variations in surface pertubations, what I don't have a good feel for is how those "blur" together at higher altitudes [18:12:47] 30x30 took forever in my script, so I am cutting it off there [18:12:59] 30x30 got closer to 10x10 again, but I think it converges [18:13:15] probably a good call on your end that we use 120 terms and not 10 like the default [18:13:32] if we want to simulate the effects of all this might as well get it right [18:14:03] I really have to fly a mission in OO some time to see this all in-sim [18:14:20] somehow I am deep in a RTCC rewrite, so, who knows when that will be... [18:14:55] 120 seems like a good balance between accuracy and the really intense side of O(n^2) [18:15:24] definitely [18:15:35] you can go as high as 600-700 in realtime though [18:16:38] the effects on RTCC and N69 and such are still not as high as I once thought [18:16:58] the thing with state vectors from ground tracking is, they are based on tracking on the previous rev, leading up to lunar landing [18:17:06] I have not actually tried NASSP+OO yet. I probably should at some point... [18:17:16] while we can pull a state vector from the API at the time of uplink [18:17:48] so I am sure we get actually relevant N69 values in OO, but, still small compared to the actual missions [18:18:32] time tagged state vectors might be more important in OO [18:18:44] with RTCC using L1 and AGC using R2 model [18:20:04] I havn't really looked much into what it would take to simulate more realistic ground tracking, but hopefully (once I finish current projects) we can have telemetry that the RTCC can use at least [18:24:13] a few months ago I looked into differential correction and the maths behind it [18:24:49] I can probably come up with something there at some point [18:25:35] regarding telemetry, it always seemed a bit overkill to put full telemetry processing in-sim in the RTCC [18:25:40] but [18:26:02] also considering the problems on the current real time mission by Turry [18:26:26] I have this (too) grand idea of having a RTCC that isn't running in Orbiter [18:26:48] but is only connected through it via something like Orb::Connect [18:27:08] can receive some limited API stuff and telemetry [18:27:12] and send uplinks [18:27:24] and you could run this yourself or via TCP/IP and play mission control for someone else [18:28:12] and I would only put the "good parts" of my current RTCC in it, not the parts I am struggling to get rid of for years [20:03:20] I'm very "on the fence" about internal/external telemetry processing. [20:35:01] yeah, maybe I just like the thought of being able to have a fresh start with an external RTCC. But it would be so much work to actually do it of course. [20:35:11] night!