[13:59:20] NASSP Logging has been started by n7275 [13:59:22] hey! [13:59:28] hi [14:00:16] I've been playing around with differential equation solvers [14:00:40] wrote a few in matlab to test [14:01:51] switching to implicit euler wont fix our stability issues [14:02:13] implicit trapazoid will improve them... [14:02:50] but we'd a few hundred iterations per timestep for it to converge, so that's out [14:03:42] damn [14:04:46] piecewize analytic is definitely an option though :) [14:05:20] why implicit anyway? [14:05:33] I know it's for stiff equations [14:05:59] but we can have "some" improvement, we don't necessarily a "solves all issues" solution [14:06:04] its conditionally stable...we just dont meet those conditions [14:06:59] but yeah, anything that adds many iterations it out of question, don't need to add any more CPU load [14:07:07] rather than assuming that temperature decreases linearly per step [14:07:25] if we assume its exponential, which it is [14:08:17] than the temperature change is just newtons cooling equation, with dt as the time over which it cools/heats [14:09:08] use the temperature change to compute the energy change, then call thermic() with it [14:09:17] yeah, analytical is what I had tried for the SPS TVC as well [14:09:21] not sure why I didn't succeed [14:09:48] I think it would have been a quite large equation [14:18:34] I can only imagine [14:19:09] I'll try implanting this in the cooling class, as that's relatively contained [14:19:22] sure [14:21:07] oh, I also looked at the HGA a bit more closly [14:21:24] definitely bouncing off the scanlimit [14:23:40] I'm moderately certain this is the correct behavior [14:23:57] ah fun [14:27:37] as soon as it hits the limit, it pops back into manual mode and drives it to the manual setpoint...which in this case it's still able to acquire at [14:29:10] right [14:29:20] it's too bad there isnt a c/w light for the scan limit warning [14:30:47] I think theres telemetry for it though [14:31:16] there was a c/w light! [14:31:22] they removed it [14:31:48] in the CSM-104 Systems Handbook we have it is still present [14:31:55] Apollo 7 might have flown it, but I could never confirm it [14:32:12] very sure it's not been there on missions that actually had a HGA [14:32:31] and we used to have that light in NASSP, too [14:59:30] oh okay. how'd I miss that [15:02:44] well, it was never working [15:03:06] or maybe it was working for a commit or two [15:03:17] but then I removed it again, because it can be annoying [15:03:24] especially if it causes a master alarm [15:06:02] and then eventually I removed the light entirely, as we found out it wasn't really flown [18:26:17] I was thinking about making a visualization of the R-2 potential model, mostly for my own curiosity, and because I couldn't find one. [18:29:54] sure [18:30:05] anything you need for that? Do you have the coefficients? [18:42:38] just the coefficients I think. [18:43:44] I've programmed the AGC equations [18:44:28] https://www.ibiblio.org/apollo/Documents/HSI-208454.pdf [18:44:44] PDF page 78 [18:45:10] and that is just the disturbing acceleration [18:45:33] that plus conic is the true acceleration [18:50:02] morning! [18:56:40] hey Mike [18:59:28] what's up? [18:59:55] got my present from UHCL [19:00:19] it is the document that I thought it is. I would say it has the minimum amount of stuff in that I hoped for [19:00:51] it does have the section about uplinks that was left out in volume 2, as not much had change from the earlier version of it [19:00:57] so that is quite useful [19:01:07] oh nice! [19:01:15] no additional display formats unfortunately [19:01:24] booo [19:01:32] just, slightly different and outdated versions of displays we already have [19:01:41] in every case inferior haha [19:01:51] as it doesn't support lunar missions [19:02:29] in some cases there are more equations and explanations than in the other volume, but it could easily be misleading and not fully apply to the LLP [19:02:35] lunar landing program [19:03:00] right yeah [19:03:05] now I wonder where Volume 3 of that document went... [19:03:13] Volume 1 is ONLY in the JSC History collection [19:03:21] volume 2 is only on NTRS, or was rather [19:03:37] somewhere at NARA maybe? [19:06:49] hmm, it might be [19:06:57] it's explicitely in the corporate index [19:07:00] not [19:07:18] that corporate index is pretty meaningless really lol [19:07:23] the orginal version of Volume 1 is there [19:07:52] yeah, I think it will be quite useful to determine if NARA has any of these documents [19:08:00] I bet if it has any it could have them all [19:08:07] including all the Volumes I don't have yet [19:08:25] or more recent ones than I got from UHCL [19:09:15] and for any more display formats I'd have to find more Philco documents, also at NARA [19:10:07] too bad "PHO-TR170A" from the JSC History Collection was such a disappointment [19:10:13] that is THE document for display [19:10:24] but it only had some update sheets [19:11:16] well it was still a 300 page document haha [19:11:59] and had some useful stuff, but it was missing like 90% of the content that is in PHO-TR170A [19:12:39] this new PDF from UHCL is a new record though [19:12:48] 621 MB [19:12:51] 930 pages [19:12:58] the pages aren't a record [19:13:01] but the file size [19:13:19] they kept these documents at about 1000 pages, seems to be a general rule [19:13:27] and then split it over volumes [19:13:42] hahahaha [19:14:07] wow [19:14:08] So if NARA has everything, then I can at least tell Ron roughly how much he has to do each time :D [19:14:10] in a few years [19:15:53] at least I now know the structure of these documents better. Always seemed like a random collection of description of routines [19:16:19] and I now know that I have nothing yet from some "subsystems" of the RTCC [19:18:22] of the detailed writeups of routines [19:19:16] so out of curiosity, when you say you wonder where volume 3 went [19:19:37] do you think there were only one or a small number of this document? or are there hints that the pieces you have went together? [19:21:01] ok, this document is "Apollo Programming Series - Mission Systems - General" [19:21:13] it has general descriptions of basically everything [19:21:49] the first function program of the RTCC, Earth Orbital Rendezvous Program, is most of Volume 1 of that document [19:22:15] then they added the LMSP, Lunar Mission Simulation Program, and that together exceeded the 1000 pages [19:22:31] so some LMSP stuff ended up in a second volume [19:22:49] then they added the LLP, Lunar Landing Program, and that got to the back of the document [19:23:01] again exceeded 100 pages, so the last third of it went to a Volume 3 [19:23:07] 1000* [19:23:20] I have Volume 2 from the archived NTRS [19:23:25] volume 1 from UHCL [19:23:39] but it's really weird how they got split up [19:23:43] even worse [19:24:23] 19730062603 Apollo programming systems. Volume 2: Book - Mission systems, general 1968 [19:24:30] this is from the restricted NTRS list [19:24:38] that is the volume 2 [19:24:49] and then the fun part [19:24:50] 19730062602 Apollo programming systems. Volume 1: Book - mission systems, AS-200 systems integration 1966 [19:24:58] that is volume 1 of an entirely different document [19:25:03] 19730062604 Apollo programming systems. Volume 3: Book - Mission system, AS-200 systems integration 1968 [19:25:12] that is volume 3 of an entirely different document [19:25:17] lol [19:25:25] actually, the description on volume 1 is even wrong [19:25:33] that's not AS-200 systems integration [19:26:04] so someone along the line must have been quite confused how these documents belong together [19:26:53] I kind of suspect they found a Volume 1,2,3, moved them together and that ended up on NTRS [19:26:59] even if it didn't actually belong together [19:27:22] and UHCL only has Volume 2, so maybe the source of these documents was even the same [19:27:29] only has Volume 1* [19:27:39] Volume 1 of the general section [19:30:56] gotcha [19:31:15] UHCL has one more of this series of documents [19:31:29] but it's a AS-200 equivalent to a document I have for AS-500 [19:31:44] not terribly interesting probably [19:32:02] but it's yet again not something NTRS had [19:32:11] it's volume 2 to the NTRS volume 3 [19:32:27] so there are no documents twice if I combine NTRS and UHCL [19:34:13] yeah that is kind of suspicious lol [19:35:30] the rest got plundered when whatever library this was in was dissolved [19:36:17] JSC Technical Library I think? [19:36:32] right, sort of like the flight control computer documents I got with big "Astrionics Library" stamps on them [19:36:35] I read somewhere that they probably have microfiched all this stuff as well [19:36:44] oh yeah that is very likely [19:37:38] and the originals were sent away [19:37:43] NARA, UHCL and wherever [19:37:53] I have no idea about NTRS though [19:38:02] when it got scanned, where the originals are etc. [19:38:11] I don't think it's the same as NARA has [19:38:30] well, that applies to the internal memos at least [19:39:06] NTRS documents have a stamp on it [19:39:10] NARA ones don't [19:39:29] well [19:39:31] a different one [19:39:55] NARA has the "MPAD Report Control Copy" [20:05:04] oh cool. I'm now a page admin for our Facebook page [20:09:37] ah fun [20:13:05] how does that work. You message Facebook and if nobody disagrees you get control after a while? [20:15:15] I found an email for Tschachim [20:16:00] did you also get this: https://twitter.com/ApolloNASSP [20:17:16] oh I'll have to ask him about that too [20:21:59] I'll add you guys too in case I get hit by a bus or something [20:26:48] ok [21:31:12] ah that's fine, I'm not really active on Facebook, haven't in years [21:34:06] yeah same here, I don't think I've touched mine in over a decade lol [21:36:10] I think the last thing I did was post photos of my bathroom in university, because it was all black from a fire haha [21:37:06] hah oh jeez [21:38:04] ventilator in the wall got stuck or something and disintegrated and caused a fire [21:38:11] only a black hole was left of it [21:38:40] when we woke up in the morning the corridor was filled with smoke and the bathroom was still hot [21:38:42] we got lucky [21:38:57] wow that's crazy [21:40:19] same bathroom also had the armature in the shower break and spray water everywhere and it ran into the other rooms... [21:40:24] great maintenance in that dorm [21:41:36] yeah no kidding lol [21:41:40] how old was that building? [21:42:49] not that old really. 70s maybe. It had gotten a "renovation" just a year earlier, but I think that mainly added some insulation to the house walls [21:43:23] The problem was mostly that nobody checked on things like that ventilator [21:43:46] we had a fire detector, but it didn't work [21:44:04] the whole dorm got new ones a few days later :D [21:45:01] hahaha I would hope so! [21:45:37] That particular dorm was mostly used to house international students and those in general didn't seem to take enough care of it. [21:45:56] I guess the official people then gave it up as well to always keep the standard high [21:46:44] We also had an ant invasion. So it was like the elements were against us. Fire, Water, Earth... [21:47:03] can't remember any problem with air :D [21:57:55] night! [19:34:30] morning! [19:45:32] hey mike [19:49:02] hey guys [19:56:34] what's up? [19:57:28] flying Apollo 8 again to create scenarios. Last time, which wasn't very long ago, I was changing too much with the MCC and didn't save all necessary scenarios, so I get to do it again [19:58:41] hahaha fun [20:03:28] at least through LOI [20:03:40] haven't touched anything beyond that in the MCC [20:08:56] I found a very old pyul bug that was causing extra spacing after accepted log section cards, that threw off the tables in the back of the listing by quite a bit [20:09:17] but now at least every memory location is allocated on the right page [20:09:32] gotta give one more go through the whole listing to check per-page vertical spacing but I'm almost there [20:10:11] nice! [20:10:22] how old can pyul bugs be, if pyul isn't very old yet... [20:18:48] haha [20:19:19] well, it's been in there since before it could even print anything out [20:19:42] it just never got triggered for Solarium or Retread [20:23:32] right [20:27:43] oh man actually, I just remembered [20:27:54] Sunburst did use subroutines, but Sunburst 120 is frozen [20:28:14] so right now the assembler works for 120 but not for 37 lol [20:29:11] that seems... deficient :D [20:29:41] haha yeah [20:29:52] I think SUBRO is the last major feature I'm missing [20:30:26] and I won't be able to follow the YUL implementation exactly, since I think it was impossible to specify specific subroutine versions with it [20:30:35] hence the need for freezing [20:34:54] what does freezing mean? [20:35:23] if you provide the subdirector card [20:35:24] S FREEZE SUBROUTINES [20:35:31] after your "ASSEMBLE REVISION" command [20:36:04] YUL will copy the contents of the subroutines into your main program, and comment out the SUBRO cards that invoked them [20:36:27] so the resulting assembly will always assemble to the same thing, as a single unit, even if those subroutines change [20:37:03] I see [20:37:05] GAP solved that in a cleaner way by letting you specify subroutine revisions on the SUBRO cards [20:38:29] I think there's no reason pyul can't support both [20:38:40] right [20:40:09] like our LVDC that magically supports Apollo 9 by having some additional code hacked in [20:40:19] haha yeah [20:40:46] actually I guess I should really say that SUBRO is the last major *YUL* thing I need to support [20:40:49] I've had that many times, I can implement something exactly how it worked in reality... at that specific moment in time [20:40:59] I also need to make the whole thing able to make GAP-formatted printouts too [20:41:05] which is going to be a nightmare [20:41:17] haha I can imagine [20:41:21] conditionals for what columns to put things into everywhere [21:52:40] night! [16:53:15] hey [16:55:13] aparently I have a small bug to fix with the HGA afterall, just not with the scanlimit [17:12:02] ah, no problem [17:12:26] I was impressed that the auto tracking worked so well in its first version already [17:13:12] have you tried something with the R2 gravity model yet? [17:13:26] I haven't yet [17:13:49] I was playing around with coasting integrators, I think I "accidentally" replicated the scheme used in the Orion spacecraft... [17:14:00] oh? [17:14:39] well it wasn't really my goal, but I somehow ended up there haha [17:15:27] the AGC uses Encke's method, with time as the independent variable [17:15:45] the RTCC uses eccentric anomaly as the independent variable. I previously failed at implementing that [17:16:09] got there by using some equations from a paper about the scheme used by Orion [17:16:21] ended up much closer to Orion than the RTCC :D [17:16:26] oh that's cool [17:17:44] I found the origional paper on the development of R-2. AIAA, of which I'm a member, wants me to pay $15 just to read it... [17:18:09] do you have a link? [17:19:29] that paper about the Orion predictor had a bunch of references I couldn't find either [17:19:35] mostly JSC publications [17:20:24] https://doi.org/10.2514/3.5479 [17:30:27] enough playing around with the integrators, I have some Apollo 8 scenarios to create [17:31:57] that Encke-Beta method that the RTCC and Orion are using has better performance than Encke-Time, so I wonder why the AGC didn't use it [17:32:11] I found an memo from MIT from 1965 doing a comparison [17:34:28] although the AGC does some interesting things to make it perform better, maybe in the end it's not much of a difference [17:34:45] or the other method needs more memory or so [17:40:07] memory would make sense [17:45:38] really glad matlab has a legendre function [17:48:26] ah yeah, that is nice [18:20:25] morning! [18:21:57] hey [18:24:21] what's up? [18:32:59] hey Mike [18:33:18] playing around in MATLAB [19:09:00] always a fun time :D [19:30:53] it's better for prototyping for sure, but you don't have access to Orbiter API, and have to copy over state vectors from scenarios etc. [19:31:14] some disadvantages [19:43:01] and I was looking into the question why the AGC was using the coasting integration scheme it used, and not a similar one that is running faster [19:43:09] there is a 1965 memo comparing the two [19:43:24] any good documents where they look back at the development history of the AGC software? [19:44:04] Some Apollo Experience Report might even have something... [19:44:46] ah yes [19:48:38] really good one actually [19:48:56] about "ONBOARD NAVIGATIONAL [19:48:57] AND ALIGNMENT SOFTWARE" specifically [19:51:34] doesn't really answer the question [19:54:13] mmmm [19:54:20] there is R-700 volume V [19:54:39] http://www.ibiblio.org/apollo/hrst/archive/1137.pdf [19:54:45] it's nowhere near as good as volume III [19:58:24] I'm not sure if we really have anything that talks about why decisions like that were made [20:11:27] yeah, if that experience report I found doesn't say it, and it doesn't, then there probably isn't really a document that talks about it [22:02:15] night! [15:39:35] hey! [15:39:58] Hey [15:41:58] what's up? [15:42:48] Currently working on a UART command line for an ESP32 so I can interactively trigger stuff during the demo next week. [15:43:13] Probably also some MQTT work after I get the console up. [15:43:45] oh fun [15:44:19] Yeah, the ESP API is implemented very well. It's so nice to work with. [15:44:59] we have some home-made IOT devices that use MQTT where I work [15:45:45] Yeah it's used quite a bit in the DIY home automation scene [15:46:18] I'd like to do get into that sometime. If only I had the time. [15:50:40] Also, I got an NVMe SSD yesterday as I wanted to play DCS and it took like 10 minutes to load with my HDD at 100%. Got it down to like 2 mins with like 3% usage. It's unbelievably fast. [15:51:32] Speed is 3500MB/s. Compared to the measly 110MB/s of my spinning rust drive. [15:51:52] lol nice [15:53:54] I managed to--i think--fix the csm antenna whiparound mode, last night. [15:55:24] hey guys [15:55:31] if you roll too quickly through its "pole" it can get a little lost, so have to run some tests on how realistic that is [15:55:33] hey [15:55:35] I saw your commit in my activity feed yeah [15:55:38] Hey Nik [15:56:59] n7275, doesn't it use the third axis to avoid that? [16:00:25] it does, but there is also a feedback signal that is constantly trying to minimize B by increasing A. the balance on those may be a bit off [16:01:37] it does okay in a 5 deg/sec roll [16:01:52] I see [16:03:45] yeah, even in B-C tracking mode, over time, if you're not changing orientation, B will reduce to 0 while A increases, maintaining track [16:05:49] oh, I also got R-2 plotted last night [16:06:08] took a looooong time to compute [16:06:12] haha [16:06:21] we should do a comparison some time [16:06:35] and I have to get my plugin release ready [16:06:50] even if I can't recommend it being used yet, not for a while [16:07:30] my matlab code has four nested for loops... [16:08:00] I feel like I've committed some kind of atrocity doing that [16:08:37] can't be worse than what I am doing implementing RTCC routines from the flowcharts [16:09:00] half the lines of code are got/label :D [16:09:02] goto* [16:09:17] in some cases at least [16:09:27] but what's the for loops for? The integration? [16:10:09] The Legendre stuff? [16:10:54] the double summation accounts for 2 of them, then 2 more for a grid of latitude-longitude [16:11:32] I'm also calling legendre() m times as many as I need to [16:12:15] legendre(n,sin(phi))(m+1) is a bit wasteful [16:12:34] should probably call it once per n [16:13:10] and then access an array of each m [16:13:58] let takes an hour for a 100x200 grid, lol [16:14:09] *it [16:14:18] uff [16:14:46] what do you use for the integration? [16:17:19] oh I hadn't even made it that far, just wanted to make a contour plot of potential to start [16:17:31] ah ok, that's what I just realized, right [16:17:38] haven't done that [16:18:09] I can see how that leads to nested for loops haha [16:18:46] could do multiple altitudes if I wanted 5 [16:19:23] I guess I was mostly interested in the long term effects on orbits [16:19:48] because that is the main reason to maybe implement that in Orbiter [16:29:26] yes, definitely [16:30:11] dont see why I couldn't use ODE45 in matlab to test [16:31:29] yeah, that's what I am using as reference [16:58:05] got downlinking of the state vectors in the AGS to the RTCC working :D [17:04:31] only unsure about the time, but that's something I have never really understood about the AGS [17:20:48] I just push the buttons the checklist tells me to, and hope for the best [17:21:00] so you're a few steps ahead of me [17:21:06] haha [17:21:28] the way the AGS updates its time is weird [17:21:50] that's always why I could never come up with a good method to calculate the K-Factor [17:21:54] also why* [17:22:07] that time you use in V47 [17:22:40] that usually got updated, by a few tenths of a second at least. So they had some method to do it [17:22:57] in the AGC it is easy as there is a time register that gets updated every centisecond [17:23:13] but the AGS only updates its time register every 6 seconds... [17:26:31] How does the AGS schedule stuff then? 6 seconds is a long time to respond to things. Is there a more precise source of time in between those 6 seconds? [17:28:44] yeah, everything runs on a schedule with different time intervals [17:29:22] shortest interval is 20ms [17:29:42] I don't think any of those timers are on telemetry though [17:31:03] on telemetry there are two words [17:32:32] together double precision absolute time of the AGS [17:32:51] one is the most signiciant half, that is register 377, the same you usually check on the DEDA for the time [17:33:04] and then there is a least significant half, but that is constant [17:33:17] only changes when you initialize time [17:50:35] there is a "telemetry special computations" routine for delta time [17:51:00] unfortunately the IBM document doesn't actually tell much about it, just refers to a Philco document [17:51:05] but possible that it is related [18:09:26] morning! [18:25:53] hey [18:30:31] what's up? [18:31:51] I can "downlink" AGS state vectors to the RTCC MFD now [18:32:00] oh nice :D [18:32:09] slightly unsure about the scaling of the least significant word of the time [18:32:52] I have this [18:32:53] T_SV = (double)(timeoct[0])*2.0 + (double)(timeoct[1]) *pow(2, -16); [18:41:22] I think it has to be right [18:41:38] if I compare AGS, LGC and actual state vectors they agree closely now [18:42:50] if I compare it downrange then the time could be wrong by 0.4 seconds at most [18:45:58] and there has been no K-Factor update anyway, so it won't get more precise right now [22:01:49] night! [19:51:14] morning! [21:39:49] hey [21:51:13] what's up? [21:59:14] not too much. small bug fix. working on a little music. slow day otherwise [22:10:21] slow weekend days are nice :D [22:24:37] yeah [22:24:49] you watching SLS? [22:25:35] yup! [22:27:26] this is exciting! [22:29:23] oop [22:30:41] well, it's all still in one piece... [22:31:21] yeah, nice clean shutdown [22:38:06] https://twitter.com/waynehale/status/1350571106038657024 [22:43:08] yeah, something broke [22:44:30] rip sls schedule [22:45:58] yeah. not good. don't imagine they have too many spare RS-25s kicking around either [01:21:30] okay, some final tweaks to the assembler pushed, and I am calling Aurora done :) [01:27:33] https://gist.githubusercontent.com/thewonderidiot/e569ce6e1894a489c55e6783e14d40f1/raw/a18c216f746691bf80a90036f586f772ed458824/AURORA.R12.lst [01:27:39] full printout ^^ [01:28:00] the very first page (output from the H-1800 operating system before YUL starts up) isn't perfect but I'm not concerned about that right now [01:28:05] the YUL output should match exactly :) [03:52:55] yay! [14:58:52] morning! [14:58:56]