[16:30:07] NASSP Logging has been started by indy91 [16:30:09] hey [17:16:38] hi [17:17:18] what's up? [17:21:26] having some trouble with reading comprehension :D [17:27:32] https://archive.org/details/70fm26images/page/n33/mode/2up [17:27:38] right side [17:27:42] under Remarks [17:27:47] specifically point c) [17:41:03] I think I am getting there myself [17:41:29] the function wants to call another function that determines when a specific radius is reached on a given trajectory [17:41:51] and as a sanity check it figures out if that radius is even possible [17:42:21] so if it wants to find the radius 40 Earth radii on the trajectory, then it first checks if the starting radius is higher than 40 [17:42:37] and if periapsis radius is also larger than 40, than it can of course never reach 40 [17:42:56] can't get lower than periapsis [17:45:11] yes [17:45:21] and it only needs to do the check if the initial position is even larger than 40 [17:45:27] that is a very easy check, so they do it [17:45:45] not 100% necessary but reduces the cases where it even needs to check [17:46:09] and then the same applies to the Moon, except with 10 e.r. [17:46:31] before, I returned an error condition for all input positions greater than 40 [17:46:36] but that isn't right [17:46:51] this is the patched conics function [17:47:13] there are cases where you are further than 40 e.r. away from the Earth and you still haven't reached the patch point [17:48:26] sadly none of this really makes sense [17:48:29] because [17:48:49] "Subroutine RBETA is restricted to cases in which the desired radius magnitude is greater than the initial magnitude" [17:49:32] so it can't even find the right crossing of 40 e.r. if it is just beyond that point, it finds a different crossing much later... [17:49:51] but I think I can solve it. I just let it use the initial position as the guess for the patch point [17:50:04] seems to work fine, as the patch point will be not much beyond that [17:50:36] this conic patching function has given me so much trouble ever since I implemented it. Not surprised I found another cases where it failed [18:39:08] morning! [18:44:40] hey [18:44:57] what's up? [18:46:32] so in Comanche 45R2, the logic to null the initial attitude error in the TVC DAP is completely skipped, right? [18:46:38] it exists, but isn't used [18:46:43] for neither CSM or CSM/LM [18:46:43] correct [18:46:59] ok, that is what I saw during the evasive maneuver [19:02:08] hmm [19:03:18] so, Apollo 10. With our TLI presettings we used have the problem that we arrive 15 minutes late at the Moon [19:03:41] and when you skip MCC-1 then it is even 10 minutes more [19:04:06] maybe I never tested the "new" TLMCC processor with Apollo 10 [19:04:20] but it gives results much closer to expected from flight plan and SCOT [19:05:12] MCC-1 is not nominally zero for Apollo 10, because they wanted to shift the approach azimuth to the landing site to be the same as Apollo 11 [19:05:38] SCOT has 56 ft/s, flight plan 57, and the RTCC MFD now has 58 [19:05:45] and only 5 minutes late at LOI [19:05:56] the real mission however did skip MCC-1 [19:06:07] and MCC-2 was only 48.7 ft/s [19:06:18] that would be 64.9 ft/s for us [19:06:41] I guess I'll take being so close to the flight plan? :D [19:06:56] but it is a change, we normally skipped MCC-1 like the real mission [19:07:07] but not if it has more than 50 ft/s [19:09:08] so I'm not entirely sure if this is even good, but it at least appears close to expected, if not close to the actual mission [19:13:10] haha close to the flight plan is positive at least :P [19:14:58] hmm [19:15:06] you have the AS-506 LVOT right? [19:27:02] 506 for Apollo 11, yes [19:27:47] not 505. Restricted NTRS has it, I requested it in July 2018 and it was rejected due to ITAR [19:29:23] hmm [19:29:26] not quite right [19:29:45] the LM Data Book request was rejected due to ITAR [19:29:51] the full Data Book [19:30:17] I got some additions to it about the LM RCS back onto the public NTRS [19:30:36] for the Apollo 10 LVOT I got [19:30:38] "The document you requested is part of an agency review and not available for public distribution. We have requested a review from the issuing Center to obtain the documentation needed to distribute the document, although we cannot provide a time frame on when, or if, the document will be made publicly available. " [19:30:49] and that's the last I heard of it [19:32:14] all while the Apollo 14 LVOT is sitting happily on the public NTRS [19:32:22] and Apollo 11 was public, but isn't anymore [19:32:26] consistency! [19:37:34] lol [19:40:26] Apollo 14 /AS-509/ operational trajectory for 31 January 1971, launch window [19:40:37] launch vehicle doesn't appear there [19:40:50] and if you google for launch vehicle operational trajectory it doesn't easily come up [19:41:02] maybe that's why they didn't notice and didn't take it down [19:41:17] but then they also took down the spacecraft operational trajectories... so what do I know [22:10:35] night! [15:11:44] hey [15:18:44] hey! [15:22:35] I think you've won me over in simplifying my mess of tanks and pipes [15:23:52] haha. I don't think I would even call it a mess, just a little overcomplicated with little gain in realism [15:25:23] I think in some cases where I've eliminated numerical instability, I'm actually getting chaotic behavior [15:25:58] ouch [15:30:24] double pendulums are pretty simple, and even those lead to chaotic behavior, so it makes sense. theres 48 thermal objects that exchange heat with one another, and 36 of them contain "fluids" [15:32:04] its time to simplify [15:32:53] sounds reasonable [15:35:11] a few days ago Thespacer had some more trouble with VHF ranging, maybe you didn't see that on the forum [15:35:36] I guess I'll do more testing of it in a few days when I get to the Apollo 10 rendezvous [15:39:10] I sent him a message letting him know, it would take me a bit to circle back, but that I would get to it. [15:40:20] ah ok. Well, I might get to it first if I find a bug :D [15:41:58] did MCC-1 earlier and just passed MCC-2 which was scrubbed [15:43:05] so still some time to go until any VHF ranging [15:48:03] okay. I did look through the code, and the only thing that made sense as a possible cause of it not working is signal strength(< -122dBm). if there is a bug, its not obvious [15:49:04] yeah, I'll just do the procedures as normal and if I have any trouble I will try to find the cause. [15:49:49] there should be some handy debug strings in both csm and lem vhf code [15:53:47] right [16:07:19] hey while I'm thinking of it, how much of a task would it be to improve the resolution of the FDAIs for the vc? [16:18:08] presuming we had a better texture. [16:20:30] no idea [16:20:38] never created a texture [16:20:53] it's one of the rare ones in dds format instead of a bitmap [16:29:36] I guess I could try it. [16:35:40] 512 x 256 [16:35:44] not that many pixels [16:42:26] hard to get thin 1° lines from that. [16:43:02] wonder if Alex had given it any thought. maybe I'll wait [17:21:35] I'm sure he will be here again soon and you can talk about it [17:21:52] I hadn't even had a chance yet to tell him about my R2 gravity model plugin [17:22:05] out of all people he is probably going to be the most excited about it [18:15:13] morning! [18:16:53] hey [18:17:26] the celestial body option changes (N88) in Comanche 45 were only for P23, right? P52 didn't change? [18:17:41] The flight plan called for a test of the P52 celestial body option [18:17:47] and they did it on the real mission [18:20:24] uhhh [18:20:36] the scaling of N88 was changed everywhere [18:22:09] ok, I only let P52 point at Mars, didn't do a full P52 [18:22:13] maybe I'll do that then [18:22:37] wanted to do Jupiter and Venus like the real mission, but wasn't in a good attitude for it [18:33:08] lol okay cool [18:33:15] you scared me for a second with that question :P [18:34:36] just wondering why the flight plan had that and remembered something about N88 was changed [18:35:19] can't find a DTO about it specifically, but maybe that change is why they wanted to test the celestial body option [18:35:25] have to check if they did any in P23 [18:35:47] or no mission had tested it yet, something like that [18:37:46] oh, and did you know we haven't gotten all GSOPs from UHCL yet? [18:38:01] GUIDANCE SYSTEM OPERATIONS PLAN FOR MANNED CM ( COMMAND MODULE ) EARTH ORBITAL AND LUNAR MISSIONS USING PROGRAM COLOSSUS 2D ( COMANCHE 72 ) // SECTION 5 GUIDANCE EQUATIONS REVISION 9 * GUIDANCE NAVIGATION AND CONTROL // [18:38:10] pretty sure we didn't get this one yet [18:41:09] oh nice! [18:41:28] that could definitely be helpful for Ron haha [18:42:14] could be, yeah [18:42:28] section 3 wasn't super helpful and V79 is mostly in section 3 [18:44:35] this pandemic better stop soon then [18:46:14] https://archive.org/details/virtualagcproject is also getting lonely [18:48:44] haha yeah [18:49:02] for what it's worth I have things to scan still -- the LM simulator document and all of the Delco books [18:49:55] I just also need to move in the next couple of months so I haven't been keen on getting new scanners / breaking apart documents for scanning haha [18:54:43] right [18:55:50] plus I got that big box of Surveyor stuff and uh [18:55:58] some of the drawings are going to be harder to scan than anticipated [18:56:37] https://photos.app.goo.gl/CG7gBJefBvmPijfY9 [19:00:20] haha [19:00:52] I'm kind of interested in making a realistic Surveyor addon. We have some decent documentation for it [19:07:51] hahaha that would be cool :D [19:22:41] and then launch Apollo 12 and land near one [20:22:39] Hey guys! [20:23:19] yo [20:24:03] What's up? [20:28:31] mostly work haha [20:28:32] you? [20:30:00] Same haha. Just finished, almost put in 11 hours today. Glad to be done. [20:30:14] Might play a little bit of DCS in a bit, been getting back into that. [20:30:58] I also finish a big project on monday so should be able to make some time for NASSP again and work on the telemetry client a little bit :D [20:31:30] nice! [20:32:48] Yep, their might be a chance it actually gets published so looking forward to see if they really want to or not. [20:32:57] s/their/there [20:41:45] hey Thymo [20:42:48] hey [22:02:22] night! [17:39:34] afternoon [17:54:09] uh oh, sw34669 found our missing sim panel... [17:55:21] hey [17:56:11] alex! [17:56:22] how's it going? [17:58:08] good thanks, Im almost finished with my move across the country, been pretty hectic but now the hard part is done [17:58:23] what about you? [18:03:04] hey guys [18:04:29] AlexB_88, good news and bad news for you. [18:04:46] bad news, I'll write you an Issue on Github for the CTD caused by the ProbeVis function [18:04:55] ah yeah [18:04:59] just saw the post [18:05:07] good news, when you weren't here a lot I played around with a plugin to simulate the R2 gravity model for the Moon [18:05:08] I really should get to fixing that [18:06:01] basically it's something optional you could enable and it does an AddForce with the appropiate force to simulate the stuff that Orbiter can't simulate [18:06:20] so you would get much more realistic long term behavior of the orbit [18:06:31] AlexB_88 I'm good. been busy breaking the fuel cells for about 2 months... [18:07:53] ohh that would be nice indeed [18:08:21] you managed to implement it? [18:08:23] yes [18:08:32] I'll do a bit of cleanup and but it on Github [18:08:35] put* [18:09:00] for that to be properly implemented in NASSP I'll have to do a bunch of RTCC changes and testing though [18:09:04] n7275, haha nice. On my end Im looking forward to continuing the CM VC [18:10:07] I made a matlab script to render the gravity model (with all the coefficients from the original paper) https://gist.github.com/n7275/e7feb004921327900725fc6c64089faa [18:11:05] oh, Alex wanted to ask you something about the VC, before I have to go back to work [18:11:15] sure [18:11:30] in the same step I'll also add the J3 parameter to the Moon config, we don't simulate that so far either. We've been stuck at the Apollo 8 gravity model I guess [18:11:49] what do you think about increasing the resolution of the fdai balls [18:11:53] indy91, looking forward to try it [18:12:09] Ill also give your MFD/MCC updates a test today [18:12:14] ah nice [18:12:36] with the VC, you can zoom right in on them. would be nice to see crisp 1° markings [18:12:58] n7275, that would be desirable indeed, do you have ideas on how? [18:13:15] I guess we would need a new texture [18:14:57] https://github.com/orbiternassp/NASSP/issues/572 [18:15:15] maybe the current FDAI ball texture can be made to a higher resolution [18:15:16] has a nice and simple procedure to replicate the bug [18:15:39] yeah, right now it has a resolution of 512x256 [18:15:45] FDAI_ball.dds or so [18:15:48] so not a bitmap for once [18:15:50] indy91, sounds good, ill look at it today [18:16:00] sure [18:16:15] and hopefully it somehow also causes the bug with the missing SM panel [18:16:23] although I haven't been able to really connect the bug to that [18:16:42] but I can't think of anything else that messes with meshes in this way [18:43:04] morning! [18:44:16] yo, how's it going Mike [18:44:29] hey Mike [18:45:27] going well over here, just woke up lol [18:46:21] I have been thinking more about the anomaly fixed in LMY99 Rev 1 and have the beginnings of an idea on how to trigger it [18:48:39] oh? [18:49:00] what anomaly was that? [18:49:40] LNY-77, No takeover when Abort from P60's [18:49:50] ah right [18:50:04] I think I had tried some things a long while ago [18:50:06] or in Russ Larson's words, "software restart causes up to 163 second activity delay" [18:51:04] happens because the timers don't get reset to safe numbers during STARTSB1 [18:52:16] 163 seconds means one of the three timers TIME3-TIME5 must somehow be set to 0 [18:52:19] probably TIME5 [18:52:28] in which case the DAP would just be stuck not running at all for 163 seconds [18:52:59] fun [18:55:03] I did a mistake on my Apollo 10 mission [18:55:15] but it turned out to be an interesting and educational situation [18:55:37] during PTC over night they let the CMC be in control, with only 4 thrusters active to keep it in the deadband [18:55:42] so uncoupled thrusters [18:55:55] I ran time acceleration with that and didn't notice it firing [18:56:50] didn't notice until much later [18:57:05] becaused it perturbed the orbit. First I thought it was bad targeting or so [18:57:21] but I could see the MCC-4 DV change between 2 scenarios that are only 15 minute apart [18:57:36] and when I run the earlier of the two I can hear it firing [18:57:52] but basically it got me into a situation where MCC-3 and 4 are still getting scrubbed, but just barely [18:58:03] perilune is 66NM instead of 60 [18:58:07] it's ok up to 70 [18:58:22] apsidal shift by LOI-1 is 28° instead of maybe 5° [18:58:27] oh man [18:58:29] acceptable up to 45 [18:58:52] MCC-3 DV would be 1.7 ft/s, MCC-4 would be 6 ft/s [18:59:09] but only MCC-3 has a DV limit where you definitely do the burn [18:59:16] which is 3 ft/s, so that it's done with the SPS [18:59:52] most missions would do the 6 ft/s MCC-4, but not Apollo 10-12 [19:01:00] but this all lead me to refine the maneuver execution criteria for those burns and it seems everything will be fine [19:01:13] I'm up to shortly before LOI-1 [19:01:22] :D [19:01:27] I guess the LOI-2 TIG might be a bit off [19:01:41] as the orbit will be rotated a bit weird [19:07:03] 10x time acceleration with active, uncoupled RCS perturbs the orbit a bit, 50x depletes the RCS completely. I did that yesterday :D [19:17:17] I can manage a good solid 3x on my rig [19:18:16] in my case I am very much CPU limited [19:18:37] so as long as I am on a panel that is light on the CPU, the framerate is good [19:19:20] When I do 50x I like to use the panel with the LEB mission timer [19:19:31] light on the CPU and I have a time reference [19:19:38] no problems then [19:20:04] might or might not work for you [21:57:41] indy91, I get a [21:57:43] 19>c:\orbiter13\orbitersdk\samples\projectapollo\src_aux\dinput.h: DIRECTINPUT_VERSION undefined. Defaulting to version 0x0800 [21:58:00] when rebuilding modules, have you seen this? [21:58:04] no [21:58:36] os that a warning or error? [21:58:40] is* [21:58:41] no build errors [21:58:56] doesnt say warning either [21:59:36] saturn.h has [21:59:37] #define DIRECTINPUT_VERSION 0x0800 [22:01:08] ah, hmm [22:01:23] so in most cases it says [22:01:24] #define DIRECTINPUT_VERSION 0x0800 [22:01:25] #include "dinput.h" [22:01:28] in that order [22:01:53] but vesim.cpp has only #include "dinput.h" [22:02:27] do you know about vesim? That's a new tool by ggalfi for mapping joystick buttons [22:02:55] but I guess it's safe, it's even defaulting to the right value [22:03:02] we can ask ggalfi about it some time, but I'm not worried [22:03:15] ok [22:03:46] now ill try to re-create the behavior in the issue you posted [22:04:16] works every time [22:04:21] unlike the missing SM panel... [22:05:37] right [22:15:24] yep CTD [22:16:22] and I'm pretty sure I tested ProbeVis [22:16:30] didn't let it call that function and no CTD [22:18:03] thewonderidiot, uh oh [22:18:11] V83 behaves very weirdly [22:18:13] .... [22:18:19] a bit like when I tried Sundance in lunar orbit [22:18:26] O_o [22:19:27] what would cause that? [22:20:03] not sure [22:20:06] have to do more testing [22:20:47] we definitely didn't touch R31.agc [22:21:16] looking at the list of changes I have no clue what would affect R31 [22:21:17] hmm [22:21:18] false alarm maybe [22:21:50] was initializing the ORDEAL [22:21:56] but it didn't really compare right [22:22:14] but I was at a yaw angle of 20° [22:22:32] might have read the Orbiter HUD wrong [22:22:48] and the weird behavior was maybe by accident, it barely seemed to change the angle it showed in R3 [22:23:37] probably had a small pitch rate [22:23:51] plus, I'm near apolune in the 60x170 orbit [22:23:57] so theta would change slow even if I am inertial [22:24:13] it just triggered that memory of Sundance's V83 haha [22:25:11] yeah I think it was a false alarm [22:25:13] sorry :D [22:30:57] hahahaha [22:31:01] cool [22:31:10] I wasn't too worried, it didn't seem like a feasible thing to be broken :D [22:32:38] I just saw both a "wrong" angle and it changing in a "wrong" way [22:32:45] first I thought I had the wrong ROM loaded or so :D [22:33:12] did a P21 check which worked fine [22:36:08] also didn't like how long it took at first [22:36:16] but that is a change from Apollo 8 which I had just flown [22:36:22] PCR 665 [22:36:44] although [22:36:49] that shouldn't take longer [22:36:52] a you know what [22:36:57] it's our friend the R2 gravity model [22:37:03] which makes it take longer to do coasting [22:37:13] as compared to Apollo 8 [22:40:03] ah it's very late. Good night! [22:58:45] cya! [14:30:24] good morning [14:31:30] hey [14:37:34] dont think I told you yesterday, but I did the tank simplification for the eps cooling [14:37:43] was fairly easy [14:37:44] ah nice [14:37:49] behaves well? [14:38:20] muuuch better [14:39:14] tanks can now be bigger too, so that helps too [14:39:35] great [14:40:32] flow rates need to be tuned a bit, and I need to simulate the regen heat exchanger [14:41:15] then I think I'll be ready to fly a mission with it [14:44:41] I'd like to have a pH value for telemetry, but still not sure how to do that [14:46:22] that seems difficult to simulate [14:46:49] do we have a static version of that yet? [14:47:14] something the CWS could also use [14:47:24] and just has a nominal value for now [14:48:11] ah, even telemetry is just normal or high, not a value [14:49:49] fuelcellstatus doesn't even have a spot for it yet [14:50:53] if memory serves, the sensor is in the potable water line [14:52:22] so it should only come on if you overheat the cells (>500°F) and cause a failure [14:52:23] yes [15:00:14] we dont have a "failed" state for the cells. in the real cells, the failure mechanism is the degradation of the PTFE seals in the cell stack. when these let go, the water KOH mix, O2, and H2 all end up in the same soup..... [15:01:37] sounds like something for NASSP 12.0 to simulate [15:02:56] I dont want to simulate that. but a timer(maybe that scales with temperature?) over 520F or so. set a failed state in the fuel cell, which could set the pH high and probably increase the reactant flow rates [15:03:22] lol. 12.0 is going to be amazing. [15:04:41] for Orbiter 2042(beta) [15:13:56] optimistic to think that there will be another Orbiter version :D [15:23:23] yeah. I hope Martin is okay. [15:26:49] as I recall, between the 2006 and 2010 release he disappeared for a fairly long time. but March 2020 coincides with a lot of covid related things [17:36:06] hey I've seen the subject of video tutorials come up on the forums, and a few other places around the web. I was thinking of starting a thread there for ideas. I think it would be a fair amount of work, but I'm confident that its doable. thoughts? [18:17:26] yeah, maybe working out a structure for a video series would be a good first step [19:01:57] agreed [19:22:05] morning! [19:25:31] hey mike [19:46:23] hey [19:49:52] what's up? [19:56:58] up to LM activation with Apollo 10, will continue there tomorrow or so [19:58:15] delete the last old bits I wanted to delete [19:58:18] deleted* [19:58:31] but will still fly the whole rendezvous to test some stuff like VHF ranging [20:54:45] Evening gents [21:04:09] yo [21:14:22] hey [21:21:25] hey Thymo. what's up? [21:22:15] C programming. Being very very careful I malloc everything properly and then don't forget to free it. [21:23:34] I need to dynamically create a string to supply as a topic to an MQTT client but the operation is enqueued. So I hope the pointer I get in the callback that the operation finished is the same as I supplied it. [21:24:23] You may place your wagers on how many segfaults I'll get. [21:28:14] oh boy, that sounds like fun. I haven't dont proper C programming in ages. [21:28:29] *done [21:31:14] Yeah, it's fun but I guarantee that everyone doing this fulltime will die 5 years early. [21:34:56] haha, oh I can only imagine [21:54:56] hahaha [21:55:02] hey, I program C fulltime [21:55:18] but also using malloc/free is strictly forbidden :P [22:02:15] Don't you have to do any dynamic allocation? Or do you do it on the stack or something? [22:02:29] nope, no dynamic allocation at all [22:02:35] everything must be statically allocated or on the stack [22:05:13] night! [22:10:51] Yeah, that poses its own challenges but I suppose your use case doesn't really need a lot of dynamic stuff [22:50:07] Nice, it works and didn't segfault [22:50:21] nice :D [22:50:57] yay! [23:40:42] nevermind [23:42:12] But it did receive data over wifi -> parse to json -> send to mqtt broker. So I'm happy. [23:42:25] Just need to figure out if the library is freeing stuff for me.