[19:30:30] NASSP Logging has been started by rcflyinghokie1 [19:30:32] With all these checklist things, I think I might have to fly 7 and audit the checklist [19:31:48] 7 is the one checklist I havent had my hands on much [19:33:22] because I claimed it for myself and then didn't do much progress with it [19:33:33] My next project will be the Apollo 7 MCC [19:33:41] and that will bring a bunch of checklists changes [19:34:11] now that we have the final flight plan I am kind of thinking we should simulate the planned mission [19:34:26] although that is still quite different from the actually flown one [19:34:32] not as far as the preliminary flight plan though [19:36:08] Historically we simulated the planned missions when doing the MCC and checklist MFD [19:36:44] Doing an iteration with the final flight plan I think would be a proper next step for 7 [19:39:06] AFK fir a while guys [19:39:10] read later [19:40:01] "although that is still quite different from the actually flown one" [19:40:19] I would preffer the flown one IMHO [19:40:47] (It´s what I flew two weelks ago, right? I flew per the actual events) [19:43:49] if we do the planned mission, then deviations from the planned to the actual make sense. I'm not sure they do the other way around though [19:44:16] well our others follow the planned mission\ [19:44:24] so I think it would make sense to follow suite [19:49:43] I dont mind giving 7 a fly through/once over in the near future...unless I should wait for MCC updates [19:50:05] TurryBoeing, yeah our MCC is mostly based on the flown mission right now [19:50:38] it's just that Apollo 7 deviated quite a bit from the planned mission, more than the others (that didn't have to be aborted) [19:50:49] not just in things like returning home early like Apollo 16 [19:50:53] but in a lot of details [19:51:18] that's the main reason why it is the flown mission and not the planned one [19:51:27] in NASSP [19:52:29] they made a lot of decisions like, the SPS minimum impulse burns in a direction that was convenient for the current, actual trajectory [19:52:36] and not the direction as in the flight plan [19:53:02] Are you thinking doing the MCC based on the final flight plan? [20:10:28] yeah, I think that is a decision to make [20:11:13] keep it close to the actual mission, which isn't an exact science as we don't have all the information from the real time decision making [20:11:51] so e.g. a bunch of the SPS maneuvers rotate the orbit in an empirically derived way that is roughly like the actual mission [20:12:12] without having any exact goal for the maneuver [20:12:37] following the operational trajectory and final flight plan that would be better in that way [20:13:36] but then it will be different from the actual mission unlike a lunar mission as-planned [20:14:12] Apollo 7 SPS-3 was like 2 days earlier than planned because of some trajectory and RCS redline considerations [21:02:18] n7275: indy91 thewonderidiot Could you check if you Orbiter forum permissions are stilll ok? [21:04:51] they appear to be [21:05:10] Cool so you can move/lock threads and such? [21:08:54] I think they still need to sort my account [21:19:46] I don't think I ever had any special permissions [21:19:52] I didn't want it haha [21:20:12] haha [21:20:41] Oh I was under the impression you did. Anyway, you should have it now. If not, let me know. You won't be able to post to the release work thread otherwise. [21:21:49] it at least appears like I can post [21:22:35] You should also see an edit or delete button under each post if you wanna be extra sure [21:25:13] ah yes, I see it. [21:28:24] yeah looks like everything is still there for me [21:29:55] we should make a "NASSP Developer" forum signature graphic or something. [21:30:31] That would be super cooll [21:31:36] I know the userbar community made some NASSP bars like 15 years ago. They look a bit dated. [21:32:42] or maybe not dated enough? :P [21:35:41] ba dum chee [21:41:52] haha [21:55:51] night! [22:22:49] wonder if that person I "ticked off" will be coming back :P [22:30:16] that's gotta be one of the strangest replies I've seen in a while. [22:30:37] the more I read it, the less sense it made [22:40:56] did I miss something? [22:50:20] ah, interesting [23:29:14] Good night/afternoon, people [00:02:29] I mean i understand I said it again, but I asked on 2 separate posts in that thread to make a new one, first one he had no issue but the second I apparently ticked him off? no clue [00:22:32] yeah, no idea [03:17:38] haha, I tried making a forum signature, and oh boy...someone with actual talent should do this, not me [05:21:28] https://imgur.com/a/P9gCAyG [05:51:34] hmm [05:52:12] if I deleted wikipedia's statement that the AGC was used for the deep submergence rescue vehicle, I wonder if they would let that stand [06:06:13] why does it say that it was? [06:13:33] ahh, it just cites some random book. [06:16:12] that's a pretty big claim to only have one source [06:29:09] ...and the book doesnt even say that, not explicitly at least. I think its implying that dsrv control system was "twice as complex" based on some author's opinions on what constitutes complexity [12:27:38] Hey hey [12:28:15] hey [12:29:00] Debriefed FD4 and updated systems data column 3 for FD3, as there was a mistake for the SPS Propellant quantity [12:29:18] Maybe later I´ll debrief FD5 [12:57:42] cool. I'll take a look [14:29:41] Come back later [15:15:17] good morning [15:19:06] morning [17:15:18] hello [17:15:28] hey [17:26:08] I've opened up my PR for everyone to test [17:50:01] nice. I'll give it a try tonight [17:52:28] the moments are at 100% strength [17:52:31] drag at 5% [17:52:34] no lift simulation [18:20:01] was there lift in the version I previously tried? [18:34:38] any particular instances you think would be best to test? [18:35:54] no I never included lift [18:36:09] lift (just like the moments) have the problem that they don't work well at 90° yaw [18:36:29] the airfoils have a singularity there [18:36:58] well, at both +/- 90° pitch and yaw [18:37:06] it's two airfoil functions usually [18:37:46] rcflyinghokie, not really. CSM is the most important, maybe uncomment the debug string and try it in various attitudes [18:38:17] in saturnmesh.cpp [18:38:31] CSMAeroVertCoeff is for total drag and vertical moment coefficient [18:38:47] CSMAeroHorizCoeff just for the moment coefficient around the horizontal axis [18:38:54] I'll see if I can mess with it after work [18:39:19] or experience the drag moment at low altitude on Apollo 7/9 [18:40:05] in their orbit before the deorbit burn the moments should be bad enough that you can't really do a P52 at perigee [18:40:12] but that's what the Apollo 7 crew reported, too [18:42:06] that might be why Apollo 8 had a 100NM perigee only [18:42:09] Apollo 9* [18:43:02] Apollo 7 used 90 [18:43:11] at 90 the torque can be quite significant [18:43:19] it's the strongest at 90° pitched up or down [18:50:20] interesting [18:50:34] Will this play into lower pre TLI EPO's? [19:11:12] nah, the CSM + S-IVB has no moments yet [19:11:14] only CSM alone [19:11:29] and in the EPO attitude there are no moments [19:22:40] gotcha [21:59:37] night! [23:55:13] Hey hey [23:55:18] FD5 Debriefed! [00:01:08] Going to bed, talk tomorrow. Good night/afternoon! [10:15:33] thewonderidiot: I just watched the video on the PM receiver. I think it may have been modified for the Atmospheric Explorer missions C through E that were launched during the 70s. I haven't been able to find a source for their downlink frequencies [10:16:25] but reportedly they did use PCM telemetry. Together with the date and "AE program" on that mod sticker it seems likely it was modifed for that program. https://nssdc.gsfc.nasa.gov/nmc/spacecraft/display.action?id=1973-101A [14:53:29] good morning [14:55:23] morning [14:55:40] guess that sw guy hasnt returned to the forums since I "ticked" him off [15:51:41] I wouldn't worry about it. [15:55:45] wanted to test Nik's update but I didnt get home until 2100 last night [16:01:20] Nah I am not worried, just amused how petty keyboard warriors can be [16:51:57] hey [16:53:44] good morning [16:55:10] Thymo, that code is stolen from the Delta Glider [16:55:14] https://github.com/orbitersim/orbiter/blob/main/Src/Vessel/DeltaGlider/DeltaGlider.cpp#L110 [16:57:02] Well in that case you have made a bigger no-no by violating the MIT license :) [16:57:48] You need to preserve his copyright notice if you want to use it. [16:58:31] you will find that most Orbiter addons use this scheme for the airfoils haha [16:58:40] I have to look, maybe I just took it from our CM [16:58:47] which I modified at one point as well [16:59:02] but maybe that was already in our CM aero function long before I did anything [17:01:27] well it was a bit different [17:01:29] https://github.com/orbiternassp/NASSP/blob/3b6bf0100184e1db9f5bd5ff4f124879cd6df5ca/Orbitersdk/samples/ProjectApollo/src_saturn/Saturn5.cpp#L245 [17:02:15] but in all essential pieces already like that [17:03:03] this seems like a quite efficient way of doing it. And this function is called multiple times per timestep, needs to be as efficient as possible [17:03:17] In any case adding a comment like "The following section contains code that has been modified or copied verbatim from Orbiter. Copyright (c) Martin Schweiger" [17:03:24] Shoulld more than cover it [17:03:41] The last copyright sentence is the most important. [17:04:12] I have to check if I copied anything directly from the DG or just our CM code [17:04:32] Yep. I'mma have dinner in the mean time. brb [17:04:44] if it's our CM code then it might even be older than the Delta Glider and martins might have copied NASSP code :D [17:04:48] all speculation [17:05:17] I'd like to keep the code as it is, but I can add a comment that says what the for loop does there [17:08:13] well one variable name is like in the DG but not in our CM, so I probably did actually copy Delta Glider code and then highly modified it. [17:08:26] not one line of code is identical to the DG [17:09:06] the DG code is provided as a baseline and example for vessel development, so I think there really isn't any copyright thing going on there [17:10:19] unless you can copyright variable names. Otherwise it's totally different [17:11:12] I can rename "nabsc" to "nlift" like we have in the CM [17:11:22] then there is no remnant of DG code whatsoever [17:16:40] morning! [17:16:56] Thymo: yeah the acronym matches, but I've found a bunch of sources for their frequencies and those don't line up [17:18:51] hey Mike [17:30:41] the XRVessels have copied some DG code [17:30:47] https://github.com/dbeachy1/XRVessels/blob/main/LICENSE#L630 [17:32:22] but I can really not say this it is still DG code in my new aero functions, except for one single variable name. Everything else is different. Seems pointless to add a copyright note just for that. [17:33:37] indy91: Rewriting does not stop it being a derivative work [17:34:44] but every airfoil function will inherently look very similar [17:35:48] I could have just as well copied our CM function [17:36:02] and the result would be 100% identical except that one variable name [17:36:58] not even sure why I used the DG one. I can't really remember copying that over directly, not sure why I would have done that. [17:38:39] isnt there an example in the api reference? I think that may be identical to the DG [17:41:14] I'm not seeing any longer code example [17:43:48] haha, when I am searching for this on the Orbiter forum I find a quote [17:43:51] "Also, "nabsc" is an awful variable name." [17:46:26] clearly they haven't seen the variable names in the fortran programs we've been looking at [17:46:59] oh my main problem with that isn't the names, but that one variable can have up to 5 names [17:47:13] why only pick one name when you can have several? [17:47:21] and they get used interchangeably [17:47:26] then you don't have to make up your mind :D [17:47:29] in the code and in the IBM RTCC documents, too [17:48:19] that's one big thing I learned from that Fortran code, it's not necessarily a typo if the (probably) same variable has two different names [17:48:25] in the flowcharts [17:48:56] If you want to be nice, include the copyright header. If not, it probably falls under transformative use and you aren't legally obligated to include it. But why risk it for such a small thing IMO [17:51:24] if there was only one line of code that is still like in the DG then I would agree that copyright matters. But it really isn't. It just so happened that I used code meant as a reference as a reference. [17:51:37] I'll rename "nabsc" [17:54:19] I could delete the functions, copy our CM aero code instead (which might have been taken from some reference, too, who knows) [17:54:33] the only difference would be formatting [17:55:11] I could look if anything else in the NASSP code was too closely inspired from any Orbiter vessel reference code [17:55:33] I think then it would make sense to have something like that XR Vessel license [18:01:08] I don't know of any specific derivatives but if there's a substantial amount it sure is worth considering [18:03:11] it's probably not. NASSP is old, Orbiter is old. Both have a lot of separate development, so maybe in some version 15 years ago there was some identical code and it's now different in both. [18:03:17] So would be hard to find out [18:09:20] I'm doing a bit of formatting fixes, adding comments and changing some variable names. Should be good enough. [18:10:45] I am still confused why I would have started with the DG airfoil code, if the CM airfoil code is literally just above the CSM airfoil I added :D [18:13:37] sorry if I am a bit annoyed, but I didn't have much time for NASSP lately and I did not want to spend it on thinking about copyright... for code that comes 99% from me [18:17:53] really 100%, with DG code serving as reference and only one variable name being identical to the DG [18:21:21] hmm, why is the CSM + S-IVB airfoil function different between Saturn IB and V... [18:21:33] It was never my intention to annoy you. I'm sorry if I did. When someone says that code was stolen from X author I want to be sure it won't cause any issues. [18:21:47] true [18:21:51] my choice or word wasn't right [18:21:53] of* [18:22:10] stolen was a bit of an exaggeration haha [18:22:45] if I would have just taken the DG function and changed some numbers then everything you said would have to be done [18:25:17] I'm fully aware of that now, so absolutely no issue from me. Just had to be sure. If Matt and Ryan finish playing with the changes its an A-OK from me. :) [18:25:40] yeah I think I want to at least resolve this Saturn IB vs. V thing [18:25:49] one has an "innovation" I came up with, the other doesn't [18:26:08] normally you add two airfoils, one vertical, one horizontal [18:26:24] all define lift, drag, moment coefficients [18:26:36] that can be a bit confusing for drag. [18:26:43] Which airfoil contributes how much drag [18:27:08] I didnt get home until about 2100 last night so I didnt have time to test much. should be able tonight though [18:27:11] and the problem is also, it has singularities, at 90° relative to the airstream [18:27:54] for symmetrical craft like the CSM and S-IVB you can define a "total angle-of-attack", which is a combination of slip angle and angle-of-attack [18:28:05] singularities are a PITA [18:28:10] and use only one airfoil, and calculate drag with that [18:28:33] that's basically what the CSM Data Book provides [18:28:42] numbers for total angle of attack [18:29:15] so I let it use this [18:29:16] VECTOR3 vec; [18:29:17] v->GetAirspeedVector(FRAME_LOCAL, vec); [18:29:18] double aoa_T = acos(unit(vec).z); [18:29:32] and not use the variable aoa in the function provided by Orbiter but aoa_T instead [18:30:32] now I wonder if there is an improvement for that where I don't even need to calculate acos [18:33:55] that only works with drag as its direction is always the same [18:34:05] so not lift and moments [18:34:22] aircraft don't usually fly with a 90° slip angle [18:34:36] but the CSM+LM do during e.g. the Apollo 9 docked DPS burn [18:34:49] the "normal" angle-of-attack has a singularity there [18:34:54] just jumps around randomly [18:35:05] because it's entirely out-of-plane [18:37:00] isnt that just a dot product? [18:39:05] no need to call unit and acos, [18:39:06] the total AOA? [18:39:36] yeah [18:39:45] well GetAirspeedVector returns the actual airspeed [18:40:01] as a vector, right [18:40:03] so unit vector is needed to get the direction [18:40:58] and you are basically seeing the result of a dot product [18:41:10] GetAirspeedVector in FRAME_LOCAL is one vector [18:41:25] and the z-axis of the CSM is the other [18:41:43] dot product of that is the z component of the airspeed vector [18:41:53] and the result is the cosine of the angle [18:42:18] in one case I use a simplified model without an array of numbers [18:42:29] coefficient as a function of the cosine of the angle [18:42:34] there I don't need the acos [18:44:08] I don't know how efficient GetAirspeedVector is, but other than that the only improvement I see is defining the array as a function of the cosine of the angle and not the angle itseldf [18:47:42] cmath acos is probably faster than most solutions to not calling it. I had things backwards in my head. [18:55:18] doesn't seem to give a nicer linear interpolation when using the cosine values [18:55:32] that would have been another reason for a change [19:03:39] one thing that is more based on a feeling is that this 5% of actual drag is like we have it right now [19:03:44] I should generate some graphs to be sure [19:11:55] Thymo any other word back on the orbiter forums account stuff? [19:29:05] I reached out to him. I'll ping him if I don't hear something tomorrow/ [19:40:40] no rush at all just curious [22:05:13] Hey guys [22:05:18] How is it going? [22:24:50] Its going lol [22:25:00] Love following these debriefs [22:46:46] Nice [23:26:34] Nite folks [14:27:24] Thymo, I have a license question for you. [14:29:30] https://ntrs.nasa.gov/api/citations/20160011252/downloads/20160011252.pdf [14:29:52] what governs the matlab code in this document? [15:02:56] Hello hello [15:03:02] FD8 has been debriefed [15:03:18] It was a hard one to debrief, lots of things. [15:14:21] nice. loving these! [15:14:38] hey Ryan [15:20:12] morning [15:21:25] just answered that star check response, hopefully that makes sense TurryBoeing [15:23:17] Perfect, yeah, it makes sense [15:23:34] Great [15:23:44] I think the MCC has a default star check interval [15:24:05] I remember we had to change a few of them for some later missions to better reflect the checklists [15:24:35] EPO missions are the most irregular as I stated due to preferring to do them in shadow [15:25:22] EPO? [15:25:58] ah sorry [15:26:03] earth parking orbit [15:26:19] if you catch us using acronyms please ask if unclear lol its habit around here [15:26:41] and LEO = low earth orbit [15:26:48] LPO lunar parking orbit [15:26:55] Aha [15:27:11] And that should have been LEO missions up there in this as EPO is more for a parking orbit before TLI [15:27:55] Thymo woo the name change went through on the forum :) Thanks! [15:29:19] The same think could happen on Lunar orbit right? The sunlight might also dim stars, and I don´t know if the moon may be brighter than earth [15:29:26] *thing [15:41:03] Yes [15:42:00] LOI1/2 were done on the far side anyways so it usually stayed the same [15:42:52] Disregard that last statement I am not caffeinated enough [15:43:50] What I meant to say is, since those 2 burns and TEI were done on the far side, and they usually planned for a sunlit landing site, you normally had darkness up to the burn allowing a nominal 30 minute star check interval [17:27:57] morning! [17:52:55] hey Mike [18:43:51] what's up? [19:25:11] mostly work stuff [19:43:10] yeah, same here [20:05:38] n7275: Regarding your license question. That document is a work of NASA, a US governemt agency. Under tile 17, section 105 of the united states code any work by a US government agency is not subject to copyright and can be treated as if it was public domain. [20:05:59] That document falls under the same rule as all the AGC ropes we have. :) [20:06:28] You can assume anything coming from NTRS is public domain unless the document itself explictly states otherwise. [20:06:47] rcflyinghokie1: Glad to hear everything is in order now [20:07:34] n7275: You can also refer here: https://sti.nasa.gov/disclaimers/. [20:09:10] That does state this though: "NASA should be acknowledged as the source of its material.". So adding a link to that document where you use that should be more than enough. [21:53:41] thank you [21:54:17] I was planning on citing that document and Pines' origional paper from 1973 anyway [22:13:07] Good night guys