[14:52:00] NASSP Logging has been started by n7275 [14:52:02] good morning/afternoon [14:52:15] looks like my IRC client was just pretending to be connected again, haha [14:54:40] hey Matt [14:55:01] nice and simple PR! [14:55:06] question [14:55:11] if(Temp > CRITICAL_T[subst_type] || Temp < 0.0){return 0.0;} [14:55:15] check if temperature is below 0? [14:58:18] hmmm, I'm trying to remember why I added it. obviously that is physically impossible [14:58:52] but then elsewhere there is [14:58:53] vap_press = exp(ANTIONE_A[composition[i].subst_type]-(ANTIONE_B[composition[i].subst_type]/Temp))*1E5; [14:59:01] divide by temperature with no such check [15:05:02] that should probably have one too, and it should also probably be "Temp <= 0.0" (empty tanks could cause NaNs, I believe) [15:05:37] yeah. Just something I had noticed. Check in one place and then divide by temperature causing PTSD for Ryan and me [15:07:36] one other thing, right now h_substance::boil will call VAPENTH() up to 4 times [15:08:03] maybe there can be a temporary variable so that it only needs to call it once? [15:08:39] ah no [15:08:45] it's called in two different functions [15:08:56] was only looking at the diff [15:09:17] or [15:09:22] called twice in Condense [15:09:26] 4 times in Boil [15:10:11] yeah, I can clean that up. [15:10:21] that function is probably called a lot of times per timestep, so a bit more efficiency won't hurt [15:10:40] functionally I am sure it's all very good and well tested [15:10:48] no scenario changes required, right? [15:13:12] yeah, that's one of those cases where you *hope* the compiler knows how to inline it, but less function calls is always better. [15:13:46] Ryan has flown most of 17 with it, I have flown 10 up to DOI [15:15:35] The only thing noticable, is if you load an old scenerio, you'll get a momentary O2 flow high alarm, as the CSM ecs adds a bit more oxygen to the system [15:17:16] that even happens in reverse [15:17:29] the scenarios I got from Ryan [15:17:39] where he used the PR [15:17:55] got O2 flow high in current NASSP [15:18:07] but harmless [15:18:11] Ryan will probably make some minor adjustments to the LM ecs, for more realistic temperatures, but it's nothing even a moderate LM fanatic would notice :) [15:23:33] update pushed [15:26:59] looks more efficient [15:37:44] I have a function like this [15:37:45] void ApolloRTCCMFD::GenericGETInput(double *get, char *message) [15:37:55] it gets called like this [15:37:58] GenericGETInput(&GC->rtcc->med_k30.ChaserVectorTime, "Choose the chaser vector GET (Format: hhh:mm:ss), 0 or smaller for present time"); [15:38:13] is there any potential issue with scope of this char array? [15:38:28] should it be defined separately from the function call? [15:40:23] I'm inclined to say it's fine. char *message should be local only to ApolloRTCCMFD::GenericGETInput() [15:41:05] and what you're passing in is just a const char[N] [15:42:47] Orbiter itself uses it that way, I am just adding one more layer [15:42:48] oapiOpenInputBox ("Vtan range (km/s) [min max, or 'a' for auto]:", VtanInput, 0, 20, (void*)this); [15:42:58] my GenericGETInput does [15:43:06] oapiOpenInputBox(message, GenericGETInputBox, 0, 25, (void*)(get)); [15:43:28] maybe I'm missing something, but it looks fine to me. [15:43:31] yeah [15:43:42] it's not causing an issue, but I was just wondering [15:43:53] char arrays and me are not good friends [15:47:27] I prefer empty strings that cause a consistent CTD [15:48:19] yeah, they're a pain to work with. [15:50:05] especially when you have code that's a good mix of C++11(or newer?) and C99(or older)ish things [16:09:50] good morning [16:10:07] Looks like someone found a VC text error https://www.dropbox.com/s/x39hhu4lp5jobeo/unknown.png?dl=0 [16:14:53] uh oh [16:15:32] morning! [16:15:37] Ryan we are go on merging the systems update, right? [16:15:41] hey mike [16:28:27] I wanted to finish the CSM side flight test [16:28:42] But At TEI I have seen nothing broken [16:30:07] hey Ryan and Mike [16:30:16] yeah the PR can wait a bit longer [16:30:24] but I'm sure it's already good [16:30:39] Yeah so far I see nothing broken [16:30:52] And I am also testing it with a few of my tweaks and the CM RCS [16:31:56] there was another update from Matt, but no functional differences [16:32:04] just making the code more efficient based on my feedback [16:33:02] I also have a checklist typo fix as well [16:33:24] oh indy91, let me know what scns you want to test I have a few I bet [16:33:32] right [16:33:44] did you always command TB8 on in all missions? [16:34:01] the perfect time for a scenario would be just after the LOX dump in TB8 [16:34:14] but anything after you have commanded TB8 on would be fine [16:34:32] well, TB8 on to a few hours later at most [16:35:28] Yeah i did it per the flight plan [16:35:48] Let me go through and find a few for you [16:36:14] Have some from 14 15 16 and 17 [16:36:28] Just need to find the right ones [16:36:42] I used your Apollo 17 TLI scenario already to fly to the right point [16:36:57] but anything from 13-16 would be great [16:37:05] I really just want to test one or two more missions [16:38:13] the scenario can be from an earlier time, I just need to fly it to the right time then for testing [16:38:42] no point to trying the calculation before the LOX dump :D [17:08:35] n7275: "that's one of those cases where you *hope* the compiler knows how to inline it, but less function calls is always better." FYI, inlining doesn't cause the compiler to store intermediate results, it will just replace the jump to the function with its body. So it will still execute that function multiple times. It might do some further optimizations if your function is marked constant. [17:08:52] In fact I think your function can be marked const since it doesn't appear to change any members [17:16:49] right. I was speeking more to the jumps and stack operations. but that is very good point. no sense in calculating the same number multiple times. [17:17:29] indy91 see if this is where you need it https://www.dropbox.com/s/ju01c1cei060n0o/Apollo%2014%20-%20Launch%200009%200001%200014.scn?dl=0 [17:17:41] and yes I will change it to const, and remove the messy brackets. [17:19:30] rcflyinghokie, thanks! [17:19:46] working on finding 15 and 16 ones now [17:22:56] I get longer burn times than the actual missions [17:23:03] but otherwise it's working [17:23:03] https://www.dropbox.com/s/2f0miukw3y8bsob/Apollo%2015%20-%20Launch%200006%200001%200003%200011%200001.scn?dl=0 [17:23:41] it's probably the LOX dump [17:23:47] not enough or too much DV [17:24:39] https://www.dropbox.com/s/098tkly12dgxqx0/Apollo%2016%20-%20TDE%200007%200005%200001.scn?dl=0 [17:24:50] 250 actual 300 seconds for me [17:25:38] I guess the S-IVB needs to do its own hybrid transfer maneuver haha [17:25:44] that's why the DV is a lot in general [17:27:26] I think I did it on 13 https://www.dropbox.com/s/mfeijsflselpxmp/Apollo%2013%20-%20Launch%200003%200004%200001.scn?dl=0 [17:29:16] Apollo 15 burn time is lower than actual [17:32:23] ok first trouble in the Apollo 16 scenario [17:32:31] initial guess didn't even impact [17:32:45] but it's in TB8 [17:32:59] did you maybe already do an impact burn with that one? [17:33:18] yeah I think so [17:33:30] I'm seeing variables for it in the LVDC scenario part [17:34:39] ok, with a bit of trial and error it gets me a (second) APS maneuver [17:34:43] still would need 240 seconds [17:35:02] but I guess the S-IVB trajectory isn't the same as the real missions after the LOX dump, it seems [17:38:48] LVDC in your Apollo 13 scenario has already shut down [17:38:53] don't think it got to TB8 [17:39:12] so didn't do first APS and LOX dump [17:39:20] would need a 470 seconds maneuvers haha [17:40:26] but it worked in all cases. The only problem is that the targetings needs initial guess for burn time, pitch and yaw [17:40:41] can take a bit of trial and error [17:40:57] Ah the 13 one may have been before we changed the shutdown time [17:42:22] I should add some error handling for this [17:42:26] checks if it's already in TB8 [17:42:41] and also after the LOX burn [17:47:10] nah just TB8 [17:47:20] the LVDC could can decide to reject an uplink if it's too early [17:47:24] can* [17:51:22] would you want another 13 scn? [17:53:16] nah it's fine [17:53:24] I think the initial version of this targeting is ready [18:02:14] sounds good [18:02:30] And I have plenty of pre LM jettison ones for you as well for that targeting ;) [18:06:58] it's in the RTCC MFD under Utilities btw. [18:07:31] it's not actually a RTCC calculation, so I didn't put it in maneuver targeting [19:04:04] huh, somehow I managed to miss that the first rope modules were p/n 1003133, not 1003733 [19:04:21] and that drawing actually gives computer program assembly numbers [19:04:32] this clarifies early block I releases a *lot* [19:07:15] how early are we talking? [19:12:10] all of the Block I flight ropes were 1003733 [19:13:46] do you think you need to read a 1003133 rope? And would it even make a different for your reader? [19:13:59] it shouldn't make a difference, I hope [19:14:05] and I would love to, but I don't know where any are [19:14:22] 1003133 programs include: Eclipse, Artemis, Moonglow, and early revisions of Sunrise [19:14:37] ah right, Artemis :D [19:15:05] the names are creative, but I guess they ran out of creativity at the end [19:19:54] hehehe yeah [19:22:44] but yeah getting Eclipse would be very very cool [19:22:52] if we ever find a copy [19:48:03] Eclipse and Skylark for the beginning and the end [19:48:09] uhh well [19:48:11] Digfly [19:48:28] or whichever came later haha [19:51:50] hah yeah [19:52:19] at this point I'm starting to think Digfly didn't even have a NASA part number [19:52:23] it may have just had an AC one [19:52:31] given what else we've seen on the DFBW system [19:56:56] and if the Digfly ropes aren't in the DFBW AGC, then I don't know where the hell else we'd find them haha [19:58:08] the basement of some retired NASA F-8 pilot [20:17:27] I successfully reduced the number of lines of code for RTCC MFD I/O from 10000 to 9000 :D [20:17:54] nice! that's a pretty decent cut :D [20:18:30] yeah. Not even done yet. [20:18:45] Just with the generic input dialog boxes [20:19:05] one for GET, one for generic double, one for generic integer inputs [20:20:02] there are a lot of custom inputs where you enter multiple numbers at once [20:20:14] but a lot more than that it's always one GET or one variable [20:20:28] should have done this a lot earlier [20:20:38] I guess I am not lazy enough to be a good programmer [20:21:02] lol [20:35:47] we're gonna need some creative solutions once I start coming up with telemetry display ideas :) [20:39:12] at least those won't need many MFD buttons [20:40:11] yeah. generic output rather than generic input [20:58:30] night! [14:54:53] Good morning [15:00:37] hey [15:04:23] I went through all of the checklist MFD files and clarified uplinks from pads based on some confusion. I think it's a bit clearer now [15:51:23] hey guys [15:51:48] hey [15:52:15] great, I updated a large table in the forum with all the AGC and AGS software versions we use vs. what really was used [15:52:22] but tables are somehow broken? [15:52:40] it doesn't show the table instead it just says the text "no code has to be inserted her" [15:52:41] here* [15:55:34] strange, I'm getting the same thing. [15:55:43] I'll write a bug report [15:56:25] Thymo, I think I made the change tou requested and then forgot to push last night... [15:56:35] *you [15:57:09] n7275: Not this commit? [15:57:10] https://github.com/orbiternassp/NASSP/pull/655/commits/88441ea474cabe7686cbfc721ef25a51672984fc [15:58:05] never mind. gmail is just sending me stuff out of order again [15:58:32] Haha. I approved it, I think it can be merged if you don't have anything else to add? [15:58:48] Or do people want to test still [15:59:07] I think we wanted to wait until Ryan has finished his Apollo 17 mission with it [15:59:19] alright [16:00:39] yeah [16:00:50] no issues thus far but I want to take it to entry [16:01:08] agreed. [16:07:35] I had an idea for my DragUpdate branch. I ran a diff and the feature creep is real [16:07:50] I think I'll port most of the changes over to Orbiter2016 branch step by step [16:07:58] Especially the things that don't even have to do with drag [16:08:12] like, I wanted to uplink an IU SV on Apollo 7 [16:08:23] real Apollo 7 mission had no IU accept switch [16:08:32] and the LVDC never switches the command system on on Apollo 7 [16:09:00] so uplinks wouldn't even work. So I just enabled that (it's an EDS relay) by default for Saturn IB S-IVBs [16:09:19] and of course I did that in the DragUpdate branch while working on Apollo 7... [16:12:03] so I think I'll port over a few things like this without merging [16:12:19] until it's a more managable update [16:12:59] Thymo, it's a bit like you were talking about with the CSM CG. Realistic drag causes a lot of additional things that have to be taken into account [16:13:25] in one aspect it's not just an added complication though [16:13:40] for the CSM the drag we have right now is extremely dependent on attitude [16:13:50] basically no drag at all with the pointy end forward [16:14:02] and nearly realistic drag with the side forwards [16:14:38] caused Ryan some problems with the RTCC on Apollo 9. So that is something that needs to be fixed and not just for added realism [16:15:30] would be better to have no drag at all than that random behavior to be honest [16:44:49] morning! [16:48:46] hey Mike [16:49:03] what's up? [16:50:31] my DragUpdate branch has severe feature creep. Looking at porting over a few things (unrelated to drag) without merging [16:54:13] and you? [16:56:44] ah feature creep, the ever present danger [16:57:02] I spent a lot of time yesterday processing various documentation relevant to the rope reader [16:57:36] it's great that we have all of the procurement specs and JDCs and things from NARA, but man they are really not easily usable in the raw scan form [17:02:04] yeah [17:03:07] not easy to find what you want to know. And if you find it it's still difficult to read. [17:11:08] and the JDCs in particular when there are 4 pages in the same image are particularly annoying to process lol [17:12:43] yeah, I guess that's why you are processing them [18:39:04] if I ever meet an ocr that can distinguish between "...00D0" and "...0000" I'll be impressed. [18:40:20] hah yeah [18:49:02] Is Orbiter SVN down? [19:00:39] hmm, don't think so [19:00:48] but then even, it's not getting updated anymore [19:09:44] It gave me an error [19:23:14] Debug build also broke again it seems [19:28:07] Nevermind, a full rebuild fixed it [19:30:36] It runs like crap in the VC though, 3 FPS. I get 28 on the 2D main panel [19:44:32] I wonder if my orbit is more different than I thought for 17 [19:44:51] TEI seems a bit different than I expected [19:46:36] https://www.dropbox.com/s/34a59z6olig0m3i/Screenshot%202021-10-18%20134623.jpg?dl=0 [19:47:16] Also, I need to get a 180 0 0 orientation for TEI REFSMMAT [19:49:23] TIG is 20 minutes later than the flight plan [19:53:36] wow [19:54:35] inclination it targeted also seems wrong [19:55:16] you said the LOPC was close to desired [19:55:26] LOPC could easily change your orbit in a weird way [19:55:47] I mean I assume it was, the TIG and dVs looked very close [19:56:22] And ascent time was only 2 minutes different than the FP [19:56:53] and the TEI DV looks about right [19:57:03] so that solution is probably correct for your current trajectory [19:57:15] what's your orbit like? HA/HP= [19:57:16] ? [19:57:27] PAMFD shows 66.1x63.7 [19:57:36] that's quite high [19:58:30] the landing site altitude is like -1.95 [19:58:38] so that makes those even high I think [19:58:41] how did that happen... [19:58:45] higher* [19:59:09] N44 shows 67.6x65.1 [19:59:25] Must have been the circ burn? [19:59:38] hmm maybe, but that one was much earlier [19:59:55] at ascent it still can't have bee too far off [19:59:56] Only other burns were LOPC and LM sep [20:00:12] maybe LOPC somehow [20:00:26] sep will make it a bit higher [20:00:30] flight plan has that, too [20:00:33] 2fps [20:01:15] And what about the inclination target [20:03:55] lower than in the SCOT [20:04:40] yeah it wont even compute it for 66.5 [20:05:28] I'll take a look more tomorrow, and you are welcome to as well [20:05:29] https://www.dropbox.com/s/3tyh28b7p7wk3sr/Apollo%2017%20-%20TEI.scn?dl=0 [20:05:37] Later! [20:36:47] night! [15:46:49] hello [15:49:59] hey Matt [15:53:02] I have most of that fortran routine typed in. just need a few more lines and a program to call it. [15:53:14] ah great [15:54:16] I'm sure that equivalence thing has a really interesting integer/double scaling thing [15:54:21] thing, thing [15:54:51] looking at the values, the variable gets limited from 1 to 18 after it gets calculated [15:55:02] and I am not sure this can have been a 32 bit processor [15:55:12] or at least not a 32 bit integer [15:56:53] oh btw I wanted to ask [15:57:12] any chance the compiler they used sees preceeding zeros as an octal value or something, like C++? [15:57:16] it looks weird [15:57:35] DATA LA, LB / 0000100000000, 01771 / [15:58:14] if not the calculation basically becomes MGO = ABS(L)/100000000 + 1771 [15:58:31] and reasonable values for L are between 1 and 18 [15:58:37] for MGO* [15:58:46] well [15:58:57] I'd say below 1 is still quite common [15:59:33] MGO = ABS(L)/100000000 - 1771 of course [15:59:34] minus [16:00:02] if MGO is exactly 1 then L would be 1.772e11 [16:00:48] even if L is a double interpreted as an integer, I don't think that can be 32 bit, can it? [16:12:46] I think I need to look at the manual again [16:13:31] sure [16:13:54] oh I figured out in the Orbiter source code why I had to use twice the drag coefficient with the legacy aerodynamic model [16:14:03] I wanted CD = 2, but had to use 4 for the right amount [16:14:40] in SetCrossSections and in SetCW Orbiter calculates an intermediate variable for drag. 0.5 * area * drag coefficient [16:15:02] but then in the actual drag calculation that gets multiplied with the dynamic pressure [16:15:10] which is 0.5 * density * velocity^2 [16:15:17] so the factor 0.5 is there twice [16:15:33] normal drag force equation only has that once of course [16:15:44] oh wow haha [16:15:52] probably not intentional [16:16:09] I found a similar case with the moment visual helpers [16:16:11] but that was my first (of many) confusing moments in the DragUpdate branch [16:16:28] speaking of confusing moments lol [16:16:46] the angular state propagation uses mass normalized moment [16:16:55] moments [16:17:31] and the visual helpers read directly from these without multiplying by mass [16:19:04] ah [16:19:17] yeah I feel like I had encountered that, too, some years ago and wondered about it [16:19:35] probably when I worked on CM aerodynamics or something [16:20:07] but things like that can get fixed [16:20:13] like tables in the Orbiter Forum [16:20:56] although I bet martins really doesn't want to have to fix the legacy aero model in Orbiter [16:21:31] that would probably break a lot... [16:22:09] yeah, drag suddenly be twice as strong for a lot of addons [16:22:13] might not be a good idea [16:25:34] well, it looks like bitsavers is down at the moment... [16:25:40] http://www.bitsavers.org/pdf/ibm/360/ [16:25:52] there should be a fortran manual in there [16:26:27] I think there are mirrors [16:27:27] I had looked at some IBM 360 FORTRAN manuals, but didn't really find much about the specific behavior of EQUIVALENCE [16:28:50] sorry, Guenter [16:29:15] ah great, there are even several subversions to Fortran IV [16:32:35] and I am not sure this is a IBM 360 that was used [16:32:52] in fact the RTCC document with the equivalent function has different LA and LB values for that weird conversion [16:32:57] although I don't fully trust that [16:33:11] the descriptions and the program flow don't agree with each other [16:45:04] morning! [16:48:36] hey Mike [16:49:11] what's up? [16:51:05] porting over some things from my DragUpdate branch to the Orbiter2016 branch. The feature creep I was talking about. [16:51:11] and you? [16:52:18] making good general rope reader progress. I fully (re-?)understand what order I need to do everything in to read data out in the order haha [16:52:34] trying to decide if I want to use an FPGA or a microcontroller for this [16:54:44] ah yes, "re-understood" [16:54:51] I have had that many times [16:54:58] hehehehe [16:55:19] it's been a couple of years since the restoration and my brain has been filled up with other stuff [16:55:27] the rope circuitry got partly garbage collected :P [16:59:27] I think the biggest open question right now is how I'm going to build the... 23 different constant current sources I need [17:00:15] .ask rcflyinghokie Now that we have the A7 final flight plan do you think the current word doc should be replaced by that pdf? [17:22:53] thewonderidiot, tables in the Orbiter Forum are fixed, so I updated this: https://www.orbiter-forum.com/threads/nassp-and-a-real-agc.37240/post-558450 [17:23:57] oh nice [17:24:17] minor correction: Apollo 13's CMC had Comanche 72 Rev 3 [17:24:34] and 10 had Comanche 45 Rev 2 [17:25:03] hopefully we can get some more flight ropes in the near future :D [17:25:14] right, I had only really added the revision number where it was relevant [17:25:23] for e.g. Apollo 10 it used to be relevant [17:25:27] but not any more of course [17:27:59] I would add an asterisk to all the reconstructed versions, but the change of the difference being relevant is so small [17:28:04] chance* [17:30:25] yeah [17:39:04] I'm very excited for the day we can compare actual Comanche 67 dumps with our attempted reconstruction lol [17:39:09] and see how far off we were [17:42:56] yeah, too bad that reconstruction is so difficult [17:43:50] it would be much easier if Artemis 72 wasn't such a major rewrite [17:44:13] we might as well not even have it as far as the reconstruction is concerned [17:45:57] I like that Artemis is a major rewrite, Artemis is pretty great :D [17:46:17] oh yeah, it's an awesome program [17:46:24] but not awesome as a reconstruction reference :D [17:51:49] almost better for Skylark than for Comanche [17:59:36] hah maybe [17:59:50] that's also made "easier" by lack of known banksums, so we can't hold ourselves to accuracy there [18:34:57] you guys ever get random CTDs when switching back to checklist MFD, from another MFD? [18:44:23] hmm, don't think so [18:44:38] not that I am not getting random CTDs occasionally, but I haven't noticed that one [20:04:44] hmm I'll look into it a bit further on my end then [20:04:53] also: https://twitter.com/bitsavers/status/1450533759426523139?t=ihZ8uo--dLpTixTktcmGkg&s=19 [20:24:16] ah [20:42:55] night! [21:25:56] n7275: Sometimes. I think so far I was always paused when I go tone [14:55:20] hey Niklas [14:55:42] good afternoon [15:03:38] I feel dumb for asking, but what is the best "keyboard only" attitude control solution for the LM? [15:05:04] it's been way to long since I flew the LM part of any mission [15:05:06] left ACA/4 Jet to disable for sure [15:05:37] otherwise you command hardover the entire time [15:05:55] and you might also want to reduce the ACA rate in V48 [15:06:10] it has 20°/s and 4°/s as options for full ACA deflection [15:06:29] 4°/s is better for keyboard [15:07:01] but ACA/4 jet is the most important switch [15:42:13] ahh okay. thanks [17:05:50] morning! [17:10:09] hey Mike [17:10:37] what's up? [17:11:07] work...mostly and messing with ctss over telnet. [17:11:48] hehehe [17:17:33] hey Mike [17:41:12] porting over parts of the DragUpdate branch is slow work and probably not the way it's intended to be done in git [17:41:31] but it works for me haha. Only way to eventually ge that fully merged. [17:42:36] yeah I can see it being hard to separate what you want from the creep the intended way [17:56:43] I have some fuel cell code that is still caught in old-branch-limbo that I should eventually resurrect [18:31:39] I think I found a solution for my current source problem last night [18:32:13] I've been struggling to find a modern component that can generate 450mA +/- 5mA with a nice controlled 700ns rise time [18:32:31] because I'd really rather not build the rope drivers out of completely discrete parts unless I have to [18:32:52] but I found this article, and it is very clever: https://www.maximintegrated.com/en/design/technical-documents/app-notes/4/4404.html [18:40:16] so the solution is basically... Ohm's law [19:12:59] hey Ryan [19:16:21] afternoon [19:16:45]